Thursday, November 06, 2014

Fabric8 version 2.0 released - Next Generation Platform for managing and deploying enterprise services anywhere

The Fabric8 open source project started 5 years ago, as a private project aimed at making large
deployments of Apache Camel, CXF, ActiveMQ etc easy to deploy and manage.

At the time of its inception, we looked at lots of existing open source solutions that we could leverage to provide the flexible framework that we knew our users would require. Unfortunately, at that time nothing was a good fit, so we rolled our own - with core concepts based around:

  • Centralised Control
  • runtime registry of services and containers
  • Managed Hybrid deployments from laptop, to open hybrid (e.g. OpenShift)

All services were deployed into a Apache Karaf runtime, which allowed for dynamic updates of running services. The modularisation using OSGi had some distinct advantages around the dynamic deployment of new services, and container service discovery, and a consistent way of administration. However, this also meant that Fabric8 was very much tied to the Karaf runtime, and forced anyone using Fabric8 and Camel to use OSGi too.

We are now entering a sea-change for immutable infrastructure, microservices and open standardisation around how this is done. Docker and Kubernetes are central to that change, and are being backed with big investments. Kubernetes in particular, being based on the insurmountable experience that google brings to clustering containers at scale, will drive standardisation across the way containers are deployed and managed. It would be irresponsible for Fabric8 not to embrace this change, but to do it in a way that makes it easy for Fabric8 1.x users to migrate. By taking this path, we are ensuring that Fabric8 users will be able to benefit from the rapidly growing ecosystem of vendors and projects that are providing applications and tooling around Docker, but also frees Fabric8 users to be able to move their deployments to any of the growing list of platforms that support Kubernetes.  However, we are also aware that there are many reasons users have to want to use a platform that is 100% Java - so we support that too!

The goal of Fabric8 v2 is to utilise open source, and open standards. To enable the same way of configuring and monitoring services as Fabric8 1.x, but to do it for any Java based service, on any operating system. We also want to future proof the way users work, which is way adopting Kubernetes is so important: you will be able to leverage this style of deployment anywhere.
Fabric8 v2 is already better tested, more nimble and more scalable than any previous version we've released, and as Fabric8 will also be adopted as a core service in OpenShift 3, it will hardened at large scale very quickly.

So some common questions:

Does this mean that Fabric8 no longer supports Karaf ?
No - Karaf is one of the many container options we support in Fabric8. You can still deploy your apps in the same way as Fabric8 v1, its just that Fabric8 v2 will scale so much better :).

Is ZooKeeper no longer supported ?
In Fabric8 v1 - ZooKeeper was used to implement the service registry. This is being replaced by Kubernetes. Fabric8 will still run with Zookeeper however, to enable cluster coordination, such as master-slave elections for messaging systems or databases.

I've invested a lot of effort in Fabric8 v1 - does all this get thrown away ?
Absolutely not. Its will be straightforward to migrate to Fabric8 v2.

When should I look to move off Fabric8 v1 ?
As soon as possible. There's a marked improvement in features, scalability and manageability.

We don't want to use Docker - can we still use Fabric8 v2?
Yes - Fabric8 v2 also has a pure Java implementation, where it can still run "java containers"

Our platforms don't support Go - does that preclude us from running Fabric8 v2 ?
No -  although Kubernetes relies on the Go programming language, we understand that won't be an option for some folks, which is why fabric8 has an optional Java implementation. That way you can still use the same framework and tooling, but it leaves open the option to simply change the implementation at a later date if you require the performance, application density and scalability that running Kubernetes on something like Red Hat's OpenShift  or Google's Cloud Platform can give you.

We are also extending the services that we supply with fabric8, from metric collection, alerting, auto-scaling, application performance monitoring and other goodies:



Over the next few weeks, the fabric8 community will be extending the quick starts to demonstrate how easy it is to run micro services, as well application containers in Fabric8. You can run Fabric8 on your laptop (using 100% Java if you wish), or your in-house bare metal (again running 100% Java if you wish) or to any PaaS running Kubernetes.



4 comments:

Richard Davidson said...

Hi Rob,

Few questions:

1. We have a lot of services (properties, features, bundles) deployed using Fabric V1 using profiles. What is the recommended way to deploy these now? Should we deploy using vanilla Karaf on Fabric V2?

2. Is V1 dead, and will there be any further development?

3. Will the next version of JBoss Fuse support V1 or V2, and what about future versions of JBoss Fuse?

Thanks,
Richard

Hendy Irawan said...

Congrats for the release!

So which one is correct?
A. Kubernetes replaced ZooKeeper
B. Kubernetes complemented ZooKeeper
C. ZooKeeper is used only for the Java variant of Fabric8 v2, but not for the main variant

Rob Davies said...

Hi Richard,

"We have a lot of services (properties, features, bundles) deployed using Fabric V1 using profiles. What is the recommended way to deploy these now? Should we deploy using vanilla Karaf on Fabric V2?"

We are working on migration tools - which will convert Profiles into the new App template. Migration between v1 and v2 will be relatively straight forward. For Fabric v2 - you can certainly use vanilla karaf too.

"Is V1 dead, and will there be any further development?
There wont be new features added to v1 - but it will still be maintained.

"Will the next version of JBoss Fuse support V1 or V2, and what about future versions of JBoss Fuse?"
There's always a lag between community and product. Right now the next version of JBoss Fuse (6.2) s going to support v1, but I would hope it will end up supporting both versions of fabric8. Versions after Fuse 6.2 will probably be Fabric8 v2 only - but that's still being decided, based on customer feedback.

Rob Davies said...

Hi Hendy,


So which one is correct?
A. Kubernetes replaced ZooKeeper
B. Kubernetes complemented ZooKeeper
C. ZooKeeper is used only for the Java variant of Fabric8 v2, but not for the main variant


All of the above! In Fabric8 v1, we used Zookeeper for both service discovery, and cluster coordination (master/slave elections etc). Kubernetes completely replaces the service discovery part (it uses etcd underneath the covers). In the 100% Java implementation we replace the etcd functionality with Zookeeper currently, though we aim to make that pluggable. However, we still need to use something like Zookeeper for the cluster coordination, so we have that as a separate service that's deployed. There will be some examples of using that for master/slave camel routes and control of ActiveMQ clusters in the quickstarts over the next couple of weeks.