so what do we use instead?
'build.js', 'deploy.js'. Makefiles if you want to scale.
Google admits Kubernetes container tech is too complex
241–250 of 449 posts
Re: Google admits Kubernetes container tech is too complex
#242Earlier quoted context omitted.
> Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). At the risk of nitpicking, docker images aren't the equivalent of VM images, as they don't include a kernel.
This isn't nitpicking at all, it's an important distinction! Docker is not virtualization, it's just an abstraction that makes some Linux process isolation features easier to manage. It also allows you to bundle whatever dependencies you have in the same bundle, but that is not the same as having a VM.
Linux containers and equivalent technologies are virtualisation (specifically OS virtualisation[1]), just not a VM. Hardware virtualisation (VMs) isn't the only kind of virtualisation that exists.
[1]: https://en.wikipedia.org/wiki/Operating_system-level_virtual...
Re: Google admits Kubernetes container tech is too complex
#243I'm scared. From 2000 til 2013 I did exclusively server side development. In 2013 I transferred (@ Google) into doing mobile and embedded work, and missed the whole docker thing & the K8 transition. I've now transferred back over to doing cloud/server/backend work and I'm just a little terrified of what I've gotten myself into. In addition to re-learning Google's Borg stack, learning Golang, and readjusting my headsp…
Do what every one else does for borg: copy-pasta something simple (hint: look at old versions of other apps' configs) and ask lots of questions.
As for cloud tech: https://www.amazon.com/Mastering-Kubernetes-container-deploy... will cover 90% of it for you.
Re: Google admits Kubernetes container tech is too complex
#244Well sure there is always room for improvement. I was already a 20 year Linux veteran when I started getting into k8s.
Imho it was very simple to understand all the components. But I can't deny that it does require a solid understanding of sysadmin concepts and containers to get ahead.
I was quite proud to have grasped kubernetes within a few months, without any formal training. No finished education in my country and not from an English speaking country. So I often struggle with technical docs that are using too much academic english.
Still today when new issues arise I can relatively quickly understand why they're happening.
In some cases though you must read the docs carefully.
Re: Google admits Kubernetes container tech is too complex
#245I think the single biggest mistake people make with Kubernetes is implementing it too soon. Last company I worked for spent piles of time fighting K8s when a simple well implemented cluster would have done the job. It makes a lot of sense to build portable infrastructure, but you can scale a long ways with much simpler technologies.
Build debs, use the package manager. VMs are already an artificial abstraction, just use them.
Ex Amazon SDE here. You are absolutely right.
Re: Google admits Kubernetes container tech is too complex
#246I work on a 3-person DevOps team that just finished migrating ~20 services from GCE vms running docker-compose to GKE. It's taken us a little over a year. Partly because K8s has a steep learning curve, but also because safely transitioning services without disrupting product teams adds a lot of overhead. The investment is already yielding great returns. Developers are happy. Actual quote: "Kubernetes is the biggest q…
> That is until management decides we're overhead and fires us to free up budget for feature developers.
Snake eating it's own tail.
But not only do I not understand K8s, I'm also an idiot.
Re: Google admits Kubernetes container tech is too complex
#247I work on a 3-person DevOps team that just finished migrating ~20 services from GCE vms running docker-compose to GKE. It's taken us a little over a year. Partly because K8s has a steep learning curve, but also because safely transitioning services without disrupting product teams adds a lot of overhead. The investment is already yielding great returns. Developers are happy. Actual quote: "Kubernetes is the biggest q…
"Kubernetes is the biggest quality-of-life improvement I've experienced in my career."
Can you elaborate? What exactly about Kubernetes improved the developers life?
Re: Google admits Kubernetes container tech is too complex
#248Putting on my Asbestos Longjohns: The more I look into k8s ecosystem, the more I'm convinced that it's one of those things that suits FAANG etc, but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill. After all no one got fired for buying IBM and recommending Kubernetes. Most teams need a simpler deployment strategies that other's have succinctly mentio…
k8s and its ecosystem represent a data center in software. Data centers are fairly complex constructs. It is then to be expected that this complexity will shine through in k8s' API, UI, UX. k8s' main mission seems to be to provide a complete digital data center, not an easy to use one, and I would argue that that is exactly the right choice. Over time, as the core of the beast is figured out, there will be (as there have been) more and more opportunities taken to actually help users navigate that complexity and/or resolve it into more natural and less error-prone interfaces. But in the meantime it seems like it's mostly on the community to provide (usually temporary) solutions for the most pressing usability concerns.
Re: Google admits Kubernetes container tech is too complex
#249Putting on my Asbestos Longjohns: The more I look into k8s ecosystem, the more I'm convinced that it's one of those things that suits FAANG etc, but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill. After all no one got fired for buying IBM and recommending Kubernetes. Most teams need a simpler deployment strategies that other's have succinctly mentio…
Kubernetes solves a very real and significant problem. But before you start using it, make sure you have the problem it solves.
If you're looking to have your small app eventually grow into a large one, read up on K8s and just make sure you're not blocking future-you from making your app work on it. E.g., work well in a container (which is useful for automated testing, deps management, etc), have a simple 'ping' endpoint to make sure the app is up, have a better config story than "recompile to change these variables", use a logging library, and tolerate any other services you're using to sometimes be down.
All useful things for a grown-up app to do anyways, all a bit of a PITA, and all better than trying to operate an app that doesn't do them.
Re: Google admits Kubernetes container tech is too complex
#250I work on a 3-person DevOps team that just finished migrating ~20 services from GCE vms running docker-compose to GKE. It's taken us a little over a year. Partly because K8s has a steep learning curve, but also because safely transitioning services without disrupting product teams adds a lot of overhead. The investment is already yielding great returns. Developers are happy. Actual quote: "Kubernetes is the biggest q…
... Until they hire you back because entropy exists :P I'm on the DevOps side as well going through the same transition, k8s also allows insane customization, and I have some colleagues that are delaying our rollout unintentionally so they can play around with developing more tooling for deployments which is really frustrating. The k8s scene seems to be filled with constant scope creep and refactoring to get it just…
"I have some colleagues that are delaying our rollout unintentionally so they can play around with developing more tooling for deployments which is really frustrating."
My impression is that the primary purpose of Kubernetes is to give SRE teams political air cover to rewrite a lot of their existing processes. Whether Kubernetes is actually required for that, or even net superior seems questionable. This unsexy work becomes justifiable because it's coupled to a mainstream accepted tech modernization.
You see this same phenomenon with database migrations. Where what the team really needed to do is just rewrite an app to use the existing database properly. But no one is going to approve that work. So what happens is people convince themselves that the existing tech sucks and use that to rationalize doing the rewrite. The result ends up not always being net superior, because sure you did the rewrite but you are also eating the operational cost of integrating a new technology into the org.