Servers, Containers, or Serverless?
Microservices architecture is quickly becoming a favorite development technique for large-scale applications. But the technology underlying microservices impacts how fast you can add business features. Should you go with servers, containers, or serverless functions?
As microservices architecture is gaining popularity and is becoming the favorite software development technique for large-scale applications, cloud providers like Amazon Web Services (AWS) and Microsoft Azure are offering multiple technologies to host your services.
However, on the journey towards microservices, it quickly becomes clear that things that used to be relatively simple in a monolith, become complex -- deployment, monitoring, logging, communication between processes and availability, just to name a few.
These are all areas that take away time from adding business value to your service. When your heart is set on microservices, it is extremely important to realize that the technology you choose will greatly impact your velocity in adding business features.
So what will it be? Servers, containers or serverless functions? The choice is not always obvious but here is the guide to save you!
This is the new kid on the block receiving all the attention. Although the technology hype cycle is at its peak, serverless compute clouds such as AWS Lambda does deliver on the promises.
Reduced management, deployment, monitoring, scaling and availability out of the box as well as cost optimization make it the ideal candidate for stateless, short-running functions such as websites or APIs. Many of the pains of designing, developing and running a microservices architecture go away. The only restrictions are that functions must execute in seconds and state must be separated from functions as functions are stateless. If you are fine with that and you can live with tools that are currently maturing there is no reason to look any further.
In most cases the pros of serverless simply outweigh the cons.
This is especially true if you are a small development team. One of the major strengths of serverless technology is the capability to integrate with the ecosystem of services provided by the vendor, such as S3, Kinesis and DynamoDB, in the case of AWS. However, if you do not want to use those services, the benefits of serverless may not be as great.
Your second choice should be containers and orchestrations such as Docker and Kubernetes.
Containers and orchestration will save you hours upon hours of building and configuring tools for deployment, availability and scaling compared to regular virtual servers. Containers allow you to deploy more advanced applications with better support for local caching and low latency, as well as support for your favorite programming languages and services.
Historically you still had to do quite a lot of work setting up the containers and orchestration environment, but lately, services like ECS, and especially AWS Fargate, have taken that complexity away. This makes containers and orchestration very attractive even to small development teams.
So what is left? While uncommon, there are some cases where you may still want go with a virtual or even dedicated server.
Does your application use technology that is not deployable using serverless or containers? Does it need to persist state permanently to local storage? Is it unable to scale horizontally? Does the application require access to specialized hardware? Are alternatives too expensive?
In any case you may want to consider refactoring your application to move it to a different technology.
At Queue-it we have been working with microservices for the last 7 years using the AWS platform. We started our journey when AWS was still in its infancy so we had to build a lot of automation ourselves. Serverless was not an option until recently and since we are mostly developing in .Net, containers were not an option either. We were left with a large number of virtual servers.
If we were to build the system again today, it would be doubtful if we'd use virtual servers at all. History has taught us that although a microservices architecture comes with a lot of benefits, it is also expensive in terms of operation and velocity. So today we embrace AWS Lambda and AWS Fargate and we are moving increasingly more services into serverless and containers to reduce the overhead of management, operations and development time.