4 ms·

> Maintaining your own server is completely nuts I've in this area professionally for some time now, and I've never "maintained" servers in any reasonable sens

> Maintaining your own server is completely nuts I've in this area professionally for some time now, and I've never "maintained" servers in any reasonable sense. There are kernel people who maintain the kernel and there are Debian devs who maintain the operating system. The server may be mine (but more often that not, it isn't) but only in very specific circumstances do I ever concern myself with maintaining any part of this stack. A vanilla Linux VM is a platform to build on. Just like AWS or anything else. It is the environment in which my software runs. Thus far, something like Debian has been more stable and much less of a moving target than any proprietary platform has been, cloud or non-cloud. Should a client wish to minimize maintenance costs of the software over the coming decade, it is most cost effective to not depend on specialized, proprietary, platform components. That may change in the future, but right now there is no indication that is the case.

numlock86 6y ago
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.
bartvk 6y ago
Yeah but those "very specific circumstances" can come up at inconvenient moments. Certbot didn't run, disk got full, CPU hitting 100% for some reason, Debian needed to be upgraded, These are all things that need to be taken care of. Sometimes, right away and just when your family needs you. I agree that it almost never happens, and that's why I run Debian as well. However, if you run production then things happen.
- this_was_posted 6y ago
  Just like when something unexpectedly breaks due to a component of the serverless environment that has been changed slightly causing your system to break, only then you have even less control when trying to debug the issue

numlock86 6y ago

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.

bartvk 6y ago

Yeah but those "very specific circumstances" can come up at inconvenient moments. Certbot didn't run, disk got full, CPU hitting 100% for some reason, Debian needed to be upgraded, These are all things that need to be taken care of. Sometimes, right away and just when your family needs you. I agree that it almost never happens, and that's why I run Debian as well. However, if you run production then things happen.

this_was_posted 6y ago
Just like when something unexpectedly breaks due to a component of the serverless environment that has been changed slightly causing your system to break, only then you have even less control when trying to debug the issue