Serverless architecture is a modern application design paradigm which allows enterprises to build and run applications and services without worrying about server management. It enables users to focus on writing business logic, while the cloud service provider takes care of infrastructure management tasks like server/cluster/capacity provisioning, patching, operating system maintenance. Serverless computing is event-driven. Common event triggers include invocation of APIs, pushing messages in a queue, and insert/update/delete operations on the database. Since computing resources are provided on-demand by the cloud service provider, users simply need to allocate memory for functions and specify target runtime.
Serverless architecture helps free up developers’ time by shifting several operational responsibilities to the cloud service provider. This, coupled with pay-as-you-go pricing, and lightweight code deployment artefacts, and shorter CI/CD cycles make it a compelling choice when modernizing legacy monolithic architecture-based applications.
This blog outlines how you can leverage serverless architecture on Amazon Web Services (AWS) to design an effective data warehouse migration solution. It focuses on effective compute and API management using AWS Lambda and Amazon API Gateway.
From monolithic to serverless in 4 steps
The ability of an enterprise to move to serverless computing depends largely on their existing technology stack and the proficiency of their developers in languages and frameworks supported by cloud providers. AWS supports most popular runtimes and also offers custom runtimes, empowering developers to write code in languages of their choice.
Though AWS serverless architecture may not be suitable for modernizing all your legacy applications, with careful planning, it can accelerate migration to a microservices-based architecture. Here’s an overview of a proven multi-step strategy to move from monolithic to serverless architecture.
- Step 1 – Breaking down monolithic architecture into microservices
The first step while moving from monolithic to serverless architecture is to identify important areas of functionality across each application. These functionalities can then be considered as transformation candidates for microservices. For example, if you are managing user account and profile, then “user account” could be one of your microservices. If you are running a digital content website, then “articles” and “subscriptions” could be your next set of candidates. Post migration, these microservices can power various functionalities in your application.
Moreover, each microservice can be a collection of API endpoints corresponding to a specific operation. So, for the microservice “user”, you could use APIs to create new users, update existing users, and delete users from the system.
- Step 2 – Identifying application functionalities that fit within serverless architecture
After breaking down functionalities into a set of microservices, the next step is to identify a fit between these microservices and the serverless architecture.
Typically, most cloud service providers allow a serverless function execution time of up to 15 minutes. This means certain long-running operations can also be done in serverless computing. However, for API endpoints, timeout is capped at 60 seconds due to constraints imposed by the underlying network layer.
From an implementation perspective, each microservice can be implemented as a REST API in Amazon API Gateway. API endpoints can be implemented as “resources” within those APIs.
For instance, you can have an API in Amazon API Gateway named “user”, which will have resources like “/user/create,” “/user/update,” “/user/delete”. Each of these resources can support HTTP methods like POST, PUT, DELETE etc. This logic can be extended to all the microservices identified in Step 1.
- Step 3 – Moving identified modules
As part of implementation, you need to provision the API endpoints using Amazon API Gateway and write business logic in AWS Lambda, a serverless event-driven compute service. To reduce turnaround time, you can port your existing logic into Lambda. While Lambda offers significant advantages, it has certain limitations:
- AWS provisions resources for your function execution each time an invocation is made. However, the first time a function is invoked, or if it is invoked after a long time, there might be a delay in preparing the runtime container for execution. This introduces a type of latency known as Cold Start. Runtimes like Java are most affected by this phenomenon because of their runtime size and the additional resources required for running JVM. However, choosing runtimes like NodeJS or C# leads to considerably lower latencies. This results in lower memory provisioning, and faster execution and application response time, which in turn helps save cost.
- While provisioning Lambda functions, you may not have as much memory and disk space at your disposal as you have on-premises or on VM servers.
- Step 4 – What about the functionalities you thought were unmovable
In the previous steps, our focus was to identify application functionalities which can be transformation candidates for microservices. However, in most enterprise applications, it is not possible to transform all the business logic into microservices.
Here are some use cases where you can take advantage of serverless architecture even when microservices are not a good fit for your application:
- Scheduled jobs – Many strategic operations are executed with fixed scheduling. For instance, a leading e-publication customer checks for active user subscriptions at a particular time every day. Such actions are not initiated externally through an API invocation, as applications tend to use Cron jobs for scheduling. However, Lambda supports the scheduled execution of functions, and allows an execution time of up to 15 minutes for long-running operations.
- Bridge services – Services of business logic that act as a connector between two or more functionalities need to be used in more than one location. To promote reusability of the associated code and avoid duplication of effort, the code should accessible in a centralized repository. For such scenarios, Lambda provides a feature called “Layers” which allows you to write commonly used code and refer to it across multiple other Lambda functions. This helps reduce the size of the Lambda code package and drives faster updates.
Ensuring zero business disruption
Attempting an all-out deployment of your monolithic applications in a single go poses several risks. Depending on the size and complexity of your existing applications, it could cause serious disruption for end users.
To ensure a seamless, risk-free migration, we recommended following a staggered deployment approach. Once you have identified transformation candidates for microservices, it is important to develop, test and deploy them one by one, and verify each one’s integrability with the rest of the system. This cycle should be continuous until the application has been migrated to the new architecture is complete.
Developing serverless applications to drive strategic benefits
Today, there are a variety of off-the-shelf tools available to write serverless applications, including those offered by leading cloud providers. These tools help:
- Reduce the time required to write code for applications
- Improve code structuring
- Simplify versioning management for functions
- Manage different stages of the migration lifecycle – development, production etc.
- Integrate various event triggers like API endpoints, queues and others
Serverless architecture is fast gaining popularity for the many benefits it offers. It helps enterprises accelerate their journey to modern application architecture, enable the rollout of new features quickly, and improve responsiveness to market changes.
With extensive experience in data platform modernization and cloud expertise, Impetus is well positioned to help you leverage the flexibility and agility of serverless architecture to achieve your digital transformation goals. To know more, get in touch with us today.