Amazon Web Services introduced their Lambda microservices engine in 2014; and since that time AWS Lambda has been the standard microservices engine for the public cloud. As Microsoft’s Azure cloud has gained in popularity the question on my mind was: will Microsoft also create a Microservices solution?

I recently attended a Town Hall hosted by Microsoft presenting their solution for microservices in the Azure cloud. The session provided a view into Microsoft’s approach and support for this rapidly growing cloud computing technology.

At the beginning of the meeting, Microsoft spent a good deal of time on their container environment including the container types that they now support; Docker Swarm, Kubernetes, and Mesos DC/OS. As the meeting went on it became apparent that the MS container environment, along with Azure Service Fabric, was the basis for their microservices solution, but that there seemed to be no microservices engine per se.

Being that my experience is more on the AWS side of the cloud computing house I was hoping to form some comparison of Azure and AWS microservices solutions. So without providing a value judgment I will try to compare the two approaches.

AWS Lambda

AWS Lambda is a microservices engine that requires no pre-provisioning of resources other than the creation of a template for the Microservices container, including a pointer to the code to execute on activation. Lambda creates the Microservices container at event detection (events can be defined as input to a queue, creation of an object in a storage container or HTTP or mobile app request).

An obvious benefit to Lambda is AWS’ claim to have zero administration, other than the setup, configuration and maintenance of the code. In all microservices constructs, if a persistence model is required the developer is responsible for its creation. The AWS Lambda engine spins down the instance once the code execution is completed.

As part of the zero administration feature when using Lambda no availability solution needs to be defined. Even though Lambda intervenes in the process of deploying the service instance, AWS claims that any possible delay is on the order of a few milliseconds.

MS Containers

Microsoft provides no microservices engine, a la AWS Lambda. Rather, they base the solution, as stated above, on containers and orchestration.  Microsoft recommends that for each microservice a pair of primary containers be deployed, for availability. These permanent – as permanent as anything is in the cloud world – primary containers, through the use of Azure Service Fabric or a third party service construct, form a model for the creation of execution containers.

Execution containers are activated, similarly to Lambda, at event detection. The service construct will create and destruct execution containers based on the primary entities and rules configured for them. Again your own persistence model needs to be applied. While Microsoft’s solution does place some administrative burden on the user, this is slight even without a distinct engine.  

Conclusion

AWS and Microsoft present two somewhat different approaches to Microservices although at the root of the two solutions the goal is the same. Microservices computing’s goal is to provide an automated, low maintenance platform for rapid spin-up and spin-down of lightweight service instances. Service developers need to weigh aspects of these, or any other, microservices paradigms to determine the best fit for their organization and for the services under development.  Some of the aspects that should be inspected are performance, administration, ease of use, service deployment and update, and provider support.