4 ms·

Most projects I encounter these days instantly reach for kubernetes, containers and microservices or cloud functions. I find it much more appealing to just mak

Most projects I encounter these days instantly reach for kubernetes, containers and microservices or cloud functions. I find it much more appealing to just make the whole thing run on one fast machine. When you suggest this tend to people say "but scaling!", without understanding how much capacity there is in vertical. The thing most appealing about single server configs is the simplicity. The more simple a system easy, likely the more reliable and easy to understand. The software thing most people are building these days can easily run lock stock and barrel on one machine. I wrote a prototype for an in-memory message queue in Rust and ran it on the fastest EC2 instance I could and it was able to process nearly 8 million messages a second. You could be forgiven for believing the only way to write software is is a giant kablooie of containers, microservices, cloud functions and kubernetes, because that's what the cloud vendors want you to do, and it's also because it seems to be the primary approach discussed. Every layer of such stuff add complexity, development, devops, maintenance, support, deployment, testing and (un)reliability. Single server systems can be dramatically mnore simple because you can trim is as close as possible down to just the code and the storage.

judge2020 4y ago
Kubernetes and containers are a means to service architecture; It enabled scalability but does not require it. You should still be containerizing your applications to ensure a consistent environment, even if you only throw it in a docker-compose file on your production server.
- andrewstuart 4y ago
  I don't even use containers - I aim primarily for simplicity and so far I have found I am able to build entire sophisticated systems without a single container. Containers I find make things much more complex.
  - John23832 4y ago
    That just means you don't know how to architect a machine with containers (and if you're effective in what you do, that's ok). But it's a pretty objective notation that manually scaled single machines don't scale as well as automation.
  - TillE 4y ago
    Docker can be super simple. Like, if I want to run a Python service, that's just a few lines in a Dockerfile and a docker-compose.yml stub. Then I can trivially deploy that anywhere.
    - paulryanrogers 4y ago
      Simple to start. Yet it is more complex at run time, which can complicate (or simplify) debugging, depending on the problem.
      - judge2020 4y ago
        Observability in production is where APM solutions like Datadog, Elastic, and Sentry come in; you can go from just logging errors all the way up to continuously profiling your application and beaming log files to them to correlate with metrics and database query timings. If you're just doing a simple application, Sentry really is the way to go, while Datadog and ELK are agent-based and more intended for complex setups and big enterprises (especially in their pricing structure/infra costs).
  - fragmede 4y ago
    Are you at least using Ansible or Chef or something?
- KronisLV 4y ago
  > You should still be containerizing your applications to ensure a consistent environment, even if you only throw it in a docker-compose file on your production server. I'll say that this is a good point, especially because if you don't use containers or a similar solution (even things like shipping VM images, for all I care), you'll end up with environment drift, unless your application is a statically compiled executable with no system dependencies, like a JDK/.NET/Python/Ruby runtime or worse yet, an application server like Tomcat, all of which can have different versions. Worse yet, if you need to install packages on the system, for which you haven't pinned specific versions (e.g. needing something that's installed through apt/yum, rather than package.json or Gemfile, or requirements.txt and so on). That said, even when you don't use containers, you can still benefit from some pretty nice suggestions that will help make the software you develop easier to manage and run: https://12factor.net/ https://12factor.net/ I'd also suggest that you have a single mechanism for managing everything that you need to run, so if it's not containers and an orchestrator of some sort, at least write systemd services or an equivalent for every process or group of processes that should be running. Disclaimer: I still think that containers are a good idea, just because of how much of a dumpsterfire managing different OSes, their packages, language runtimes, application dependencies, application executables, port mappings, application resource limits, configuration, logging and other aspects is. Kubernetes, perhaps a bit less so, although when it works, it gets the job done... passably. Then again, Docker Swarm to me felt better for smaller deployments (a better fit for what you want to do vs the resources you have), whereas Nomad was also pretty nice, even if HCL sadly doesn't use the Docker Compose specification.
  - vbezhenar 4y ago
    When it comes to Java, everything could be used as a directory installation. Like you need JDK, maven and tomcat? Download and extract it somewhere. Modify your current PATH to include java and that's about it. You can build big tar.gz instead of OCI container which will work just fine. So IMO it's perfectly possible to run Java applications without containers. You would need to think about network ports, about resource limits, but those are not hard things. And tomcat even provides zero-downtime upgrades, although it's not that easy to set up, but when it works, it does work. After I've got some experience with Kubernetes, I'd reach for it always because it's very simple and easy to use. But that requires to go through some learning curve, for sure. The best and unbeatable thing about containers is that there're plenty of ready ones. I have no idea how would I install postgres without apt. I guess I could download binaries (where?), put them somewhere, read docs, craft config file with data dir pointing to anotherwere and so on. That should be doable but that's time. I can docker run it in seconds and that's saved time. Another example is ingress-nginx + cert-manager. It would take hours if not days from me to craft set of scripts and configs to replicate thing which is available almost out of the box in k8s, well tested and just works.
- ownagefool 4y ago
  So the goal is basically being able to do builds whilst running as few setup steps as possible. Containers are a good common denominator because you essentially start with the OS, and then there's a file that automates installing further dependencies and building the artifact, which typically includes the important parts of the runtime environment. - They're stupidly popular, so it basically nullifies the setup steps. - Once setup, they by combinding both OS layers and App, they solve more of the problem and are therefore slightly more reliable. - They're self-documenting as long as you understand bash, docker, and don't do weird shit like build an undocumented intermediary layer. Infrastructure as Code does the same thing for the underlying infra layers and kuberenetes is one of the nicer / quicker implementations of this, but requires you have kubernetes available. Together they largely solve the "works on my PC" problem.
tluyben2 4y ago
By far most indeed. And if you want failover, just run 2 two machines. More fun (for me) also than tying together all that complexity.
John23832 4y ago
Kubernetes just orchestrates containers. You can still run beefy machines and scale (if necessary) accordingly. If anything, Kubernetes allows you to save cost by going with a scalable number of small, inexpensive, fully utilized machines, vs one large, expensive, underused one.
- sitkack 4y ago
  I would wager that the majority of users of k8s do so on a cloud where they could provision VMs of the proper size to begin with. The utilization argument is specious.
  - John23832 4y ago
    > The utilization argument is specious. It's not. Utilization is a key metric in capacity planning of large scalable apps. Capacity is based upon max utilization. A scaled web app is does not have constant utilization. The parent I was responding to suggested running on one large/face instance. Ok... if you're capacity planning, are you planning for peak rps or min rps? Obviously peak. Peak times are always a fraction of your total server uptime. This means one big/fast server would be underutilized most of the time. How do you expect to dynamically vertically scale in cloud to fit demand while using a single server? Re-provision another server (either smaller or larger), redeploy all apps to the server, and then route traffic? Great, you're doing kubernetes job by hand.
traceroute66 4y ago
> I find it much more appealing to just make the whole thing run on one fast machine. Indeed. Lots of examples out there, one being Let's Encrypt[1] who run off one MySQL server (with a few read replicas but only one write). [1] https://letsencrypt.org/2021/01/21/next-gen-database-servers.html https://letsencrypt.org/2021/01/21/next-gen-database-servers...
- anamexis 4y ago
  That doesn't really seem like an example, since the whole thing doesn't run one machine. The database alone has multiple machines.
  - traceroute66 4y ago
    > That doesn't really seem like an example, since the whole thing doesn't run one machine. It is an example. It shows you how you can run a service that issues a few hundred million SSL certs a year off relatively few pieces of hardware, i.e. no need to go drinking the cloud Kool aid. There will never be a "perfect" example. The overall point here is demonstrating that the first answer to everything doesn't have to include the word "cloud". > The database alone has multiple machines. As I said, and the blog says ... there is only one writer. The other nodes are smaller read replicas. Which again shows you don't need to go with the cloud buzzword-filled database services.
    - erik 4y ago
      Last I read, Hacker News was still running on one big machine. And still uses text files as its database.
      - threeseed 4y ago
        Twitter runs ads and generates billions in revenue. It can't just tolerate being down or having under-load issues like HN often is.
    - threeseed 4y ago
tambourine_man 4y ago
>… without understanding how much capacity there is in horizontal. I think you mean vertical, right?
- andrewstuart 4y ago
  Ha ha yes I do! (corrected)
  - tambourine_man 4y ago
    Freudian slip :)
vasco 4y ago
Kubernetes is useful if you have many teams working on things in parallel and you want them to deploy in similar ways to not have to reinvent the same wheel in 5 different ways by 5 different teams. If you don't have multiple teams, you don't need it.
- jupp0r 4y ago
  It's also useful if you want your app to update without being down, which even a single team might want to do.
  - dinosaurdynasty 4y ago
    You don't need k8s for that, teams have been doing that for decades before k8s was ever a thing
    - jupp0r 4y ago
      Sure, but whatever they built themselves to accomplish this is also complicated. I know because I have built such systems (and replaced them by k8s).
      - erulabs 4y ago
        Hah, exactly. It's not that you can't accomplish all the same things as k8s with your own bash scripts - it's that k8s exists to replace all your custom bash scripts!
        jupp0r 4y ago
        But you can still land on top of HN with a "I replaced kubernetes with this 500 line bash script without unit tests" blog article ;)
yodsanklai 4y ago
> The thing most appealing about single server configs is the simplicity. The more simple a system easy, likely the more reliable and easy to understand. What if your unique machine crash?
- readonlybarbie 4y ago
  [dead]
- andrewstuart 4y ago
  Well you gotta have a backup strategy. I'm talking about the primary machine here, I assumed that would be obvious but maybe not. You build your failover strategy into your architecture - there's lots of ways to do it - I use Postgres so I would favor something based around log shipping.
  - ffssffss 4y ago
    And uptime is important, so you want to have that secondary running and ready, with a proxy in front of everything so you can switch as soon as you detect a failure. That's three hosts, plus your alerting has to be separate too, so that's four. Now, to orchestrate all this, we'll first get out Puppet...
    - toast0 4y ago
      If you're going from one machine to two, and you add an automatically failover mechansim, chances are your load switching mechanism is going to cause more downtime than just running from your single machine, and manually switching on failure (after being paged).
- pclmulqdq 4y ago
  You spin up a backup as the new "unique machine."
- fbdab103 4y ago
  I think you should always plan for failures, but modern enterprise hardware is quite reliable. I would even posit that if you stood up a brand new physical server today, it has a good chance of beating AWS uptime (well, not the AWS dashboard numbers) over a one year period.
Thaxll 4y ago
Because OP example is very simplistic and left on the table very important details, you would base 250M on a single machine? What about backups, obervability, how do you update that stack without bringing down everything ... Also this is napkin maths, this could be off by 10 or 100x which would change everything. It's very simple to make a PoC on a very powerful machine, make it ready from production serving hunderd of millions of users is completely different.
- jupp0r 4y ago
  In addition, you should worry about what happens to your app if a hardware error, network problem or natural disaster makes your machine unavailable.
  - eddsh1994 4y ago
    Split the DB from the app and replicate with a load balancer?
    - jupp0r 4y ago
      Now you have "Production Twitter on three machines". Follow the rabbit and you end up with something like what Twitter looks like today.
    - threeseed 4y ago
      That database is going to need to be clustered as well for resiliency. Sounds like you already have quite a number of different containers already.
      - eddsh1994 4y ago
        Four vms isn’t too bad to manage, I was the first dev at a startup that went prelaunch to acquisition from 2 App/DB servers in EC2 for a mobile app that hit #1 on both stores with a fairly high user tx rate and some ML stuff.
  - pixl97 4y ago
fifilura 4y ago
I dont think k8s is what you are shooting at but the IPC that is required to run a set of microservices. Like kafka. My impression is that it is the serialisation that comes with each service-to-service communication that is really expensive.
pikdum 4y ago
I go with k8s even on a single server nowadays, it just makes everything so much more convenient. https://k3s.io/ https://k3s.io/ makes it really easy to set up, too.
- vbezhenar 4y ago
  I never tried k3s, but what's wrong with kubeadm? I think that's literally two commands to run single server k8s: kubeadm init and kubectl taint something. The only thing bad about single server kubernetes is that it'll eat like 1-2 GB of RAM by itself. When you whole server could be 256 MB, that's a lot of wasted RAM.
  - pikdum 4y ago
    Nothing wrong with kubeadm, but k3s should be a bit more lightweight.
yazzku 4y ago
If I remember correctly, Lichess runs on a single server.
vbezhenar 4y ago
Projects are optimized to be developed by so-called ordinary developers. We have python service which consumes gigabytes of RAM for quite simple task. I'm sure that I'd rewrite it with Rust to consume tens of megabytes of RAM at most. Probably even less. But I don't have time for that, there are more important things to consider and gigabytes is not that bad. Especially when you have some hardware elasticity with cloud resources. I think that if you can develop world-scale twitter which could run on a single computer, that's a great skill. But it's a rare skill. It's safer to develop world-scale twitter which will run on Kubernetes and will not require rare developer skills.
brightball 4y ago
I tend to agree on simplicity. Really just depends on whether you can tolerate downtime for either outages or deployments. As soon as you start accounting for redundancy you have to fan out anyway.
kbumsik 4y ago
> The thing most appealing about single server configs is the simplicity. In my experience this ended up with more complicated. Those systems are typically developed by people who already left and are undocumented, and they become extremely difficult to figure out the config (packages, etc files... oh, where even the service files are located?) and almost impossible to reproduce. It might be okay to leave it there, but when we need to modify or troubleshoot the system a nightmare begins... Maybe I was just unlucky, but at least k8s configs are more organized and simpler than dealing with a whole custom configured Linux system.
deleted 4y ago
[deleted]

judge2020 4y ago

Kubernetes and containers are a means to service architecture; It enabled scalability but does not require it. You should still be containerizing your applications to ensure a consistent environment, even if you only throw it in a docker-compose file on your production server.

andrewstuart 4y ago
I don't even use containers - I aim primarily for simplicity and so far I have found I am able to build entire sophisticated systems without a single container. Containers I find make things much more complex.
- John23832 4y ago
  That just means you don't know how to architect a machine with containers (and if you're effective in what you do, that's ok). But it's a pretty objective notation that manually scaled single machines don't scale as well as automation.
- TillE 4y ago
  Docker can be super simple. Like, if I want to run a Python service, that's just a few lines in a Dockerfile and a docker-compose.yml stub. Then I can trivially deploy that anywhere.
  - paulryanrogers 4y ago
    Simple to start. Yet it is more complex at run time, which can complicate (or simplify) debugging, depending on the problem.
    - judge2020 4y ago
      Observability in production is where APM solutions like Datadog, Elastic, and Sentry come in; you can go from just logging errors all the way up to continuously profiling your application and beaming log files to them to correlate with metrics and database query timings. If you're just doing a simple application, Sentry really is the way to go, while Datadog and ELK are agent-based and more intended for complex setups and big enterprises (especially in their pricing structure/infra costs).
- fragmede 4y ago
  Are you at least using Ansible or Chef or something?
KronisLV 4y ago
> You should still be containerizing your applications to ensure a consistent environment, even if you only throw it in a docker-compose file on your production server. I'll say that this is a good point, especially because if you don't use containers or a similar solution (even things like shipping VM images, for all I care), you'll end up with environment drift, unless your application is a statically compiled executable with no system dependencies, like a JDK/.NET/Python/Ruby runtime or worse yet, an application server like Tomcat, all of which can have different versions. Worse yet, if you need to install packages on the system, for which you haven't pinned specific versions (e.g. needing something that's installed through apt/yum, rather than package.json or Gemfile, or requirements.txt and so on). That said, even when you don't use containers, you can still benefit from some pretty nice suggestions that will help make the software you develop easier to manage and run: https://12factor.net/ https://12factor.net/ I'd also suggest that you have a single mechanism for managing everything that you need to run, so if it's not containers and an orchestrator of some sort, at least write systemd services or an equivalent for every process or group of processes that should be running. Disclaimer: I still think that containers are a good idea, just because of how much of a dumpsterfire managing different OSes, their packages, language runtimes, application dependencies, application executables, port mappings, application resource limits, configuration, logging and other aspects is. Kubernetes, perhaps a bit less so, although when it works, it gets the job done... passably. Then again, Docker Swarm to me felt better for smaller deployments (a better fit for what you want to do vs the resources you have), whereas Nomad was also pretty nice, even if HCL sadly doesn't use the Docker Compose specification.
- vbezhenar 4y ago
  When it comes to Java, everything could be used as a directory installation. Like you need JDK, maven and tomcat? Download and extract it somewhere. Modify your current PATH to include java and that's about it. You can build big tar.gz instead of OCI container which will work just fine. So IMO it's perfectly possible to run Java applications without containers. You would need to think about network ports, about resource limits, but those are not hard things. And tomcat even provides zero-downtime upgrades, although it's not that easy to set up, but when it works, it does work. After I've got some experience with Kubernetes, I'd reach for it always because it's very simple and easy to use. But that requires to go through some learning curve, for sure. The best and unbeatable thing about containers is that there're plenty of ready ones. I have no idea how would I install postgres without apt. I guess I could download binaries (where?), put them somewhere, read docs, craft config file with data dir pointing to anotherwere and so on. That should be doable but that's time. I can docker run it in seconds and that's saved time. Another example is ingress-nginx + cert-manager. It would take hours if not days from me to craft set of scripts and configs to replicate thing which is available almost out of the box in k8s, well tested and just works.
ownagefool 4y ago
So the goal is basically being able to do builds whilst running as few setup steps as possible. Containers are a good common denominator because you essentially start with the OS, and then there's a file that automates installing further dependencies and building the artifact, which typically includes the important parts of the runtime environment. - They're stupidly popular, so it basically nullifies the setup steps. - Once setup, they by combinding both OS layers and App, they solve more of the problem and are therefore slightly more reliable. - They're self-documenting as long as you understand bash, docker, and don't do weird shit like build an undocumented intermediary layer. Infrastructure as Code does the same thing for the underlying infra layers and kuberenetes is one of the nicer / quicker implementations of this, but requires you have kubernetes available. Together they largely solve the "works on my PC" problem.

tluyben2 4y ago

By far most indeed. And if you want failover, just run 2 two machines. More fun (for me) also than tying together all that complexity.

John23832 4y ago

Kubernetes just orchestrates containers. You can still run beefy machines and scale (if necessary) accordingly. If anything, Kubernetes allows you to save cost by going with a scalable number of small, inexpensive, fully utilized machines, vs one large, expensive, underused one.

sitkack 4y ago
I would wager that the majority of users of k8s do so on a cloud where they could provision VMs of the proper size to begin with. The utilization argument is specious.
- John23832 4y ago
  > The utilization argument is specious. It's not. Utilization is a key metric in capacity planning of large scalable apps. Capacity is based upon max utilization. A scaled web app is does not have constant utilization. The parent I was responding to suggested running on one large/face instance. Ok... if you're capacity planning, are you planning for peak rps or min rps? Obviously peak. Peak times are always a fraction of your total server uptime. This means one big/fast server would be underutilized most of the time. How do you expect to dynamically vertically scale in cloud to fit demand while using a single server? Re-provision another server (either smaller or larger), redeploy all apps to the server, and then route traffic? Great, you're doing kubernetes job by hand.

traceroute66 4y ago

> I find it much more appealing to just make the whole thing run on one fast machine. Indeed. Lots of examples out there, one being Let's Encrypt[1] who run off one MySQL server (with a few read replicas but only one write). [1] https://letsencrypt.org/2021/01/21/next-gen-database-servers.html https://letsencrypt.org/2021/01/21/next-gen-database-servers...

anamexis 4y ago
That doesn't really seem like an example, since the whole thing doesn't run one machine. The database alone has multiple machines.
- traceroute66 4y ago
  > That doesn't really seem like an example, since the whole thing doesn't run one machine. It is an example. It shows you how you can run a service that issues a few hundred million SSL certs a year off relatively few pieces of hardware, i.e. no need to go drinking the cloud Kool aid. There will never be a "perfect" example. The overall point here is demonstrating that the first answer to everything doesn't have to include the word "cloud". > The database alone has multiple machines. As I said, and the blog says ... there is only one writer. The other nodes are smaller read replicas. Which again shows you don't need to go with the cloud buzzword-filled database services.
  - erik 4y ago
    Last I read, Hacker News was still running on one big machine. And still uses text files as its database.
    - threeseed 4y ago
      Twitter runs ads and generates billions in revenue. It can't just tolerate being down or having under-load issues like HN often is.
  - threeseed 4y ago

tambourine_man 4y ago

>… without understanding how much capacity there is in horizontal. I think you mean vertical, right?

andrewstuart 4y ago
Ha ha yes I do! (corrected)
- tambourine_man 4y ago
  Freudian slip :)

vasco 4y ago

Kubernetes is useful if you have many teams working on things in parallel and you want them to deploy in similar ways to not have to reinvent the same wheel in 5 different ways by 5 different teams. If you don't have multiple teams, you don't need it.

jupp0r 4y ago
It's also useful if you want your app to update without being down, which even a single team might want to do.
- dinosaurdynasty 4y ago
  You don't need k8s for that, teams have been doing that for decades before k8s was ever a thing
  - jupp0r 4y ago
    Sure, but whatever they built themselves to accomplish this is also complicated. I know because I have built such systems (and replaced them by k8s).
    - erulabs 4y ago
      Hah, exactly. It's not that you can't accomplish all the same things as k8s with your own bash scripts - it's that k8s exists to replace all your custom bash scripts!
      - jupp0r 4y ago
        But you can still land on top of HN with a "I replaced kubernetes with this 500 line bash script without unit tests" blog article ;)

yodsanklai 4y ago

> The thing most appealing about single server configs is the simplicity. The more simple a system easy, likely the more reliable and easy to understand. What if your unique machine crash?

readonlybarbie 4y ago
[dead]
andrewstuart 4y ago
Well you gotta have a backup strategy. I'm talking about the primary machine here, I assumed that would be obvious but maybe not. You build your failover strategy into your architecture - there's lots of ways to do it - I use Postgres so I would favor something based around log shipping.
- ffssffss 4y ago
  And uptime is important, so you want to have that secondary running and ready, with a proxy in front of everything so you can switch as soon as you detect a failure. That's three hosts, plus your alerting has to be separate too, so that's four. Now, to orchestrate all this, we'll first get out Puppet...
  - toast0 4y ago
    If you're going from one machine to two, and you add an automatically failover mechansim, chances are your load switching mechanism is going to cause more downtime than just running from your single machine, and manually switching on failure (after being paged).
pclmulqdq 4y ago
You spin up a backup as the new "unique machine."
fbdab103 4y ago
I think you should always plan for failures, but modern enterprise hardware is quite reliable. I would even posit that if you stood up a brand new physical server today, it has a good chance of beating AWS uptime (well, not the AWS dashboard numbers) over a one year period.

Thaxll 4y ago

Because OP example is very simplistic and left on the table very important details, you would base 250M on a single machine? What about backups, obervability, how do you update that stack without bringing down everything ... Also this is napkin maths, this could be off by 10 or 100x which would change everything. It's very simple to make a PoC on a very powerful machine, make it ready from production serving hunderd of millions of users is completely different.

jupp0r 4y ago
In addition, you should worry about what happens to your app if a hardware error, network problem or natural disaster makes your machine unavailable.
- eddsh1994 4y ago
  Split the DB from the app and replicate with a load balancer?
  - jupp0r 4y ago
    Now you have "Production Twitter on three machines". Follow the rabbit and you end up with something like what Twitter looks like today.
  - threeseed 4y ago
    That database is going to need to be clustered as well for resiliency. Sounds like you already have quite a number of different containers already.
    - eddsh1994 4y ago
      Four vms isn’t too bad to manage, I was the first dev at a startup that went prelaunch to acquisition from 2 App/DB servers in EC2 for a mobile app that hit #1 on both stores with a fairly high user tx rate and some ML stuff.
- pixl97 4y ago

fifilura 4y ago

I dont think k8s is what you are shooting at but the IPC that is required to run a set of microservices. Like kafka. My impression is that it is the serialisation that comes with each service-to-service communication that is really expensive.

pikdum 4y ago

I go with k8s even on a single server nowadays, it just makes everything so much more convenient. https://k3s.io/ https://k3s.io/ makes it really easy to set up, too.

vbezhenar 4y ago
I never tried k3s, but what's wrong with kubeadm? I think that's literally two commands to run single server k8s: kubeadm init and kubectl taint something. The only thing bad about single server kubernetes is that it'll eat like 1-2 GB of RAM by itself. When you whole server could be 256 MB, that's a lot of wasted RAM.
- pikdum 4y ago
  Nothing wrong with kubeadm, but k3s should be a bit more lightweight.

yazzku 4y ago

If I remember correctly, Lichess runs on a single server.

vbezhenar 4y ago

Projects are optimized to be developed by so-called ordinary developers. We have python service which consumes gigabytes of RAM for quite simple task. I'm sure that I'd rewrite it with Rust to consume tens of megabytes of RAM at most. Probably even less. But I don't have time for that, there are more important things to consider and gigabytes is not that bad. Especially when you have some hardware elasticity with cloud resources. I think that if you can develop world-scale twitter which could run on a single computer, that's a great skill. But it's a rare skill. It's safer to develop world-scale twitter which will run on Kubernetes and will not require rare developer skills.

brightball 4y ago

I tend to agree on simplicity. Really just depends on whether you can tolerate downtime for either outages or deployments. As soon as you start accounting for redundancy you have to fan out anyway.

kbumsik 4y ago

> The thing most appealing about single server configs is the simplicity. In my experience this ended up with more complicated. Those systems are typically developed by people who already left and are undocumented, and they become extremely difficult to figure out the config (packages, etc files... oh, where even the service files are located?) and almost impossible to reproduce. It might be okay to leave it there, but when we need to modify or troubleshoot the system a nightmare begins... Maybe I was just unlucky, but at least k8s configs are more organized and simpler than dealing with a whole custom configured Linux system.

deleted 4y ago

[deleted]