How To Design A Microservices App In Aws Using Lambda

Getting Started with Microservices on AWS Lambda

Microservices are a hot trend in IT architecture right now. Let's recap the definition: microservices are an architectural style that structures an application as a collection of services where each service implements different capabilities or roles.

Microservices are distributed and don't have to rely on a common central database; every microservice can use its own DB with a different data model. You can assign development, deployment, management, and operation of microservices to separate, independent teams. This allows you a great level of autonomy and operational agility. With such approach, every component is independent of one another, and you can change, upgrade and replace your microservices with no impact on the remaining microservices or components.

Each microservice aims to deliver a different set of capabilities and focuses on a specific domain. For instance, you can have a component responsible for getting thumbnails and pictures from a database and returning them to the web or mobile application. Another microservice can generate thumbnails from images uploaded to the data store. Yet another component can extract metadata from images and store them in a database. And so on…

Autonomous components and polyglot programming

The autonomy of every single component gives you the flexibility to reuse the same microservice with different applications. Each component is a single building block and it makes up an application together with other blocks. You can split components into two or more services if they become too large or complex.

In general, we can treat a single microservice as a black box that keeps its input, output, and a set of functions under the hood, hidden from other components. A well-defined API handles all communication between the services.

Monolithic vs. Microservices

If you develop a legacy, monolith application, you often have no option but to use the same programming language, same framework, same data stores, etc., across all development teams. This one-size-fits-all approach doesn't always do the trick as specific issues call for specific tools.

With microservices, it's a whole new ball game. You can develop each component on its own, with a dedicated tool that best suits it. Ultimately, it doesn't matter what's inside our black box. As individual microservices are independent of one another and can be developed by separate teams, they can employ different architectures. This gives you even more flexibility.

We call this approach polyglot persistence and polyglot programming.

The DevOps Factor

Autonomous components also have another advantage; they help companies follow the DevOps principles, where the team responsible for building a service also takes charge of operating it and maintaining in production. Each team works closely with their service across its entire lifecycle, so they know it inside out. As a result, such services are quickly developed, tested, delivered and deployed. And the quality of the code significantly increases.

AWS Lambda for greater agility

It's clear that microservices can help companies become more agile and develop software faster. But where does AWS Lambda enter the equation?

Lamba is a service that allows you to run your functions in the cloud entirely serverless and eliminates the operational complexity.

You upload your code to Lambda, and it takes care of everything required to run and scale its execution and fulfill conditions and high availability requirements.

Lambda supports several programming languages so you can choose the most suitable. It integrates with the API gateway, enables you to invoke functions with the API calls, and makes your architecture completely serverless. There are several ways to invoke a function: an event, another AWS service, or another service or application.

The figure below shows the example architecture of serverless microservices built out of managed services.

Creating AWS Lambda function

Creation of a new Lambda function is pretty straightforward. You need to choose a name for the function, create the code and specify the configuration of the execution environment to run your function:

The maximum memory, which also determines a compute power.
A timeout after which the function terminates, no matter if it has completed or not.
An IAM role to describe what your function can do and what other resources it can use.

AWS Lambda invocation types

Whatever the method for the function call (event, command line, service, API), there are two AWS Lambda invocation types, synchronous (via RequestResponse) or asynchronous.

ActiveResponse invocation type waits for a function to finish its work and return a result, while the asynchronous invocation call returns immediately without a result, and the function continues its work.

The diagram below shows the RequestResponse invocation type.

An example of such invocation can be a function searching for some value in a database and returning other values related to it. Function interprets the value to search for as an event.

The event, expressed in JSON, sends the input parameters to the function. The service uses the context to describe the execution environment and define how the event is received and processed.

In the second diagram, we can see the asynchronous invocation type.

The only difference between the two is that the second type returns no value.

When a function completes or breaks, the system retains no session information, in accordance with the stateless approach. This means that a function can be invoked, call another function and finish without returning a result, while another function can still be running.

This type of invocation is useful when the function's aim is to access or modify other resources, call another function, send a notification, etc.

How much does it cost?

In terms of pricing, Lambda charges you for some invocations and for the hundreds of milliseconds of an execution time of all invocations, depending on the memory assigned to the functions. The monthly free tier includes the first one million invocations and the first 400,000 seconds of execution time with 1 GB of memory.

Amazon API Gateway for API calls

Of course, you can invoke your function manually using the command line (aws lambda invoke) and providing specific input parameters. Still, a better option may be to replace AWS Lambda Invoke API with your own web API and avoid using AWS APIs, CLI or SDKs. You can build it by mapping access to the Lambda function to more generic HTTP URLs using Amazon API Gateway.

Let's try to implement a simple phonebook; its users will want to make a contact list, add contacts, get phone numbers, update phone numbers and delete contacts.

With Amazon API Gateway you can map access to a specific resource (URL) with the HTTP method to the invocation of a Lambda function.

A sample configuration may look like this:

Resource+HTTP method Function/phonebook+GET GetAllContacts/phonebook+POST CreateNewContact/phonebook/{id}+GET GetContactById/phonebook/{id}+PUT CreateOrUpdateContactById/phonebook/{id}+DELETE DeleteContactById

When you run a HTTP GET on a /phonebook resource, you invoke the GetAllContacts function. It will return a list of all contacts from the phonebook.
HTTP POST on the same URL will create a new contact in the phonebook and will return its ID.
Once you have the ID, you can use it to display the contact's details (GET) or update (create) a new contact with a particular ID.
In a similar way, it works for the DELETE method.

You can create several functions and use them as microservices. Functions can be also easily adapted to manage all sorts of catalogs. To do that, change a function name and modify the name of the resource.

Amazon API Gateway Methods

You can use the same functions for different applications, phonebooks and books catalog for instance. Our phonebook app can become a microservice for another, much larger application.

If you want to migrate your legacy HTTP-based API to Lambda, you may use Amazon API as a proxy to your legacy API:

You may configure the details of each method:

Method Request: select parameters you want to receive as input.
Integration Request: this section maps input parameters to a JSON format understood by Lambda.
Integration Response: this section extracts and maps Lambda's response to different HTTP statuses and formats. It can also map errors returned by the function to HTTP statuses (4xx or 5xx HTTP errors for instance).
Method Response: customize the HTTP response.

Ready to start with microservices?

Thanks to microservices, you can build your application from independent, reusable building blocks, using different services and invoking functions with various parameters to obtain the desired end results. Your service access can be secured with Amazon Cognito.

AWS Lambda boosts the flexibility and speed of development offered by microservices, as it takes away the pain of installing and maintaining the servers.

Now you know the basics that should help you start the ball (or should we say blocks?) rolling. Ready to play?

P.S. Great document => https://blog.bluesoftglobal.com/comparison-aws-azure-gcp