Microservices architecture: the case of AWS

Cloud computing has always been about abstraction and virtualization. 

One of the very first offerings was virtual servers. 

With virtual servers, the specific hardware and physical components like racks, cords, and connections were abstracted out. 

The management and configuration effort was shifted only to the software running on the servers. 

For example, in AWS, this level of abstraction is achieved with EC2, the virtual servers. As cloud service offerings increased and matured more abstraction became available in the form of containers. With containers, the specific OS software and supporting network libraries are abstracted out.
The user could now just focus on specific application components. 

In AWS, examples of services offering this level of abstraction are ECS and Elastic Beanstalk. 

ervers are still running but choices don’t have to be made about the underlying OS and supporting packages and libraries on the infrastructure. There is yet another level of abstraction available in what is often referred to as serverless. 

At this level, the language runtime itself is being abstracted out and focuses instead turned only to the individual functions performing specific tasks. 

AWS Lambda is one of the AWS services providing this level of abstraction. With Lambda, just specific code functions are what is running, only when they are needed, and without any knowledge of the servers or the OS or the language runtime configuration. 
A snippet of code that is designed to perform some process is provided and the rest is taken care of by Lambda. The two primary components of AWS Lambda are the Lambda function itself and the event source:

• The function part is simply some custom code that has been written and uploaded to the service.
• The event source is something that is capable of publishing an event that will invoke the function.

Code is written to process events and event sources publish events for processing.
The Lambda function consists of custom code and some configuration.

Event sources can be other AWS services that support publishing events or custom applications written to publish events and invoke Lambda functions. There are many AWS services that can be configured as event sources and this list will continue to grow (S3, DynamoDB, Simple Notification Service, Kinesis streams, Gateway API…). 

Microservices architecture

One common use case of Lambda is in designing what is referred to as microservices architecture.

This is typically accomplished by using the Amazon API Gateway as the event source for Lambda functions. This is referred to as an on-demand invocation of Lambda as explicit requests come into the API and then the API invokes Lambda functions. 

Another common use case for Lambda is for file or data processing by using S3 as the event source. S3 can publish events of different types such as when objects are added, updated, copied, or deleted within buckets. Using the bucket notification feature, S3 can be configured to invoke a Lambda function when one of these bucket events occur. For example, raw data being gathered from the Internet and initially placed into an S3 bucket. In this example, the raw data needs to be cleaned up and formatted before it can be used in some internal application. When the data is added to the S3 bucket, S3 triggers the object-created event, which then invokes the Lambda function. S3 knows which Lambda function to invoke based on the event source mapping that is stored in the bucket notification configuration. 
The Lambda function runs, cleans up the data, and then writes it out to a data storage to be used by some internal application. So when architecting applications on AWS, it is important to consider the level of abstraction that can be tolerated by the business use cases and application being designed. Take advantage of the virtualization options the cloud provides and consider removing as much maintenance and administrative overhead as possible.