2014 saw a breakthrough release of AWS Lambda offering a powerful new way of running applications on the cloud. However, soon it was realised that a structure is needed to run an application, and it’s difficult to manage all of the containers that lambda introduces.
This gave way to the most powerful framework for building applications exclusively on AWS lambda which was called Serverless framework.
With increasing number of organizations riding the wave of serverless, the way they develop and deliver software has undergone drastic transformation. Let’s get to know the details of serverless web apps and explore how they work.
The What and Why of Serverless
Serverless refers to an application framework for building web applications without going into the detailing of servers. The servers are managed by cloud provider, taking care of its provisioning and allocation.
This makes the application to run in a stateless compute containers that are ephemeral and event-triggered. The productive efforts of developers can be channeled in the right direction, and saves their time in getting caught up in intricate web of modern complex infrastructure.
Pricing is based on pay-per-use model rather and not pre-purchased compute capacity. Serverless has the most realistic offerings, and is anticipated to be one of the most used cloud services in upcoming years.
We have already mentioned in our blog - 5 Reasons To Consider Serverless AWS For Drupal - why AWS is considered the best hosting provider for Drupal websites.
If we compare the architecture for a multi-user, mobile friendly app which requires user authentication of a monolithic with that of a serverless web app, it would look somewhat like the one shown below:
Monolithic Architecture (Source: Dzone)
The serverless architecture would look something like the one shown below:
Serverless Architecture (Source: Dzone)
With serverless, application development is dependent on a combination of third-party services, client-side logic and cloud-hosted remote procedure calls, and is hence referred to as Functions as a Service.
FaaS refers to an implementation of serverless architecture where a piece of business logic processes individual requests. It is an independent, server-side, logical functions which are small, separate, units of logic that take input arguments, operate on them and return the result, such as lambda. It is stateless, which means, any two invocations of the same function could run on completely different containers.
AWS Lambda, Azure Functions, IBM OpenWhisk and Google Cloud Functions are most well-known FaaS solutions available, supporting a range of languages and runtimes e.g. Node.js, Python, etc.
Source: Slideshare
Composition of Serverless App
Assembling a modern application implies you’re creating a solution by combining SaaS with a managed/serverless service. This makes the process faster, but complex at the same time, as the process requires a lot of manual work to bring all the pieces together.
However, with serverless components, it becomes quite simpler. Every project uses AWS resources and divides these resources into three groups:
- AWS Lambdas
- AWS API Gateway REST API
- AWS other resources such as DynamoDB tables, S3 Buckets, etc.
Serverless projects live exclusively on cloud i.e. AWS and don’t have specific environment. Serverless isolates the AWS resources a project uses for development, testing and production purposes through stages.
Stages can be thought of as environments, except for the fact that they exist merely to separate and isolate your project's AWS resources.
Each serverless project can have multiple stages, and each stage can have multiple AWS Regions.
- AWS Lambdas
Lambda functions on AWS can be replicated across each region your project uses. When you include a function in your project to a stage, it deploys a lambda. It can be triggered by events from other AWS services but not from direct HTTP requests.
- AWS API Gateway REST API
If your functions have endpoint data, a REST API on AWS API Gateway will automatically be created for your project which can be replicated across each region.
When you deploy an endpoint to a stage, it builds it on your API Gateway REST API and then creates a deployment in that API Gateway stage.
- AWS Other Resources
Your project's other AWS resources have separate deployments for each stage which can be replicated across each region your project uses.
Components presents a single experience for you to provision infrastructure and code across all cloud and SaaS vendors saving development time.
Creating a Serverless Application
Let’s take a look at how you can use serverless components to create an entire serverless application. A Serverless solution consists of a web server, Lambda functions (FaaS), security token service (STS), user authentication and database.
- Client Application : The UI of your application is rendered client side.
- Web Server: Amazon S3 acts as a robust and simple web server which can serve the static HTML, CSS and JS files for our application.
- Lambda function (FaaS): It is the key enabler in a serverless architecture. AWS Lambda is used in the above shown framework for logging in and accessing data to read and write from your database and provide JSON responses.
- Security Token Service (STS) : STS generates temporary AWS credentials (API key and secret key) for users of the application to invoke the AWS API (and thus invoke Lambda).
- User Authentication : User login can be added to mobile and web apps by an identity service integrated with AWS Lambda. Not only this, it helps in authenticating users through social identity providers with SAML identity solutions.
- Database : AWS DynamoDB provides a fully managed NoSQL database. DynamoDB is used as an example here.
Any cloud service can be packaged as a serverless component.
Understanding Through An Example
You want to write a serverless image processing API that pulls images from S3. To do so, you might create an AWS API Gateway endpoint to call an AWS Lambda function, which then pulls an image from the AWS S3 bucket and modifies it.
All serverless components can be nested in a larger component to create a serverless image processing API, as shown in the image below:
Here’s why this is important: when you create this image processing API, you’ll configure each component. However, this can be avoided by nesting those infrastructure-level components in a higher-order component, which can expose simpler configuration, and can be used somewhere else.
Composing components to form an entire application
The complete web application can be built by nesting the serverless components.
Serverless framework believes in making infrastructure more invisible, enhancing developers’ ability to focus on outcomes, and fosters a community to share and reuse outcomes.
CloudFormation is a service that AWS offers as a unit with all the necessary pieces to make a Lambda do any actual work. It treats a complete serverless ‘stack’ as a configuration file that can be moved and deployed in different environments.
How do we tell our Lambda where its running, and how do we give it the configuration that it needs to interact with other services?
We need secrets to authenticate to our DB, but we also need our Lambda to know that it’s running on staging so that it doesn’t try to update the production database during our test runs.
So we can identify three key sections of our serverless app: our function, its resources, and the secrets/configuration that make up its environment.
In a highly virtualized environment it can be difficult to point where is a particular code running. The ‘environment’, stack, its configuration, and secrets will collectively exist across multiple zones or even in services.
An active stack refers to a complete set of functions, resources, and environment. Dev, test and prod can be the three active stacks where you’re running your code. If these production stacks are distributed to three different AWS regions, you again have three active stacks.
It is important to build a plan to manage all these features so as to adopt a serverless model for part of our architecture. You must have:
- Programmers to write functions and also manage their source code
- Cloud professionals to manage the resources those functions need
- Operations and security to deploy these stacks in the right environments
Srijan can help you assemble matching stacks and their environments, and easily define complete applications and re-deploy them in different AWS regions. Contact our experts with your requirements.
