lostcolony I think you are over stating how hard to is to run ops on your own server. The separation between engineering and ops has gotten a little out of control. Engineers should know how to do basic ops. So the cost savings you say you are getting by letting your engineers focus ONLY on the product and not worry about those pesky little details called ram and cpu you really shoot yourself in the foot. It's like putting blindfolds on your engineers and saying code away as if the world will always be this dark. The skills your engineers learn in deploying their own code to 1 digital ocean box is priceless. Well it's $5 a month to digital ocean. But it's not just the savings in bills to lamba, it's the knowledge in engineering craft they learn that is priceless. Because the world runs on servers. The world does not run on magical things that are not servers.
I think lostcolony didnt explicitly mention it, but it's not the concern about ops lifecycle of one $5 box. I agree with you, that's easy. But "what if" it suddenly NEEDS to scale more than a $5 box? Now your engineers need to rush to put together an HA solution, load balancing, etc. is it worth planning & building that for each microservice, or is it better to just deploy code to a scalable platform?
I meant more than that. Even if your application is just going to remain on one box, how many applications are you going to have? Are you going to have a dev, stage, and prod box? When an underlying library is updated, how do you manage that? Are you certain it will not break anything, and so make it automatic, or do you do it manually? When a box needs to be replaced, you have to handle that. Etc. It's more than just "buy a box and done".
Yes, no one of these is hard to do, and they should be things any engineer is familiar with. But -why are you spending your time on it-?
If your project is small enough, serverless allows you to spend all of your time on your actual code, not ops tasks, and -know- it will be trivial to scale, for the same amount of money.
If the project is large enough, the same thing applies; the ops tasks required for multiple boxes get more complicated, and serverless keeps you just focused on the code, with it scaling trivially.
In short, bear in mind the opportunity cost. If someone feels the ops work + cost of hardware < going serverless, fine. That's their decision. But to be dismissive of those who find it's a better value to go serverless, because they can iterate faster, because it's no more money at first, and only gets more expensive at scale (when they hopefully are making money, -and- have saved themselves the work of building an HA solution, as well as handling any unexpected shared state), seems misplaced.
"and -know- it will be trivial to scale" that's my point. You won't know that. If you spend all your time in fantasy land where ram and cpu are infinite you start to loose touch with reality in how you code. You have to code defensively against ram and cpu use.
When going serverless, not really. That's...kind of the point. Or are you saying that because you stop having to worry about it, if ever you go back to servers you're going to make scaling mistakes?
Yes. Guaranteed. Like the movie rush about race car driver Nikki launder. He tuned that race car engine down to every last detail to get performance. With server less their will always be big big low hanging fruit optimizations.
