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.

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:

Okay, 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).

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.