Archive for developers

Kubernetes Grows Up – The View from KubeCon EU 2019

This was originally published on the Amalgam Insights site on Wednesday June 5 2019.

Our little Kubernetes is growing up.

By “growing up” I mean it is almost in a state that a mainstream company can consider it fit for production. While there are several factors that act as a drag against mainstream reception, a lack of completeness has been a major force against Kubernetes broader acceptance. Completeness, in this context, means that all the parts of an enterprise platform are available off the shelf and won’t require a major engineering effort on the part of conventional IT departments. The good news from KubeCon+CloudNativeCon EU 2019 in Barcelona, Spain (May 20 – 23 2019) is that the Kubernetes and related communities are zeroing in on that ever so important target. There are a number of markers pointing toward mainstream acceptance. Projects are filling out the infrastructure – gaining completeness – and the community is growing.

Project Updates

While Kubernetes may be at the core, there are many supporting projects that are striving to add capabilities to the ecosystem that will result in a more complete platform for microservices. Some of the projects featured in the project updates show the drive for completeness. For example, OpenEBS and Rook are two projects striving to make container storage more enterprise friendly. Updates to both projects were announced at the conference. Storage, like networking, is an area that must be tackled before mainstream IT can seriously consider container microservices platforms based on Kubernetes.

Managing microservices performance and failure is a big part of the ability to deploy containers at scale. For this reason, the announcement that two projects that provide application tracing capabilities, OpenTracing and OpenCensus, were merging into OpenTelemetry is especially important. Ultimately, developers need a unified approach to gathering data for managing container-based applications at scale. Removing duplication of effort and competing agendas will speed up the realization of that vision.

Also announced at KubeCon+CloudNativeCon EU 2019 were updates to Helm and Harbor, two projects that tackle thorny issues of packaging and distributing containers to Kubernetes. These are necessary parts of the process of deploying Kubernetes applications. Securely managing container lifecycles through packaging and repositories is a key component of DevOps support for new container architectures. Forward momentum in these projects is forward movement toward the mainstream.

There were other project updates, including updates to Kubernetes itself and Crio-io. Clearly, the community is filling in the blank spots in container architectures, making Kubernetes a more viable application platform for everyone.

The Community is Growing

Another gauge pointing toward mainstream acceptance is the growth in the community. The bigger the community, the more hands to do the work and the better the chances of achieving feature critical mass. This year in Barcelona, KubeCon+CloudNativeCon EU saw 7700 attendees, nearly twice last year in Copenhagen. In the core Kubernetes project, there are 164K commits and 1.2M comments in Github. This speaks to broad involvement in making Kubernetes better. Completeness requires lots of work and that is more achievable when there are more people involved.

Unfortunately, as Cheryl Hung, Director of Ecosystems at CNCF says, only 3% of contributors are women. The alarming lack of diversity in the IT industry shows up even in Kubernetes despite the high-profile women involved in the conference such as Janet Kuo of Google. Diversity brings more and different ideas to a project and it would be great to see the participation of women grow.

Service Mesh Was the Talk of the Town

The number of conversations I had about service mesh was astounding. It’s true that I had released a pair of papers on it, one just before KubeCon+CloudNativeCon EU 2019. That may have explained why people want to talk to me about it but not the general buzz. There was service mesh talk in the halls, at lunch, in sessions, and from the mainstage. It’s pretty much what everyone wanted to know about. That’s not surprising since a service mesh is going to be a vital part of large scale out microservices applications. What was surprising was that even attendees who were new to Kubernetes were keen to know more. This was a very good omen.

It certainly helped that there was a big service mesh related announcement from the mainstage on Tuesday. Microsoft, in conjunction with a host of companies, announced the Service Mesh Interface. It’s a common API for different vendor and project service mesh components. Think of it as a lingua franca of service mesh. There were shout-outs to Linkerd and Solo.io. The latter especially had much to do with creating SMI. The fast maturation of the service mesh segment of the Kubernetes market is another steppingstone toward the completeness necessary for mainstream adoption.

Already Way Too Many Distros

There were a lot of Kubernetes distributions a KubeCon+CloudNativeCon EU 2019. A lot. Really. A lot. While this is a testimony the growth in Kubernetes as a platform, it’s confusing to IT professionals making choices. Some are managed cloud services; others are distributions for on-premises or when you want to install your own on a cloud instance. Here’s some of the Kubernetes distros I saw on the expo floor. I’m sure I missed a few:

Microsoft Azure Google
Digital Ocean Alibaba
Canonical (Ubuntu) Oracle
IBM Red Hat
VMWare SUSE
Rancher Pivotal
Mirantis Platform9

From what I hear this is a sample not a comprehensive list. The dark side of this enormous choice is confusion. Choosing is hard when you get beyond a handful of options. Still, only five years into the evolution of Kubernetes, it’s a good sign to see this much commercial support for it.

The Kubernetes and Cloud Native architecture is like a teenager. It’s growing rapidly but not quite done. As the industry fills in the blanks, as communities better networking, storage, and deployment capabilities it will go mainstream and become applicable to companies of all sizes and types. Soon. Not yet but very soon.

How Red Hat Runs

AI Logo

This post was originally published on the Amalgam Insights website.

This past week at Red Hat Summit 2019 (May 7 – 9 2019) has been exhausting. It’s not an overstatement to say that they run analysts ragged at their events, but that’s not why the conference made me tired. It was the sheer energy of the show, the kind of energy that keeps you running with no sleep for three days straight. That energy came from two sources – excitement and fear.

Two announcements, in particular, generated joy amongst the devoted Red Hat fans. The first was the announcement of Red Hat Enterprise Linux version 8, better known as RHEL8. RHEL is the granddaddy of all major Linux distributions for the data center. RHEL8, however, doesn’t seem all that old. As well as all the typical enhancements to the kernel and other parts of the distro, Red Hat has added two killer features to RHEL.

The first, the web console, is a real winner. It provides a secure browser-based system to manage all the features of Linux that one typically needs a command line on the server to perform. Now, using Telnet or SSH to log in to a remote box and do a few adjustments is no big deal when you have a small number of machines, physical or virtual, in a data center. When there are thousands of machines to care for, this is too cumbersome. With web console plus Red Hat Satellite, the same type of system maintenance is much more efficient. It even has a terminal built in if the command line is the only option. I predict that the web console will be an especially useful asset to new sysadmins who have yet to learn the intricacies of the Linux command line (or just don’t want to).

The new image builder is also going to be a big help for DevOps teams. Image builder uses a point and click interface to build images of software stacks, based on RHEL of course, that can be instantiated over and over. Creating consistent environments for developers and testing is a major pain for DevOps teams. The ability to quickly and easily create and deploy images will take away a major impediment to smooth DevOps pipelines.

The second announcement that gained a lot of attention was the impending GA of OpenShift 4. OpenShift 4 represents major change in the Red Hat container platform. It incorporates all the container automation goodness that Red Hat acquired from CoreOS, especially the operator platform. Operators are key to automating container clusters, something that is desperately needed for large scale production clusters. While Kubernetes has added a lot of features to help with some automation tasks, such as autoscaling, that’s not nearly enough for managing clusters at hyperscale or across hybrid clouds. Operators are a step in that direction, especially as Red Hat makes it easier to use Operators.

Speaking of OpenShift, Satya Nadella, CEO of Microsoft appeared on the mainstage to help announce Azure Red Hat OpenShift. This would have been considered a mortal sin at pre-Nadella Microsoft and highlights the acceptance of Linux and open source at the Windows farm. Azure Red Hat OpenShift is an implementation of OpenShift as a native Azure service. This matters a lot to those serious about multi-cloud deployments. Software that is not a native service for a cloud service provider do not have the integrations for billing, management, and especially set up that native services do. That makes them second class citizens in the cloud ecosystem. Azure Red Hat OpenShift elevates the platform to first class status in the Azure environment.

Now for the fear. Although Red Hat went to considerable lengths to address the “blue elephant in the room”, to the point of bringing Ginny Rometty, IBM CEO on stage, the unease around the acquisition by IBM was palpable amongst Red Hat customers. Many that I spoke to were clearly afraid that IBM would ruin Red Hat. Rometty, of course, insisted that was not the case, going so far as to say that she “didn’t spend $34B on Red Hat to destroy them.”

That was cold comfort to Red Hat partners and customers who have seen tech mergers start with the best intentions and end in disaster. Many attendees I spoke drew parallels with the Oracle acquisition of Sun. Sun was, in fact, the Red Hat of its time – innovative, nimble, and with fierce loyalists amongst the technical staff. While products created by Sun still exist today, especially Java and MySQL, the essence of Sun was ruined in the acquisition. That is a giant cloud hanging over the IBM-Red Hat deal. For all the advantages that this deal brings to both companies and the open source community, the potential for a train wreck exists and that is a source of angst in the Red Hat and open source world.

In 2019, Red Hat is looking good and may have a great future. Or it is on the brink of disaster. The path they will take now depends on IBM. If IBM leaves them alone, it may turn out to be an amazing deal and the capstone of Rometty and Jim Whitehurst’s careers. If IBM allows internal bureaucracy and politics to change the current plan for Red Hat, it will be Sun version 2. Otherwise, it is expected that Red Hat will continue to make open source enterprise friendly and drive open source communities. That would be very nice indeed.