11 ms·

Main benefits of Kubernetes: • Lets companies brag about having # many production services at any given time • Company saves money by not having to hire Linux

by zelly 6y ago

Main benefits of Kubernetes: • Lets companies brag about having # many production services at any given time • Company saves money by not having to hire Linux sysadmins • Company saves money by not having to pay for managed cloud products if they don't want to • Declarative, version controlled, git-blameable deployments • Treating cloud providers like cattle not pets It's going to eat the world (already has?). I was skeptical about Kubernetes but I now understand why it's popular. The alternatives are all based on kludgy shell/Python scripts or proprietary cloud products. It's easy to get frustrated with it because it's ridiculously complex and introduces a whole glossary of jargon and a whole new mental model. This isn't Linux anymore. This is, for all intents and purposes, a new operating system. But the interface to this OS is a bunch of <strike>punchcards</strike> YAML files that you send off to a black box and hope it works. You're using a text editor but it's not programming. It's only YAML because it's not cool to use GUIs for system administration anymore (e.g. Windows Server, cPanel). It feels like configuring a build system or filling out taxes--absolute drudgery that hopefully gets automated one day. The alternative to K8s isn't your personal collection of fragile shell scripts. The real alternative is not doing the whole microservices thing and just deploying a single statically linked, optimized C++ server that can serve 10k requests per second from a toaster--but we're not ready to have that discussion.

paloaltokid 6y ago
I've never coded in C++, so I'm curious - what is the feedback loop like? My understanding is that since C++ is a compiled language, you can't "hit refresh" the same way you can in JavaScript/Ruby/etc. Is that an incorrect understanding? I know C++ is supposed to be great for performance, but in truth I've never needed anything to be that fast. And if I can get the job done just as well with something I already know, I won't bother learning something like C++ which has a reputation for not being approachable. But maybe I don't have full context?
- lloeki 6y ago
  The other day (actually years) I did a gamejam in Go, I bound Cmd+R to essentially the following: system("go build") exec("./main") Not a literal hot code reload that some advanced stuff get to enjoy, but nice enough to shorten the feedback loop.
- d3nj4l 6y ago
  If you're a ruby user looking for extra performance, try Crystal[1]. Everything you love + types compiled to native binaries. You can set up sentry[2] to autocompile and run every time you save, so the feedback loop is just as tight. [1]: https://crystal-lang.org/ https://crystal-lang.org/ [2]: https://github.com/samueleaton/sentry https://github.com/samueleaton/sentry
- astrobe_ 6y ago
  Technically you can have some sort of command in your C++ program to make it fork itself, that is restart itself disk, maybe after freeing non-shareable resources like listening sockets. One could even imagine that this command includes self-recompilation by invoking make (or whatever your build system is). An alternative is to have your program expose its pid somewhere, and your make file could send a signal to that pid when a new version is ready. The advantage is that if your program crashes on startup, you don't have to do something different to restart it. If your application has to include an "auto-update" feature (like browsers), use that instead - its certainly better to eat your own dog food. Maybe just hack it a little bit so that you can force a check programmatically (e.g. by sending it a signal) and so that it connects to a local updates server. It is true that C++ is an overly complicated language; if you don't need maximal performance, you have a lot of AoT languages that are a bit slower ( something around 0.5 C ) but more "user-friendly". In particular, if you are into servers and want fast edit-compile-run loops, Go might be a good choice.
- JeanMarcS 6y ago
  > I've never needed anything to be that fast In a world where you are billed by ressources used, wouldn’t it be a good idea to have light and fast services that don’t consume those ressources ? I’ve been wondering this for a time now.
  - pathseeker 6y ago
    The part of the equation you are missing is how little traffic the majority of business applications end up seeing. A B2B app that has at most 10 concurrent requests can run on the smallest EC2 instance whether it's written in PHP or written in C++. Bandwidth doesn't change with language choice and neither does the storage requirements of your app so those billable items don't come into the equation either. So the CPU cost can effectively be dropped off of 95% of the apps out there today. At that point your main variable cost between C++ and something like PHP/Javascript is going to be the cost of development. All I can say to that is that it's a lot harder to find developers who can write C++ web apps at the same pace as developers slinging PHP for web apps. There is a reason Facebook uses a PHP derivative for huge portions of its web backend.
    - JeanMarcS 6y ago
      I agree with you. So maybe the question we should ask ourselves is: why isn’t there a smaller, cheaper EC2 instance (or any other provider than AWS) ? This industry is tailoring the levels. Of course it’s understandable because, well, they live on it. And they count on small instances to share hardware ressources to overbook said hardware. And I don’t blame them for that, I’m doing the same on my own bare metal servers, hosting multiple websites for clients and making money on it. But I have the feeling that there is a lot of ressource loss somewhere in it, just for the sake of loosing it because it’s easier. Maybe I’m wrong.
      - pas 6y ago
        Scaleway, Hetzner, OVH, DigitalOcean, etc. AWS LightSail. ... also the t1.micro is small and cheap. Could you give some concrete numbers?
- Perseids 6y ago
  It doesn't have to be C++ of course. The main point of OP lies in C++ being fast and easy to deploy (at least it can be). Go, Rust, to some extend C# and Java also fall in that category. This feature set becomes interesting, because it has the potential to simplify everything around it. If you don't need high fault tolerance you can go a very long way with just a single server, maybe sprinkled with some CDN caching in front if your users are international. If you do need higher availability you can go the route StackOverflow was famous for for quite some time of having a single ReadWrite master server, a backup master to take over and a few of ReadOnly slave servers, IIRC. With such setups you can ignore all the extra complexities cloud deployments bring with them. And just because such simple setups make it possible to treat servers like pets, doesn't mean they have to be irreproducible undocumented messes.
- zelly 6y ago
  Go will get you 90% there in performance. I recommend that instead of C++ because it compiles fast for that edit-build-refresh cycle. Go also has the benefit of producing static binaries by default which solves a lot of the problems Docker was for. C++ is more for the extreme control over memory. An optimized C++ server can max out the NIC even on a single core and even with some text generation/parsing along the way.
- pas 6y ago
  Working in strongly statically typed languages is quite different, because the types (and the IDE/compiler) guides you. You don't have to hit refresh that often. Even just working in TypeScript with TSed and a few basic strongly typed concepts (Rust's Result equivalent in TS, Option or Maybe, and typed http request/response, and Promise and JSON.parse) makes a big difference. A lot less okay, just echo/print/log this object (or look up documentation eew), look at what does this look like and how to transform it into what I need. Instead you do that in the IDE.
edwinyzh 6y ago
or a Free Pascal server (powered by mORMot (https://github.com/synopse/mORMot) https://github.com/synopse/mORMot))? Natively compiled, high performance, and supports almost all OS's and CPU's
- slim 6y ago
  404 not found
  - narag 6y ago
    Try removing the trailing parenthesis.
danielovichdk 6y ago
Absolutely agree. A lot of people is just really interested in having something complex instead of understanding their actual needs.
atopuzov 6y ago
So now it's kubernetes + kludgy shell/Python scripts.
- pas 6y ago
  If it makes things more deterministic, then yeah, why not?
pwdisswordfish2 6y ago
I am ready! NetBSD is running on the toaster. I think haproxy can do 10K req/s. tcpserver on the backends. I only write robust shell scripts, short and portable. As a spectator, not a tech worker who uses these popular solutions, I would say there seems to be a great affinity amongst in the tech industry for anything that is (relatively) complex. Either that, or the only solutions people today can come up with are complex ones. The more features and complexity, the more something is constantly changing, the more a new solution gains "traction". If anyone reading has examples that counter this idea, please feel free to share them. I think if a hobbyist were to "[deploy] a single statically linked, optimized [C++] server that can serve 10k requests per second from a toaster" it would be like a tree falling in the forest. For one because it is too simple, it lacks the complexity that attracts the tech worker crowd, and second, because it is not being used by well-known tech company and not being worked on by large numbers of people, it would not be newsworthy.
- tutfbhuf 6y ago
  I can see your point for small hobby projects. But enterprise web development in C++ is no fun at all. For example: "Google says that about 70% of all serious security bugs in the Chrome codebase are related to memory management and safety." https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs... Developer time for fixing these bugs is in most cases more expensive, than to throw more hardware at your software written in a garbage collected language.
  - Perseids 6y ago
    True, but the alternative to C++ with that reasoning is Rust or Go (depending on your liking), not Ruby. And with both of these you can step around a lot of deployment issues, because a single server can be sufficient for quite high loads. Avoid distributed systems as much as you can: https://thume.ca/2020/05/17/pipes-kill-productivity/ https://thume.ca/2020/05/17/pipes-kill-productivity/
    - pas 6y ago
rocho 6y ago
I don't agree with the last paragraph. Your C++ example is orthogonal to the deployment aspect because it discusses the application. Kubernetes and the fragile shell scripts are about the deployment of said application. How are you going to deploy your C++ application? Both options are available, and I would wager that in most cases, Kubernetes makes more sense, unless you have strict requirements.
- jrumbut 6y ago
  In a world where your architecture is that simple I don't think kubernetes would be the choice for long. I think for the average application there's still something to be said for manual cross-layer optimization between infrastructure, application, and how both are deployed. What I mean is we can't yet draw too clear a line between the application and how it's deployed because there are real tradeoffs between keeping future options open and getting the product out the door. A strength of kubernetes is that if you get good at it it works for a variety of projects, but a lot of effort is needed to get to that point and that effort could have gone into something else.
  - p_l 6y ago
    Even then there's the question of "where are the logs?" "how is the application deployed?" etc.
- zelly 6y ago
  Kubernetes is for orchestrating a distributed system. What I was suggesting is to (1) make a monolith and (2) make it fast, light and high-throughput. The goal of your service is to reliably serve users at scale; this is just another way of doing it, just much more esoteric. A "C++ monolith" allows me to potentially bypass a lot of this deployment stuff because it could serve lots (millions) of users from a single box.
  - harpratap 6y ago
    >Kubernetes is for orchestrating a distributed system. No it's not. You can use it to run bunch of monoliths too. K8s provides a common API layer that all of your organisation can adhere to. Just like containers are a generic encapsulation of any runable code.
nonines 6y ago
Can't agree more. To this add the moving-sand landscape of an ecosystem there. But then again it's actually the first public/popular attempt on a cloud OS. There might be a next one with better ergonomics than yamls.
- howox 6y ago
  Well aren't Openshift and Rancher offering those ergonomics?
baybal2 6y ago
I don't think that kubernetes is getting popular at all.
bmikaili 6y ago
Disagree with the GUI part. Text based configuration is stable, version-controllable, and intuitive to use. Look at Xcode for a nightmare of GUI configuration.
- capableweb 6y ago
  > stable, version-controllable, and intuitive to use Neither of those features are inherently impossible to do with GUIs. Alternatively, you can have a GUI editing your text based configuration. Although, doesn't look as cool so, here we are.
  - pas 6y ago
    There are quite a few GUI tools for k8s. Currently mainstream k8s is text based, because it's still too fast moving and new. Creating a great GUI would be a serious overhead and there's not enough interest/demand for it. It'll come eventually.
    - Multicomp 6y ago
      Rancher does a lot of the orchestrating of k8s clusters and works well in my experience.
      - howox 6y ago
        Rancher is even more approachable and streamlined than Openshift. Yeah we need k8s to be more streamlined. It's fragmented cluster-something right now. There is no pride in making systems more complex nor there is pride in knowing how to operate them.
    - yrro 6y ago
      OpenShift's web interface lets you do a lot (other alternatives are of course available). And it's quite nice being able to edit the YAML of everything via the web interface as well!
saalaa 6y ago
This, and more but it's all in the same vein. I was pretty skeptical too but then handed over a project which was a pretty typical mixed bag: Ansible, Terraform, Docker, Python and shell scripts, etc... Then I realized relying on Kubernetes for most projects has the huge benefit of bringing homogeneity to the provisioning/orchestration which improves things a lot both for me and the customer or company I work for. Let's be honest here, in many cases it does not make a difference whether Kubernetes is huge, inefficient, complicated, bloated, etc... or not. It certainly is. But just the added benefit of pointing at a folder and stating : "this is how it is configured and how it runs" is huge. I was also pretty skeptical of Kustomize but it turned out to be just enough. So, like many here. I kind of hate it but it serves me well.
- collyw 6y ago
  I am still not convinced by Kubernetes, but you make a good point.
- spenrose 6y ago
  As a fellow Kubernetes-hater, this is the best explanation I've read for its virality. Thanks!
101404 6y ago
I like that alternative. Especially now that we have Rust and Actix Web.
dorian-graph 6y ago
> • Company saves money by not having to hire Linux sysadmins .. but hire others to manage k8s? Or existing software engineers have to spend time doing so? Many of the other points don't seem unique to k8s either. I do like the alternative you've suggested though.
wastedhours 6y ago
Are there any decent GUI services for creating the YAML files? Most of it can be managed by text boxes on the front-end with selections and then it can just generate or edit the required files at the end of a wizard?
SomeoneFromCA 6y ago
AFAIK, Yandex Taxi uses "single statically linked, optimized C++ server that can serve".
max_effort 6y ago
> • Company saves money by not having to pay for managed cloud products if they don't want to In some cases, the cost of a managed cloud product may be cheaper than the cost of training your engineers to work with K8s. It just depends on what your needs are, and the level of organizational commitment you have to making K8s part of your stack. Engineers like to mess around with new tech (I'm certainly guilty of this), but their time investment is often a hidden cost. > The alternatives are all based on kludgy shell/Python scripts or proprietary cloud products. The fact that PaaS products are proprietary is often listed as a detriment. But, how detrimental is it really? There are plenty of companies whose PaaS costs are insignificant compared to their ARR, and they can run the business for years without ever thinking about migrating to a new provider. The managed approach offered by PaaS can be a sensible alternative to K8s, again it just depends on what your organizational needs are.
banifo 6y ago
"The alternative to K8s isn't your personal collection of fragile shell scripts. The real alternative is not doing the whole microservices thing and just deploying a single statically linked, optimized C++ server that can serve 10k requests per second from a toaster--but we're not ready to have that discussion." You are writing this and i thought yesterday how to extend my current home k8s setup even further. I would even manage that little c++ tool through k8s. K8s brings plenty of other things out of the box: - Rolling update - HA - Storage provisioning (which makes backup simpler) - Infrastructure as code (whatever your shellscript is doing) I think that the overhead k8s requires right now, will become smaller over the years, it will be simpmler to use it, it will become more and more stable. It is already a really simple and nice control plane. I like to use a few docker containers with compose. But if i already use docker compose for 2 projects, why not just using k8s instead?
tsss 6y ago
If you really think that deploying a single binary is an alternative to microservices then you don't understand microservices.
robert_g 6y ago
I would speculate that for companies these two statements will be exclusive: • Company saves money by not having to hire Linux sysadmins • Company saves money by not having to pay for managed cloud products if they don't want to As a developer I want to right code, not manage a Kubernetes installation. If my employer wants the most value from my expertice they will either pay for a hosted environment to minimize my time managing it or hire dedicated staff to maintain an environment.
burntoutfire 6y ago
> The real alternative is not doing the whole microservices thing and just deploying a single statically linked, optimized C++ server that can serve 10k requests per second from a toaster--but we're not ready to have that discussion. The alternative is to have a old and boring cluster of X identical java nodes which host the entire backend in a single process... The deployment is done by a pedestrian bash script from a Jenkins. It used to work fine for too long I guess and folks couldn't resist "inventing" microservices to "disrupt" it.
eyberg 6y ago
> Company saves money by not having to hire Linux sysadmins Citation? In my experience companies hire more sysadmins when adopting k8s. It's trivial to point at the job reqs for it. > Company saves money by not having to pay for managed cloud products if they don't want to Save money?! Again citation. What are you replacing in the cloud with k8s? In my experience most companies using k8s (as you already admitted) don't have a ton of ops experience and thus use more cloud resources. > Treating cloud providers like cattle not pets Again. Citation? Companies go multi-cloud not because they want to but because they have different teams (sometimes from acquisition) that have pre-existing products that are hard to move. No one is using k8s to get multi-cloud as a strategy. > It's going to eat the world (already has?). Not it won't. It's actually on the downtrend now. Do you work for the CNCF? Can you put in a disclaimer if so? > just deploying a single statically linked, optimized C++ server that can serve 10k requests per second from a toaster completely un-necessary; most of the HN audience is not creating a c++ webserver from scratch; most of the HN audience can trivially serve way more than 10k reqs/sec from a single vm (node, rust, go, etc. are all easily capable of doing this from 1 vcpu)
- tapirl 6y ago
  You says all what I want to say.
pjmlp 6y ago
And this is why I only give Linux like one decade more to still be relevant on the server. With hypervisors and managed environments taking over distributed computing, if there is a kernel derived from Linux or something completely different, it is a detailed that only the cloud provider cares about.
- kag0 6y ago
  That doesn't really make sense in the context of docker. It's still Linux inside the container. Even if it's some abstract non-Linux service thing running the container, what happens in the container is still the concern of the developer.
  - pjmlp 6y ago
    Yes it does, my application written in Go, Java, .NET, doesn't care if the runtime is bare metal, running on an hypervisor type 2, type 1 or some other OS. I run Docker on Windows Containers, no Linux required. There are also the ugly named serverless deployments, where the kernel is meaningless.
buboard 6y ago
What is your estimate about when we ll be ready to have that discussion?
neop1x 6y ago
Your static app won't scale. Once your kernel is saturated with connections, once your buffers are full, you will get packets dropped. Your app may crash unexpectedly so you need to run it in an infinite loop. And of course your static example is a simple echo app or hello world. That works fine from a toaster. In the real world we use databases where every store takes a significant time to process and persist. You quickly overgrow a single server. Then you need distributed systems and a way to do versioning so you use containers and then you need an orchestrator so you pick K8S because it's most mature and there are many resources around. And then you can even do rolling updates and rollbacks. Finally you use Helm, Terraform and Terragrunt and never look back. It works surprisingly good. I lost several years by learning all this stuff, it was difficult but it was worth it. I have more visibility into everything now thanks to metrics-server, Prometheus Operator, Grafana, Loki and I have two environments so I can update deployments in one environment and test, once tested ok, I can apply to live. No surprises. No need to run 5 year old versions of software and fear updating it...
p_l 6y ago
You still need quite a lot of stuff for that one, statically linked, heavily optimized C++ server. In a way, that's actually what k8s comes from ... How do you manage deployments for that C++ monolith? How is the logging? Logrotate, log gathering and analysis? Metrics, their analysis and and display? What happens when you have software developed by others that you might also to want to deploy? (If you can run a company with only one program ever deployed, I envy you). All of that is simplified by kubernetes by simply making all stuff follow single way - "classical" approaches tend to make Perl blush with the amount of "There is more than one way to do it" that goes on.

by zelly 6y ago

paloaltokid 6y ago

I've never coded in C++, so I'm curious - what is the feedback loop like? My understanding is that since C++ is a compiled language, you can't "hit refresh" the same way you can in JavaScript/Ruby/etc. Is that an incorrect understanding? I know C++ is supposed to be great for performance, but in truth I've never needed anything to be that fast. And if I can get the job done just as well with something I already know, I won't bother learning something like C++ which has a reputation for not being approachable. But maybe I don't have full context?

lloeki 6y ago
The other day (actually years) I did a gamejam in Go, I bound Cmd+R to essentially the following: system("go build") exec("./main") Not a literal hot code reload that some advanced stuff get to enjoy, but nice enough to shorten the feedback loop.
d3nj4l 6y ago
If you're a ruby user looking for extra performance, try Crystal[1]. Everything you love + types compiled to native binaries. You can set up sentry[2] to autocompile and run every time you save, so the feedback loop is just as tight. [1]: https://crystal-lang.org/ https://crystal-lang.org/ [2]: https://github.com/samueleaton/sentry https://github.com/samueleaton/sentry
astrobe_ 6y ago
Technically you can have some sort of command in your C++ program to make it fork itself, that is restart itself disk, maybe after freeing non-shareable resources like listening sockets. One could even imagine that this command includes self-recompilation by invoking make (or whatever your build system is). An alternative is to have your program expose its pid somewhere, and your make file could send a signal to that pid when a new version is ready. The advantage is that if your program crashes on startup, you don't have to do something different to restart it. If your application has to include an "auto-update" feature (like browsers), use that instead - its certainly better to eat your own dog food. Maybe just hack it a little bit so that you can force a check programmatically (e.g. by sending it a signal) and so that it connects to a local updates server. It is true that C++ is an overly complicated language; if you don't need maximal performance, you have a lot of AoT languages that are a bit slower ( something around 0.5 C ) but more "user-friendly". In particular, if you are into servers and want fast edit-compile-run loops, Go might be a good choice.
JeanMarcS 6y ago
> I've never needed anything to be that fast In a world where you are billed by ressources used, wouldn’t it be a good idea to have light and fast services that don’t consume those ressources ? I’ve been wondering this for a time now.
- pathseeker 6y ago
  The part of the equation you are missing is how little traffic the majority of business applications end up seeing. A B2B app that has at most 10 concurrent requests can run on the smallest EC2 instance whether it's written in PHP or written in C++. Bandwidth doesn't change with language choice and neither does the storage requirements of your app so those billable items don't come into the equation either. So the CPU cost can effectively be dropped off of 95% of the apps out there today. At that point your main variable cost between C++ and something like PHP/Javascript is going to be the cost of development. All I can say to that is that it's a lot harder to find developers who can write C++ web apps at the same pace as developers slinging PHP for web apps. There is a reason Facebook uses a PHP derivative for huge portions of its web backend.
  - JeanMarcS 6y ago
    I agree with you. So maybe the question we should ask ourselves is: why isn’t there a smaller, cheaper EC2 instance (or any other provider than AWS) ? This industry is tailoring the levels. Of course it’s understandable because, well, they live on it. And they count on small instances to share hardware ressources to overbook said hardware. And I don’t blame them for that, I’m doing the same on my own bare metal servers, hosting multiple websites for clients and making money on it. But I have the feeling that there is a lot of ressource loss somewhere in it, just for the sake of loosing it because it’s easier. Maybe I’m wrong.
    - pas 6y ago
      Scaleway, Hetzner, OVH, DigitalOcean, etc. AWS LightSail. ... also the t1.micro is small and cheap. Could you give some concrete numbers?
Perseids 6y ago
It doesn't have to be C++ of course. The main point of OP lies in C++ being fast and easy to deploy (at least it can be). Go, Rust, to some extend C# and Java also fall in that category. This feature set becomes interesting, because it has the potential to simplify everything around it. If you don't need high fault tolerance you can go a very long way with just a single server, maybe sprinkled with some CDN caching in front if your users are international. If you do need higher availability you can go the route StackOverflow was famous for for quite some time of having a single ReadWrite master server, a backup master to take over and a few of ReadOnly slave servers, IIRC. With such setups you can ignore all the extra complexities cloud deployments bring with them. And just because such simple setups make it possible to treat servers like pets, doesn't mean they have to be irreproducible undocumented messes.
zelly 6y ago
Go will get you 90% there in performance. I recommend that instead of C++ because it compiles fast for that edit-build-refresh cycle. Go also has the benefit of producing static binaries by default which solves a lot of the problems Docker was for. C++ is more for the extreme control over memory. An optimized C++ server can max out the NIC even on a single core and even with some text generation/parsing along the way.
pas 6y ago
Working in strongly statically typed languages is quite different, because the types (and the IDE/compiler) guides you. You don't have to hit refresh that often. Even just working in TypeScript with TSed and a few basic strongly typed concepts (Rust's Result equivalent in TS, Option or Maybe, and typed http request/response, and Promise and JSON.parse) makes a big difference. A lot less okay, just echo/print/log this object (or look up documentation eew), look at what does this look like and how to transform it into what I need. Instead you do that in the IDE.

edwinyzh 6y ago

or a Free Pascal server (powered by mORMot (https://github.com/synopse/mORMot) https://github.com/synopse/mORMot))? Natively compiled, high performance, and supports almost all OS's and CPU's

slim 6y ago
404 not found
- narag 6y ago
  Try removing the trailing parenthesis.

danielovichdk 6y ago

Absolutely agree. A lot of people is just really interested in having something complex instead of understanding their actual needs.

atopuzov 6y ago

So now it's kubernetes + kludgy shell/Python scripts.

pas 6y ago
If it makes things more deterministic, then yeah, why not?

pwdisswordfish2 6y ago

I am ready! NetBSD is running on the toaster. I think haproxy can do 10K req/s. tcpserver on the backends. I only write robust shell scripts, short and portable. As a spectator, not a tech worker who uses these popular solutions, I would say there seems to be a great affinity amongst in the tech industry for anything that is (relatively) complex. Either that, or the only solutions people today can come up with are complex ones. The more features and complexity, the more something is constantly changing, the more a new solution gains "traction". If anyone reading has examples that counter this idea, please feel free to share them. I think if a hobbyist were to "[deploy] a single statically linked, optimized [C++] server that can serve 10k requests per second from a toaster" it would be like a tree falling in the forest. For one because it is too simple, it lacks the complexity that attracts the tech worker crowd, and second, because it is not being used by well-known tech company and not being worked on by large numbers of people, it would not be newsworthy.

tutfbhuf 6y ago
I can see your point for small hobby projects. But enterprise web development in C++ is no fun at all. For example: "Google says that about 70% of all serious security bugs in the Chrome codebase are related to memory management and safety." https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs... Developer time for fixing these bugs is in most cases more expensive, than to throw more hardware at your software written in a garbage collected language.
- Perseids 6y ago
  True, but the alternative to C++ with that reasoning is Rust or Go (depending on your liking), not Ruby. And with both of these you can step around a lot of deployment issues, because a single server can be sufficient for quite high loads. Avoid distributed systems as much as you can: https://thume.ca/2020/05/17/pipes-kill-productivity/ https://thume.ca/2020/05/17/pipes-kill-productivity/
  - pas 6y ago

rocho 6y ago

I don't agree with the last paragraph. Your C++ example is orthogonal to the deployment aspect because it discusses the application. Kubernetes and the fragile shell scripts are about the deployment of said application. How are you going to deploy your C++ application? Both options are available, and I would wager that in most cases, Kubernetes makes more sense, unless you have strict requirements.

jrumbut 6y ago
In a world where your architecture is that simple I don't think kubernetes would be the choice for long. I think for the average application there's still something to be said for manual cross-layer optimization between infrastructure, application, and how both are deployed. What I mean is we can't yet draw too clear a line between the application and how it's deployed because there are real tradeoffs between keeping future options open and getting the product out the door. A strength of kubernetes is that if you get good at it it works for a variety of projects, but a lot of effort is needed to get to that point and that effort could have gone into something else.
- p_l 6y ago
  Even then there's the question of "where are the logs?" "how is the application deployed?" etc.
zelly 6y ago
Kubernetes is for orchestrating a distributed system. What I was suggesting is to (1) make a monolith and (2) make it fast, light and high-throughput. The goal of your service is to reliably serve users at scale; this is just another way of doing it, just much more esoteric. A "C++ monolith" allows me to potentially bypass a lot of this deployment stuff because it could serve lots (millions) of users from a single box.
- harpratap 6y ago
  >Kubernetes is for orchestrating a distributed system. No it's not. You can use it to run bunch of monoliths too. K8s provides a common API layer that all of your organisation can adhere to. Just like containers are a generic encapsulation of any runable code.

nonines 6y ago

Can't agree more. To this add the moving-sand landscape of an ecosystem there. But then again it's actually the first public/popular attempt on a cloud OS. There might be a next one with better ergonomics than yamls.

howox 6y ago
Well aren't Openshift and Rancher offering those ergonomics?

baybal2 6y ago

I don't think that kubernetes is getting popular at all.

bmikaili 6y ago

Disagree with the GUI part. Text based configuration is stable, version-controllable, and intuitive to use. Look at Xcode for a nightmare of GUI configuration.

capableweb 6y ago
> stable, version-controllable, and intuitive to use Neither of those features are inherently impossible to do with GUIs. Alternatively, you can have a GUI editing your text based configuration. Although, doesn't look as cool so, here we are.
- pas 6y ago
  There are quite a few GUI tools for k8s. Currently mainstream k8s is text based, because it's still too fast moving and new. Creating a great GUI would be a serious overhead and there's not enough interest/demand for it. It'll come eventually.
  - Multicomp 6y ago
    Rancher does a lot of the orchestrating of k8s clusters and works well in my experience.
    - howox 6y ago
      Rancher is even more approachable and streamlined than Openshift. Yeah we need k8s to be more streamlined. It's fragmented cluster-something right now. There is no pride in making systems more complex nor there is pride in knowing how to operate them.
  - yrro 6y ago
    OpenShift's web interface lets you do a lot (other alternatives are of course available). And it's quite nice being able to edit the YAML of everything via the web interface as well!

saalaa 6y ago

This, and more but it's all in the same vein. I was pretty skeptical too but then handed over a project which was a pretty typical mixed bag: Ansible, Terraform, Docker, Python and shell scripts, etc... Then I realized relying on Kubernetes for most projects has the huge benefit of bringing homogeneity to the provisioning/orchestration which improves things a lot both for me and the customer or company I work for. Let's be honest here, in many cases it does not make a difference whether Kubernetes is huge, inefficient, complicated, bloated, etc... or not. It certainly is. But just the added benefit of pointing at a folder and stating : "this is how it is configured and how it runs" is huge. I was also pretty skeptical of Kustomize but it turned out to be just enough. So, like many here. I kind of hate it but it serves me well.

collyw 6y ago
I am still not convinced by Kubernetes, but you make a good point.
spenrose 6y ago
As a fellow Kubernetes-hater, this is the best explanation I've read for its virality. Thanks!

101404 6y ago

I like that alternative. Especially now that we have Rust and Actix Web.

dorian-graph 6y ago

> • Company saves money by not having to hire Linux sysadmins .. but hire others to manage k8s? Or existing software engineers have to spend time doing so? Many of the other points don't seem unique to k8s either. I do like the alternative you've suggested though.

wastedhours 6y ago

Are there any decent GUI services for creating the YAML files? Most of it can be managed by text boxes on the front-end with selections and then it can just generate or edit the required files at the end of a wizard?

SomeoneFromCA 6y ago

AFAIK, Yandex Taxi uses "single statically linked, optimized C++ server that can serve".

max_effort 6y ago

> • Company saves money by not having to pay for managed cloud products if they don't want to In some cases, the cost of a managed cloud product may be cheaper than the cost of training your engineers to work with K8s. It just depends on what your needs are, and the level of organizational commitment you have to making K8s part of your stack. Engineers like to mess around with new tech (I'm certainly guilty of this), but their time investment is often a hidden cost. > The alternatives are all based on kludgy shell/Python scripts or proprietary cloud products. The fact that PaaS products are proprietary is often listed as a detriment. But, how detrimental is it really? There are plenty of companies whose PaaS costs are insignificant compared to their ARR, and they can run the business for years without ever thinking about migrating to a new provider. The managed approach offered by PaaS can be a sensible alternative to K8s, again it just depends on what your organizational needs are.

banifo 6y ago

"The alternative to K8s isn't your personal collection of fragile shell scripts. The real alternative is not doing the whole microservices thing and just deploying a single statically linked, optimized C++ server that can serve 10k requests per second from a toaster--but we're not ready to have that discussion." You are writing this and i thought yesterday how to extend my current home k8s setup even further. I would even manage that little c++ tool through k8s. K8s brings plenty of other things out of the box: - Rolling update - HA - Storage provisioning (which makes backup simpler) - Infrastructure as code (whatever your shellscript is doing) I think that the overhead k8s requires right now, will become smaller over the years, it will be simpmler to use it, it will become more and more stable. It is already a really simple and nice control plane. I like to use a few docker containers with compose. But if i already use docker compose for 2 projects, why not just using k8s instead?

tsss 6y ago

If you really think that deploying a single binary is an alternative to microservices then you don't understand microservices.

robert_g 6y ago

I would speculate that for companies these two statements will be exclusive: • Company saves money by not having to hire Linux sysadmins • Company saves money by not having to pay for managed cloud products if they don't want to As a developer I want to right code, not manage a Kubernetes installation. If my employer wants the most value from my expertice they will either pay for a hosted environment to minimize my time managing it or hire dedicated staff to maintain an environment.

burntoutfire 6y ago

> The real alternative is not doing the whole microservices thing and just deploying a single statically linked, optimized C++ server that can serve 10k requests per second from a toaster--but we're not ready to have that discussion. The alternative is to have a old and boring cluster of X identical java nodes which host the entire backend in a single process... The deployment is done by a pedestrian bash script from a Jenkins. It used to work fine for too long I guess and folks couldn't resist "inventing" microservices to "disrupt" it.

eyberg 6y ago

> Company saves money by not having to hire Linux sysadmins Citation? In my experience companies hire more sysadmins when adopting k8s. It's trivial to point at the job reqs for it. > Company saves money by not having to pay for managed cloud products if they don't want to Save money?! Again citation. What are you replacing in the cloud with k8s? In my experience most companies using k8s (as you already admitted) don't have a ton of ops experience and thus use more cloud resources. > Treating cloud providers like cattle not pets Again. Citation? Companies go multi-cloud not because they want to but because they have different teams (sometimes from acquisition) that have pre-existing products that are hard to move. No one is using k8s to get multi-cloud as a strategy. > It's going to eat the world (already has?). Not it won't. It's actually on the downtrend now. Do you work for the CNCF? Can you put in a disclaimer if so? > just deploying a single statically linked, optimized C++ server that can serve 10k requests per second from a toaster completely un-necessary; most of the HN audience is not creating a c++ webserver from scratch; most of the HN audience can trivially serve way more than 10k reqs/sec from a single vm (node, rust, go, etc. are all easily capable of doing this from 1 vcpu)

tapirl 6y ago
You says all what I want to say.

pjmlp 6y ago

And this is why I only give Linux like one decade more to still be relevant on the server. With hypervisors and managed environments taking over distributed computing, if there is a kernel derived from Linux or something completely different, it is a detailed that only the cloud provider cares about.

kag0 6y ago
That doesn't really make sense in the context of docker. It's still Linux inside the container. Even if it's some abstract non-Linux service thing running the container, what happens in the container is still the concern of the developer.
- pjmlp 6y ago
  Yes it does, my application written in Go, Java, .NET, doesn't care if the runtime is bare metal, running on an hypervisor type 2, type 1 or some other OS. I run Docker on Windows Containers, no Linux required. There are also the ugly named serverless deployments, where the kernel is meaningless.

buboard 6y ago

What is your estimate about when we ll be ready to have that discussion?

neop1x 6y ago

Your static app won't scale. Once your kernel is saturated with connections, once your buffers are full, you will get packets dropped. Your app may crash unexpectedly so you need to run it in an infinite loop. And of course your static example is a simple echo app or hello world. That works fine from a toaster. In the real world we use databases where every store takes a significant time to process and persist. You quickly overgrow a single server. Then you need distributed systems and a way to do versioning so you use containers and then you need an orchestrator so you pick K8S because it's most mature and there are many resources around. And then you can even do rolling updates and rollbacks. Finally you use Helm, Terraform and Terragrunt and never look back. It works surprisingly good. I lost several years by learning all this stuff, it was difficult but it was worth it. I have more visibility into everything now thanks to metrics-server, Prometheus Operator, Grafana, Loki and I have two environments so I can update deployments in one environment and test, once tested ok, I can apply to live. No surprises. No need to run 5 year old versions of software and fear updating it...

p_l 6y ago

You still need quite a lot of stuff for that one, statically linked, heavily optimized C++ server. In a way, that's actually what k8s comes from ... How do you manage deployments for that C++ monolith? How is the logging? Logrotate, log gathering and analysis? Metrics, their analysis and and display? What happens when you have software developed by others that you might also to want to deploy? (If you can run a company with only one program ever deployed, I envy you). All of that is simplified by kubernetes by simply making all stuff follow single way - "classical" approaches tend to make Perl blush with the amount of "There is more than one way to do it" that goes on.