Go Serverless with AWS
Most organizations adopting micro-services or starting to think in that direction, still are thinking as making stateless services with horizontal scaling as the best / most optimal design for scaleable micro-services.
In my opinion for majority of applications needing a typical workload of 500-1k TPS (2k at most); don't really need dedicated self-managed cluster that can potentially scale unlimited.
The general idea is to build stateless micro-services and put them behind auto scaling. In practical usage for most un-predictable workloads (serving a particular location like US, etc), we land up using higher capacity. We either use time based scaling or keeping a minimum no. of servers. This is to avoid the scenario where servers are not added fast enough to load balancer if we get a sudden increase in load.
Typical Micro-Service Arch would look like below; reference
What is vastly ignored is the use of serverless components. There are numerous articles which will tell you how easily you can deploy you logic to lambda's and then interface it behind API Gateway. Lambda's can serve a lot of traffic when required; you can even set provisioning which could avoid any latencies due to cold start refer. Even if you have to build a service with significant complexity on business logic, one would debate why not use Fargate. refer
Recommended by LinkedIn
But with AWS your options are not just limited to lambda's. A lot of companies are now inclining towards using GraphQL which allows clients to make query like requests to the backend to get what is required on the client side. AWS provides AppSync which can give you GraphQL endpoints, based on your data model(dynamo) in just a few clicks. The beauty is that the entire GraphQL stack here also is serverless and you really don't need to manage anything. There are still a lot of improvements required w.r.t AppSync but I really feel this simplifies API development for Key-Value data stores to a great extent. (especially with single digit performance for DynamoDB) refer
Lastly I would like to touch upon AWS Batch. For any kind of asynchronous workloads, I feel batch is an excellent option. With the option of using a spot fleet, it just becomes so much cost effective. As an example of a particular use case I was looking in which we built a micro-service using typical on-demand EC2 instances, if replaced with AWS batch implementation could easily save us 90% cost (excluding cost savings from spot prices) refer
With every change there would be resistance. But my take is if something could be implemented in a way that I get time to do other things, and its cost effective and it scales on demand, I would opt for it. Go Serverless!!
Great article Saurabh Gupta on describing alternative ways of describing microservices using Serverless from cost, scaling, maintainability, and manageability. I know a lot of customers shy away due to a Vendor Lock-in with these technologies or higher hosting cost for larger workloads without realizing TCO for the lifecycle of the product, speed to market, risks, and minimal overhead benefits.