6 ms·

That's exactly the argument why you should go serverless. If all you do is keep a vanilla Linux distro running in a VM with occasional updates and some initial

That's exactly the argument why you should go serverless. If all you do is keep a vanilla Linux distro running in a VM with occasional updates and some initial config-magic (webserver, certs, ip tables, ssh etc.) why even bother? The serverless isn't going to be any different, other than it just runs. No need to make a cron for updates, no iptables, no certs or webserver-stuff ... just put your app on it and let it go. On the other hand, if you actually need to tinker with your OS, roll your own. But what you described is the prime example of serverless target audience.

jeroenhd 6y ago
One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of luck to you if you're about to catch a big customer but they demand your application to run on their premises. There's also the long-time guarantee; if you write an application that runs on Ubuntu Server or Windows Server now, you can bet your ass that it will still run, unchanged, for another 10 years. The only maintenance you need to do is to fix your own bugs and maybe help out with some database stuff. If you deploy a Lambda app now, you have nothing to guarantee compatibility for such a long time other than "Amazon probably won't change their API, I think".
- nicbou 6y ago
  You can also predict the costs, and shop around if your provider gets greedy. If Amazon changes its pricing structure, what are you supposed to do?
  - ajsnigrutin 6y ago
    It's a lot easier to change providers, if your service is an (eg.) docker image(s), than to move something relying on amazons api.
    - xorcist 6y ago
      It's even easier if your application is just (an equivalent of) a binary, or a tarball.
      - ForHackernews 6y ago
        Unless it relies on any system libraries, in which case you're in dependency hell when you upgrade or change the OS.
        joana035 6y ago
        This is a solved problem, and dependency hell happen when not choosing dependencies wisely when creating programs.
  - VHRanger 6y ago
    If you built everything in proprietary infrastructure, porting is a lot more work. Using lambdas tie you to AWS because as soon as you use a few step functions, or you have a few lambdas interacting, changing to Azure or GCP becomes a huge pile of dev work and QA. Having everything "just run" on linux instances let you be perfectly portable and now you can actually shop around.
collyw 6y ago
Because you can reproduce that environment locally. Often useful for fixing bugs.
- gimboland 6y ago
  Also useful for doing the development in the first place!
  - collyw 6y ago
    Kubernetes, microservices, distributed systems, SPA apps. Getting a development environment to reproduce bugs takes up so much of my time these days (a fair bit is because of our crappy system, but there also a lot of inherent complexity in the system because of the architecture choices listed above). We get the promise of scaling, but most places making these choices don't actually need it.
xorcist 6y ago
The above comment was intended to answer exactly that: because it is much less maintenance in the long run. Had you deployed an application to a proprietary cloud platform ten years ago, a handful of those services would have had their APIs changed or even been sunset by now.

jeroenhd 6y ago

One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of luck to you if you're about to catch a big customer but they demand your application to run on their premises. There's also the long-time guarantee; if you write an application that runs on Ubuntu Server or Windows Server now, you can bet your ass that it will still run, unchanged, for another 10 years. The only maintenance you need to do is to fix your own bugs and maybe help out with some database stuff. If you deploy a Lambda app now, you have nothing to guarantee compatibility for such a long time other than "Amazon probably won't change their API, I think".

nicbou 6y ago
You can also predict the costs, and shop around if your provider gets greedy. If Amazon changes its pricing structure, what are you supposed to do?
- ajsnigrutin 6y ago
  It's a lot easier to change providers, if your service is an (eg.) docker image(s), than to move something relying on amazons api.
  - xorcist 6y ago
    It's even easier if your application is just (an equivalent of) a binary, or a tarball.
    - ForHackernews 6y ago
      Unless it relies on any system libraries, in which case you're in dependency hell when you upgrade or change the OS.
      - joana035 6y ago
        This is a solved problem, and dependency hell happen when not choosing dependencies wisely when creating programs.
- VHRanger 6y ago
  If you built everything in proprietary infrastructure, porting is a lot more work. Using lambdas tie you to AWS because as soon as you use a few step functions, or you have a few lambdas interacting, changing to Azure or GCP becomes a huge pile of dev work and QA. Having everything "just run" on linux instances let you be perfectly portable and now you can actually shop around.

collyw 6y ago

Because you can reproduce that environment locally. Often useful for fixing bugs.

gimboland 6y ago
Also useful for doing the development in the first place!
- collyw 6y ago
  Kubernetes, microservices, distributed systems, SPA apps. Getting a development environment to reproduce bugs takes up so much of my time these days (a fair bit is because of our crappy system, but there also a lot of inherent complexity in the system because of the architecture choices listed above). We get the promise of scaling, but most places making these choices don't actually need it.

xorcist 6y ago

The above comment was intended to answer exactly that: because it is much less maintenance in the long run. Had you deployed an application to a proprietary cloud platform ten years ago, a handful of those services would have had their APIs changed or even been sunset by now.