[djhaskin987]

> Nobody wants to manage servers. Managing servers is a nasty side effect of wanting to execute code.

Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app.

You know how I would replace all that stuff? 1 single VM. (Alright, maybe 2, 1 for the database.)

A server buys you ease of deployment. It really does. Code needs an environment. Lambdas punt on dependency management and environment. You have to build the environment for the lambdas using IAM roles, RDS, s3 -- out of toothpicks. All that stuff (security, storage) is already there for you in a VM.

I was talking with my brother in law about his serverless deployment of ~23 microservices he had carved up out of a Java Spring app. A small change anywhere in the code meant he had to redeploy all of it, not because of how the code was structure but that was the only way the build tools allowed him to do it. More problematically, the dependencies had to be built into every single lambda and made the build longer. (No, lambda layers didn't work for us. Way too complicated to figure it out.)

Honestly after going through tons and tons of pain to deploy these lambdas in both cases, it's just way easier to deploy on a VM. Maybe not for developers who just can't do anything if it's not done in their IDE, but from a broader, more globally-looking DevOps perspective, there are hidden costs.

Yes, it's easy to develop for lambda. But WOW, it's awful in deployment in comparison to just putting things on VMs.

[cnorthwood]

It's not just "1 single VM" though, as you'll have to configure the applications on top of that. Configuring/installing a Postgres instance on a VM, nginx for your load balancers, iptables for your firewall, user accounts, an application server (could be as simple as forever for a NodeJS app, or Gunicorn or something for Python, etc). And if you want to automate that (as it sounds like you do), you're still writing a bunch of Ansible and Terraform. I'm not sure that it is any easier or less time consuming, unless you already know one way and not the other, and have to bake in time to learn to one approach.

[Scarbutt]

You don't have to throw out the baby with the bathwater. You can still use AWS firewall, RDS, S3 and ELB with a VM/EC2 instance.

[dbrueck]

I can see both sides, and have used both sides (at my last company we used 1500-2000 EC2 instances at any given time and at my current company we have one non-critical EC2 instance and then a bunch of cloud functions on Firebase/GoogleCloud, though the current company is much earlier in its life than the former one).

For a new project, serverless seems to involve a ton of momentum-stealing upfront work before you can really get going, and thereafter you do always feel one step further removed from your code, so it can be a pain to debug and troubleshoot.

OTOH, for any real production application, a single VM instance is rarely sufficient if it's critical to the business, and even within a single machine there always seem to be a lot of ops tasks like setting up process keep-alive stuff, rotating and deleting logs, making backups, etc.

For now, either approach can work great. Long term I think serverless is the way to go, but it still has a lot of maturing to do (the good news is that pretty much all of the annoyances of serverless seem like very solvable problems).

[djhaskin987]

> you do always feel one step further removed from your code, so it can be a pain to debug and troubleshoot.

This reminded me of a story I heard about RMS's kernel, GNU Hurd. Linux being built as a monolith in the 90's, Hurd was being built as a microkernel (microservices) architecture. Guess which one was easier to debug[1]?

1: https://biblioweb.sindominio.net/telematica/open-sources-htm...

[p_l]

Considering some other stories regarding how Hurd project was managed early on, the lack of appropriately capable debugger might be due to non-technical issues...

[staticassertion]

> 23 microservices he had carved up out of a Java Spring app. A small change anywhere in the code meant he had to redeploy all of it,

Those aren't microservices, by definition.

[hamiltont]

> not because of how the code was structured but that was the only way the build tools allowed him to do it

Pretty sure that's the point OP was trying to make - they put in the effort to build microservices, and crappy tooling means they are instead stuck with an mangled over-engineered monolith

[staticassertion]

It sounds like the build tooling was forcing them to distribute a dependency across every lambda build, which was forcing a redeploy of all services, which is a code issue that maybe looks like a tooling issue. Just going off of context.

Regardless, it doesn't sound like microservices, it sounds like a distributed monolith.

Having built a product out of microservices and lambdas I definitely have not found that build tooling has ever forced a full redeploy. I suspect this is just a case of converting a monolith to a microservice being much more difficult than people realize.

[hamiltont]

> It sounds like the build tooling was forcing them to distribute a dependency across every lambda build, which was forcing a redeploy of all services, which is a code issue that maybe looks like a tooling issue. Just going off of context.

Yea, you are probably right on the money.

IME lots of folks struggle with DRY when trying to actually implement their services. In teams I work with, we frequently see attempts to build a shared library and have to re-hash the discussion every time

[rumanator]

Microservices are by definition stand-alone, independent, and self-contained. That's the whole point of microservices, and one of the reasons why people tolerate the pain that goes with a distributed system.

If your application does not meet any of those requirements then call it something else, as it clearly isn't a microservice.

[hamiltont]

> and crappy tooling means they are instead stuck with an mangled over-engineered monolith

Not sure you read my post. I called it a "mangled over-engineered monolith"

[claudiusd]

Ugh, these arguments frustrate me, but here I go getting sucked into another...

> Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app.

I'm sorry but if this took you 6 weeks then you're doing it wrong. To be fair, I haven't tried using CFTs and Ansible for my serverless deployments, but then again these seemed like big time overkill to me. Your experience seems to back that up.

Look, I don't want to say infrastructure-as-code is a bad thing, but don't blame the infrastructure when it's your choice of tools that is the problem. The AWS CLI makes it so easy to write a bash script to deploy a small project. But hey if you think an extra 6 weeks is worth it to use Ansible, then by all means...

[redisman]

> that was the only way the build tools allowed him to do it

What build tools? We have over 60 Lambdas and aren't aware of any issues like this. We literally had to build extra tooling to be able to push more than one Lambda simultaneously so I'm a bit confused how is this related to the platform.

The only "build tools" Lambda itself has is literally a file upload and a version promotion.

[christiansakai]

This.

I now work in a company where they do things themselves, bare metal, and use ansible, ssh, etc pretty much basic stuffs.

I like this way more than my AWS/kubernetes insanity that my previous company had. It was so hard to debug, and everything needs a ticket.

[ct520]

1 VM and managed database service. Couple mins to deploy. I’ve drank the serverless koolaide before.

I find it makes sense more for my uses cases to use it as a tool if I need to extend a monolithic app, not as a standard to create an app.

[untog]

I don’t dispute that serverless deployments are a mess. But I look at it the other way: they make you deal with scaling up front, whether you need it or not. RDS, S3, all that... it scales to huge volumes. Your single VM will not. You can set up auto scaling with multiple VMs but by that point you’re going to be dealing with a lot of the issues you have with serverless deployments.

Now, could a lot of serverless deployments do just fine on a single VM because they never get enough traffic? ...probably. To my mind that's the real problem with serverless: it's a premature optimisation that simply isn't needed in a lot of cases.

[nthj]

Right, I’m a big fan of the monolith, but that doesn’t preclude anything you just described. Absolutely use RDS. Absolutely use S3. Even on a low traffic app.

But what I see a lot of is engineering teams making sweeping consistency judgements. RDS and S3 are great as services, everything should be a (micro)service. Our calendar feels amazing as a React SPA—everything should be built in React.

No. 90% of a product is just CRUD to support the 10% of magic that customers really value. Ship the 90% as a monolithic CRUD app and spend those cycles on that 10%.

[corytheboyd]

This right here. As a less experienced engineer in the past I once made the unfortunate call to go all in on a JavaScript SPA to replace the simple server rendered rails views because it was “correct” and we should have “modern” code.

It’s been many years since then and all this really did was bloat the client with metric tons of business logic, punch inconsistent holes through the API layer, and cause the entire web product to have abysmal load times (normal is somewhere in the 5 second range IIRC).

I think it’s understated how much damage the young technical leaders typically employed by early stage startups can really do. I can tell you this because I was exactly this person, and I got to see what following hype without doing actual mature research leads to.

[ct520]

This! Lol I even went one step further.. On my monolithic apps I use the language framework mvc or mvvm option. (Currently developing on Asp.net) and only has spa on a complicated page! My productivity has been great. Coming from someone with a background across just about all backend frameworks and working with spas since pre angular 1.0.

[djhaskin987]

While true, I regard that as premature optimization. I think we should stick to something simple until we can measure what kind of workload is needed until we have a good idea of the load we're going to be looking at up front.