Why Kubernetes Is the New Application Server

https://developers.redhat.com/blog/2018/06/28/why-kubernetes-is-the-new-application-server/

by rterzi • 8 years ago

281 175 8 years ago

developers.redhat.com

zokier• 8 years ago

Is this a response for the Jib announcement and the inevitable comments that followed? Sounds a lot like it is...

testvox2• 8 years ago

Sorry but this article implies that containers can solve issues like the difference between path separators on Windows and Linux. They can't even solve issues arising from differences in kernal versions, not to mention operating systems.

SriniK• 8 years ago

Did you consider http://kubevirt.io/ ? It supposed to solve some of these hard limitations.

pdimitar2• 8 years ago

This can work, but stacking framework on top of the framework is what made the classic application servers undesirable and a horrible mess to begin with.

Observing similar patterns creeping in the Kubernetes culture and ecosystem does not inspire optimism in a side observer like myself.

lkrubner• 8 years ago

Nor does Docker protect against such obvious things as differences in versions of base images. Check out the Slack dialogue at the end of this:

http://www.smashcompany.com/technology/docker-protects-a-pro...

craftyguy2• 8 years ago

Always use /

Windows can, surprisingly, handle it just fine.

JetSpiegel• 8 years ago

On interactive uses, sure. But it's not clear cut, some code paths are lower level and bypass that.

lardo• 8 years ago

I spent two hours scratching my head today because I had put

  "/path/to/thing/**"

in a nuspec file instead of

  "\path\to\thing\**"

The backslash was escaping the wildcard characters :(

mkesper• 8 years ago

Never use windows, why should you for development and deployment?

taeric12• 8 years ago

It is hard not to build this impression of containers. Worse, it seems that the docker image format is massive compared to what most war files were like. This is annoying not just in terms of raw bytes to move around, but in taking stock of what is getting moved around.

My team originally pitched how docker solved much of the dependency upgrade management by having layers for each major set of dependencies. That ignored the fact that upgrading a layer is not really something you do.

So, then you can go around the path of coordinating many containers communicating with each other. That works, but in that world, things really don't seem any easier than the earlier alternatives. Harder, in many ways.

Don't get me wrong, the momentum and raw money being put into containers certainly paints it as the future. It just feels like lying to say that they have even come close to parity with what we were capable of not that long ago.

xj92• 8 years ago

the linux world is slowly (and badly) recreating technology that has existed in FreeBSD and Solaris/Illumos for decades.

taeric12• 8 years ago

Be fair here. The software world is slowly recreating technology. Being even more fair, they do often add to it. Usually UX capabilities, but sometimes full on features. Yes, often the features require more resources than were available before. Such that previous versions couldn't have offered some of these things.

That said, it is not limited to any one set of our industry. It is likely not even limited to our industry.

tomsthumb• 8 years ago

Which technologies were those?

I’m only vaguely familiar with FreeBSD, and not at all with Solaris.

grapeli232• 8 years ago

You probably never heard or used - Linux VServer. Available from the later version of the 2.4 kernel.

https://en.wikipedia.org/wiki/Linux-VServer

pjmlp2• 8 years ago

And HP-UX/Tru64 before them.

We were deploying into HP Vaults in 2000.

ecnahc515• 8 years ago

Yeah, except even jails has gaps, like for example; shared memory isn't jailed.

dnomad2• 8 years ago

Exactly. Docker files are worse than war files in pretty much every way.

The economics are interesting though. Computing resources are super cheap and getting more cheap everyday. (Well except for RAM!) The waste produced by containers means says, yeah, give each application its own app server. Its own web server, its own JDBC driver, even its own JDK. We'll throw it all on the cloud and run it for a few cents each hour.

The problem is that testing isn't cheap. This is where microservices and containers and the all this craziness will fall down. Now you've got dozens and dozens of applications all running with their own application servers, JDBC drivers, and their own JDK. This is a combinatoric explosion in your testing surface.

The true value of the application server approach is that it forced applications to conform to a clear contract. Once your application conformed to this contract it could be thrown over the wall into a full-time ops organization that could transparently deploy, monitor and manage the app.

The container madness will come to an end. People will realize that giving developers the keys to the kingdom and total freedom over their application is a terrible idea. (And smart developers don't want total freedom.) What will emerge will be something much more interesting: a hybrid approach where applications can be bundled into into artifacts that fully express their dependencies and containers can be annotated in a way that fully express their capabilities.

Containers provide isolation and immutable infrastructure and this is good. Appservers provide standardization, specialization and separation of responsibilities and this is also good. There's no reason why we can't enjoy both.

kinghajj• 8 years ago

Nothing prevents one from having a container with many WAR files, so that there's only a single JVM for multiple applications.

tyldum• 8 years ago

We use containers to reduce the testing surface and enforce standards. And if course to ease testing as we now transition the same build through dev, staging and prod.

The devs just have a single base container to work off from and we use CICD to further enforce whatever we need to.

It also makes it easier for devs to propose changes, as we know we can consistently apply them.

parasubvert6• 8 years ago

Exactly. Docker files are worse than war files in pretty much every way.

They focus at far too low level a problem.

The problem is that testing isn't cheap. This is where microservices and containers and the all this craziness will fall down. Now you've got dozens and dozens of applications all running with their own application servers, JDBC drivers, and their own JDK. This is a combinatoric explosion in your testing surface.

I fail to see how this more difficult from 95% of existing enterprise systems that run various JDK versions, various WebSphere versions, JDBC drivers etc.

The difference with containers is that vendoring your dependencies makes all that explicit. Whether you choose to stay on old versions is a mistake you can still make (and will make if you leave container creation and patching in the hands of dev teams).

That said, since when does any organization build horizontal testing libraries, like, "test X version of JDBC", so they can standardize on a single driver across all projects? It's never done. Projects are all over the place with their dependencies unless there is institutionalized forcing through Maven repos or what not to block the download of old/insecure versions.

There is no combinatorial problem here, each test suite needs to unit test the individual service and then test the API contract of the service. If you let your dependencies decay you're accepting major security and maintenance risk, but you were in the WAR file world too.

The true value of the application server approach is that it forced applications to conform to a clear contract. Once your application conformed to this contract it could be thrown over the wall into a full-time ops organization that could transparently deploy, monitor and manage the app.

LOL, I really think you're exaggerating. I've worked with WebLogic, WebSphere, IIS, JBoss, Tomcat, Django, Rails, Node, you name it over the years, and while some orgs got close in the Java world, this was mostly a pipe dream that never happened in any cost effective manner as a standard practice.

The container madness will come to an end. People will realize that giving developers the keys to the kingdom and total freedom over their application is a terrible idea. (And smart developers don't want total freedom.)

This I agree with. It's all far too low level.

This really was Docker, Inc.'s fault IMO, their marketing message was to empower developers to get ops out of the way by building these containers that would magically just be run as opaque lego blocks. That was the hype everyone on HN was drooling over in 2013. Turns out it's not quite that simple.

mmt9• 8 years ago

People will realize that giving developers the keys to the kingdom and total freedom over their application is a terrible idea. (And smart developers don't want total freedom.)

Sadly, I don't think it's actually developers that were pushing for this "freedom" (with which comes responsibility, hence it makes sense that it would be unwanted), as such.

Rather, I place the blame with managers and with (fellow) sysadmins for not embracing, empowering, or forcing (whatever it takes) the aspects of the original DevOps cultural movement to have Ops bring the equivalent [1] of a production environment to every developer.

Containers provide isolation and immutable infrastructure

I thought they weren't even (necessarily) immutable. If not, then maybe they're merely immutable-through-practice, but that's as unsatisfying as configuration management systems creating reproducible deployments that lack traceability [2].

[1] In terms of tooling for things like builds, deployment, and management (especially of dependencies), not necessarily full hardware capacity, although at one place I did provide each developer with a copy of yesterday's production database on their own, personal bare-metal database server, less "beefy" than the production hardware.

[2] is that the right word? something like chain-of-custody for code and/or configuration.

dionian• 8 years ago

So just reuse the common layers and only have your WAR file layer changing

taeric12• 8 years ago

The problem is when there is a vulnerability in some part of an earlier layer. You have to rebuild the entire stack.

I honestly don't think this is necessarily a terrible thing. But, the idea that your common layers are stable is a dangerously bad assumption.

tzakrajs• 8 years ago

Instead of the new Application Server, Kubernetes is the new OpenStack. A conglomeration of projects that support a platform for deploying and operating software in containers or virtual machines. Just like OpenStack, some of the components deal with storage, others with networking, and others still with service discovery or proxying.

Without getting too far into semantics, I think the author is using a well overloaded terminology. When I hear Application Server, I immediately think tomcat or some other jvm.

sewercake2• 8 years ago

We're in the process of migrating our (primarily) java services from straight AWS to kubernetes.

At the beginning the author poses the following questions:

* Do you use Mac, Windows, or Linux? Have you ever faced an issue related to \ versus / as the file path separator? What version of JDK do you use? Do you use Java 10 in development, but production uses JRE 8? Have you faced any bugs introduced by JVM differences?

* What version of the application server do you use? Is the production environment using the same configuration, security patches, and library versions?

* During production deployment, have you encountered a JDBC driver issue that you didn’t face in your development environment due to different versions of the driver or database server?

* Have you ever asked the application server admin to create a datasource or a JMS queue and it had a typo?

I've experienced problems whose root cause are some form of all of those. Much of it could be chalked up to growing pains etcetera, but, for example, there are concrete differences between docker versions running on mac and linux that have shown up for me.

This doesn't reduce the author's argument, but they do seem liked strange examples.

Our choice to move to Docker and kubernetes came from developers, and specifically spoke to the need for consistent, reproducible test environments. We had dockerized most applications many months before the notion of using them in production was put on the table. What remains to be seen is if the switches in production reduce complexity and maintenance on the devops end of things, as well. I'm also curious how many other organizations had containers introduced 'from the bottom up' like us.

taeric12• 8 years ago

Honestly, most of the introduction I've seen has been bottom up or from new hires. I think there is a major point in having happy development environments. Happiness with tools is a very important point that is hard to quantify. https://www.johndcook.com/blog/2011/07/31/enjoyment-of-ones-... has a fun exploration of two great quotes on this vein.

That said, if you can, I'd be ridiculously interested in a retrospective when you have a chance on your transition. Good luck with it!

knesek• 8 years ago

Hm. My team is running and developing a somewhat complex system based on jvm for years, and never encountered any of the issues in the bullet points. Having consistent test, staging and production environments produced by ansible have been working out for us (and is not hard). Are we just being lucky?

sewercake2• 8 years ago

I don’t have enough experience to say how common my experience (or yours) is, but I don’t know how much luck is involved. I’m sure many institutions have solved these problems without containers and sicker.

But For various reasons, political, personal, technical etcetera, consistent, accessible test environments were not available. It was a huge bottleneck for developers.

This is why docker was so appealing: it allowed devs to circumvent the political and technical issues. We didn’t have to justify provisioning more instances, since we could just use docker compose to run stacks on local machines.

So I’m that sense, the choice and it’s benefits arose from non technical hurdles.

eecc• 8 years ago

Well, until someone develops and releases (and strangle all naysayers) a language independent thing remotely like JEE JNDI... it’s just not. Sorry, JEE was horrible but also so beautifully ahead of its time

hyperman1• 8 years ago

Unfortunately, JEE was horribly behind the times. A lot of the ideas came from the COBOL middleware world. Others were a remix of CORBA.

dkhenry3• 8 years ago

I would say Kubernetes is becoming the new Application Server, but not for anything listed in the article. Kubernetes is more and more being sold to "enterprise" as a solution for running services much like Application servers were, and much like application servers the standard Kubernetes deployment is becoming a tangled mess of buzzwords and dreams, which work great in a demo, but won't work at all without an army of consultants.

colechristensen• 8 years ago

Very similar abstractions are being created over and over, if you are too close it is hard to see that the abstractions are largely the same, and the grand benefits being toted are actually quite small when comparing one to the other and the differences are just attitudes and a tiny bit of tooling that could be recreated for any of the abstractions.

taeric12• 8 years ago

It does get frustrating to lose tooling you previously had. Even more frustrating when some of the instrumentation that you take for granted in the old world is "TBD" in the new one.

threeseed4• 8 years ago

I can spin up a Kubernetes cluster in seconds using AWS, Azure or GCP. And with helm installing new applications is a pretty trivial affair.

I am not disagreeing that it’s complex and a lot of buzzwords but every day the situation is getting better and better.

dkhenry3• 8 years ago

You can also spin up Tomcat with everything needed to run an application with your local package manager and you can deploy your WAR file by putting it in the right location, but that's not what IBM, Oracle, and Red Hat have sold as Application Servers.

This is effectively what is being sold now but using Kubernetes and Containers instead of Application Servers and J2EE

halbritt7• 8 years ago

Easy peasy.

Now try troubleshooting it.

brozaman3• 8 years ago

I'm a former OpenShift (Red Hat's distribution of Kubernetes) consultant and currently I work at Red Hat in a different position and I have to disagree on the "won't work at all without an army of consultants".

While it's true that some of our customers have an army of consultants, the vast majority of our customers don't use consulting at all or that only use it very infrequently. If you don't want a lot of customization, have the right amount of people and the right people and realistic expectations you don't need consulting at all.

When people want to get a highly customized experience (often, for the wrong reasons), or want to get in production after 2 months, when their people have no experience in kubernetes and didn't do adequate testing (load, fault-tolerance, etc) it will give lot of problems. But that's the case for everything, not only for kubernetes

In my opinion (mine, not Red Hat's) getting someone to deploy it with you the first time, showing how it's done and why things are done, and after that and do a workshop explaining the basic concepts has great value, saves a lot of time and isn't expensive.

dkhenry3• 8 years ago

This is the same process that was done with J2EE and Application Servers, it starts out with a _simple_ standard to have a Java application served with a standard API, and then it grows out of control. You are already seeing it with Itsio and Helm being layered on top. Today you might be able to get the stock Kubernetes up without much assistance, but give it a few years as "features" get added on.

mmt9• 8 years ago

want to get in production after 2 months [...] it will give lot of problems. But that's the case for everything, not only for kubernetes

Are you asserting that any modern production environment that takes less than 2 months to set up is bound to cause problems? Or the whole company/startup/project?

If the former, I'd say there are many tech startups who would disagree, or at the very least, point out that it doesn't matter because they'd cease to exist during those 2 months without an MVP in production.

dsmithatx4• 8 years ago

I'm helping build an Openshift platform with 2-3 redhat consultants. I do not work for Redhat, I'm a Linux/Devops admin. It's been very simple to install and fully automate everything. It also is allowing developers to focus on writing code and not infrastructure as AWS does. Most of it is bare metal for now, but we will be able to spin up AWS and Azure in a few hours with the same code.

The instructions are accurate, it's been easy to learn, and does not require an army of consultants. We will be moving 1000's of apps to multiple data centers globally with a team of around 6 people. It took 100s of employees years to build and maintain infrastructure for those apps.

Note - Consultants are not needed at all, they simply help speed up the process with expert knowledge.

marenkay4• 8 years ago

I have to disagree here. From personal experience I can say: you need exactly one person willing to read, try and properly observe the installation and population of a kubernetes cluster with applications and tools.

The actual cluster deployment is not mess at all. Even if done with a mere Bash script, it can be done in like 20 lines of code.

I can only recommend to actually try using Kubernetes because what you wrote reads more like you are actually still in the state of "wtf is this and why should I touch this crap?" but have not yet tried it.

fauigerzigerk6• 8 years ago

Here's my prediction: DevOps is dead. In 5 to 10 years developers will no longer be mentioned in articles like this.

There will be specialisation once again, because it makes absolutely no sense to make people whose main job it is to think about use cases, business logic and user interfaces to also deal with stuff like this.

anothergoogler• 8 years ago

What does "DevOps is dead" mean?

mandelbrotwurst• 8 years ago

Seems he's essentially just predicting an increase in the division of labor between product development and infrastructure work going forward.

fauigerzigerk6• 8 years ago

That devs will no longer do ops.

dsmithatx4• 8 years ago

In Devops ops write infrastructure as code. I'm an old school bash perl sysadmin. Devops with Agile is a cultural shift and has transformed the last 4 companies I've worked at. Two of them having ~100,000 employees. We now do ops with 6-10 people for systems that used to require 100+ people to build and maintain.

cphoover• 8 years ago

Yes it makes no sense for developers to understand the underlying systems that run their applications. /sarcasm

fauigerzigerk6• 8 years ago

Understanding the characteristics of the underlying systems is one thing, but actually building and maintaining them is something completely different.

pdimitar2• 8 years ago

You definitely have to have a good knowledge about the underlying system, no doubt.

But actually shouldering the burden of creating and maintaining the entire runtime -- and orchestrate it -- is a bit much and stretches people thin.

lainga• 8 years ago

Maybe that's true, but it also makes no sense for me to be interrupted every 15 minutes by someone asking me "I need you to restart your $deployment for something I'm doing" while I'm trying to develop.

barrkel• 8 years ago

K8s establishes a pattern for implementing many ops tasks as controllers rather than scripts or configs. The level of abstraction will be raised, and more and more of the custom hacks specific to individual companies will become modules you deploy on your cluster.

In this way, devs will be doing ops, but not as ops for any given prod environment, rather encoding operational tasks in reusable software.

Ops themselves will bifurcate, one towards configuring prebuilt controllers, others towards troubleshooting problems in production. The middle ground will hollow out.

dorian-graph• 8 years ago

This is how we ended up with Electron apps.

fauigerzigerk6• 8 years ago

No, that's unfair. User interfaces have always been and will always be a key responsibiliy of developers.

Writing native UI code is no more low level than using electron. It's just less familiar to web developers and less portable. These are completely different considerations than the greater degree of division of labour I'm predicting for the server side.

jimmy1• 8 years ago

VSCode is an electron app and it's pretty amazing.

solomatov3• 8 years ago

Another prediction in 5 to 10 years infrastructure will be so streamlined, so that developers won't need to think it at all. I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise.

pishpash2• 8 years ago

Exactly. It will be as simple as working with one machine (long overdue), when developers never needed help.

zapt022• 8 years ago

Have you used the AWS interface lately? It's getting further and further away from being streamlined.

some_account2• 8 years ago

No, the future is serverless applications in the major cloud providers where every server is abstracted away and things scale automatically.

The reason for this is the enormous cost benefits (its super cheap, you only pay when your code actually runs, no upfront costs, no passive server costs, no overprovision or underprovision of compute resources etc).

jerf• 8 years ago

"I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise."

As someone trying to be primarily a dev who keeps getting roped into doing ops stuff for deploying my stuff, my experience is the exact opposite, and in particular putting Kubernetes on the end as the least complicated technology seems outright crazy to me, like, seriously, what on Earth are you talking about? You literally can't bring up a hello world web app without basically knowing everything you needed to know to bring it up on bare metal, and everything you needed to know to bring it up on a VM (whose crazy virtual networking stuff now seems like simplicity itself compared to Docker/Kubernetes), and everything you need to know to bring it up in Docker, and everything you need to know to bring it up in Kubernetes... and you need some sort of solution around building Docker images, too, so you're still going to need to know that, too.

There's all kinds of reasons this is necessary and there's all kinds of reasons why provising a new hardware server, blasting a Linux distro on to it, and just running your server is a bad idea. By no means am I proposing we need to go back to some glorious past, where losing a single hard drive sector means "oh well, guess the database is gone! recovery plan? Our recovery plan is to not need the database anymore!" I'm just saying, it's crazy to think this is all getting simpler. Try looking at this through the eyes of a fresh grad sometime.

Granted, I'm a bit crabby that literally every time I go to deploy something new, on a roughly 18 month time frame (the intervening time being maintenance and feature development), I have to go learn something else for my one-off task. (I don't think devops manages to beat the Node/JS world for churn, but it's probably in second place.) But still, it's getting more and more complicated, not less, and I don't even sense that we've passed an inflection point on the complexity reducing yet.

bamboozled2• 8 years ago

We’ve had Heroku for almost over ten years now...

marenkay4• 8 years ago

Infrastructure already is streamlined as hell these days, even bare metal installations. Manual installations from 1996 versus a kickstarted USB installation, iPXE, etc. already feels like things are on pre-school level.

What will very likely not be going away in the next decade is networks.

Unless we can build tooling for setting up the network infrastructure below all these cloud tools, you will still be stuck with people doing admin work like 30 years ago. From personal experience: k8s clusters are easy. Building the hardware and especially networking below so that everything actually can be automated in k8s... whole different story.

parasubvert6• 8 years ago

Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations)

But more broadly, Kubernetes in the hands of most developers that are doing non-platform level work is a step backwards and will be disastrous. It's far too low level, it's like, hey this Python/Ruby/Java thing was great, but have you seen this new bytecode linker and assembler?

New platforms and runtime built ON TOP OF Kubernetes are probably going to be fine. But that's going to take a while.

chris_mc• 8 years ago

Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations)

Everyone who comments about DevOps should have read "The Phoenix Project" first, so that they understand what you just said. It's not about consolidating workloads onto generalists, it's supposed to be about breaking down the silos in an organization, nothing more!

fauigerzigerk6• 8 years ago

Your broader point is correct but I think you're mischaracterizing Devops

You are right. What I should have said is that using DevOps as an excuse to make application developers do complex infrastructure design, automation and maintainance as a side-job is an unsustainable practice.

amorousf00p2• 8 years ago

I think devops was defunct once the asphalt hit the hardpan. Approaching 'generic' secure operational environments as programmable, iterable and contained is one of the great IT lies of the last 20 years.

pjmlp2• 8 years ago

You are quite right, I already have to jungle .NET, Java/Android, C++, SQL, Web on my head, don't need this as well.

tormeh• 8 years ago

There's a lot of benefits to having the same people doing a lot of stuff (see also full-stack devs). It means that someone has an overview of things and have situational awareness.

Without generalists with overview and situational awareness, you're going to need a lot of documentation, paperwork and meetings to preempt communication problems.

humbleMouse4• 8 years ago

I think what a lot of people forget is that this is being driven by costs. Companies don't want to pay for disaster recovery, and it's cheaper to set up a k8's platform. The platform itself performs disaster recovery, so now that's one less cost for the company.

It's all about saving money on DR. When these companies realize that developers can't handle doing ops AND complex business logic, maybe they'll rethink it. Until then I expect this trend to spread rapidly as companies look for ways to abstract away DR costs.

hodgesrm2• 8 years ago

Can you define what you mean by disaster recovery? To me it means the ability to recover business applications from a site failure.

Assuming you have a similar definition how does Kubernetes solve that problem?

humbleMouse4• 8 years ago

What I mean by DR is that if a data center gets nuked, you still have a replica of your k8's platform running in your other data center(s).

So k8's basically runs a replica of your whole system behind the scenes so if a physical location goes down you still have your system running.

tannhaeuser3• 8 years ago

In my experience, people are using k8s et al and microservices because "everyone is doing it", "nobody got fired for choosing microservices", "I need more cloud stuff on my resume" and a vague (and unsubstantiated, unless you're in SF maybe) hope to hire ops staff on the cheap. Frequently, it ends up in a mix of a partial k8s setup for services plus dedicated DB, logging, backup, and other proprietary persistence infrastructure services. In other words, the union of problems/risks, and the intersection of capabilities; and in particular such that moving to another cloud provider is impossible :)

Cloud services is pretty much a business of huge marketing budgets and old-school lock-in strategies.

newcrobuzon• 8 years ago

Isn't that problem solved equally with VMs?

humbleMouse4• 8 years ago

No, not unless you replicated the VMs accross different data centers manually. Which actually isn't that difficult using docker.

amdelamar• 8 years ago

As mentioned in the article, The EFK stack (Elasticsearch, Fluentd, Kibana) is great for unified logging. And its not just for OpenShift, its working wonders for our current project with Kubernetes on AWS.

nikon• 8 years ago

I find it a little heavy for log aggregation. LogDNA has been great for my K8s clusters, and is relatively cheap.

gog• 8 years ago

Could you give more details about why Fluentd and not Beats + Logstash on the other end? I don't like the idea of running Ruby on every machine just to ship logs somewhere.

Beats are pretty lightweight and for what I used them they work.

mehblahwhatevs• 8 years ago

Many people use the ELK stack which is Logstash. I imagine you can swap out Fluentd for Logstash.

rdsubhas• 8 years ago

I feel a bit alone here. The most obvious benefit of kubernetes is that It's an API. There is definitely a tooling angle, but the core disruption that kubernetes brings to the picture is, it allows to model infrastructure as an API.

Take the standard cloud application stack: Every app needs an artifact (disk image), a running service, an instance template, a group of VMs running using those templates, networking and a load balancer.

Before kubernetes, you had to automate by writing terraform scripts which mutate physical infrastructure as you apply.

With kubernetes, you POST a bunch of well-defined resources (container spec for the service, pod spec for the instance, pod as a VM, deployment as the group of VMs, services and ingress for traffic). Every physical cloud resource has a clear API mapping. Basically you save in kubernetes what you need as a first-class API resource. And then, kubernetes responds to what you saved by changing infrastructure to match.

You can do the same for practically any kind of infrastructure resources. Want an S3 bucket? Duh, POST a S3 bucket resource and you can write a controller to react and fulfil that bucket.

Kubernetes comes with a built-in set of functionality that fulfils a certain core set of infrastructure using containers. But you are not restricted to that. In theory, you could POST a VM as a resource, or an Instance Group as a resource, and you can write a kubernetes controller to fulfil those resources.

Why? Because APIs are more powerful than tools. APIs allow a different axis of infrastructure evolution, even if you distribute the control to everyone. By modeling these as APIs, you can bake in a huge amount of infrastructure intelligence into the API. Want to enforce different, code-driven resource-based policies, linting, sane defaults, organizational context? Yeah, make the controller do just that. If you just provide a tool to every engineering team, you basically lose any form of cross-cutting orchestration, and you lose the ability to evolve infrastructure in a separate axis independent of the tool that each team uses.

Basically, kubernetes is "Infrastructure as an API". Thinking about it as a "new application server" kinda hides the whole point of it.

sciurus• 8 years ago

Before: Write HCL then run `terraform apply`

After: Write YAML then run `kubectl apply`

;-)

moondev2• 8 years ago

terraform has a kubernetes provider so you can still `terraform apply` ;-)

https://www.terraform.io/docs/providers/kubernetes/index.htm...

halbritt7• 8 years ago

Infrastructure as software vs infrastructure as code.

zeckalpha2• 8 years ago

That’s not a benefit to me. Is it reproducible? Keeping desired state under version control is valuable.

dsmithatx4• 8 years ago

The state is defined in yaml manifests file which are trivial to store in Git and create templates with in Ansible.

nojvek• 8 years ago

Yep. Super reproducible. Even more than the old ways. You can store the docker configs and store docker containers in registry. Store the yaml files, or auto generate them using build process based on other central DSL.

We could probably bootstrap our entire product from scratch in a couple of hours if it disappeared off the face of earth.

“Infrastucture as a config” is a very powerful concept. I’d say that’s what the big power of k8s is.

blackadder• 8 years ago

Bingo, you've hit the nail :) This is what I love about K8S. In addition you've got the K8S reconciliation loop running constantly to make sure the system is in the state you described via the API.

sheeshkebab• 8 years ago

The software world keeps on going in circles :).

Next up - lightweight k8s server - stripped down of all the crap that can easily run and deploy a single container.

marcus_holmes• 8 years ago

yes, this. I'm just skipping the whole Docker thing this time around, and waiting until the circle turns and the herd decides that containers create too much complexity ;)

ironjunkie• 8 years ago

I hope that the Kubernetes Steering committee will continue its good work to keep the Core tidy and simple.

What really makes me afraid are the thousands of complex addons that are being pushed by the community (For example, Istio, Networking addons, etc etc). Those should be kept outside and it MUST be made clear they are definitely not needed for a normal installation of Kubernetes.

Istio for example, is such a political brainwash power-move by some bigger companies that benefit from it. I believe less than 5% of the use-cases really require Istio, still it is being pushed as something you should always install in your cluster. This is bad for everyone.

iKSv22• 8 years ago

Guys who have worked with Kubernetes and virtualization, I have a genuine personal question for you - I have been working as SysAdmin and then into virtualization (VMware / HyperV sort of things) and while natural progression in it says go for advanced VMware courses (related to Virtual machine and its concepts), do you think its better to switch lanes now to container-tech rather than some years down the line? I am totally 0 on Docker / Kubernetes / OpenStack (if thats related with containers).

voltagex_• 8 years ago

FWIW coming from a Windows dev side of things, I'd have a look at Docker for Hyper-V (https://docs.docker.com/machine/drivers/hyper-v/) and just have a play with things.

If you're still getting enough work as a sysadmin and enjoying it, I think "VMs" as a concept will still be around for a long time.

clhodapp• 8 years ago

At this point it is clear that this is a thing that will happen for a whole lot of orgs. You would be well advised to dabble at this point and see if it connects with you. At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation. That said, VMs and scripted/config-managed deployment will continue to be with us for the foreseeable future.

iKSv22• 8 years ago

"At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation"

Seriously, this is so embarrassing at the current point ( with me having absolutely 0 understanding of the concept)

Why Kubernetes Is the New Application Server

Related Stories