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.
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.
What do we want to deploy, okay, stop monitoring/alerts, okay, flip the load balancer, install/copy/replace the image/binary, restart it, flip LB, do the other node(s), keep flipping monitoring/alerts, okay, do we need to do something else? Run DB schema change scripts? Oh fuck we forgot to do the backup before that!
Also now we haven't started that dependent service, and so we have to rollback, fast, okay, screw the alerts, and the LB, just rollback all at once.
And sure, all this can be scripted, run from a laptop. But k8s is basically that.
...
And we get distributedness very fast, as soon as you have 2+ components that manage state you need to think about consistency. Even a simple cache is always problematic (as we all know how the cache invalidation joke).
Sure, going all in on microservices just because is a bad idea. Similarly k8s is not for everyone, and running DBs on k8s isn't either.
But, the state of the art is getting there. (eg the crunchydata postgresql operator for k8s.)
This.
I was in a company where devops was just a fancy marketing term, developers would shit out a new release and then it was our problem (we the system engineers / operations people) to make it work on customers' installations.
I now work as a devops engineer in a company that does devops very well. I provide all the automation that developers need to run their services.
They built it, they run it.
I am of course available for consultation and support with that automation and kubernetes and very willing to help in general, but the people running the software are now the people most right for the job: those who built it.
As I said in my other comment: it's really about fixing the abstractions and establishing a common lingo between developers and operations.
If you want to be a successful indie company, avoid cloud and distributed like the plague.
If you want to advance in the big corp career ladder, user Kubernetes with as many tiny instances and micro-services as you can.
"Oversaw deployment of 200 services on 1000 virtual servers" sounds way better than "started 1 monolithic high-performance server". But the resulting SaaS product might very well be the same.
Php under apache.
I run a monolithic ensemble that abstracts away the concept of multiple processes to deliver a unified API.
In short, it's multithreaded.
All this docker and k8s stuff just feels like reinventing application servers, just 10x more complex as means to sell consulting services.
However, their learning curve is pretty steep (particularly Rust) and most developers don’t enjoy having to worry about low-level issues, which makes recruitment and retention a problem. Whereas one can be reasonably proficient with Python/Ruby in a week, Java/C# is taught in school, and everyone has to know JS anyway (thanks for nothing, tweenager Eich), so it’s easy to pick up manpower for those.
Disclaimer: Neither do I claim to be a very good developer, nor do I think you, the reader, is only average. Just given that you are reading Hackernews is a strong indicator for your interest in reflection and self improvement, regardless of your favorite language.
So big companies might be forced to settle for less skilled developers, simply because the top tier is doing their own thing. I assume that's also why acqui-hiring is a thing.
For every time I have to deal with k8s I deeply miss application servers.
Within our teams, we’ve found we can do with an (even) higher level of abstraction by running apps directly on PaaS setups. We found this sufficient for most of our use-cases in data products.
And at this point the hobbyist might wonder, "why isn't my toaster software being used by well-known companies? where are the pull requests to add compatibility for newer toaster models?"
> 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.
I think you have it backwards. General/abstract solutions (like running arbitrary software with a high tolerance for failure) have broad appeal because they address a broad problem. Finding general solutions to broad problems yields complexity, but also great value.
Not this one. :)
That, and mixture of a sunken cost fallacy/lack of the ability to step back and review if the chosen solution is really better/simpler rather than a hell of accidental complexity. If you've spend countless months to grok k8s and sell it to your customer/boss, it just has to be good, doesn't it?
Plus, there's a great desire to go for an utopian future cleaning up all that's wrong with current tech. This was the case with Java in the 2000s, and is the case with Rust (and to a lesser degree with WASM) today, and k8s. Starting over is easier and more fun than fixing your shit.
And another factor are the deep pockets of cloud providers who bombard us with k8s stories, plus devs with an investment into k8s and/or Stockholm syndrome. Same story with webdevs longing for nuclear weapons a la React for relatively simple sites to make them attractive on the job market, until the bubble collapses.
But like with all generational phenomenae, the next wave of devs will tear down daddy-o's shit and rediscover simple tools and deploys without gobs of yaml.
The domain I'm working in might be non-representative, but for me fixing my shit systematically means switching from C++ to Rust. The problems the borrow checker addresses come up all time either in the form of security bugs (because humans are not good enough for manual memory management without a lot of help) or in the form of bad performance (because of reference counting or superfluous copies to avoid manual memory management).
But otherwise I agree with you that if we never put in the effort to polish our current tools, we'll only ever get the next 80%-ready solution out of the hype train.
However, it doesn't matter how much modern we make C++, if you don't fully control your codebase, there is always going to exist that code snippet written in C style.
However I always have static analysers enabled on my builds, so it is almost as if they were part of the language. Regardless if we are talking about Java, C# or C++.
Just like most people that are serious about Rust have clippy always enabled, yet it does stuff that ins't part of Rust language spec.
K8S is developed by a multitude of very large companies. Each with their own agenta/needs. All of them have to be addressed. Thus the complexity. If you think about it they probably manage to keep the complexity to relatively low levels. Maybe because it is pushed to the rest of the ecosystem (see service meshes for example).
Being pushed by the behemoths also explains the popularity. Smaller companies and workers feel that this is a safe investment in terms of money and time familiarizing with the tech stack so they jump on. And the loop goes on.
Main business reason for all that though I think it's the need of Google et all to compete with AWS creating a cloud platform that comes to be a standard and belongs to no-one really. In this sense it is a much better, versatile and open ended openstack attempt.
And yes, there is less fancy companies like one where I work where we don't use Kubernetes because it's kind of overkill if all of your production workload fits onto 2 beefy bare metal servers.
I can see a point in using Docker to unify development and production environments into one immutable image. But I have yet to see a normal-sized company that gets a benefit from spreading out to hundreds of micro instances on a cloud and then coordinating that mess with Kubernetes. Of course, it'll be great if you're a unicorn, but most people using it are planning for way more scaling than what they'll realistically need and are, thus, overselling themselves on cloud costs.
Last year, my bare metal website had 99.995% uptime. Heroku only managed 99.98%.
Of course, I could further reduce risk by having a hot standby server. But I'm not sure the costs for that are warranted, given the extremely low risk of that happening.
hah, i've noticed that too - specifically around k8s/deployments/system architecture too. i've taken to calling it complexity fetishisation.
i think it stems from the belief/hope that, whilst they don't "google sized" data today, they need to allow for it.
i'll take two toasters, please.
The older i get the more i realise the less i want in my stacks.
This article listed as a benefit, frequent, multiple major updates each year, new features and no sign of it slowing down. I just cringed and wondered who the fuck is asking for this headache?
Ive been working a lot with wordpress lately and the stability of the framework is spoiling me rotten.
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.
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)
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.
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.
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.
I can leave my current job, jump into a new one and start providing value within less than couple of days. Compared that to spending weeks if not months trying to understand their special snowflake of an infrastructure solving the same problems already solved a million times before.
No it doesn't. Let's assume you write that application as a C++ monolith. Congratulations, you now have source code that could potentially serve 10k users on a toaster... If only you could get it onto that toaster. How are you going to start the databases it needs? How are you going to restart it when it crashes, or worse: When it still runs but is unresponsive. How are you going to upgrade it to a new version without downtime? How are you going to do canary releases to catch bugs early in production without affecting all users? How do you roll back your infrastructure when there is an issue in production? How do you notice when your toaster server diverges from it's desired state? How do you handle authorization to be compliant with privacy regulations? I'd love to see that simple and safe shell script of yours which handles all those use cases. I'm sure you could sell it for quite a bit of money.
What you fail to understand is that k8s never was about efficiency. Your monolith may work at 10k users with a higher efficiency but it can never scale to a million. At some point you can't buy any bigger toasters and have no choice but to make a distributed system.
Besides, microservice vs monolith is orthogonal to using k8s.
I use Convox [1] which makes everything extremely simple and easy to set up on any Cloud provider. They have some paid options, but their convox/rack [2] project is completely free and open source. I manage everything from the command-line and don't use their web UI. It's just as easy as Heroku:
convox rack install aws production
convox apps create my_app
convox env set FOO=bar
convox deploy
convox rack params set Private=true
I run a simple monolithic application where I build a single Docker image, and I run this in multiple Docker containers across 3+ EC2 instances. This has made it incredibly easy to maintain 100% uptime for over 2 years. There were a few times where I've had to fix some things in CloudFormation or roll back a failed deploy, but I've never had any downtime.
My Docker images would be much smaller and faster if I built my backend server with C++ or Rust instead of Ruby on Rails. But I would absolutely still package a C++ application in a Docker image and use ECS / Kubernetes to manage my infrastructure. I think the main benefit of Docker is that you can build and re-use consistent images across CI, development, staging, and production. So all of my Debian packages are exactly the same version, and now I spend almost zero time trying to debug strange issues that only happen on CI, etc.
So now I already know I want to use Docker because of all these benefits, and the next question is just "How can I run my Docker containers in production?". Kubernetes just happens to be the best option. The next question is "What's the easiest way to set up Docker and Kubernetes?" Convox is the holy grail.
The application language or framework isn't really relevant to the discussion.
[2] https://github.com/convox/rack
P.S. Things move really fast in this ecosystem, so I wouldn't be surprised if there are some other really good options. But Convox has worked really well for me over the last few years.
* Effortlessly achieve 100% uptime with rolling deploys
* Running a single command to spin up a new staging environment that is completely identical to production
* Easily spinning up identical infrastructure in a different AWS region (Europe, Asia, etc.)
* Easily spinning up infrastructure inside a customer's own AWS or Google Cloud account for on-premise installations
* Automatic SSL certificates for all services. Just define a domain name in your Convox configuration, and it will automatically creates a new SSL certificate in ACM and attach it to your load balancer.
* Automatic log management for all services
* Very easily being able to set up scheduled tasks with a few lines of configuration
* Being able to run some or all of my service on AWS Fargate instead of EC2 with a single command
* Ease of deploying almost any open source application in a few minutes (GitLab, Sentry, Zulip Chat, etc.)
https://docsv2.convox.com/reference/hipaa-compliance
Note that dedicated instances are no longer required for HIPAA compliance [1]. Also note that the private Convox console is completely optional. You can achieve all of this with the free and open source convox/rack project: https://github.com/convox/rack
As I mentioned in my original comment, you still need to do a lot of work to set up company policies and make sure your application complies with all regulations.
You should also be aware that I'm comparing Convox with some other popular options for HIPAA-compliant hosting:
* Aptible: https://www.aptible.com (Starts at $999 per month)
* Datica: https://datica.com (I think it starts around $2,000 per month, but not 100% sure)
These companies do provide some additional security and auditing features, but I think there's no reason to spend thousands of dollars per month when Convox can get you 95% of the way in your own AWS account. PLUS: If you have any free AWS credits from a startup program, you might not need to pay any hosting bills for years.
[1] https://aws.amazon.com/blogs/security/aws-hipaa-program-upda...
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.
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.
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.
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.
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?
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.
.. 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.
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?
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.
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?
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.
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.
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.
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.
AWS LightSail.
... also the t1.micro is small and cheap. Could you give some concrete numbers?
I get a lot of mileage serving a lot of content for several domains on a free Google Cloud Platform f1 micro instance. I also prefer GCP when I need a lot of compute for a short time.
Hetzner has always been my choice when I need more compute for a month or two. For saving money for VPSs OVH and DO have also been useful but I don’t use them very often.
The problem as you go cheaper is the cost of ipv4 addresses.
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.
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.
system("go build")
exec("./main")
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.
• 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.
A lot of people is just really interested in having something complex instead of understanding their actual needs.
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.
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.
I run Docker on Windows Containers, no Linux required.
There are also the ugly named serverless deployments, where the kernel is meaningless.
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.
• 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.