ActiveBlog

A Technical Look At Stackato v3.0-beta
by Phil Whelan

Phil Whelan, November 14, 2013

Last week, ActiveState released a beta version of the much anticipated Stackato v3.0. This release is a preview of what is to come later this year from the leading Enterprise Platform-as-a-Service (PaaS) solution, Stackato by ActiveState.

It incorporates the newly rewritten open-source Cloud Foundry v2, Docker containers, and more. In this post I will go over some of the more technical aspects of this release.

Cloud Foundry v2

Cloud Foundry v2 is a significant milestone in the Cloud Foundry ecosystem. It marks the end of a year-long effort to rewrite the entire codebase from the ground up. Cloud Foundry v1 was under the control of VMware, who instigated the project. When the project was taken over by Pivotal, it inspired a fresh start.

Stackato v3.0 is the first commercial Enterprise solution built on Cloud Foundry v2, and this beta gives our customers a way to start working with the new APIs straight away.

There are many components of Cloud Foundry, all of which have had a rewrite since v1. While Ruby is still predominant, the Ruby frameworks have changed. Now we see more Sinatra, where there was Rails. We also see a move to using threads over pure event-based code, which was provided by EventMachine. EventMachine is still present, but mostly contained to Thin and EM.defer calls, which is just another way to run code in a thread pool.

Thin is still a core part of the Cloud Controller, but where it would spawn a new Ruby Fiber for each inbound request, it now spawns a new Ruby Thread. In fact, if you search through the code-base, you will find that Ruby Fibers are no longer used. Whatever your view on Threads vs event-based programming, I think it is good not to mix the two. In the past, I have seen some hard-to-debug issues in Ruby when a Fiber is resumed on a different Thread.

Stackato Re-integration

With Cloud Foundry v1, which ActiveState had been working with for the past several years, we added a tremendous amount of value on-top of the Cloud Foundry base. A lot of the work has gone into making sure those great features, such as log streaming, port services, ssh-ing into application containers, LDAP support and more, are all present alongside the newer Cloud Foundry code-base. The kato administration tool still works in the same way to manage the cluster.

Stackato has always shipped as an easily deployable virtual appliance, that can run either on your laptop, any hypervisor (such as vSphere or KVM) or any infrastructure layer (such as EC2, OpenStack or CloudStack). This method of deployment is something that has worked really well for previous versions of Stackato, so we have done the same with this newer Cloud Foundry v2-based Stackato. You can still just download, start up the virtual appliance and build your own Stackato cluster in minutes.

New API

The API of Stackato v3.0 is compatible with Cloud Foundry v2. So, just as you can push any Cloud Foundry v1-compatible application to Stackato v2, the same is true for Cloud Foundry v2-compatible applications with Stackato v3.0.

Having everything available as an API is very powerful for integration with both Operations and Development processes. This was one of the drivers to getting a beta release out to our customers as soon as possible. They want to start building out their DevOps tool-set to work with the upcoming 3.0 release of Stackato as early as possible. They want to hit the ground running when 3.0-final is released.

Web Console

Where you will notice the biggest changes with Stackato v3.0 is when you fire up the web console for the first time. It has been completely rewritten and makes use of all new APIs from Cloud Foundry v2 and additional Stackato APIs.

The web console is now based on Backbone.JS and Twitter Bootstrap, which helps to make the whole web console experience snappier and brings advantages such as real-time updates.

We have a new Activity Stream interface that integrates social and timeline features. This new addition to Stackato stems from our acquisition of Appsecute early this year. It enables you to be able to track application deployments, updates and issues in real-time and start a dialog based on any event. This has been driven by requests from our customers and it takes PaaS functionality to a whole new level.

Just like in its predecessor, Stackato v2, the web console is entirely JavaScript-based. This means anything you can do in our web console you can still do programmatically via API calls to the Stackato API. Again, this is very powerful for automation of DevOps processes.

Single binary client

The multi-platform Stackato command-line client, aptly named “stackato” (lowercase), has been updated to work with the new APIs and Cloud Foundry v2 features. This is a single binary that is shipped on the Stackato virtual appliance and can be downloaded for Mac, Linux or Windows directly from the web console. This is a very powerful tool that covers all of the Cloud Foundry v1 and v2 APIs as well as Stackato-specific features.

Organizations and Spaces

Cloud Foundry v2 now has the concept of Organizations and Spaces. This was not available in Cloud Foundry v1, so Stackato provided its own Groups. Stackato v3.0 has dropped Groups in favor of the new Organizations and Spaces. This is all easily manageable from the web console or the stackato command-line client.

An Organization is high-level concept that groups together users. This allows for multi-tenant PaaS implementations. Users within one Organization cannot see or access resources of another Organization. Organizations can be limited in the amount of resources they are allowed to utilize.

Spaces are a way to group applications within an Organization and one Organization may have many Spaces. It is possible to move an application between different Spaces. For instance, an Organization may have Spaces for Development, QA and Production. Users can be given different access rights to Spaces.

Docker

Docker, Docker, Docker... sick of hearing about Docker yet? Well, Stackato v3.0 is not going to help you avoid what we think is a great project focused on the packaging and deploying of LinuX Containers (LXC).

For almost 3 years, we had already been using the fundamentals of what Docker provides (LXC plus Union filesystem) within Stackato. What dotCloud did when they extracted their implementation from their dotCloud public PaaS, was package this concept and create a project that brought LXC to the masses. The Docker project is wildly popular and moving rapidly. From the project's outset the dotCloud team have added some great features and that feature-set is growing quickly.

With Stackato v3.0, we have replaced our own LXC implementation with Docker containers. Having a team that has spent almost 3 years working with LXC containers, and securing them for Enterprise-grade usage, is the key reason we could incorporate Docker into v3.0 and not have to wait until 4.0 or beyond. Our team really knows their stuff in this area and the folks at dotCloud have been very supportive and open to help where needed.

Having a large community focused on things like security is very powerful. Security is still a major focus for us and our customers, but the Docker community bring a lot to the table in this area.

There is still a lot going on above the Docker layer to deploy, monitor and orchestrate containers. Also, we have not gone fully-Docker, yet. By this, I mean we have done a strict one-for-one swap of our LXC implementation for Docker. For this reason, many of the features of Docker will not be exposed in v3.0-beta, which retains consistency with previous versions of Stackato. This stability is important for our customers as they make the transition to the new Cloud Foundry v2 base and new APIs.

This is the first Enterprise-grade commercial solution which uses Docker. This is something we are proud of, but understand that it is not Docker that our customers need right now. They need their developers to be able to easily deploy their applications without over-burdening Operations teams or being slowed down by resource provisioning requests. This is what Stackato provides.

In the next 6-12 months, if Docker continues to spread like the wildfire it has been to this point, it will be found more commonly in the hands of Developers, Operations and DevOps teams in large Enterprises. Stackato is now positioned perfectly to move in-step with this demand.

New Cluster Configuration

Doozerd is no more. With Doozerd, we found too many hard limitations and the community behind it was not a strong as we have seen in other open-source projects we incorporate in Stackato. We did not want to be bound by its constraints and we could not see a clear path forward technically, so we opted to drop Doozerd from Stackato. Instead, we have chosen to use Redis in its place.

Redis is proven and gives a consistent client-side experience across the many languages that Stackato's components are built with.

With Doozerd, we used a great deal of its features and even added some of our own. "Watchers" would allow any process in the cluster to monitor and take real-time action on changes to any configuration updates across the cluster. With Redis we have replaced this with pub-sub and this is the mechanism by which the cluster can receive updates in real-time.

New NATS

NATS is a “lightweight publish-subscribe and distributed queueing messaging system” and a core part on inter-process communication throughout Cloud Foundry v1, v2 and all previous Stackato releases.

With v3.0 we have introduced gnatsd, which is a rewrite in Go of the original Ruby implementation. This brings the ability to do clustered multi-node NATS instead of relying on a single-node NATS.

In v3.0-beta, we have not enabled clustering support, but we hope to have this fully integrated in the near future.

NATS and gnatsd are both written by the same author, Derek Collison, who was actually the original architect of Cloud Foundry v1.

Still Got A Lot Of Polyglot

The Stackato development team never stops pushing the boundaries. We look at new technologies on a daily basis and consider how they relate to Stackato and PaaS in general. We are not constrained by development language and continue to use the best tools for the job. Like previous iterations of Stackato, Stackato v3.0 comes with components written in Ruby, Go, Node.JS/JavaScript, Tcl, and a multitude of frameworks on top of those.

Why Beta?

As you can see, a lot has changed in Stackato v3.0 over the previous Stackato v2 releases. While we continue to push forward the boundaries with 3.0, we still provide support and updates to Stackato v2, which is a proven and solid solution for our customers to run in production.

Our philosophy is to work closely and openly with our customers, partners and the broader Cloud Foundry ecosystem. There are lot of things we think are cool, that we would love to add to Stackato, but if it does not add value for our Enterprise customers and will not work at large scale with a strong focus on security, then we fail.

Even with open dialog, anyone who has used software, or any new product, knows that until it is in your hands, you cannot have a complete opinion. So far, the opinion of v3.0-beta has been positive and we look forward to delivering 3.0-final in the near future.

You can find out more about Stackato v3.0-beta and download the virtual appliance for VMware player, VirtualBox, vSphere or other hypervisors here.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

Phil Whelan has been a software developer at ActiveState since early 2012 and has been involved in many layers of the Stackato product, from the JavaScript-based web console right through to the Cloud Controller API. Phil has been the lead developer on kato, the command-line tool for administering Stackato. Phil's current role is a Technology Evangelist focused on Stackato. You will see Phil regularly on ActiveState's Blog. Prior to coming to ActiveState, Phil worked in London for BBC, helping build the iPlayer, and Cloudera in San Francisco, support Hadoop and HBase. He also spent time in Japan, where he worked for Livedoor.com and met his wife. Phil enjoys working with big data and has built several large-scale data processing applications including real-time search engines, log indexing and a global IP reputation network. You can find Phil on Twitter at @philwhln, where you can ask him any questions about Stackato. Alternatively, email at philw at activestate.com