Cloud Zone is brought to you in partnership with:

Passionate about technology and startups. Have worked for the BBC in London, Livedoor.com in Japan, Cloudera in San Francisco and MailChannels in Vancouver, Canada. Currently reside in Vancouver where I'm working on building PaaS based on Cloud Foundry, called Stackato. I enjoy writing about technology, especially when it relates to interesting startups. Phil is a DZone MVB and is not an employee of DZone and has posted 59 posts at DZone. You can read more from them at their website. View Full User Profile

PaaS: Service Orchestration Vs Container Orchestration

02.20.2014
| 4587 views |
  • submit to reddit

In Krishnan Subramanian's post "PaaS Is Dead. Long Live PaaS", he makes a distinction between the old and new worlds of PaaS, citing two distinct "flavors of PaaS". The first being service orchestration and second being container orchestration.

Service Orchestration

Krishnan cites services like Google App Engine, Heroku, and Engine Yard for "service orchestration". These are all essentially public PaaS solutions. They provide a black-box solution in the public cloud, which are primarily focused on individuals, startups and small teams. They are not focused on enterprise IT.

Being public PaaS solutions, there is a limit to what they can offer and the level of integration they can provide into an enterprise's IT infrastructure. For this and other reasons, they are not the type of platform that an enterprise would choose to standardize on company-wide.

Compliance is one such limitation of these public solutions and something that we often see as a driver towards private PaaS. Small teams, wanting to prototype quickly and innovate at the rate their enterprise parents demand of them, are looking to public PaaS solutions to get something up and running quickly. It is often a good short-term solution to bypass the red-tape and hierarchy that adds months to building a prototype, when it might only take days to actually prove a hypothesis. Unfortunately, once the hypothesis is proven, the ship has sailed. Using these public services beyond prototype will have the legal department flapping their wings and shouting "Compliance! Compliance! Compliance!"

Using a service in the cloud to run your applications can be thought of as out-sourcing. Out-sourcing is commonplace amongst large organizations, primarily for cost reduction. However, there is another cost to out-sourcing: lack of control. It is ok to give up a little control here and there, as long as you retain overall control and have the ability to take action when things start going badly.

There is a tipping point at which too much outsourcing leads to a loss of control. Yes, some companies outsource their entire IT organization, but I would argue they are not serious about IT. Yes, Netflix outsources its entire infrastructure layer to a public service, but they proactively put additional levels of resilience into their usage of the service. Ultimately though, they are at the whim of their service provider.

Container Orchestration

As we move from public PaaS to private PaaS, we are starting to open up what was once a black box and look inside.

When you are in closed system, like public PaaS, you care little for where your application is running, as long as the service reports it as running. It is just a service.

This is fine for developers, who only care that their Python or Ruby code is executing in the way it should be and there is no latency in loading their web pages. For the Operations teams of large organizations, it is a different story.

As we move to ownership of the system, with open-source projects like Cloud Foundry and OpenShift becoming more and more popular, we start to care more. One of the reasons for this, is the audience is changing. The users of these systems are moving from the novice individuals and startups to the more serious enterprise focused users.

We want to know where our applications are running. Enterprise IT is concerned with scale and not just with an individual application, but with the system as a whole. They want to scale it across the organization, across teams, across departments, across budgets and expose it into areas where trust may not be guaranteed.

Security is everything. Reliability and understanding of the system is important, just as it is with legacy infrastructure. Isolation between application instances is paramount, to ensure the integrity of the platform.

Many, if not most, private and public PaaS solutions have been using LXC containers for several years now. It was out of this that technologies like Docker were born. It is the desire for private PaaS and container orchestration that has fueled rapid adoption and ground-swell around Docker.

In many ways, it felt like Docker shined a light on what is a core component of private PaaS, and helped with a greater understanding of the potential of private PaaS. Many are still rubbing their eyes in wonder and have not yet realized what it would mean to add an orchestration layer on top of containers. Some do not care, but Enterprise IT does.

Just The Beginning

Yes, as Krishnan mentions, there is a lot of speculation on the future of PaaS. As a technology, PaaS adoption is not moving quickly enough for some, and they equate rapid adoption to a successful market. PaaS is new, and PaaS is definitely evolving, but we are definitely seeing adoption.

At ActiveState, we see so many new technologies in this space that it makes for exciting times. For Enterprise IT, who are known to move more cautiously, it must feel like stepping onto a quickly moving escalator. Many have not even seen an escalator before, so they continue to opt for the stairs.

Published at DZone with permission of Phil Whelan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)