Does serverless really mean portability?

From an architectural perspective I used to be able to call a virtual machine a container, but then containers got popular and all I did was confuse people, sorry do you mean an actual container or a conceptual one? Now we have functions running on a "serverless” platform and I find myself looking for a new word to describe the “box” that contains an application running in the cloud. So I thought, package? Granted it’s not very elegant and, in my mind at least, it could be associated with the child proof packaging that my son's toys come in that require a welder and industrial bolt cutters to access them but it’s not a bad noun! That made me think, if package is an acceptable term? Does that mean its aids transportation?

Stepping away from the techno-religious arguments around what is better/most secure/most reliable/most scalable  and focusing purely on the portability aspect I would suggest that one of the biggest differences between virtualisation, containers and serverless is the way the developer interacts with the infrastructure, and this makes serverless much more portable, consider:-

1. With a virtual machine, you still need  awareness on how to configure the hypervisor, virtual networking, the VM specification (vCPU, vRAM, vDisk etc.) and any scaling/HA capabilities. You still need to create your base images and install any supporting binaries and then build your application using whatever deployment tools you have to hand! Yes you can/should automate this but you still require a broad knowledge of IT infrastructure.
2. Containers simplify the process to a certain extent as you don’t really need to understand much about the underlying OS or virtualisation layer but you probably do need to understand how to schedule your container and anyone who’s spent time with a dockerfile will realize there are still things you need to understand at an infrastructure level but certainly less than with a VM!
3. Serverless really only cares about making sure you package your function with all its dependencies and define the triggering event and “the platform” will take care of the rest of it. It will also scale your function based on demand and its transient (existing simply to perform a function) so HA,resilience is taken care of!

As the infrastructure becomes so abstracted, platform related questions such as does it run in a container? what physical server will it run on? become irrelevant (although your security team probably will care, but that’s beyond the scope of this short article), the only thing that really matters is can the platform handle the demand in a consistent way? This level of abstraction also means cloud to cloud portability is a real possibility. For example, consider a simple python function that based on event, calculates, stores and returns a complex value and writes a message to a log with success/fail status that you want to migrate from one provider to another:-

1. In the world of virtual machines, not only would you have translate one flavor on one platform to an instance on another, you would then normally have to export the disk, convert the virtual disk image and import/mount the image all using a variety of platform API's. Now start the new instance, reconfigure your application and your ready to go as long as you've remembered to configure the right security groups and any platform specific access keys!
2. In the world of containers, you can move your container, you will probably need to adjust the application configuration and run it. You will need to understand the scheduler API (kubernetes etc.) and you might still need to modify your container config file  depending on how you're exposing or consuming service.
3. In serverless, you don’t really care about the infrastructure and if you use an IDE plugin or something like the AWS chalice “micro framework” you REALLY don’t care. You simply send your application archive to the platform, potentially configure the triggering event and away you go. You still need to understand some API's but there very much application related not infrastructure related.

There is of course some “stuff” you can’t abstract or step away from:-

• AWS lambda is clearly specific to AWS as is cloudwatch (logging) and chalice so stuff you build around these API’s or deployment process will only work with AWS
• Most serverless solutions today work with a limited number of frameworks, AWS lambda works with Node.js, Java and python only and specific versions of those frameworks whereas VM’s and containers will support pretty much anything
• You still need to monitor your app and its performance to make sure the platform is delivering what you need it to be and these will likely be provider specific
• Some level of ownership around security (shared security model) will always be required and while portability will drive value, this value needs to be managed in the context of the companies security framework

So IMO the adoption of serverless represents a great opportunity to provide true portability between clouds, allowing the engineering team to focus on building and deploying application functions (in a finite set of frameworks) without really thinking too much about the underlying cloud as long as you consider a level of abstraction around deployment API’s, application monitoring and most importantly make sure security is “baked in” to your function.

Capgemini has a wealth of experience in transforming our clients’ cloud journey. Find our latest thinking on key topics and trends on cloud business and technology here: https://www.uk.capgemini.com/expert-connect

Contact us at: https://www.uk.capgemini.com/contact-capgemini .