Looking at Containers as a Service offering compared to other compute paradigms for cloud architectures and considering what AWS, Azure, and GCP offer.

On the 1st of December, 2020, as the world was preparing for the end of a turbulent year dominated by the COVID-19 pandemic among other things, AWS presented the cloud community with an early present. Container support for AWS Lambda functions. The ability to package and deploy Lambda functions as container images, hence allowing you to run your Lambda functions with the benefits that containers provide.

Serverless functions allowed the industry to get up and running with business code in an instant. The novel compute service provided the ability to break away from the complexity of setting up complex infrastructure and configurations, along with the scalability and related operations of running in production.

However, serverless offerings are in their current state, greatly limiting. For example, when attempting to use a programming language not supported by the serverless offering you’re using, or when typing to import libraries. AWS  Lambda layers targets this problem by allowing the user to add their required libraries and external code bases as ‘layers’ on top of your AWS Lambda function. Similarly Azure provides  Binding Extensions which is used as an open-source model for the community to build new types of bindings that can then be brought into your Azure Functions.

Unfortunately, these methods have limitations on how they may be leveraged. Hence the new container image support for AWS Lambda functions follows AWS’ goal of providing workarounds and solutions in mitigating the barriers that the cloud community is facing.

#aws #azure #serverless #lambda #kubernates #contaienrs