Archive for DevOps

The Breadth and Width of Kubernetes

This blog was previously posted on Amalgam Insights

Standing in the main expo hall of KuberCon+CloudNativeCon Europe 2018 in Copenhagen, the richness of the Kubernetes ecosystem is readily apparent. There are booths everywhere, addressing all the infrastructure needs for an enterprise cluster. There are meetings everywhere for the open source projects that make up the Kubernetes and Cloud Native base of technology. The keynotes are full. What was a 500-person conference in 2012 is now, 6 years later, a 4300-person conference even though it’s not in one of the hotbeds of American technology such as San Francisco or New York City.

What is amazing is how much Kubernetes has grown in such a short amount of time. It was only a little more than a year ago that Docker released it’s Kubernetes competitor called Swarm. While Swarm still exists, Docker also supports, and arguably is betting the future, on Kubernetes.

Kubernetes came out of Google, but that doesn’t really explain why it expanded like the early universe after the big bang.  Google is not the market leader in the cloud space – it’s one of the top vendors but not the top vendor – and wouldn’t have provided enough market pull to drive the Kubernetes engine this hot. Google is also not a major enterprise infrastructure software vendor the way IBM, Microsoft, or even Red Hat and Canonical are.

Kubernetes benefited from the first mover effect. They were early into the market with container orchestration, were fully open source, and had a large amount of testing in Google’s own environment. Docker Swarm, on the other hand, was too closely tied to Docker the company to appease the open source gods.

Now, Kubernetes finds itself like a new college graduate. It’s all grown up but needs to prepare for the real world. The basics are all in place and its mature but there is enormous amount of refinement and holes that need to be filled in for it to be a common part of every enterprise software infrastructure. KubeCon+CloudNativeCon shows that this is well underway. The focus now is on security, monitoring, network improvement, and scalability. There doesn’t seem to be a lot of concern about stability or basic functionality.

Kubernetes has eaten the container world and didn’t get indigestion. That’s rare and wonderful.

GraalVM is a Technology to Watch


This was originally published on the Amalgam Insights site on April 17, 2017.

Oracle Labs has recently (April 17, 2018) announced the 1.0 release of GraalVM. GraalVM is an open source language virtual machine(VM), much like the Java VM or Node.js virtual machine. What makes GraalVM interesting, is that it can execute code written in a variety of languages including Java (and Java VM based languages such as Scala, Groovy, or Kotlin), R, JavaScript, along with Ruby, R, and Python. This is a departure from mainstream VM designs. It is much more common to have separate and specific VMs for languages such as PHP or Python. In some cases, a language will byte compile to a different virtual machine, for instance Clojure compiling to the run on the Java VM. Those languages are purpose built to run on a specific VM. GraalVM, on the other hand, runs code written in languages originally built for their own VM.

This approach offers advantages over the traditional approach of one language, one VM. For example, any program that is compiled for GraalVM can share libraries with other programs that is likewise compiled. Developers can write in different languages but still maintain interoperability and code reuse across them all. This also allows developers to continue to use code written in “older languages” while migrating to a new one. Similarly, it allows the continued used of majority language, such as Java, while leveraging languages that are built for specific purposes, such as R. Another advantage of GraalVM is ubiquity. One VM for multiple needs means fewer VMs to provision and update across IT servers and containers. That can be a serious time saver and makes maintaining large and complex systems a bit easier.

GraalVM is also embeddable. The ability to build plugins using GraalVM was one of the reasons that Oracle started the Graal project. By creating GraalVM compatible code that can be embedded in an Oracle Database opens the door to customers extending their Oracle databases. This is clearly better than writing code outside the database for common query-related processing.

At the moment GraalVM only supports a handful of languages – in other words, it does not have ubiquitous support for all common programming languages. The mainstays of Microsoft application programming, Microsoft CLR based languages such as C# and F#, are not available. Obviously, languages that are native compiled, such as C, C++, or Go, won’t run on GraalVM unless they can be compiled for it. This will probably limit GraalVM to the Java and open source language crowd that is dabbling in Node.js JavaScript for microservices or R and Python for analytics. Another small hang-up is that Ruby, R, and Python are listed as “experimental.” This should inhibit deployment of these languages in production environments using GraalVM. That is a temporary issue that time will hopefully solve.

GraalVM has serious potential. It can simplify a complex VM landscape and allow choice in programming languages without proliferation of VMs and libraries. At the moment, it’s mostly potential, especially given the limited range of supported programming languages. That potential, however, is the reason why GraalVM is worth keeping an eye on.