A comparison of Azure and AWS microservices solutions
Updated 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 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.
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.
Update June 19: I would like to thank all of those who read and commented on this article. A number of readers brought to my attention Microsoft's Azure Functions product which seems to be a direct competitor to AWS Lambda. It is curious that during a two and a half hour town hall, on microservices architecture solutions, held at Microsoft's New York conference centre the Functions product was never mentioned. Additionally, within Azure Functions' documentation, the term microservices is not referred to. I will now give a brief overview of Azure Functions.
Azure Functions is a serverless architecture for cloud computing. In Functions, container activation can be event-driven or bound to other Azure services. In much the same way as Lambda, users only pay for the resources (CPU, RAM, disk) consumed during the service execution. Additionally Azure Functions provides a Functions editor which is intended to enable rapid development and deployment of services. In the near future I will attempt to make a more in-depth comparison of Azure Functions and AWS Lambda.
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 organisation 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.
Interested in hearing industry leaders discuss subjects like this and sharing their Cyber Security & Cloud use-cases? Attend the Cyber Security & Cloud Expo World Series events with upcoming shows in Silicon Valley, London and Amsterdam to learn more.
- » Understanding Kubernetes today: Misconceptions, challenges and opportunities
- » How to solve visibility issues from AIOps: A guide
- » Confluent’s $2.5 billion valuation may provide affirmation amid open source turbulence
- » How AI can help IT teams see through the clouds of complexity
- » How new cloud agents are increasing confidence in the public cloud