Let AWS worry about the backend so your developers can develop.
Building and maintaining an application is not cheap. With a traditional on-premise approach, businesses had to invest in servers and hardware to host the application as well as a fully-fledged development and ITOps team to maintain it. Modern cloud environments and DevOps approaches have brought down the costs significantly, but even these approaches need significant capital investment. Developers often have to predict the demand for their applications and provision servers beforehand. It also takes serious skill and expertise to manage these apps and meet the requirements.
Over the last decade, businesses have shifted from these server-full applications to serverless applications to better manage their business processes.
A serverless application is where the developers let a third-party take care of the servers for hosting it. The name comes from the development team’s perspective; these applications have servers, but as far as developers are concerned, it acts as if it doesn’t. The goal of a serverless architecture is to let the business focus on developing the application without worrying about the underlying infrastructure.
The serverless framework is the next step in the evolution of application development. In the early days of computer applications, businesses bought and maintained their hardware. With the advent of cloud computing, they started to deploy apps on vendor hardware using cloud platforms.
But even then developers still had to provision the servers according to the demand, scale up and down to manage the costs, and build and manage backend services like authentication, and others. Businesses also had to pay to keep their services active even when no users were requesting the services.
The serverless framework evolved out of the necessity to reduce the cost and complexity of maintaining the different elements of an application to ensure uninterrupted service delivery.
Unlike the traditional server-full approaches, the serverless framework scales the applications automatically with demand. The applications are packaged in containers and when they’re called the vendor allocates the resources and the code is executed. Once it’s finished, the application won’t use any more resources and the user pays just for the time the code was executed.
The serverless architecture usually makes use of a set of services that are called as needed. These services often act as a replacement for the different elements of an app built in the traditional approach. For instance, instead of a custom-built authentication solution in the traditional approach, a serverless app may use Amazon Cognito, an AWS access management service. Instead of hosting the web app on-premise, the serverless solution may use AWS Amplify.
Building a serverless application essentially means handing over the server-side aspects to a cloud service provider. The vendor would provision the servers, balance the loads, manage the server security patches, monitor the servers, and in general lets the business build the application. This could be achieved in two different ways; BaaS or Backend As A Service and FaaS or Function As A Service.
In the early days, serverless usually meant BaaS. But now all of the major cloud service providers have both BaaS and FaaS products.
With a BaaS approach, developers build a serverless application by bringing together multiple third-party services to handle everything that happens behind the scenes.
A web or a mobile application needs both frontend and backend to function. The frontend is more or less everything that a user may see on the app. The backend collects, processes, and stores user input, and sends back the appropriate output.
For instance, if you’re trying to log in to an app, the front end collects the username and password and the backend verifies them and later grants or denies access.
In BaaS, vendor-provided services will handle these backend processes. For example, an application may use Amazon Cognito for authenticating users, DynamoDb for database, and Immuta for access control.
With Backend As A Service, developers simply pick and choose the services. These services are completely vendor designed and the application just calls these services through an API. But with this approach, developers can’t deploy their own backend code or functions; there isn’t a lot of customization with BaaS.
Functions As A Service or FaaS is the latest approach to serverless.
With FaaS, the developers write their backend code but the cloud service provider will execute it when triggered. The developers still don’t have to worry about managing the infrastructure or provisioning the services.
These functions take zero resources when they’re not executed and users have to pay for just the time they are executed. This may last just a couple of milliseconds; some vendors limit the time to 300 seconds.
For example, imagine you want to create a web app that removes the background from photos. You can write the code for processing the photos into Amazon Lambda. If there are no users the function would remain inactive. When someone uploads a photo to your website, it triggers the function, allocates resources to it, and executes the code.
Development teams can use multiple different functions within a serverless application in this manner handling different functions of the app. FaaS is commonly used in microservices architecture with different functions forming entire services or parts.
For small businesses and startups, the AWS serverless framework offers a low-cost way of developing applications.
Unlike the traditional architecture, serverless applications don’t take any resources until they’re executed. The users have to pay only for what they use. Businesses also don’t have to choose between reserving enough capacity for the highest demand scenarios and paying huge costs and provisioning resources for average usage and settling for a worse user experience in the event of high demand.
The AWS serverless architecture allows businesses to build their applications with a smaller development team. Developers can focus on writing just the code and launch the product much more quickly. Serverless apps generally have better code since the team has more resources to manage the functionality.
Another benefit of serverless apps is that businesses don’t have to worry about availability during peak seasons. Serverless apps scale automatically with demand; during peak seasons when there are a lot of users, vendors allocate more resources. Once the demand goes down, the resources are shut down.
Traditional monolithic architectures are generally not flexible. It’s not easy to make changes to them or add new features to them. Since the different components are tightly linked with each other, a small change in one of them can affect the entire application.
Due to this, businesses are opting to migrate to serverless architecture and make the organization more agile. Broadly there are two different ways businesses may make this move: one single move or a long-term migration with small changes over time.
This approach is often referred to as the ‘Big Bang’ method. Here the team builds the entire application in a serverless architecture more or less maintaining the same features. Once the application is ready, the users will be directed to it and the legacy system will be shut down. Even though the application is built at a go, the team may shift the user base gradually to test out the new application and prevent service disruption.
The big bang approach may be suitable for small applications with few features.
The big bang approach can go seriously wrong if it’s not managed properly. Huge changes rarely go well with software development. This approach can also be very complex and may take significant resources. The team will have to spend considerable time developing the application and testing it out before it’s ready to launch.
The size of the project also makes it difficult for the teams to estimate the resources or the time it may take to complete it. Big bang migrations often go way beyond the budgets and exceed deadlines.
The migration to serverless is performed in incremental steps in the lift and shift approach. In the method, the whole application is split into individual functionalities. These functionalities are then built using serverless components and migrated to it. In this manner, the entire application is moved to the new architecture.
The method is sometimes referred to as the strangler fig approach referring to how the plant takes root. The plant starts its growth from a seed dropped in the upper branches of a tree. It relies on the host tree for nutrition to grow as it extends toward the soil where it takes root. Soon the host tree will be completely consumed by the strangler fig which will grow in its place.
Similarly, the new application slowly grows over the legacy architecture replacing it.
For instance, for a simple eCommerce web app, you can first move the database from the existing app to a serverless service like MongoDB Atlas. After testing this move, you can move the backend to an AWS Lambda function and so on.
The advantage of this method is that it mitigates the risk of service disruption. If there are any issues with a change, you can revert it more easily. But as you can imagine, this will take a while to complete and you won’t get all the benefits of the serverless framework in the beginning.
The lift and shift approach is often recommended for large applications.
Part of moving to serverless is making a lot of choices – about your architecture, how you want to migrate, if you should go for BaaS or FaaS, the services you may need, the vendors you’ll need, and many others.
You should also consider if serverless is the right approach for you. Serverless is great if you have fluctuating demands – you can scale as necessary and you won’t have to pay for resources you’re not using. If you’re a startup and you want to bring your product to market in the lowest time and with the least resources, serverless may be a good option for you. The same is true for SMBs that don’t have a lot of resources to build and maintain a traditional app.
But if you have a large development team or your demands are fairly stable, evaluate if serverless is the route for you.
You’ll also have to consider the skills and expertise of your developer team. If you’re building a team from scratch, you can expect to have a smaller team for serverless. But if you already have a team and they’re not experts on serverless, you may have to hire more people. Of course, you’ll also have to evaluate the benefits of serverless to the cost of migration.
Once you’ve decided to go the serverless route, you need to decide how you want your architecture to look. For this, you need to figure out the specific business requirements. If you want a made-for-you backend and to reduce your workload, BaaS may be the route for you. But if you want more custom code with the benefits of serverless, you should look into functions as a service.
Startups and SMBs should also explore their migration strategy depending on their existing application and their business requirements. It may be a good idea to bring in a consultant to evaluate the requirements properly before making the move.
Here are some best practices that experts have developed to migrate to AWS serverless framework
Migrations often fail because organizations fail to properly evaluate the resources they need. They end up exceeding the budget, missing deadlines, and not achieving the goals.
Not two migrations are the same so it’s not easy to nail down how much time and effort it may take. If your organization doesn’t have the expertise, it’s best to bring in external consultants or hire new talent to carry out the migration.
Migrations are complicated and there are plenty of things that can go wrong. Your services may become unavailable which can stall your business processes and affect the user experience. Take the time to plan and build a solid plan.
Before you migrate your applications to serverless, the business has to answer why you’re making the move. What are you trying to achieve and what do you expect to gain from migration?
Migration is not successful if you just move the application from legacy infrastructure to serverless. It should help you reduce your infrastructure or maintenance costs, make your apps more scalable, or meet your other goals.
For that, you need to define your goals with the migration and set KPIs and metrics for the process. These goals should then drive the migration process.
Even if you’re going for a big-bang approach, you need your team to trust the process. For this, it’s best to make the move in small but definite steps. When you start, pick a small process or a workflow and complete it perfectly and on time. Then move on to larger projects and build on this success.
For a successful migration, you need to get buy-in from the management as well as the employees of the organization. They need to believe in the benefits of migration. These small wins can help you showcase the benefits and take it up further.
Migration to serverless needs a strong team. Invest in your team and train them on the nuances of the serverless approach. Ensure they are on board before you move further.
