Kubernetes is a nightmare. What's the IaaC version of a Turing Tarpit?
I wish Hashicorp would release Nomad under a better license. It's a superior system in every way except mindshare.
Kubernetes is not the point
21–30 of 32 posts
Re: Kubernetes is not the point
#22Serious question: If everyone ultimately wants the usability of Heroku - which I can believe - why didn't Cloud Foundry take off? Am I (and Betty Junod, and Seth Vargo) wrong about the desirability of Heroku's interface? Was Cloud Foundry far worse than Kubernetes, or did it just not get traction? I admit that's a pretty loaded question, so I should give context: I dealt with Cloud Foundry from the user side, not the…
> If everyone ultimately wants the usability of Heroku - which I can believe - why didn't Cloud Foundry take off?
Cloud Foundry isn't like Heroku, it's more like "build your own AWS" or maybe "build against this shim layer so you can make a credible threat to migrate when your cloud provider jacks up their prices".
The target audience isn't application developers, it's CTOs and CFOs.
Re: Kubernetes is not the point
#23I read the whole thing and I'm not sure I understand what IS the point except that things are too complex? A whole lot of words for not a lot of content.
The point was that too many firms focus on Kubernetes as a thing in and of itself instead of focusing on app development. From a business perspective it can, and most of the time does, benefit an organization to outsource app deployment. I’ve seen first-hand organizations that have gigantic teams of DevOps working endlessly on perfecting these systems, all the while taking teeth pulled for an app developer to get a n…
It's possible that those platform engineers did a poor job exposing kubernetes to the developers, in the anecdotes you've mentioned. But there is a LOT more being instrumented in an effective deployment platform than just deploying an app somewhere. Centralized logging and metric aggregation and then visualization of those is an important aspect to any platform for app deployments that get overlooked by many naive developers. Deploying a service to some PaaS site is great until you need to extract any runtime information out of it, if it doesn't also instrument those features, which I've been a consumer of many of them that don't really do that at all. And then performant and reliable shared cluster storage is another animal altogether in on premise kubernetes clusters in particular. So far my best experience in that area has been with Ceph, which is like learning a completely different distributed system with its own complexities.
The app developer doesn't see it, but behind every decent app deployment in kubernetes, there are millions of hours of expertise in running distributed applications reliably. And the simpler deployment platforms do a good job of abstracting some of this, but from what I've seen nobody does all of that exceptionally well, and if they did, they could probably be able to charge whatever they wanted to people wanting to use it.
Re: Kubernetes is not the point
#24I read the whole thing and I'm not sure I understand what IS the point except that things are too complex? A whole lot of words for not a lot of content.
Fear of complexity is the number one reason why many "simple" homebrew solutions were born to solve simple problems at time, from what I observed in recent years across a few companies I worked for. The hard truth is, fewer simple things can stay simple while continue being useful in the long run.
The value I get from Kubernetes, is the API platform that allows my system to organically become more complex overtime, but hopefully in an organized way.
Re: Kubernetes is not the point
#25Earlier quoted context omitted.
The point was that too many firms focus on Kubernetes as a thing in and of itself instead of focusing on app development. From a business perspective it can, and most of the time does, benefit an organization to outsource app deployment. I’ve seen first-hand organizations that have gigantic teams of DevOps working endlessly on perfecting these systems, all the while taking teeth pulled for an app developer to get a n…
It's possible that those platform engineers did a poor job exposing kubernetes to the developers, in the anecdotes you've mentioned. But there is a LOT more being instrumented in an effective deployment platform than just deploying an app somewhere. Centralized logging and metric aggregation and then visualization of those is an important aspect to any platform for app deployments that get overlooked by many naive de…
When webmail (Gmail, Hotmail, etc) first came out, one objection I remember is that it was a bad idea, because it meant you couldn't get at your email if the service went down. How foolish of you to rely on someone else to keep their website up 100% of the time. That thinking passed as expertise in keeping systems up became its own branch of software engineering. So we forget that it's very possible to do a bad job of keeping a website up. some of the platform engineering work isn't just for show, it turns out.
Re: Kubernetes is not the point
#26Serious question: If everyone ultimately wants the usability of Heroku - which I can believe - why didn't Cloud Foundry take off? Am I (and Betty Junod, and Seth Vargo) wrong about the desirability of Heroku's interface? Was Cloud Foundry far worse than Kubernetes, or did it just not get traction? I admit that's a pretty loaded question, so I should give context: I dealt with Cloud Foundry from the user side, not the…
Google App Engine was ahead of its time, but it's still quite a successful product. I think it didn't get traction back then because it was too different from the status quo for developers to want to invest in it. The other thing is vendor lock-in and costs. If you're all in on Heroku (or AWS or GCP or...) you have no recourse if they decide to raise prices on you. Even though that's never really happened other than the ipv4 AWS thing for developers, (ie DocuSign doesn't count) the mere possibility that you could get hosed by your vendor scared enough people off that it failed to get the traction it deserved, imo.
Re: Kubernetes is not the point
#27Serious question: If everyone ultimately wants the usability of Heroku - which I can believe - why didn't Cloud Foundry take off? Am I (and Betty Junod, and Seth Vargo) wrong about the desirability of Heroku's interface? Was Cloud Foundry far worse than Kubernetes, or did it just not get traction? I admit that's a pretty loaded question, so I should give context: I dealt with Cloud Foundry from the user side, not the…
> If everyone ultimately wants the usability of Heroku - which I can believe - why didn't Cloud Foundry take off? Cloud Foundry isn't like Heroku, it's more like "build your own AWS" or maybe "build against this shim layer so you can make a credible threat to migrate when your cloud provider jacks up their prices". The target audience isn't application developers, it's CTOs and CFOs.
I mean.. from the user side (aka the developers deploying applications within the org) Cloud Foundry was a lot like Heroku. I think the Buildpack concept (incepted at Heroku) was picked up by the Cloud Foundry Foundation and developed in lockstep with Heroku. For a while there was a lot of pollination between both projects.
The reason IMO that Cloud Foundry didn't catch on is that from the admin side, deployment of vanilla CF was a nightmare, and maintenance could be challenging.
You could pay for an Cloud Foundry distribution with guardrails, but that ended up being $$$ and still required having employees with systems/ops knowledge if you weren't just deploying to the cloud provider du jour anyway.
I think CF had its golden years before k8s really started to catch on. Then there was a push by a lot of companies to bring CF to k8s (I was working at one such company as it went from the Cloud Foundry Distribution -> Cloud Foundry Distribution on K8s journey). I think these could have caught on if someone could have made it work in a truly seamless way, but unfortunately all the abstractions for bridging CF concepts to a K8s world developed in pursuit of this goal ended up being leaky, and requiring your customers to have CF domain knowledge atop K8s domain knowledge to successfully deploy and maintain their in-house CF, which proved to be too tall an order.
Unfortunately, CF seems to have fallen by the wayside now (though I'm sure there will still be companies running it for 20 years if their needs don't outgrow the capabilities of their mostly-working deployments) and AFAIK nothing has really taken its place.
I haven't had the opportunity to try this yet, but Kubevela (https://www.cncf.io/projects/kubevela/) looks like it could be the closest thing to a modernized CF-like experience on top of K8s that should (hopefully) be more sensible to deploy and manage. Would really love to hear thoughts from people who have used both though.
Re: Kubernetes is not the point
#28Earlier quoted context omitted.
Yeah, the way I read it, it boils down to "I worked on Docker. Kubernetes is great but too complex for developers to actually use." Which yes, is something that everyone who isn't fooling themselves has been saying since its inception. I've been managing on prem kubernetes clusters for the better part of a decade, a lot of it makes sense to me now, but was absolutely painful to learn. In my opinion the article would…
Disclosure I work for a company, Noop [1], which is the picture of the steak. As someone working on the marketing side of the endeavor, I see the shift the author describes. there are a handful of PaaS companies picking up where Heroku left off and in the enterprise world devops is evolving toward "platform engineering". Platform engineering suffers from being poorly defined, but there appears to be growing demand wi…
Noop actually looks cool, I’ll give it a spin sometime. I’m using Fly.io for all my stuff at the moment but recognize at some point my infra my outgrow it…
Re: Kubernetes is not the point
#29I read the whole thing and I'm not sure I understand what IS the point except that things are too complex? A whole lot of words for not a lot of content.
1. Developers want to deploy their apps easily, 2. The default is to use containers, but that's only a part, 3. Because of containers, k8s got very popular, 4. But for developers, it doesn't really matter what the underlying tehc is, it could be k8s, it could be k8s, it could be anything as long as it works smoothly, 5. that's called IDP or PE now, but it's similar to what Heroku offered years ago
Re: Kubernetes is not the point
#30Earlier quoted context omitted.
Kubernetes is a generalized solution to the problem - hence the complexity. Tools such as Docker Swarm were tailor fit to solve a particular application deployment and scaling problem - hence the simplicity. I haven't looked in a while, but I recall at one time there being a utility that could take a Docker Swarm yaml and convert it to Kubernetes - Kompose? Has that matured into something useful?
On the subject of Kompose, frankly, I think a person looking to get into Kubernetes either knows how to convert what is essentially a docker-compose file to kubernetes manifests themselves, or they're going to struggle working with kubernetes to the point that no amount of "this is how you convert to this" tooling will save them. At the end of the day, you're working on kubernetes, so you need to know how to work wit…
That's fair. It's usually worthwhile to suck it up and learn the basics of what it is you need to do.