Archive for developers

The Abstraction Disconnect is Silly

This blog originally appeared on the Amalgam Insights site on May 8, 2018

 

Over the past two weeks I’ve been to two conferences that are run by an open source community. The first was the CloudFoundry Summit in Boston followed by KubeCon+CloudNativeCon Europe 2018 in Copenhagen. At both, I found passionate and vibrant communities of sysops, developers, and companies. For those unfamiliar with CloudFoundry and Kubernetes, they are open source technologies that abstract software infrastructure to make it easier for developers and sysops to deliver applications more quickly.

Both serve similar communities and have a generally similar goal. There is some overlap – CloudFoundry has its own container and container orchestration capability – but the two technologies are mostly complementary. It is possible, for example, to deploy CloudFoundry as a Kubernetes cluster and use CloudFoundry to deploy Kubernetes. I met with IT professionals that are doing one or both of these. The same is true for OpenStack and CloudFoundry (and Kubernetes for that matter). OpenStack is used to abstract the hardware infrastructure, in effect creating a cloud within a data center. It is a tool used by sysops to provision hardware as easily scalable resources, creating a private cloud. So, like CloudFoundry does for software, OpenStack helps to manage resources more easily so that a sysop doesn’t have to do everything by hand. CloudFoundry and OpenStack are clearly complementary. Sysops use OpenStack to create resources in the form of a private cloud; developers then use CloudFoundry to pull together private and public cloud resources into a platform they deploy applications to. Kubernetes can be found in any of those places.

Why then, is there this constant tension between the communities and adopters of these technologies. It’s as if carpenters had hammer people and saw people who argued over which was better. According to my carpenter friends, they don’t. The foundations and vendors avoid this type of talk, but these kinds of discussions are happening at the practitioner and contributor level all the time. During KubeCon+CloudnativeCon Europe 2018, I saw a number of tweets that, in essence, said “Why is Cloud Foundry Executive Director Abby Kearns speaking at KubeCon?” They questioned what one had to do with the other. Why not question what peanut butter and jelly have to do with each other?

Since each of these open source projects (and the products based on them) have a different place in a modern hybrid cloud infrastructure, how is it that very smart people are being so short sighted? Clearly, there is a problem in these communities that limit their point of view. One theory lies in what it takes to proselytize these projects within an organization and wider community. To put it succinctly, to get corporate buy-in and widespread adoption, community members have to become strongly focused on their specific project. So focused, that some put on blinders and can no longer see the big picture. In fact, in order to sell the world on something that seems radical at first, you trade real vision for tunnel vision.

People become invested in what they do and that’s good for these type of community developed technologies. They require a commitment to a project that can’t be driven by any one company and may not pan out. It turns toxic when the separate communities become so ensconced in their own little corner of the tech world that they can’t see the big picture. The very nature of these projects defies an overriding authority that demands the everyone get along, so they don’t always.

It’s time to get some perspective, to see the big picture. We have an embarrassment of technology abstraction riches. It’s time to look up from individual projects and see the wider world. Your organizations will love you for it.

GraalVM is a Technology to Watch

Oracle

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.