AWS Lambda: A WhatsApp-Like Movement in Serverless Computing

We are witnessing a paradigm shift in IT architecture evolution and infrastructure provisioning using infrastructure as code. We also know the pain of onboarding physical servers, and how easy it has become with container technology and cloud infrastructure/platforms/software services (IaaS, PaaS, SaaS, etc). The traditional waterfall model to the current agile/DevOps model to the future NoOps Model gives an opportunity to explore next-generation application architecture. Physical servers, Virtual Machines, then containers, and now serverless computing have acted as a game changer for the cloud computing space. In this post, I will give you a big-picture view of the AWS Lambda service.

Serverless computing is a hot topic in cloud computing architecture. The "Big Five" public cloud vendors — Amazon, Microsoft, Google, IBM, and Alibaba — are heavily invested in serverless. Serverless architectures consist of two concepts: Function as a Service (FaaS) and Backend as a Service (BaaS). These two service models, "FaaS and BaaS," fall under Platform as a Service (PaaS).

AWS Lambda is a FaaS (Function as a service)/ It lets developers run code without provisioning or managing servers. The Lambda service is designed to serve microservices (for example, lightweight web server frameworks like Node.js ) instead of resource-intensive frameworks like Apache, Websphere, or .NET. Since the release of AWS Lambda, microservice applications has become a buzzword and starting point for developers to be part of the cloud journey, as serverless computing is a cloud-computing execution model.

Currently, microservice architecture is spreading in large enterprises and is now one of the the driving forces of innovation. Many companies are already using it; some are very actively implementing it and some are trying to use it. If we can focus on the latest trend in the industry — adopting cloud services — "FaaS" services are drastically increasing. The IT industry is witnessing a WhatsApp-like movement in the adoption of serverless architecture, developing microservice applications in the public cloud.

If we compare Lambda with Docker containers, both have a place in the modern digital enterprise. Both services are used to build microservices, but serve different needs. If we want to eliminate application management and don't care about the architecture, then Lambda (serverless) is the best option. If we want to deploy an application on a specified system architecture and have control over it, then Docker (containers) will be the best option.

Monolithic vs. SOA vs. Microservice Application Design Approach

There are multiple issues a developer can face while developing and deploying a monolithic application, like storing all application components in one archive (EAR or WAR). The size of the file will keep growing when the application is enhanced. With every new release, there are new functionalities and features added, so the code base keep grows. Initially, we can neglect it, but eventually, it will hamper development teams' productivity, as the IDE cannot handle large amount of code efficiently. A small change in one module of the application demands the deployment of the entire application.

Service Oriented Architecture (SOA) is an architectural pattern that guides a business solution to create, organize, and reuse its computing components. Adopting SOA will help developers separate business process from the application and the latest method of application development, i.e. microservice applications with serverless computing, can solve the problems of monolithic and SOA frameworks. Application functionalities are broken down into small services which talk to each other using HTTP/REST (synchronous or asynchronous). For example, an application might consist of services like the invoice management service, the user administration service, etc. These services can be developed independently and we can deploy them independently with one-to-one or one-to-many mapping between services and the database. This will keep things smooth when we touch one module and we can relax because our other module will still be operational.

There are four ways of running code in AWS cloud:

1. EC2 as IaaS (infrastructure as a service)

2. ECS as a hosted container environment

3. Beanstalk as PaaS (platform as a service) to abstract the infrastructure

4. Lambda as the Intersection of EC2, ECS, and Elastic Beanstalk

Compute Options

Compute options for AWS lambda include VMs, containers, and serverless.

• VM: Machine as the unit of scale (abstracts the hardware)

• Containers: Application as the unit of scale (abstracts the OS)

• Serverless: Functions as the unit of scale (abstracts the application)

Use Cases

Here are some of the most popular use cases of AWS Lambda:

• VMs: When you want to configure Storage, Network, OS

• Containers: When you want to run servers configure applications and control scaling

• Serverless: To run your code whenever it is needed

Why Use Lambda?

AWS Lambda runs our code in response to events without provisioning or managing servers. It takes an event from an AWS Resource and creates an Instance to execute it. We only need to provide the code. There is no Infrastructure to manage and no startup/shutdown cost. Scalability and monitoring are built in, and there is zero administration needed.

Components of Lambda

• Lambda functions

• An Event Source

• The Lambda service

• The Function Networking Environment

Lambda Functions

• Our code (Java, NodeJS, Python, and any other supported languages)

• The IAM role that the code assumes during execution

• The amount of memory allocated to our code

Event Source Options

• S3 Bucket

• API Gateway

• DynamoDB

• SQS

• Kinesis Streams

• SNS

• CloudWatch

• Amazon AI

AWS Lambda supports Node.js, Python, Java, C#, and Go.

This has been an overview of the AWS Lambda environment for microservices and serverless computing, including its design approach, functions, components, compute options, and use cases.