Is KUBERNETES Overly Complex? | Kelsey Hightower & Dave Farley Debate The Open-Source System

[@ContinuousDelivery]

Set up your team for success. This FREE GUIDE is a great resource for team leads or business leaders managing technical teams and are looking for advice from me in a convenient, short-form handbook. Available to download NOW ➡ www.subscribepage.com/organise-teams-guide

[@timtim9o5]

This guy is great, and he speaks very well!

[@vanivari359]

What annoys me about Kubernetes is that in many large corporations we - thanks to Conway's law - use it like we used application servers (which was already not the intended way). Thanks to banal criteria like how to assign costs to projects, many companies create one Kubernetes cluster for 1 or 2 "micro"-services. Or even worse, every project get's it's own landing page in AWS/Azure and manages everything themselves. The giant waste produced by these silos just so everyone get's their own bill at the end of the month. Kubernetes can manage like 150,000 pods and i have seen customers where dozens of clusters run like 2-8 pods, each operated by a different external vendor who implements those x pods as part of a large system. It's frustrating that teams of 5-10 people have to care about file system space and networks and routers and node-updates and log-forwarding and node metrics and all that stuff when kubernetes provides all the abstractions necessary to manage that centrally and efficiently with experts without them being a bottleneck for anybody.

[@optimalchoice270]

Your point is salient. I've been watching this problem, in different forms for decades. "Large corporations" = bad management.

[@blaiseutube]

We should talk... I've had ring side seating to the clown show called enterprise cloud computing. Last year I discovered a bug in cost accounting and I will no longer try to help enterprises adopt continuous delivery. I am going to leverage the bug as a competitive advantage instead.

[@voidmind]

I hear you. Infrastructure as code does fell like corporations trying to push the sys admin job on developers. We used to have a server for hosting small forms and a database and we uploaded our code with FTP. Now every one of these forms has to be in it's own pods. The amount of overhead to get something going in Kubernetes doesn't make much sense for projects that don't need the power of clusters to scale.

[@trumpetpunk42]

This is where a platform-as-a-service is such a huge advantage, but then those same corporate drones go "that's WAY too expensive! We'll just build our own platform! How hard could it be?" Double the cost/schedule later...

[@mannion1985]

The problem is that it seems most do say "we need a jackhammer" as soon as they encounter a nail rather than start simple and grow the solution in line with the problem.

[@edwardallenthree]

The metaphorical realm of your statement makes it difficult for me to understand what you're actually saying. What's an example where containers and application deployment aren't relevant and development, and where someone might actually implement them anyway. Nobody's grabbing a jackhammer to hang up a picture. Nobody is using a tack hammer to break up large sections of concrete, and they probably shouldn't even using the tool for small sections of concrete.

[@CharlesDenison]

Yes! I see newer engineers overdesign in this way because they think they have to use all the features available or build for lots of "what if" scenarios that will likely never exist for us. And I see non-technical management falling into a similar trap where they think we always need to use the latest things that they are hearing about just because they're new and getting a lot of attention in the industry.

[@trumpetpunk42]

The other side of the "grow the solution" analogy is you can end up duct-taping a hammer-drill to a pogo stick, when a jackhammer was actually what they needed

[@mgbrown09]

In the software field we suffer from keyword driven recruitment. People see lots of job advertisements requiring Kuberneties and they think they must make their project use it so they remain employable. Then there is another project requiring it on job adverts and the feedback loop amplifies the problem.

[@orstorzsok6708]

I absolutely agree. Hypes always come and pass... I am wondering what the next idiotism will be...

[@mgbrown09]

@@orstorzsok6708 Macroservices are due a turn.

[@JeffryGonzalezHt]

I think the key point was made early on - raising the bar of abstraction. Keeping developers focused on business requirements instead of technical requirements. Using annotations to declaratively handle things like authn/authz, CORS, caching, log aggregation, a mature cluster is like AOP at scale.

[@voidmind]

All valid points, but considering that system administrators used to take care of all that software configuration (at least in large enough companies) in the past, the "keeping developers focused" part doesn't quite work in my experience. Devs who also have to take on dev ops will be significantly less productive than if the infrastructure what handled by a separate, specialized team.

[@rialpleya]

As the saying goes: use the right tool for the job. K8s certainly has its value when we deal with a fairly large distributed system with a fleet of services and applications. Such system is complex by nature and thus the tool to schedule the work. However in such cases you will need to manpower the administer and monitor the system. Before you had a decicated team working around the clock to both maintain and observe the system. Now you need probably a Platform Team taking care of the K8s cluster. That said, most of the time your application consists on a handful services, each with its own replica. In such cases you are better off with serveless solutions such as Elastic Beanstalk, App Engine, Heroku, etc

[@RobinEdmunds]

Excellent guest.

[@MasonPayne]

My company has a really good approach. Everything is on Kubernetes. But most developers don’t have to deal with the specifics. We have standard application settings and rules. We have a tool that does all the configuration for us. It takes a dedicated team to make sure we have tools that work well enough for us.

[@awworrell]

I find Kubernetes to be extremely complex and in some cases more complex than software and systems I've built or supported before using it. It's not a bad thing but sometimes that complexity is not needed. I think part of the issue is when something fails a person needs to understand how Kubernetes works under the hood to begin understanding how to debug issues. I've run into a few problems so far with it where I had to understand how the scheduling system works to begin to try to debug the issues we were having and more importantly how to fix them so that the scheduler would schedule them. One other issue I've seen too is that companies invest heavily in training, troubleshooting, and using the tool. As a result, when someone has a use case that is really better suited as a serverless application for example, the company ultimately throws it in k8 because that's what is done. That isn't the fault of the tool necessarily but the added complexity and management that comes with k8 does influence those decisions. Personally, I love serverless development in large part because I don't have to think about infrastructure or managing that infrastructure. K8 did solve some problems but also created new ones I think by how it solved problems.

[@cccc2740]

perfect example of leaky abstraction, isn't?..and same is true for some other famous softwares, like git....you really need to understand internal of git to do trouble shooting

[@sl1msn1per]

I've seen Kubernetes fail at a big company and work at a small company. For my money it works when: 1. You use a cloud provider to manage it (or otherwise hire a full time expert to solely manage it, though cloud is more reliable and quicker to scale/adapt) 2. There is wide developer buy-in. It helps a lot if people are using an easy-to-container/scale language like Go. 3. Don't worry about doing anything fancy if you don't need to. Deploy some bog standard helm packages for log collection, and their log querying tools can do quite a bit of heavy lifting in terms of giving you metrics/alerts/etc.

[@W4ldgeist]

When a simple, monolithic CMS system is run on a server, that runs Kubernetes, that runs ONE docker container, then you know people are just doing stuff because Google told them it's cool.

[@robertkerr229]

Not entirely bad scenario. Running that monolithic app in that container means the mean time to recovery is improved. Coming with that is immutability, controlling configuration drift, separation of concerns, and probably lots more. Plus as they peel off some of the monolith's services which they want to be scalable, they're halfway home.

[@W4ldgeist]

@@robertkerr229 Those are academic attributes tbh. "time to recovery" is relevant to whom, when and where? I've been working in this industry for 20 years. Most of that time hosting on pure metal, not even virtualized servers. In 20 years that was not a single hardware failure that would warrant adding such a complexity to improve the "time to recovery". Then we get to the "oh, but i have the same config as on dev" argument. Which for 20 years also has never been a problem for me practically, as I work with PHP based systems, that run on quite limited, standard PHP plugins (symfony basically). Then adding the scalability argument. Again in 20 years most "scalability" was easily achieved by adding a varnish cache, which made most systems easily perform 10k connections and users per second, which is magnitudes above what our customers needed. There ware always situations where going above and beyond with these complex setups, but in literal decades I've rarely come across them, to justify making that a standard for every project to run.

[@orstorzsok6708]

Not Google was the one who told them.... but their own stupidity. (Google uses it for real problems and for a huge amount of HA services...)

[@orstorzsok6708]

@@W4ldgeist 👌

[@keithndhlovu]

@@W4ldgeist As Kelsey said, if you don't need it don't use it. In your situation, you did not need it for 20yrs which is fine.

[@JayJay-ki4mi]

Using Kubernetes when you don't need to use kubernetes is what introduces complexity. For the most part I've written my own provision scripts, and use Vagrant to manage my dev servers. The same provision scripts are used in production, with the same level of security. My computer is powerful enough to do this. As a solo developer it's rare I'll need to use it unless I'm joining a project that already uses it. My projects are never big enough to warrant it.

[@sneibarg]

Kubernetes is great for a microservice architecture because you can expose the services that service your users in a public network and keep the backend in a private network. We all want our backend to respond as quick as possible, and the best way for that to happen is for it to run on the loopback.

[@fishzebra]

When would I choose kubernetes and containers over utilizing inbuilt cloud tools? For example in Azure I can simply deploy to an App Service with a Plan. I can decide the power, know it always has latest patches, geo redundancy, logging and alerts in Azure. It would certainly be useful if I wanted to abstract away the cloud provider in case I wanted to move it to AWS for example. In most cases relying on the cloud's inbuilt services are a lot simpler and result in cheaper development, even though using kubernetes maybe cheaper in terms of hosting costs.

[@pl4nty]

Containers enable lots of really efficient developer workflows, and reduce dependency on the cloud provider. eg App Service is pretty slow to support new NodeJS/Python versions, but containers can run anything. They're also portable in case onprem/multicloud is strategically relevant to your organisation. Whether to run those containers on k8s or a managed service (Azure Web Apps, ECS, etc) is a different tradeoff though. I've found the k8s ecosystem provides very powerful observability and governance, particularly with large and homogeneous app estates. But it needs a ton of investment, so lots of organisations start with a managed service and migrate to k8s if needed (especially if they need to containerise older apps first).

[@pl4nty]

It's also worth noting that App Service can run on your own k8s cluster via Azure Arc

[@veryjust]

Everything is both complex and simple at the same time, as it is all down to what you want to archive. Personally I think Kubernetes is fairly simple and straight forward, there are many common coding frameworks out there that is more magic and harder to understand, and I come from background as a developer.

[@brownhorsesoftware3605]

My solution is to avoid complexity by designing for high network latency on the computer that fits in your pocket. I use an App Engine Standard headless web app to pipe async messages to other phones via Firebase. The app runs on simple local file system xml. I use the cloud as a message switch and Google does all the heavy work for pennies a month.

[@Omnifarious0]

The rotating blue borders are really distracting.

[@GustinJohnson]

For me the main problem with Kubernetes is that it is not a "batteries included" solution. Networking, storage, container image registry, there are so many pieces that are missing. Adding those pieces is non-trivial and so I don't see Kubernetes as a completed standard yet.

[@TheALEXiSounds]

The great thing about Kubernetes, is that it can be as complex as you want it to be. It certainly does not have to be complex, and at it's bare bones, it's simply a container orchestration tool.

[@ReconTek]

I think people fail to realize though that just introducing k8s also introduces a bare minimum level of complexity. This complexity needs to be understood from top to bottom to use effectively and be able to troubleshoot it when something goes wrong.

[@TheALEXiSounds]

@@ReconTek It certainly does not need to be understood from top to bottom. You can get started with a production ready cluster, using EKS or GKE and not understand how the control plane works.

[@pl4nty]

@@ReconTek cloud providers abstract away most of the k8s complexity - cluster autoscaler, node autopatching, managed controlplane, etc. It's pretty hard to hit platform issues these days, and even then it's usually limitations with the underlying provider that occur with VMs too (Azure NAT 🙃). I mostly see devs struggling to debug broken apps tbh

[@rialpleya]

After minute 10:00, and I guess as Kelsey starts feeling more comforable and excited, when I close my eyes I think it's Snoop Dogg I'm listening to. Same voice!

[@WayneMunro]

Have a look at Service Fabric as a first-class platform for microservices and containerization that is way simpler than k8s.

[@PeterPerhac]

Kubernetes is the jQuery of Ops

[@marcellodimarinoazevedo]

Is KUBERNETES Overly Complex? Who is asking, a developer? Ask that for an infrastructure person used to manage all aspects of an OS/hardware administration. Since Kubernetes is a platform to create platforms it is not simple because it's powerful. Many teams have to work together to deliver its value to business.

[@jasondbaker]

I can understand the use case for k8s in a private datacenter where you need to support a standardized infrastructure delivery model. Where I struggle to see a fit is when companies layer it on top of an existing public cloud infrastructure layer. The public cloud already acts as an infrastructure SDK. Why do I need to add another infrastructure layer and core dependency in my app platform? It’s just another layer that we need to maintain, monitor, and fix. Here’s why I think k8s is valued by businesses: K8s offers a lift-and-shift delivery model which helps companies avoid the need to build cloud-native applications.

[@edwardallenthree]

What an odd statement. Essentially what you're saying is why should we standardize the way we describe deployments, when every data center already has their own unique tools that do two-thirds at the job?

[@jasondbaker]

@@edwardallenthree No, I’m not saying that at all. Almost the opposite. I recognize the attractiveness of k8s in private datacenters where companies typically lack an infrastructure SDK and standardized software deployment model.

[@mzbmwbbpkf]

Some companies need a cloud provider exit plan for compliance reasons. It is much easier to prove this plan using Kubernetes. It's easier to find a K8s developer than an ECS developer. Many open-source projects are easily deployable to Kubernetes, thanks to Helm. But I agree, you should avoid it if you can.

[@pl4nty]

cloud provider sdks aren't as standardised as k8s for observability or deployment, even if using terraform etc as a wrapper. So k8s can be a good trade-off for really large or homogeneous application estates

[@jasondbaker]

@@pl4nty I agree. K8s introduces a narrow set of constraints on businesses from an infrastructure and delivery perspective. It reduces complexity in some sense while steering companies away from the rich ecosystem of managed cloud services. Some companies intentionally don’t want to build cloud native applications. To me it really comes down to an organization’s cloud maturity, its capacity to teach cloud-native development patterns, and its ability to implement delivery guardrails. K8s is a reasonable choice if an organization struggles in any of those areas.

[@softwaretestinglearninghub]

Like you view on it, thank you for the information.

[@user-es9qo9hx2r]

9:37 what kubernetes does is just say, "let's be honest about it"

[@quranthecompanion4528]

Kelsey: bro, you are good. Indeed you are very good.

[@justinoleary911]

K8s is the new silver bullet solution 😂 it’s fixes everything by making everything extremely more complex simply so developers have an easier way to package software

[@reactiveland3111]

I happily used hashi corp nomad. Simpler than Kunernates

[@esra_erimez]

For those interested, here is a link to the video against Kubernetes: kzbin.info/www/bejne/fmbWgXqoqttlr8U

[@dandogamer]

please don't link other channels, especially theo's 😆, the guy doesn't even do unit tests

[@someperson22]

The Aws CDK is way simpler than Kubernetes and more powerful.

[@alvaromoe]

"Cool"

[@kasparsr]

EJB of modern days

[@ayotundeayoko5861]

lets not lie...its complex

[@xcross4228]

The animations around the video are really annoying

[@Thorax232]

GraphQL is the better/perfect replacement for Kubernetes.

[@TheALEXiSounds]

Wtf are you even talking about lol.

[@Thorax232]

@@TheALEXiSounds you got a ways to go

[@TheALEXiSounds]

@@Thorax232 I don't think you understand what Kubernetes is let alone GraphQL

[@edwardallenthree]

To take the hammer analogy, you just mentioned your favorite screwdriver and offered it up as a replacement for a jackhammer.

[@xaxfixho]

Troll 😒

[@optimalchoice270]

🤮 Repost of prior content

[@orstorzsok6708]

en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes