[deleted]
Kubernetes is not the point
11–20 of 32 posts
Re: Kubernetes is not the point
#12Serious 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…
Afaik cluster administration is pretty complicated. They had a pretty big internal deploy at JP Morgan Chase and I was under the impression other Fortune 50s had internal deployments but it takes a dedicated team to run.
I think nowadays building on top of Kubernetes has completely eclipsed the CF stack. There's a buildpacks CNCF incubator and you can get k8s pretty close with different tools/abstractions.
Re: Kubernetes is not the point
#13The major problem is the lack of individual domain knowledge on the underlying server techs that run simple to complex workloads. We have abstracted away a lot of that with APIs and YAMLs so developers don't need to know the inner-workings of Linux, Networking, and Storage. This is a huge negative when things go wrong and there are hundreds of tools that we have access to which makes things insanely complicated if not used correctly.
A lot of developers will throw compute resources at problems rather than solving within their code. I get it, that is the faster route in almost every case. They won't get hired or promoted if they don't use the current "new hottness" in our industry. This leads to insane cloud spend and super complex deployment setups.
Businesses and VC have been trying to obsolete the sysadmin role on the team for over 15 years now. They shove this responsibility onto developers and expect them to get paid to effectively two jobs for the price of one. We are simply overloaded with work and not having to deal with getting your code into production is something that some developers don't want to own and want an easy button to press to do this job. This is what is driving the want for a "Platform Experience". All of us in the tech community are paying the price with more work responsibilities and higher expectations from the C suite to deliver features faster.
I am all for making Ops more easier for everyone on the engineering team to consume but, not at the complexity price we are currently paying.
Re: Kubernetes is not the point
#14I don't agree exactly. The standardization in Kubernetes has brought calm to the chaos. Having controllers which act as the public interfaces for additional capability in ways that can integrate with other controllers cleanly is transformational. I have vendors supporting the interfaces that Kubernetes has defined which commoditizes the vendor, which is exactly what I want in a platform. I am not locked into a vendor…
> I am not locked into a vendor because
I see this often mentioned in the context of k8s and find it baffling that it gets repeated. K8s is simply swapping a form of lock in, to the abstract layer.
Re: Kubernetes is not the point
#15I 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.
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…
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?
Re: Kubernetes is not the point
#16I 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.
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 within large enterprises for something like internal-heroku. But there's still a problem.
To me, the problem is not kubernetes. The problem is that tooling has become so specialized that the focus of work has become integration between tools. And that cumulative integration work complicates the operational responsibilities of software developers. Even if you have a dedicated devops team, the complexity of those integrations flows down to developers in the form of different systems for logging, monitoring, firewall, cdn, ci/cd, secrets, etc.
Re: Kubernetes is not the point
#17I 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 new container deployed.
Re: Kubernetes is not the point
#18Earlier 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…
My take is DevOps and SRE didn't take off how big companies thought they would and the outcome is platform engineering which used to be more a combination of infrastructure engineering and sysadmin roles
Re: Kubernetes is not the point
#19I don't agree exactly. The standardization in Kubernetes has brought calm to the chaos. Having controllers which act as the public interfaces for additional capability in ways that can integrate with other controllers cleanly is transformational. I have vendors supporting the interfaces that Kubernetes has defined which commoditizes the vendor, which is exactly what I want in a platform. I am not locked into a vendor…
> I am not locked into a vendor because I see this often mentioned in the context of k8s and find it baffling that it gets repeated. K8s is simply swapping a form of lock in, to the abstract layer.
K8s does have a lot of open interfaces like CRI, CNI, CSI that can & are used in other solutions like Hashicorp Nomad.
The core/control plane components aren't interchangeable but a lot of the "userland" can be swapped around (I have cri-o, Calico, and a homemade CSI on libvirt VMs at home and it runs workloads the same as containerd, AWS VPC CNI, EBS CSI at work)
However, it's not open in the way there's a drop in replacement
Re: Kubernetes is not the point
#20Earlier 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…
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 with kubernetes. That might come off as gatekeeping to some, but it is an honest estimation of how much effort goes into productionizing workloads for kubernetes.