Table of Contents for

Programming for PaaS

PaaS is often tied to Infrastructure-as-a-Service. The early PaaS companies, such as Heroku and EngineYard, used Amazon Web Services as their IaaS provider. As PaaS continued to evolve, an important technology shift occurred in IaaS. It all started from a simple question: what if Amazon Web Services technology was open source?

In July 2010, Rackspace and NASA jointly launched a new open source initiative known as OpenStack. The idea was to create the world’s first open source IaaS project. The first code contributions came from NASA’s Nebula platform (called Nova) and Rackspace’s Cloud Files platform (called Swift). The promise of OpenStack was enormous. If it could be built, theoretically anyone could run their own AWS-like service. Such a large promise turned out to be very hard to execute on. Early on, there were a lot of complaints about how immature the software was. However, it has matured quickly and is becoming more and more stable and feature rich every day.

OpenStack has become so successful in the few years since its inception that now there are at least two large public clouds that any developer can use based on it: one from Rackspace, and another from HP. IBM, Dell, and many others plan to utilize OpenStack in key product offerings in the future. There are literally hundreds of companies, large and small, that have committed time, money, and resources to making OpenStack a huge success.

OpenStack’s success has been so great that other projects have sprung up like it. For example, CloudStack started out as a closed source system and is now open source as well, under the Apache 2.0 license; it is now managed by the Apache Foundation.

OpenStack’s success has opened up possibilities for both the public cloud and the private cloud, providing more options on which PaaS can be built. Since a lot of PaaS technology depends on APIs for provisioning servers, and since OpenStack and CloudStack now provide options to do this in private clouds, PaaS is becoming more and more important in both public and private clouds.

Currently, the adoption of OpenStack is driving a new wave of IaaS options for companies like Rackspace. Rackspace started out as a managed hosting provider, offering managed services as well as managed servers. The company took a leadership position in OpenStack development because it wanted to offer OpenStack hosting on its managed platform, like Amazon Web Services, but with a technology that can be used in different ways. Rackspace accomplished that and now has a cloud system running on OpenStack; it’s available in the public and private cloud.

When you decide to choose an IaaS provider, you’ll find that there are an abundance of options. But, while offering you the luxury of choice, this abundance of providers can be frustrating and confusing.

You can go with the incumbent Amazon Web Services or you can try out OpenStack or CloudStack, but be prepared to learn all the different APIs. You can also choose a proprietary system like Joyent or Azure, which have even more proprietary APIs. As you start building your applications, they will become more and more tied to the platforms you choose. The nature of IaaS is to lock you into one infrastructure provider; as you use it more, you become more dependent on it.

As a developer, you just want to get your job done. You want to get resources up and running. But creating new infrastructure on these different platforms becomes problematic given how complex and different their APIs end up being. Also, figuring out the different ways to consume IaaS on different infrastructures can be a very tedious task and not very much fun.

PaaS has the ability to actually run on different infrastructures and incorporate them in a way that doesn’t have to look different. Your PaaS does not have to look different on OpenStack than it does on AWS, or on CloudStack. The version that is being run in a private cloud on-premises doesn’t have to differ from the public-cloud versions. This gives PaaS more flexibility than IaaS. It can be run in different environments that have different APIs, so as a developer, you do not have to figure out the differences. This can be a big time-saver for developers when creating applications and trying different infrastructures to run those applications on.

Running infrastructure on different providers is incredibly difficult. Not only do you need to figure out the different APIs, but you also must figure out how to monitor and maintain your applications within those environments, which can be a Herculean task. To add to your headaches, you also have to deal with large-scale cloud outages.

It seems that every other week a big cloud provider goes down and takes half the Internet with it. This raises an incredibly important problem—perhaps the most important problem that application developers have had to deal with in the last decade.

How can you build a reliable and robust application on infrastructure that is not reliable and robust, and on data centers that are not reliable and robust?

A modern developer has to question whether keeping applications within a single provider is a good enough solution anymore. Whether you can trust a single IaaS provider or region becomes a difficult question to answer. If you cannot trust your infrastructure, the consequences of that are also difficult to manage. Here are some additional questions to consider:

These are very difficult questions, made even more difficult by the variety of available IaaS technologies. OpenStack can help resolve these problems by providing solutions in the public cloud and in the private cloud, but having the same IaaS technology in private and public clouds is only a partial solution. The way that infrastructure providers choose their technologies leads to variety; that variety makes high availability and failover harder to think about.

So, PaaS has a huge opportunity—the opportunity to be a technology that lives one layer higher in the stack. Platform-as-a-Service can think about and manage the IaaS for you. It can understand OpenStack APIs just as well as it can AWS APIs, and make them somewhat, if not fully, transparent to developers.

With PaaS, a developer doesn’t have to realize that the underlying infrastructure is consumed, built, or managed in different ways; that gives PaaS a unique ability to provide insight at higher layer than the infrastructure level. It also makes it easier to think about failover and high availability than it is at the IaaS level. If you do indeed use OpenStack in the public and private clouds, there might be failover and high availability options for you that do not exist otherwise. However, configuring and managing two data centers without PaaS is still an incredibly huge headache.

We are living in a world where the ideal of having one technology everywhere is increasingly less likely to ever be realized. This means you may have to deal with a proprietary closed source system that is fundamentally different than what you are running internally. And this is why PaaS will prove so valuable. It can step in and fill that gap where IaaS can’t.

Open source PaaS options like Cloud Foundry, OpenShift, and Cloudify are using community leadership to build broad and deep operational knowledge into PaaS in a sustainable way.

Originally written by Derek Collison at VMware, Cloud Foundry is a set of more than a dozen programs that are loosely coupled and work together to provide PaaS functionality. Keep in mind that Cloud Foundry alone does not provide everything you might have come to expect from PaaS as described in this book. Cloud Foundry can be very difficult to set up and run at scale on your own. There are some providers that have done this hard work for you, like AppFog and CloudFoundry.com, and there are ways you can set up Cloud Foundry in development mode easily on your laptop, but like OpenStack, it is only as powerful as the team operating it.

However, the Cloud Foundry library does provide many of the features you’ve come to expect with PaaS: being able to deploy apps with a command-line interface to a REST API, scaling and load balancing your application without configuring anything, and adding database and caching services like MySQL and Redis. Cloud Foundry can get these things up and running quickly and easily, but if it breaks, you need to be operationally knowledgeable about how to debug Cloud Foundry to find the problem. You also need to know how to run and scale MySQL as it grows.

One of the biggest concerns developers have about PaaS is giving up too much control and having to strictly conform to exactly how the PaaS vendor wants things to work. Open source libraries like Cloud Foundry and OpenShift are beginning to break down those concerns. Because they are fully open source, you can dig into their guts to see exactly how Apache and MySQL are configured. You can also create new runtime support—for example, the Erlang community has added Erlang support to Cloud Foundry.

In short, there’s a lot of sophisticated technology behind open source PaaS technology, making it a powerful choice and a strong tool for developing the next generation of PaaS services.

In the future, we’re going to see more attempts at building a sustainable PaaS service that tries to tackle a significant problem: developers want to use PaaS, but it’s very difficult right now for companies, both big and small, to adopt it. This has led to a dilemma in how to deliver PaaS. But over time we’re going to see more and more companies trying to solve this problem so that developers can keep writing code the way they want to.

PaaS will to continue to be adopted by developers. They will start thinking about ways they can use PaaS more, and they’ll start working around its limitations and using it in more creative ways. Platforms will start to adopt more use cases, be more flexible, and offer higher performance. But developers are truly reaping the benefits of PaaS right now. That is what’s pushing PaaS forward as a development methodology—one that that’s going to continue to flourish with the next generation of applications.