5 ms·

I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' hav

I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' have a lot more moving parts than a traditional server based equivalent. Try showing the you from 10 years ago a modern serverless architecture and they'll think you're mad. More moving parts is more maintenance/problems, but on the plus side, does allow you to throw more resources at a specific part of the whole. Second - with each cloud provider's serverless service, I've noticed that the underlying complexity is shifted into your application and provisioning. They're a great example of leaky abstractions. The name 'serverless' may lure you into thinking that you don't need to think about servers any more, but actually you do have to adjust to the way they've implemented a service that you're using. Think of Lambda cold starts, or have a look at the DynamoDB pricing page. There's still a server running somewhere. Personal experience: I've found that ECS (Fargate) is a decent step into the serverless realm, if you've been running normal containers on normal EC2s. It does take away the EC2 management aspects, and it's especially useful if you have some applications that are resource hungry, and some are not. It's a cheap way to run ETLs (we use the ECS Operator from Apache Airflow, which itself is on EC2). It doesn't take long to learn, and it's a good place to start. It does come with its own baggage... the 'stack' that you had on a single EC2 is now scattered about; you may need AWS Cloud Map for service discovery, ALBs for networking, SSM/KMS for secrets, Cloudwatch for logging. That's when you realize, those sticker infested laptops at Devops conferences are actually modern architecture diagrams.

ahallan 6y ago
I agree. I only generally use Fargate with containers, and control with cron or with always on APIs, with Cloudwatch for monitoring, and it’s seems like a good midpoint between ec2 and serverless. The APIs cost a bit more a month (they’re on quite low cpu/memory) because they’re always on, but it minimises complexity and it’s nice to know that you can move those containers over to another platform if needed.
- yellow_mixer 6y ago
  The increase in price is well worth it for our team to not have to manage any servers.
jasonhansel 6y ago
Infrastructure is always much harder to maintain (and test) than application code. Serverless architectures can risk moving complexity from (easy-to-test) application code to (hard-to-test) infra.
- csours 6y ago
  Hmmm maybe if you're talking about developing from scratch, but most developers have a lot of knowledge and assumptions about existing implementations of infrastructure; also, in many organizations developers don't have to think too much about implementing the infrastructure, someone else takes care of that. And at the very least, there's a separation of concerns: you don't have to think about both at the same time. Actually, re-reading your comment, I'm not sure what you were trying to say. I may be agreeing with you. --- I think it is possible for serverless to supplant PaaS et al, but I don't know if it's quite mature enough yet.
- GordonS 6y ago
  Hmm, I think that, as usual, it depends (TM). For stateful systems such as databases, that typically require complications like replication and backup, configuration, testing and maintenance is hard to get right. But for stateless systems, IMO infrastructure is pretty straightforward.
john-tells-all 6y ago
Seconded. Serverless has the benefits and drawbacks of Microservices: you build and deploy smaller units, at the consequence of having to debug the interconnects between everything, with poor tools. I'm a fan of OpenFaas: you get the benefits (but not all the drawbacks) of containers and serverless. It's easy to mix and match running 100% locally, or mix-in baked 3rd party components, or running in Kuberenetes or other systems in production. Also, no vendor lock-in.
- big-malloc 6y ago
  +1 for openfaas. I haven’t used it in production, but the option to run an entirely custom container underneath the function opens up the possibility of running a “proper” application underneath (the use case I’ve been meaning to test is a fully-featured rails app)

ahallan 6y ago

I agree. I only generally use Fargate with containers, and control with cron or with always on APIs, with Cloudwatch for monitoring, and it’s seems like a good midpoint between ec2 and serverless. The APIs cost a bit more a month (they’re on quite low cpu/memory) because they’re always on, but it minimises complexity and it’s nice to know that you can move those containers over to another platform if needed.

yellow_mixer 6y ago
The increase in price is well worth it for our team to not have to manage any servers.

jasonhansel 6y ago

Infrastructure is always much harder to maintain (and test) than application code. Serverless architectures can risk moving complexity from (easy-to-test) application code to (hard-to-test) infra.

csours 6y ago
Hmmm maybe if you're talking about developing from scratch, but most developers have a lot of knowledge and assumptions about existing implementations of infrastructure; also, in many organizations developers don't have to think too much about implementing the infrastructure, someone else takes care of that. And at the very least, there's a separation of concerns: you don't have to think about both at the same time. Actually, re-reading your comment, I'm not sure what you were trying to say. I may be agreeing with you. --- I think it is possible for serverless to supplant PaaS et al, but I don't know if it's quite mature enough yet.
GordonS 6y ago
Hmm, I think that, as usual, it depends (TM). For stateful systems such as databases, that typically require complications like replication and backup, configuration, testing and maintenance is hard to get right. But for stateless systems, IMO infrastructure is pretty straightforward.

john-tells-all 6y ago

Seconded. Serverless has the benefits and drawbacks of Microservices: you build and deploy smaller units, at the consequence of having to debug the interconnects between everything, with poor tools. I'm a fan of OpenFaas: you get the benefits (but not all the drawbacks) of containers and serverless. It's easy to mix and match running 100% locally, or mix-in baked 3rd party components, or running in Kuberenetes or other systems in production. Also, no vendor lock-in.

big-malloc 6y ago
+1 for openfaas. I haven’t used it in production, but the option to run an entirely custom container underneath the function opens up the possibility of running a “proper” application underneath (the use case I’ve been meaning to test is a fully-featured rails app)