The last few years have seen a rise in interest in exciting new concepts such as serverless and microservices architectures. While these concepts don’t get as much hype and buzz as artificial intelligence or virtual reality, they are, in my humble opinion, more applicable to more companies undergoing a digital transformation.
The combined serverless microservices architecture offers many benefits, from parallel development and deployment to improved scalability and testability. In this article, I will discuss why you should consider using a serverless microservices architecture, as well as your options to implement the recommended technology stack and details on the most widely used Amazon Web Services (AWS) platform.
First, what is a serverless microservices architecture?
A serverless microservices architecture is the combination of a microservices architecture and a serverless architecture. The first part deals with how business logic is handled and is concerned with breaking down said logic into small modular services. The second part outlines a way of deploying code by relegating most of the responsibility to cloud service providers. These two architectural solutions tackle problems independently but are very complementary to one another.
Many small services talking to one another.
Microservices architecture is a way of developing software that focuses on many small functions that interface with each other to complete the required tasks. In other words, instead of building one big service that does all the work, you build many small services that talk to each other to accomplish the task at hand.
In this article, I will use a cookie bakery as an example to help breakdown our concept. In this theoretical bakery, there are four types of “services”:
- Baker: A perfect robot that takes ingredients from the fridge, mixes them, and then puts them into an oven
- Oven: Takes the mixture from the baker, bakes it, then alerts the server that the cookies are done
- Server: A perfect robot that takes the cookies from an oven and puts them on display
- Cashier: A perfect robot that gives cookies from the display to a customer
All of these services work together to fulfill the required functionality: serving customers with cookies.
Microservices architecture breaks down the traditional structure.
In the past, these services would live inside one monolithic architecture or one bakery. With the introduction of inventive microservices architecture, serving cookies to customers can be thought of differently. Microservices architecture breaks down the traditional structure allowing the cashier and storefront to operate independently of the server between the oven and the display. The server is now also independent of all of the ovens set up to bake cookies. The ovens, likewise, are separate from all the bakers that are mixing ingredients. Each service is now independent of one another. In doing so, microservices architecture provides a few key benefits:
- Parallel development and deployment
- Improved scalability
- Improved testability
Let’s go through each benefit outlined above, using our new example.
Parallel development and deployment
Let’s imagine that we needed to upgrade the ovens. With traditional monolithic architecture, the developers would need to go into the existing kitchen and change the ovens while other developers make bug fixes to the baker. This can result in a few issues:
- Code conflicts as various pieces of the code are changed at the same time
- Bugs introduced in the oven will affect the bakers immediately
- Deploying the oven requires the fixes in the bakers to be complete as they are implicitly dependent
Instead, using a microservices architecture, developers are able to work on the oven and baker separately. This can drastically improve the productivity of developers by allowing them to work on writing code for each service, in parallel.
Improved scalability
The second benefit is improved scalability. It’s not unusual for our services to require a different workload at any given time. For example, there might be a time where more bakers are needed to keep up with demand but no additional ovens are needed because they are already able to accommodate more cookies being baked. In monolithic architecture systems, we would have to create a completely new instance of the whole bakery to serve the increase in demand just for the bakers. In the new microservices architecture system, we would only need to create new instances for the specific service (in this case, bakers) needed.
Improved testability
Since developers are now making changes to only one service at a time, QA is now also able to focus on testing the changes to that individual updated service (granted they are maintaining the interfaces between the various services). This makes the testing cycle for QA shorter and reduces risk when deploying, taking us into the third key benefit of microservices architecture: improved testability.
By making the testing cycle shorter and reducing risk when deploying, this in effect will improve the overall QA test coverage. Since QA is able to focus on the individual service being deployed, the team can achieve the velocity required for continuous deployment when combined with other strategies such as unit testing, integration testing, and automated API testing. Overall, the team can freely make changes to the application and make quick improvements from continuous customer feedback.
Dynamic service provisioning.
Serverless architecture or serverless computing is using a cloud services provider to dynamically manage the required services. In simpler terms, you will rely on a provider, typically AWS or Azure, to allocate machine resources when needed. This highlights two key benefits: (1) you are able to run your system completely by a machine, without any intervention from a human, and (2) pay as you go.
When your system is run by a machine, it eliminates the need to have someone from IT manually add a new server to your physical server stack. This can significantly free up developer time and resources by focusing on only what you need, greatly simplifying scaling of resources to accommodate demand.
Explaining with the example above, let’s say our bakery gets a different number of customers on any given day. With the current server-based architectures, the bakery can either (1) have enough instances to accommodate all the customers that will be coming in, but have extra resources and spend money unnecessarily on those resources when they are unused or (2) have enough instances to accommodate the number of customers that come most of the time, but deal with a potential backlog of customers.
The first solution means we will be paying for extra resources when they are not required. The second solution could lead to a poor customer service experience, and likely send customers to another bakery. Instead, a serverless architecture will give us one more way to handle variable demand: Have enough instances to accommodate all the customers at any given time and be able to immediately bring in more bakers, ovens, servers, or cashiers as needed if the number of customers increases.
Scale using AWS Lambda.
Reducing operational costs is probably the biggest factor in deciding whether or not to implement a serverless microservices architecture. To take advantage of this, we recommend using AWS Lambda. AWS Lambda is a service created by Amazon that allows developers to create pieces of code that can be run specifically when needed. There are other services you can use, such as Azure Functions or Google Cloud Functions; however, AWS Lambda is easier to implement and supports most popular frameworks and languages, including Java, Node.js, C#, and Python.
AWS Lambda functions can be scaled individually as necessary. It automatically takes care of creating new instances and developers only pay for the processing time when the lambda is running. As AWS Lambda will automatically take care of creating the new instances, you can rest easy knowing that if there is a sudden spike in customers, the system will automatically scale without manual intervention.
You are able to create an AWS Lambda function for each service you need. This means you can have a baker Lambda, an oven Lambda, and so forth. With a function for each lambda, development teams can focus on writing code for each lambda in parallel, enhancing the productivity of the developers.
AWS Lambda is only about four years old, but it has matured enough now that it can be used by development teams with ample documentation and help.
Pair with AWS.
When setting up your server, we recommend utilizing AWS. AWS offers many benefits in comparison to other service providers, such as:
- AWS has the largest variety of services to choose from that tackle a range of requirements such as authentication, AI, and file hosting
- AWS has 41.5% of the market share, the largest slice for a single cloud provider on the market
- AWS comes with a year of free services (though some services are always free)
- There is a vast amount of guides and documentation online that cover a wide variety of use cases
- AWS has been around the longest
- With built-in capabilities such as DDOS mitigation and data encryption, AWS makes building a secure infrastructure much easier.
AWS is certainly one of the leaders when it comes to simplifying the process of building a serverless microservices technology stack. With AWS Lambda, you can look forward to a fast and seamless digital transformation.
Some things to keep in mind.
Serverless microservices architecture built on AWS Lambda, like any technology, is not a panacea that will solve all problems. There are some downsides that need to be considered, such as potentially increased overhead due to the communication between the different services. AWS Lambda can also have warmup issues when creating new instances that need to be mitigated.
That said, building a digital solution using a serverless microservices architecture will drastically improve your development team operations. It will provide you with parallel development and deployment, improved scalability, and improved testability, and, as a result, save you time and money. Building it specifically on top of AWS Lambda will provide automatic scalability, and make creating and deploying microservices easier.
