Fabric8 V2, Docker, Kubernetes & OpenShift V3 and Jube! Oh My!
There are huge changes taking place right now in the cloud. Innovation in the cloud seems to really be accelerating and many things are consolidating!
Docker isn’t even 2 years old and its already had a massive impact on how we build, run and manage software. Kubernetes has come from Google and in a few months is having a similarly rapid and impressive effect on the cloud ecosystem with MicroSoft, Red Hat, VMware and others supporting it.
I was explaining to colleagues a few weeks ago how impressed I was with the OpenShift team refactoring version 3 to be based completely on kubernetes; working closely with the kubernetes community to improve things inside kubernetes; then building above kubernetes in OpenShift Origin for things like the familiar git push build workflow that are popular in PaaS systems these days.
Then the penny dropped; the fabric8 team needed to make a similar kind of leap too! ;).
After a head spinning few weeks, now Fabric8 V2 is a thing! We’ll be releasing our first 2.0.0.Alpha1 next week.
Fabric8 V2 is now completely based on kubernetes for container orchestration and as the REST API for Container As A Service.
So we now have a standard, technology agnostic way to define and orchestrate containers and services; with a standard REST API and standard way to package up cloud applications so that they can run as lightweight containers any cloud plus a standard way to share cloud applications too!
For those folks who’ve used fabric8 V1 before there are quite a few implementation changes though lots of things stay the same:
- awesome web console — thanks to hawtio — which lets you view all the various kubernetes resources (pods, replication controllers, services) and dive inside any JVMs and get the full rich hawtio UI inside your JVMs; and lets you work with app zips and making a kind of cloud app store (storing your teams library of cloud applications in a versioned git repository)
- lots of quickstarts, archetypes and examples ready for use
- maven tooling to make it really easy to turn your Java maven build into a docker image and a cloud application zip that can be easily installed and ran on any cloud
Though in terms of folks writing and consuming services in Java and building with maven on top of fabric8; there’s not a huge change in many ways.
The main difference are:
- we focus on building docker images at build time (or release time) rather than doing it at runtime with profile metadata
- all container orchestration is now done on the outside by kubernetes; so there’s no requirement to embed lots of fabric8 Java code for things like service registration or service discovery; this makes things much simpler and easier!
- we use kubernetes services to wire things together (check out the background on how kubernetes services work)
- the cloud application zip is now completely runtime/framework/language agnostic; being just based on the kubernetes JSON model and docker images (so it can orchestrate any permutation of redis, ruby, nodejs, python, go or java equally well)
This should make things much more simple for folks going forward; as we can support any runtime, application server, framework or language going forward. (Previous fabric8 1.x releases were a little brittle depending on what version of karaf/tomcat/widlfly we used to embed fabric8 orchestration code).
One common reaction when we talk about fabric8 V2 is:
- we’re not yet ready to try one or more of: Linux / Docker / Kubernetes / OpenShift V3
- what about AIX / Solaris and other non-modern-linux platforms?
We hope we can all eventually use a modern linux as our runtime operating system along with great technologies like Docker, Kubernetes & OpenShift V3 as the container orchestration layer going forward.
However we have lots of customers in the Java ecosystem who must use other operating systems (like Windows, Solaris, AIX etc).
For Windows folks; golang already works great, Docker is usable (albeit with boot2docker and virtualisation) and MicroSoft is committed to having native Windows docker support; so eventually Docker + Kubernetes/OpenShift V3 could be a great pure windows orchestration solution. Its just not there yet…
Until then; for folks who can’t yet use the new Docker / Kubernetes / OpenShift V3 hotness; we’ve created an open source project called jube — which is a pure java implementation of the kubernetes model.
Its pretty small and simple; and is only intended for folks who can’t use Docker & Kubernetes / OpenShift V3; but it helps us all move forwards quickly while supporting all operating systems that have a JVM.
So if folks are not yet ready to adopt Linux, Docker, Kubernetes or OpenShift V3; folks can give jube a try and just use pure Java for now. Though we highly recommend going the OpenShift V3 / Docker way if you possibly can!
So fabric8 V2 can be used either on top of Kubernetes / OpenShift V3 or on top of jube. For most java developers who are not using linux; we suspect jube is gonna be the easiest way to get started in fabric8 V2 until the combination of OpenShift V3 + Docker is really polished for Windows & OS X; as jube isjust a single stand alone pure Java tarball and shell script to run ;)
Onwards to the first alpha!
So next week we should release 2.0.0.Alpha1 of fabric8 V2 along with a first release of jube so you can have a play and tell is what you think.
I’m personally hugely excited about the new kubernetes based future; it makes so many things simpler (e.g. wiring services together, doing discovery) while making things much more powerful and open.
We’re already working on a super sophisticated MQ auto scaler for example. Ioannis has been working on an easy way to automatically provision ZooKeeper ensembles on kubernetes.
The part thats made my head spin the most the last month is the realisation we can finally start building an enterprise cloud application store ecosystem using cloud application zips that anyone can build and host using any tool; but which folks can drag and drop from your desktop to/from your application library UI (in hawtio).
This is for public open source middleware stuff like the current apps in our wiki along with internal applications created by you and your development teams. (We’re looking to reuse maven repositories for folks using java/maven/gradle builds to easily release and distribute apps using existing tools for example).
In summary; this is gonna be fun! ☺