The Kubernetes Oligopoly and Jenkins X

I have written previously about making use of the Big 3 Clouds for both build/test/deploy of apps but also as a desktop replacement for developers. In the time since those blogs, Amazon has announced the general availability of their much awaited EKS service (of which CloudBees was a launch partner )

Myself and others often like to talk about the “oligopoly” of cloud providers, given the size and muscle of the companies behind them:

When I actually think about the meaning of the word, I don’t think it is the right term, as I do not think this is a limited state of competition.

Firstly, there are more than just the Big 3 at play: Digital Ocean recently announced an early access . Oracle are in on it as are IBM . In fact, Codeship published a round-up of managed hosting platforms you can get here .

Back to the so-called oligopoly

The big three clouds have big three logos, so let’s take a look at their logo game:

Azure got a brand new one this year (swish!), but only Amazon took the time to make an EKS logo for their service (see, competition already paying off!). I wanted to show these logos atop fighting dinosaurs, but I am pretty sure the terms of use for trademark (and my editing skills) won’t allow that, so you will have to imagine it (I trust imagining it won’t infringe any trademarks… if it does, then forget I asked).

More seriously, I think there are real benefits to the competition - even between these three - that makes everyone better off. Let's pick a few that I believe are driven by competition:

• Google announced support for multi-regional support

  • A great way to stand out, make something that was exotic and the realm of only the most advanced now a feature

• Amazon are working towards Fargate

  • Fargate will bring the serverless, low-cost, operational model to Kubernetes and container workloads

• Microsoft bought GitHub!

  • GitHub is a huge social network where collaboration on things like Kubernetes happen

Ok that last one is a stretch, but clearly the Big 3 are effectively “sharpening each other,” and finding ways to differentiate. The beneficiaries are all the users! All of us! It is also great to see so many vendors contribute together to move Kubernetes forward.

I am excited to see players like Digital Ocean get involved with hosting Kubernetes and am very interested at what flavor they bring: I have often enjoyed the Digital Ocean documentation / articles that explain Linux concepts in detail for developers.

So, what next?

As for what you can do with Kubernetes, now that all the heavy lifting is done for you? Well, you can get back to building apps: as I have written about before, Jenkins X was developed to be an end-to-end CD tool for shipping apps continuously with Kubernetes, with batteries included. Jenkins X does not require you to be a Kubernetes expert to get great results.

Jenkins X can even make use of multi-regional support that Google just announced, and aims to provide excellent support in bootstrapping on your cloud of choice, to make the most of it. If you are curious about the capabilities of Jenkins X, an online recording on CI/CD run by the Cloud Native Computing Foundation (CNCF) is available . On it, James Strachan gives a tour of how it all works.

An aside

One question that has come up as interest in Jenkins X grows: Can you use Jenkins X to build things other than Kubernetes apps? Of course! The answer is YES. As there are still pipelines involved, this is possible (and in fact the Jenkins X project itself uses Jenkins X to build binaries for distribution as libraries or command lines, outside of a Kubernetes cluster).

Additionally, CloudBees was a launch partner for EKS and our software on EKS is generally available right now .

You can create and manage teams for your CI/CD infrastructure with CloudBees Core on EKS:

Choose a sweet icon:

Edit and run pipelines:

Watch the video to see a demo of all of this in action, with each team getting their own tooling provisioned and managed for them.

Roads and railways: Jenkins X vs. Jenkins

I was talking recently with Kohsuke Kawaguchi and we were reaching for a metaphor to describe the dichotomy between Jenkins and Jenkins X. As we are both, in some small way, train nerds (I will admit it) we realized we could describe it using a rail vs. road metaphor. You can view Jenkins X as a railway, perhaps a maglev, or a metro, that takes you where you need to go quickly and efficiently. It has stations in popular places to take you around, and you don’t need to know how to drive it.

However, there are plenty of places railway stations will not take you to, or perhaps you have to carry something unusual home from a shop: in that case there are roads, cars and trucks. It is Jenkins (without the X) that is the road network for all those other places you need to go.

Links

• James Strachan explaining Jenkins X at CNCF

• Jenkins X Dev Pods for development time tools on a Kubernetes cluster.

• Codeship guide on deploying to Kubernetes clusters from the Codeship CI service.

Michael Neale is a development manager at CloudBees. Michael is an open source polyglot developer. For his sins, he spent time at JBoss, working on the Drools project and then Red Hat, where he continually caused trouble on various projects. Post-Red Hat, Michael was one of the co-founders of CloudBees, seeing great opportunity in cloud technologies. His interest in the cloud is natural, as he is attracted to disruptive technologies. Michael lives and works in the Blue Mountains, just outside Sydney, Australia. He has no hobbies, as his hobbies tend to turn into work anyway. Mic’s motto: “Find something you love doing, and then you will never work a day in your life again.” Follow Michael on Twitter .