Table of Contents for

Programming for PaaS

In general, the term ”private cloud” refers to a cloud computing platform that runs on hardware you control. Private cloud, however, is a controversial term. Some people even claim it does not exist, because they say it’s not cloud if you are running it yourself. Others say that if you put IaaS or PaaS technology on servers you own or manage, that is sufficient to call it cloud.

For the purposes of this section, we will assume that private cloud means running IaaS or PaaS technology in an environment where you own or manage the servers.

Private cloud PaaS is less familiar to most developers than its public counterpart. When people think about PaaS, they generally think about public PaaS. It is the PaaS that most people are more comfortable with.

Private PaaS takes many different forms, but essentially it involves running PaaS on your own hardware, possibly directly on servers that you own. It can run on top of an on-premise IaaS platform, like OpenStack, vSphere, CloudStack, or Eucalyptus, or even directly on your unvirtualized hardware. The difference is that typically with private cloud PaaS you are the one running the PaaS code and you have to manage the code itself.

People running private cloud as opposed to public cloud PaaS get similar functionality and deployment mechanisms for the running of applications, but they are responsible for operating the PaaS code and making sure it stays running. This gives you added flexibility because you get more control over the servers; you can use your own servers and you do not have to be tied to a particular infrastructure provider.

There are some providers, like AppFog and OpenShift, that can actually run on both public and private clouds; these providers let you choose whether you want to host your applications on your existing dedicated infrastructure or on a public cloud. However, many of the other PaaS providers do not provide that choice.

In the arena of private cloud PaaS, you can choose between open source and closed source options. Enterprises and independent hackers can evaluate both.

For example, Cloud Foundry is an open source project that can run many different technologies. It does not care where it runs or how it runs. In fact, you can run it on your laptop and get PaaS functionality. The downside is that running it in production is very, very hard. It is a large distributed program and scaling it is a very difficult problem. There are providers like AppFog and Tier 3 that will do this for you, but you can also do it yourself.

Another open source tool is OpenShift by Red Hat. It is also something you can tinker with and run yourself, but it has different architecture than Cloud Foundry. You can get managed versions from Red Hat. For the independent hacker, these two options are the leading open source ones.

Cloudify is another open source PaaS. This one is aimed more toward enterprises than independent developers, and GigaSpaces (creator of Cloudify) has commercial support for it. While it is more geared toward Java, it does have support for some other technologies. (Compare Cloudify to choices such as Cloud Foundry, which have strong support for many technologies: Java, Node, PHP, Ruby, Python, and many others.)

Apprenda is a closed source PaaS specifically built for .NET. It has the added benefit of some runtime .NET functionality that no other .NET PaaS provides.

Here are some resources for getting started:

As a developer, you have to think hard about what kind of application you are trying to build and whether it fits into the PaaS model. High-frequency trading applications for the stock market are never going to be an ideal use case for Platform-as-a-Service. Super-high-performance situations in which every microsecond is critical may not be ideal for PaaS for a long time. PaaS really is intended to solve some hard problems, but in the process it only addresses applications that fit within some sort of standardized molding. The more you get fancy and try to add many different kinds of features and functionality to a single application, the less likely it is to fit into the PaaS model.

Here is one example in Node. Developers sometimes build Node applications that open two network ports at the same time, accepting data from each port independently, with both feeding into one single application. A typical standard for PaaS is to have only one port open to the Internet, and that doesn’t fit the mold for this kind of application, so building apps like this does not typically work well within Platform-as-a-Service.

Monolithic applications that have a big filesystem, a lot of functionality, and use many gigabytes of RAM are also not ideal candidates to work within the limitations of PaaS. When it is hard to decompose applications into smaller components and services, it tends to be harder to justify running them within a PaaS. Trying to debug deep problems in complicated apps running in production, depending on which PaaS you are using, can be very difficult and frustrating. This process really lends itself best to local development environments so that you can dive into some of the runtime details that are not available within a production environment.

Another limitation involves building distributed applications on PaaS. With highly distributed applications, you have to be aware of the message bus and understand whether your PaaS allows the message bus technology you depend on to connect your distributed applications. Whether you are using a message queue system or a database system in your distributed application, making sure that the pieces that you need to glue together are all well supported within a PaaS environment is another consideration.

Other limitations might be institutional. If you are working within a small- to medium-sized business or an enterprise, there may be an operations team who is responsible for running your applications and you might not even have a choice. There are cases where you can do your own development on a PaaS and hand that app to the operations folks, and they will get it working without a PaaS. So sometimes you can do your development in a PaaS and not have to worry about how it is ultimately deployed. But other times this becomes a problem; the cultural boundaries of what your operations team allows you to do will prevent you from running applications in a PaaS environment. We’ll take a further look into cultural considerations later in this chapter.

Also consider the services and databases that you are using. If you are building an application that is going to require master-master replication and high availability, and if your system is going to require many gigabytes of database storage, you should think about these factors up front and make sure that the PaaS you choose supports your requirements. If you can’t trust that this will be the case, PaaS may not be for you at this time.

In general, you should always check with your bosses to make sure they know where you are running your applications; not getting the OK from above is another reason why you might not be allowed to use a Platform-as-a-Service. System administrators are the ones that get the phone calls at 4 a.m. if it all breaks, and they can sometimes be resistant to new tools and technologies, so checking with them is an important thing to do in any business.

If you are working in an enterprise or a government agency, the data restrictions can be very limiting, and that might prevent you from picking a PaaS. If you have to go with a private cloud PaaS, there might be limitations on what languages it supports and how well it supports them.

If you are dealing with high-performance tweaks, if you have to customize your version of Ruby, if you are changing the internals of your runtime (like PHP), some PaaS vendors may allow that flexibility, but some will not. If you need to custom-compile your own version of Python, PaaS might not be the right fit. If you need to use a certain kind of processor or a certain kind of hardware to run your application, it might not work with the PaaS you choose.

Ultimately, when you are weighing the limitations and benefits of PaaS, it is a matter of control. The more control you are willing and able to give up, the more PaaS functionality you will be able to leverage. So, the two sides of the scale are control and how much power you get from your PaaS. The degree to which you’ll experience the advantages of velocity, speed, and time to market will depend on how much control you are willing to give up. Typically, the more you are able to fit into the mold of PaaS, the less you have to worry about the running of your application.

It is easy to shop around to find a PaaS that fits your needs. One of the strongest points about PaaS is how easy it is to set up and try out. You should evaluate the ease with which you get your first application running. This is a good indicator of not only the quality of the service, but also how you are going to be interacting with that service going forward.

As an informed developer, perform a survey: