For people in industry, how important is serverless really? Is it actually likely to take a significant chunk of the cloud market in future? Or is it likely to remain a relatively niche thing? Are there any market analyses out there comparing market share of serverless vs PAAS vs IAAS?
Serverless is a much more efficient use of resources and much more manageable than most companies can do on a low budget. For dollars a month you can have a system that has higher availability guarantees than a several hundred dollar a month system would. And the devops skill barrier to get there is lower.
I build all my systems in serverless now and I've been building web apps for 24 years. The only exception is if I know I'm going to have sustained and predictable CPU usage or I need to listen on a TCP or UDP port (note: I didn't say Websockets as you can now do serverless websites).
And for databases it's a game changer, the cost of having a redundant high availability database is huge compared to serverless databases until you get into very predictable and consistent workloads.
I'm actually to the point where I question someone's decision if they choose to use actual servers.
Note that if you're a large enough enterprise you can also run your own "serverless" environment on your existing hardware investment with things like Docker and creating pools of available resources and give you team tools to launch workloads.
It's really it's just a natural extension of the existing trends of immutable infrastructure and cattle vs pets.
On the flip side, if you have predictable workloads (either constant load or you know exactly what time you need to provision it and tear it down) or workloads that last more than 15 minutes or have very high CPU... servers still have their place.
Not sure I get your implication. I have no stake in any Serverless platforms. I've launched everything from bare metal to Kubernetes clusters in the last 20+ years. I honestly think it is a game changer.
Sorry if I'm too enthusiastic about it that I sound like I'm biased. But unless your company is made of money and has tons of devops resources and/or you have a very specific use case, I believe it should be the default go-to.
Edit: I know, my name has "throwaway" in it but check my karma. I didn't just come here to post serverless praise.
I'm invoking humor to contradict you because I disagree with you as the offerings stand, and as you staked so much (in the upstream) in relying on serverless.
I think you left out the nuance of your experience.
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.
I can only speak from my own experience, but if you're anywhere close to the limits that Lambda imposes, then you should probably have already converted those functions over to Fargate or your own ECS or EKS clusters a long time ago. Many people abuse Lambda as a way to quickly launch an instance that's supposed to last for a relatively long time instead of one whose lifespan should be measured in terms of milliseconds or maybe just a few seconds.
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.
I agree with a lot of what you said. Though you may want to look into AWS EFS a sit has opened up a whole bunch of use cases that were previously very difficult with AWS. You can also use Lambda with VPC Endpoints to make the network distance to DynamoDB more efficient.
But yeah, if latency between servers is a concern of your's than Lambda is not the best. But for a different reason than you described, I think it is the lack of ability to have a long running network connection that is the hurdle there since handshakes take time.
Didn't mean to imply it is a free lunch either. But I do think it should be most people's default. The goal should not be to be free it should be to provide high availability and reasonable performance for minimal cost. And in my experience Serverless does that very well.
Even at $legacy-big-company where I worked at the time, moving whatever made sense away from autoscaling instances and onto Lambda resulted in such significant cost savings that no-one is likely to ever look back. For simple things like the ‘pull a list of recent clients from the DB’ API, there’s nothing cheaper, and when you constrain your usage to only things that make obvious sense, it remains relatively easy to deploy and run.
I used to work for a startup that quickly grew to become one of the biggest Lambda users in my country (according to AWS). The entire business was serverless, not just Lambda but backend DynamoDB, APIGW, Cloudfront, etc. There was maybe 2 EC2 instances in the whole company.
Having seen what that model of development can do from an operational/security/agility/scalability/efficiency perspective, I think the comments on HN about serverless saying "it's just CGI" or that they could do something similar without vendor lockin are honestly laughably ignorant. If you haven't messed with Zappa (https://github.com/Miserlou/Zappa) or Serverless Framework (https://www.serverless.com/) at least a little you are missing out.
It's a pretty fluid term (and maybe fading from use except in the 1st gen stuff?) and different implementations have different strengths and weaknesses. I think something developer friendly and high level like fly.io, Cloud Run, etc will be a sweet spot.
The usage of the term is even further muddied by its usage to describe some SaaS APIs, like AWS calls DynamoDB a serverless database. Maybe Google Sheets will be called a serverless spreadsheet next.
About AWS Lambda specifically, it's a pretty low level building block for web facing cases, using it directly makes you spend a lot of time in web -> lambda wiring using API Gateway, authentication, juggling either the anachronistic zip files for deployment or dealing with all the container registry & container CICD logistics, setting up a lot of fine grained authorization IAM roles, trust relationships, etc, all the aws provided monitoring and logging stuff necessitated to troubleshoot all that, and the infra-as-code for all of the above which is tedious but necessary to keep any kind of sanity in managing the complexity. But in the running costs it does save you a few bucks of per month compared to the overpriced always-on EC2 stuff in AWS especially if your service is low volume, or high volume with spiky load.
The main reason it's significant is because it's cheaper. We'd all[1] rather fling servers running containers all over the place, but leaving those servers running all the time even when nobody is using them is expensive. Serverless stuff means you can just pay per request and they take care of listening for the connection and all that so you just pay for the time your business logic has to run.
[1]: I would like to fling servers running containers all over the place, but that might just be because I like building devops rube goldberg machines in my spare time. Some people think coding for lambda (or things like CF Workers) is easier/more fun.
