|
I work in a company that's all in with serverless on AWS, but unlike you I can't give a glowing recommendation. The answer should always be "it depends". IMHO the more distributed a system the more difficult it is to correctly build. Serverless architectures encourage distribution by building your service from different AWS components, commonly say, Lambdas, S3, DDB, SQS, etc, you end up building a distributed system from AWS provided distributed systems. System performance is commonly a function of data locality, and serverless typically spreads things out. The Lambda's have no persistent state of their own, though DDB is fastish, it's still multiple network hops away. Speaking of performance, you are also always trying to work within the 15 minute / 10 GB lambda hard limits, which has made my current role the one with the most performance management work yet! Lastly, you require a rather high proficiency in AWS, both in general (IAM polices, roles, cloud formation, cloudwatch, et al), and in specific services - and each service is it's own thing with it's own performance traits and consistency guarantees and semantics. It takes a lot to pick it all up. Meanwhile, single servers, being whether you rent an EC2 virtual instance, an OVH rented physical instance, or purchase one, have gotten extraordinarily powerful. And postgres has proven to be very useful. I'm not suggesting people ignore AWS all together, but perhaps using less services could serve a lot of people rather well, 1 EC2 using Postgres RDS and EBS, can do an awful lot. I notice the M6a instances apparently max out at 192 VCPU, 768GB RAM, 50Gbps networking and 40Gbps of EBS connectivity. Most people know how to run 1 host, everyone has 1 host they use as their work desktop, they have routers and home servers, and they get great data locality and a much easier to reason about system. Some might allege that such a host will have less uptime compared to what someone might build with a serverless architecture. However, I believe most outages are a result of human error, be it in configuration or code, and by simplifying the system to a host, a DB and a SAN volume, one might be able to make it much more straightforward, which also helps recover from outages much quicker. (Serverless observability is no where near as good as what one gets with a process running on a Linux server you can SSH into.) Some might say you will hit hard scaling limits, since such a design scales up rather than out. This is true, but AWS is a minefield of quotas and hard limits, and you have to design carefully around them. A Linux host will also have such limits, but AWS Serverless will be a superset, since at the end of the day AWS Serverless is running your process in a Linux firecracker VM anyway. I don't mean to be an advocate for any part of the spectrum, just that I don't think there's any free lunch here by picking serverless. Much like picking a programming language, I think it might come down largely to what your existing skills are and your personality. |
Lambda gives you way more rope than you need to hang yourself many times over.
Don't get me wrong, it's a great tool when it fits your use case, but there are a lot of people who got started with it without really understanding their serverless use case, and because it worked so well they just never bothered to do their due diligence to find out if it really was the right solution. And even if they did do their due diligence at the time, they just cast that decision in stone and never came back to it.
It is possible to build and run a Tier 1 class service and take dependencies on serverless technologies plus DynamoDB and other Tier 0 or Tier 1 services. More than a few services at AWS are built that way. But you have to be careful when incorporating Lambda into that kind of equation.