This is quite a bit like comparing moving your stuff into an apartment vs. building a house to move your stuff into. If you don't need the flexibility and stability of owning the structure then it's best to rent just what you do need. If you do need a house, then it's worthwhile to compare the complexity and costs of different methods of construction.
The Cult of Kubernetes
181–190 of 338 posts
Re: The Cult of Kubernetes
#182Earlier quoted context omitted.
Part of the problem is the hiring process (plus attitudes seen on here). Your resume needs to have lots of fashionable buzzwords rather than pragmatic good enough / keep it simple choices. You must keep on learning (lots of things rather than mastering any one thing). I can write a really nice site in standard Django with some JQuery, and it will take me half the time that adding React to it will. But adding React wi…
Rails with turbolinks or Django/Laravel + pjax is good enough for most purposes. When Kubrrnetes first appeared it was laughable if you used it for anything less than provisioning a massive fleet of servers. Now it's something you sprinkle on your corn flakes.
Yep. We just started implementing it at my place. I had only just started and wanted to say that it seemed like overkill, but it was under way when I started and bringing that up in my first week didn't seem like a good way to start.
Top be fair it has reduced our server costs a bit (after maybe 6 months of developer time). I am unconvinced it will be worth the hassle.
Re: The Cult of Kubernetes
#183Earlier quoted context omitted.
The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. It is typical for devs. Meanwhile ops have to support every half-arsed tyre-fire technology until the end of time, because a dev wanted to try it once, and now it’s in prod with users relying on it. Kubernetes is in a sense the pushback against that “do…
It's typical for web application devs . There is a huge ecosystem of software developers outside of web services who are much less fad-happy and much more focused on using established tools to produce useful, reliable systems.
DBEs as well. We're constantly getting new database back ends for apps to the point that the Ops DBAs support some 9 backend database solutions. Granted, that probably falls under WebAppDevs for the most part.
Re: The Cult of Kubernetes
#184I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…
Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea.
Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything needs to be a plugin and nothing should work out of the box the complexity started to creep up.
You should be able to run your small blog on kubernetes without requiring a team of consultants to set it up or manage it. Just waving your hands and saying well it needs to be complex to scale is a total lie.
Re: The Cult of Kubernetes
#185Earlier quoted context omitted.
K8S is hardly just "writing config files" is it? You've still got to understand a ton of moving parts underneath before you're able to.
K8s is writing config files just like Python is writing Python Syntax. If you don't understand the underlying mechanism, either with Python or K8s yaml files, you're going to have a very bad time. Somewhat ironic side note - Asking folks to write K8s config files is exposing too much complexity for some developers I work with. And I kind of get it. Properly setting up a service with changing environment variables, se…
Yeah, fully integrated “DevOps” at scale is a pipe dream. You will always have some segregation of dev and ops because the scope of knowledge is so different, especially today where “Ops” often means “expert in XXX cloud vendor’s product portfolio and how our operating model uses the features”.
What we call “DevOps” is really a delicate balance of giving the dev teams enough rope to hang themselves while child-proofing the gallows.
Re: The Cult of Kubernetes
#186Earlier quoted context omitted.
The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. It is typical for devs. Meanwhile ops have to support every half-arsed tyre-fire technology until the end of time, because a dev wanted to try it once, and now it’s in prod with users relying on it. Kubernetes is in a sense the pushback against that “do…
> “do what you want, as long as k8s is up, what you run in your pods is your problem, not ours” Until somebody cyberattacks those pods and steals all personal data of your users because the devs didn't bother to apply security patches. But hey, it's not your problem. You are not responsible for the pods. k8s is still up.
But hey, it's not your problem. You are not responsible for the pods. k8s is still up.
But that has always been true. If a dev leaves a SQL injection for example in the code and it got penetrated, absolutely no one would blame the sysadmin for that.
Re: The Cult of Kubernetes
#187I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…
I’m not sure I agree. K8s’ primary benefit is that it strings together the IAAS abstraction into a single api.
It allows you to deploy multiple replicas, automatically setup a load balancer and handles maintaining the link between the LB and the backend. While also replacing any failed replicas.
Re: The Cult of Kubernetes
#188After years of ignoring it, I'm no longer able to fight the cloud urge. What's the best way to learn k8s in 2019?
I'd suggest to read "Kubernetes: Up and Running" book, it's short enough and cover basics of k8s. Also it's important to have hands-on k8s cluster, so Google Kubernetes Engine would help a lot about spinning up a cluster.
I had to get up to speed on k8s at work this year and from that experience I would recommend to use minikube at first. Only go to GKE or such once you outgrow minikube. Doing minikube first also makes for a nice way to develop an application. Minikube for local development and testing, then deploy to GKE for QA & prod.
Re: The Cult of Kubernetes
#189Earlier quoted context omitted.
Not all of them though. Still happily using JEE/Spring/ASP.NET + VanillaJS in what concerns webdev projects.
Being old doesn't mean good. From my experience, using j2ee or spring to make a web app is grossly overcomplicated (I have heard of but not yet used spring boot). Asp.net is fine but anyone who is paying $$ for that is probably a dumbass
From my experience it still offers more performance than anything based on JavaScript, or scripting language du jour.
And while other AOT compiled languages might offer a little bit more performance, they lack in tooling and libraries.
Re: The Cult of Kubernetes
#190I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…
Where would you draw the dividing line between where you think it does make sense to use something like Kubernetes and where it doesn't?
I'm starting to feel that the whether or not you need Kubernetes is closer to old conversations related to whether or not you need a dedicated DBA. Can your organization survive and recover with hourly/nightly backup restores to recover from an incident? Is your replication so complex that you really need a guy to ensure that's never getting into a bad state? Worse case scenario can most people working on the project restore the database to a valid state if something does go wrong? I feel like these questions have similar representatives in whether or not Kubernetes is right for an organization.
Kubernetes also makes more sense if you look at it as a common way for an organization to run applications among disparate teams with a shared operations infrastructure. It provides a standardized model for things to work the same enough to work the same. If you are only delivering one kind/whole organization thing and it all looks and quacks like a duck maybe you should just deliver a duck instead of putting a duck hat on Kubernetes and asking it to quack.
I don't think there is anything wrong with designing an application that would transition easily into Kubernetes but I feel like many of the proposals/PoC I have seen in the last few years are either fresh systems that get consumed by Kubernetes complexity or are poor replacements to systems that already exist and only seem to serve as resume padders for the team architecting the replacement which gets a viking funeral as soon as they leave. Often the latter case is because the underlying architecture and goal of the system is pre-Kubernetes and doesn't fit the model well of having mostly stateless/replaceable pieces.