4 ms·

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 sys

by throwaway2016a 4y ago

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.

scollet 4y ago
> I build all my systems in serverless now > I'm actually to the point where I question someone's decision if they choose to use actual servers. These are the "Paid for by..." aspects of the comment, but I agree with the important part, which is where it stops: > Serverless is a much more efficient use of resources and much more manageable than most companies can do on a low budget.
- throwaway2016a 4y ago
  > These are the "Paid for by..." 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.
  - scollet 4y ago
    Ah, no I didn't mean it literally. That's why I had the quotes. It's an emulation. 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.
srer 4y ago
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.

scollet 4y ago

> I build all my systems in serverless now > I'm actually to the point where I question someone's decision if they choose to use actual servers. These are the "Paid for by..." aspects of the comment, but I agree with the important part, which is where it stops: > Serverless is a much more efficient use of resources and much more manageable than most companies can do on a low budget.

throwaway2016a 4y ago
> These are the "Paid for by..." 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.
- scollet 4y ago
  Ah, no I didn't mean it literally. That's why I had the quotes. It's an emulation. 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.

srer 4y ago

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.