In 2006, on top of virtualization came the next big step into the cloud: the application programming interface (API). APIs added a sophisticated layer of automation, enabling you to control, start, stop, and create new virtual machines through simple and real-time commands. First created by companies such as Amazon with Amazon Web Services, APIs paved the way for Infrastructure-as-a-Service, which heralded a lot of what we now consider cloud standards.

At this point in the history of the cloud, it was so easy to spawn a multitude of virtual machines that managing servers became a headache. With unlimited servers at your fingertips, how do you take care of managing them all? That is where DevOps came into play.

DevOps became a mainstream force around 2010. It arose from the need of developers to do their jobs faster. They were tired of waiting for operations to deploy their code. They were tired of not having tools to easily manage services. They were tired of having to do it all manually. Out of these frustrations, programmers moved into the cloud and became DevOps gurus. They built systems to manage and maintain infrastructure and to interact with servers in a programmatic fashion.

Important DevOps tools like Chef and Puppet were introduced, providing systems to manage thousands of servers, upgrade code, replace code, replace servers, deploy new servers into a template, and make modifications, all of which had been very labor intensive and difficult from a developer’s point of view. We even saw the rise of automated DevOps tools like RightScale and ScaleXtreme.

DevOps offers developers the most control out of all the cloud tools. The trade-off is that you still need to spend time building and managing operations; if things go wrong, you are still the go-to person. And so, DevOps is not the ultimate answer to the hopes of developers. Here’s why.

As a developer, you will most likely spend time writing code that works with Chef and Puppet, while your ultimate goal is probably to spend less time managing operations. If that is your goal, Platform-as-a-Service can handle operational tasks for you today, freeing up even more of your time. With PaaS, you do not have to write the Chef cookbooks or the Puppet scripts to manage servers. You can spend more of your time writing the code that interacts with your users.

DevOps technologies were—and remain—essential for application lifecycle management tools, which we’ll discuss in a moment. Application lifecycle management would not be possible without DevOps, so DevOps is not going to go away. DevOps is a core foundational technology, and there will always be a need for it in a cloud world.

DevOps tools are also a big part of how any Platform-as-a-Service runs under the covers. For platforms such as Heroku, EngineYard, AppEngine, and AppFog, DevOps tools are essential behind-the-scenes tools.

Thanks to DevOps, one can now manage thousands of machines easily, but one still sees the world through the glasses of infrastructure. Applications care more about services (e.g., MySQL and MongoDB) than the details (e.g., what version of libxml is installed across virtual machines). Managing services and applications remains outside the grasp of DevOps and even IaaS. The next layer of cloud technology is application lifecycle management.

App lifecycle management tools are typified by technologies like Cloud Foundry, OpenShift, and Cloudify. They are not yet really PaaS (though they sometimes claim to be), because they still need an operator to run them (hence not really removing the big pain of running operations yourself). However, they do provide a cornerstone to PaaS technology. These tools know how to start, stop, and deploy applications. They often know how to run and manage some of your services, like MySQL, as well.

App lifecycle management tools handle applications holistically, managing applications across many different servers, so an application can run on hundreds or even thousands of them. Traditionally, IaaS and DevOps tools have had trouble thinking in terms of applications—of the needs, resources, and services that span hundreds of servers. App lifecycle management understands applications, treats them from a services point of view, and knows how to manage, scale, and maintain them.

In many cases, you can run app lifecycle management tools on your own laptop. Cloud Foundry has a Micro VM that can do a proof of concept very quickly. OpenShift and Cloudify have similar tools. Taking app lifecycle management to the next level and building out a production-ready version of the same tool can be daunting; it often takes teams of 5–10 operations people and involves managing dozens or hundreds of machines, even for small production installations.

The benefits of app lifecycle management are great, though. Take, for example, a Drupal website that is going to be hit by massive traffic overnight. In this example, you’ll need to go from a single server to 1,000 servers to handle this huge influx of new users.

Before app lifecycle management, you would need to engage a team to manually figure out how to incorporate hundreds of new servers into the process. You would need to deploy the right code and take a very hands-on approach. It required significant human intervention and it needed to scale with human resources.

Even with DevOps, this can be a daunting task. How do you ensure that the servers that Puppet created are all working the way you expect them to? How do you maintain these servers? How can you see in real time how the application loads are affecting each server? These are only some of the shortcomings of DevOps tools.

An app lifecycle management tool such as Cloud Foundry changes all this. You can tell it that your application needs 1,000 more instances, and Cloud Foundry will do all the plumbing. It makes the changes necessary to run those applications across your servers. It greatly simplifies the process.

But there’s a hitch. You still need people watching and monitoring the app lifecycle tool itself. You don’t get rid of operations; you are simply shifting your attention from an individual application to the running of your lifecycle tool.

In our example, prior to the advent of app lifecycle management tools, when you needed to scale up the number of servers the development team would interact directly with the operations team to ensure success. Sometimes the same team, or even the same person, would be responsible for both, but the roles would be separate. The operations people would be in charge of manually figuring out how to hook all the servers together.

Now an app lifecycle management tool can do all that for you. It knows about the application, it knows how to execute the code, it knows how to add the servers and instances to the application. But the app lifecycle management tool itself needs operations. People are required to operate the tool. The difference is that it is an abstract tool into which you can put anything, any application. As a developer, it does not matter if the operations people running the tool are in-house and sitting right next to you, or if they are hundreds of miles away in a place like Portland, Oregon.

Thus we enter the realm of NoOps and Platform-as-a-Service.

The cloud has been instrumental in moving us away from a paradigm that involved significant expenses, not only in terms of buying servers, but also of running those systems, with all the personnel involved.

In the past, any startup would have had a similar experience. You would need to hire people to handle your core competency, and then spend millions of dollars to handle all of the data center and management pieces.

The central concept and the main benefit of the cloud, beginning with Infrastructure-as-a-Service, is to reduce the cost of buying data centers. You do not need to buy data centers anymore. But you still need operations people to run the servers that you are now renting.

NoOps fully removes the need for operations and development people to work hand in hand. Operational needs are still being fulfilled, but they are being accomplished independently of any individual application. NoOps refers to the idea of outsourcing operations roles and providing a way for developers to get their jobs done faster. Developers don’t have to wait for another team to deploy their code, and the systems that automate those processes for developers operate seamlessly.

NoOps is a controversial term, because some people read it as “No Ops,” suggesting that operations are no longer relevant. On the contrary, however, operations are more relevant and important today than ever. The intent behind the term NoOps is to highlight that from the developer’s perspective, you no longer interact as directly with the operating guts of running the application. It’s the same as how “NoSQL” doesn’t mean that SQL is no longer relevant, but rather that there is another way of approaching data storage and retrieval where a developer doesn’t interact with SQL.

Platform-as-a-Service outsources operations. It is not getting rid of operations, but decoupling them from development, so that you can get your job as a developer done easier and faster.

The original iterations of managed Platform-as-a-Service, which included systems such as Force.com and the Google App Engine, were very constrained. They required you to develop your code against their APIs, so that they only worked within their contexts. Their Platform-as-a-Service features were accessed only when you tied them directly to their systems. They promised that you could access special data and that you could take advantage of features like auto-scaling—but doing so could be difficult.

There were two downsides to early PaaS. The first was that you needed to learn a new set of APIs in order to program against them, so there was a learning curve just to get acclimated. The second downside involved portability. If you were to program against the Google App Engine, for example, it would be difficult to move your application and try it out on a different platform. There were upsides as well, though such as the extractive system data and the services that they provided.

Then new players began to arrive on the scene, and with their arrival came a movement toward platforms like Heroku and EngineYard. They broke the mold of saying that you needed to code against APIs. They said, in effect, “We are going to take your application as is. You don’t have to make any changes that work against proprietary APIs. You can run this code just as easily on your own hardware as you could on our systems, and you aren’t going to have to change your code to make that happen.” For developers, this was a revolutionary moment in the history of the cloud.

Initially, in order to provide their innovative services, these PaaS providers limited the language technology. Early users of Heroku and EngineYard, for example, could only pick Ruby. So while the upside was that you didn’t have to program against APIs, the downside was a restriction on what languages you could pick.

PaaS quickly evolved with the help of next-generation PaaS companies like AppFog and dotCloud, which were no longer tied to a single language. Today, many larger PaaS companies, and even older ones like Heroku and EngineYard, support many programming languages. This represents a significant transition from restrictive platforms to those that are more open.

Some PaaS companies are still tied to single programming languages, however, claiming that there is more benefit in having deeper domain knowledge for a single language.

A popular trend in PaaS with companies like AppFog is multi-infrastructure PaaS. This allows you to run apps in many different infrastructures at the same time, even operated by completely different companies. For the first time in history, you can easily run your app on Amazon Web Services and Rackspace at the same time. If Amazon Web Services goes down, Rackspace can act as a disaster recovery program that keeps applications up and running on a separate system. This has been a dream for most programmers that PaaS can uniquely fulfill.

Traditionally, shared web hosting has been the easiest way for web developers to get started. Examples include GoDaddy, Yahoo!, Comcast, and many ISPs to this day.

The central concept revolves around an FTP account. You get credentials for your FTP application server. That server hosts thousands, sometimes tens of thousands, of websites. Usually the server is large, but it can very quickly get bogged down. If one or two of those websites start to get popular, even with a powerful server, it might be enough to soak up all of the resources. The result: tens of thousands of websites could become very slow or might not even respond.

The upside to shared hosting is price. Shared hosting is cheap, sometimes even free. Also, it’s a hands-free account. You don’t have to do security patches. You don’t have to manage the software. You don’t have to know anything about how the software is written. All you need to know is how to write some HTML code; you hand it over, and everything else is handled for you. But because it’s so inexpensive, your provider can’t afford to handle things well at all times. It can’t scale. It can’t go beyond its capabilities, but it usually does work for simple situations.

While it’s an economy of scale for the hosting provider, it’s not a reliable system for putting up a storefront, a complicated website, or even a site that you want your clients to be able to reliably visit to get your contact information.

Another pitfall of shared hosting is security. Your code can be on the same system as over 10,000 other pieces of code. Keep in mind that a normal website can easily get hundreds of security attacks every day. Multiply that by tens of thousands of pieces of code that aren’t yours, and you can see the risks involved in running a production site on a shared system.

Despite its disadvantages, developers still find shared web hosting useful to host personal web pages, to put up simple ideas, and to try out new ideas. It’s useful for development when you’re not sure if you want to invest the kind of money it would take to run your own servers, and when you don’t need to scale yet. The trouble is that when you do need to scale, it can become a painful process to move from a shared to a dedicated system.

Developers, especially web developers, have traditionally used shared web hosting to get started because it’s cheap and easy. When they look to graduate beyond that, they often turn to dedicated web hosting. This could be as simple as hosting your own server at home using your Internet connection. But there are several other options that provide varying degrees of service and scalability.

Here is a generalized list of dedicated hosting options, sorted by decreasing order of control (and typically, performance):

Let’s now take a look at each of these in more depth.

Let’s return briefly to the example in which you’ve made a TV appearance and your website suddenly experiences a spike in traffic. The problem with dedicated hosting is moving from a single server to 100 servers. It’s a potential nightmare because you’ll need to hire a team of people to help manage those 100 servers. With Platform-as-a-Service, moving from a single server behind your app to 100 servers can take seconds. All you do is move a slider from the left to the right.

As you’ll see, Platform-as-a-Service can provide the power, speed, reliability, and scalability that you wanted with dedicated hosting, and yet be as simple to use as shared hosting. You might go so far as to say that Platform-as-a-Service is the developer’s Holy Grail of scalability and reliability.

This enhanced reliability comes courtesy of one of the key tenets of scalable architecture in the modern web development era: N-tier architecture.

With N-tier application architecture, you don’t put your app logic on the same servers as your database servers or caching servers or load balancers. You have different layers of servers that handle different aspects of the application independently.

You do this for horizontal scalability, so that you can add more capacity by simply adding more of a certain kind of service in parallel and then configuring the software to distribute the load. So now you have gone from having a single server to at least three or four layers of servers, or tiers. Within each of those tiers, you’re replicating for failover and high availability.

This architecture is what you usually end up piecing together when you are using dedicated servers. But every Platform-as-a-Service has N-tier built into it from the start. It’s packaged into the offerings as a de facto standard from the ground up, blending a best-of-breed approach to dedicated web hosting with a simple deployment strategy for deploying your code.

There are a number of different approaches to Platform-as-a-Service. Some vendors focus on a single programming language, meaning you’ll be restricted to working only with Java, or PHP, or Python, or Node.js.

Other PaaS vendors let you choose from a variety of different languages. On the one hand, a multilanguage provider has the benefit of being a one-stop shop. On the other hand, you will sometimes have a more highly tuned environment with a single-language PaaS provider. In general, the most widely used PaaS systems tend to be multilanguage.

One should also be aware of vendor lock-in issues. Some Platform-as-a-Service providers require you to program against their APIs, and once you have tied your code to their APIs it can be very difficult to move it anywhere else. If this is simply at the level of database services, your code can still remain quite portable. However, if there are custom libraries and custom code APIs, it can be problematic and sometimes impossible to compartmentalize these integration points to the point that you can quickly move your app to another PaaS provider.

Almost every Platform-as-a-Service provider lets you try it for free. Usually you can set up at least a few applications for free. This is a useful way for developers to get started and familiarize themselves with Platform-as-a-Service. Once you want to deploy a production application, there are many options, with pricing models that vary depending on which platform you choose. Rates for production-ready apps in PaaS can run from as little as $20 per month to thousands of dollars per month.

For example, with one leading PaaS service you can deploy applications for free, but when you want to scale those applications and add more instances behind them (making them production-ready), you start paying on a per-instance basis. Those instances can each cost $30–40 a month. If you want background processing, that is another $30–40 a month. So, with some Platform-as-a-Service providers, the price can grow quickly as your application needs to scale.

Other platforms have different pricing models. Some charge based on how many virtual machines you use. Others charge on a resource consumption model. With AppFog, you have a set amount of RAM; within that amount of RAM you can deploy as many applications, or as many instances behind those applications, as you want. The monthly fee is based on how much RAM you need, not how you use it. dotCloud has a similar model.

Several questions arise. Is Platform-as-a-Service a new concept? Or is it simply an extension of Infrastructure-as-a-Service? Is the “big idea” the concept of APIs with provisioning servers? Or is Platform-as-a-Service a new and separate kind of idea?

There is a strong case to be made that IaaS and PaaS are very different from one another and that Platform-as-a-Service is not a feature of Infrastructure-as-a-Service. Fundamentally, it comes down to what is important to each service.

What are the central concepts behind IaaS and PaaS? Another way to ask this question is this: what are their atomic units?

Let’s return to an earlier example: when you want to sequence DNA, you want to do it as quickly as possible, so you use low-level languages like C and Assembly to get as much performance as you can.

In PaaS, the tendency is more toward building out web applications, and latency is not as critically important. The quality that is valued more highly for the types of applications that run on PaaS is the ability to create things quickly and connect them quickly. The higher-level languages—the dynamic scripting languages like Ruby, PHP, Python, and Node.js—are better suited to this than some of the lower-level languages.

Thus, the tendency within PaaS is toward languages that a few decades ago were thought of merely as scripting languages. Now they have become powerful tools for businesses to power their applications. Facebook, one of the biggest sites on the Internet, uses PHP to power its systems. Yahoo! also used PHP. Twitter was initially built on Ruby. LinkedIn used Ruby, then changed to Node.js. So you can see a proliferation of web content being built on dynamic languages.

The new generation of languages is also breeding a new style of development: quick iterations on smaller sections of code, faster production of applications that are smaller and at scale. The applications that are generally being built are API-type applications. Examples of these kinds of applications (on a larger scale) include Gmail, Twitter, and MobileMe, which use APIs to communicate with their web frontends. Those same APIs can be used in the context of mobile applications, making sure that a mobile app can register users and that users can communicate with each other. This all must happen through APIs and backend services.

Managing the backend for a mobile application can easily take more time than building it in the first place, which is why Platform-as-a-Service is such a vital tool. If you have a mobile app that gets on the Apple App Store’s top 10 list, you need to make sure that your backend application can scale with the needs of your user growth and can handle millions of users accessing it from their phones every minute. Traditionally, this has taken armies of IT and ops people. Platform-as-a-Service gives you the ability to manage hundreds or even thousands of backends simply with a slider, rather than with a team of people.

In case this remains unclear, it should be stated that PaaS puts control and power into the hands of the developer. At long last, that pager has been rendered unnecessary. PaaS won’t eliminate code bugs, obviously, but hardware and infrastructure failure should not be concerns for developers anymore.

Launched in 2008, Force.com, Salesforce’s developer platform, allows you to build applications that extend the functionality of Salesforce, a very popular SaaS customer relationship management (CRM) sales tool. This was one of the first incarnations of PaaS as we know it today. Force.com inspired a generation of applications, and thousands of developers built new ways to access and analyze Salesforce’s rich dataset.

The Force.com Platform-as-a-Service provides Web Service APIs and toolkits, a user interface for building apps, a database for persistent data, and basic website hosting functionality. More recently, it has added mobile capabilities that make it easy to create mobile applications using the Force.com PaaS as well.

The downside to using Force.com is that you cannot build general-purpose applications using any programming language you want. Application logic is built and run using Apex, a strongly typed, object-oriented, Java-like language that runs on Force.com. The upside is that getting started creating new applications is simple and fast using the web-based interface. You choose the data types you want to collect, creating data structures that can autogenerate web and mobile interfaces for collecting that data.

On top of data input options, you can also add formulas, approval processes, email sending, and tests very quickly and easily. The Force.com PaaS even has its own Force.com IDE for developing, testing, and deploying applications quickly and easily.

When you work within the constraints of the Force.com platform, you do not have to worry about scaling or managing your application; Salesforce does that for you. This idea is the foundation from which PaaS has gained popularity.

As the Force.com platform has matured, more and more services have been added: one example is Database.com, a database service with custom APIs and data feeds for building applications used by around 100,000 businesses worldwide.

Google App Engine (GAE), also launched in 2008, was one of the very earliest forms of PaaS. Its promise was that you could tap into the vast power of Google, draw on Google’s computing resources, and use Google’s infrastructure and expertise in running and operating machines. The caveat was that your application would have to adhere to Google’s standards. Google has built not only an operations team, but also a set of tools and systems that work in a specific way—and they work that way in order to scale to “Google scale.”

What kind of scale are we talking about? A very large one in which you are dealing with many, many thousands of machines all working together to solve a single problem. When you are dealing with a scale as large as Google’s, the tools are very prescriptive; they need to be in order to process volumes of data that are so immense. Google literally processes the entire Internet. One of the central ideas of GAE is that if you adhere to its standards, you too could have that power inside your application, and only pay for the processing power that you use.

Here it becomes evident why GAE is non-portable. It has an existing infrastructure that you are allowed to tap into only if you play by Google’s set of rules. On the one hand, you have to write your code around Google’s expectations. On the other hand, if you do so, you gain the benefits of being able to run at Google scale.

Many PaaS platforms have limitations of various types. When you are dealing with a non-portable PaaS such as GAE, those limitations can be strict. You have to adhere very closely to them in order to take advantage of GAE’s features.

With GAE, there are limitations on access to the filesystem, on access to memory, on the amount of memory you can tap into, and on how long your processes can run.

These limitations can force a developer to think in different ways. For example, let’s suppose you have a website that needs to compile a large list of information and compute data for each item on that list. In a traditional hosting environment, when a user makes a request to such a site, delivering results can take a significant amount of time. All of the processing must happen before the response goes back to the user. And, depending on the complexity of this processing, it could easily take seconds.

This is where we encounter another of the limitations within GAE: there is a set amount of time within which your application must respond. If it doesn’t respond fast enough, GAE will kill the process.

But this can actually be a positive factor in the development of the user experience if the application is designed to know that it cannot live that long. It forces the developer to ask himself, “Instead of simply doing it the way I always have done it, how does Google want me to do it?” So, instead of compiling the list every time a user hits the website, you could create a cache and serve up the list from the cache. The cache could serve very quickly and provide a better user experience. In order to compile that cache in the background, you would have to use a different set of Google tools to do those calculations in a more scalable fashion, and then put those into the caching database.

GAE has a large following and a large developer mindshare behind it. Its promise—taking advantage of the power of Google—has helped make it a leader in the non-portable PaaS category.

Microsoft also thought very hard about how to build a Platform-as-a-Service. Its expertise with the .NET Framework led the company to consider the best way to accomplish this around .NET. In 2008, Microsoft launched Windows Azure.

The company set out to create a set of libraries. These were designed in such a way that if a developer were to incorporate them into her system, Azure would take advantage of those libraries in order to scale the system. Microsoft also provides standard services that can scale independently.

With Windows Azure, you have basic systems, like a message bus and queuing systems, and a variety of different options based on the specific needs of your application. These provide patterns for developers to build distributed applications that can interact with each other over networks. If you incorporate through the libraries the technologies and services that Microsoft has built, you can take advantage of the Azure system and be able to scale your application fairly quickly and easily.

Recently, Microsoft has taken steps to move away from a non-portable Azure system, decoupling some of the requirements that tie developers into required services. This has allowed expansion into different languages and technologies, taking Azure from a non-portable PaaS more into the portable realm, which requires no changes to the code in order for it to run. So, Azure is actually a system that started out as non-portable and has been moving slowly toward portability. In fact, Microsoft recently released a very portable version of its Platform-as-a-Service.

Although all of these PaaS options started out as non-portable, many of them are adding functionality that makes them more and more portable every day. GAE has released PHP support that requires fewer and fewer changes to work out of the box. Windows Azure has also released PHP support, and developers can do more without programming against the Microsoft APIs than ever before.

Heroku, founded in 2007, was one of the earliest companies offering a portable Platform-as-a-Service. Heroku saw what Force.com and Google App Engine were doing and concluded that forcing developers to write their code against its APIs didn’t make as much sense as just letting any code be written.

Heroku started out as a Ruby-only independent startup company, allowing Ruby code to be deployed in any form. It has since been acquired by Salesforce.com and has expanded its language offerings. However, Heroku still doesn’t let you write to the filesystem. The rationale is that this makes it easier to create more instances of your app (Heroku calls them “dynos”). If you were to upload or change a piece of code, it would only end up running on a single dyno, and if your application runs on 100 dynos, the uploaded file would not be propagated, leaving an inconsistent dyno. In order to prevent that problem, Heroku simply says that you cannot write to the filesystem (except for an ephemeral temporary directory).

As with Google App Engine, there is also a certain amount of time (although it’s more generous with Heroku) that an application can survive for before it is timed out. But there are also tasks that can run in the background and do some work that is asynchronous. These ideas were pioneered by Heroku and set some of the early standards for what can be done with portable Platform-as-a-Service.

A further comparison of Heroku to Google App Engine illustrates some of the key differences between portable and non-portable PaaS.

With Google App Engine, you have to be very strict about the code you are writing, making sure that it adheres specifically to Google’s APIs. With Heroku, the code you write—whether it is on a shared or dedicated host—is the same as it is on Heroku. The difference in portability has to do with writing your code against the provider’s system versus writing it in a generic way. The reason it becomes portable is that you can take that same code from Heroku and run it on your own systems without having to make major modifications to it.

One of Heroku’s other innovations revolves around deploying code. The early PaaS offerings, like Google App Engine, had programs through which you would deploy your code. Heroku took a more general approach and created a git-based deployment system (git is a source-controlled management tool that lets you keep revisions of your software over time, like CVS and other source-control tools).

At Heroku, when you commit your code into the git source control, pushing the code into Heroku triggers a deployment. It’s a very quick and easy way to allow developers to deploy their code, unlike trigger shell hosting systems that generally use FTP. With FTP, you have to look for files that have changed and make sure you upload them and sync them. But git will track the file changes over time and keep a history of those changes so you don’t have to go hunting for files that have changed. It identifies them and sends those files to the platform automatically.

Built by VMware, Cloud Foundry is a generational new technology that is centered around PaaS. A more recent creation than either Google App Engine or Heroku, it comprises a set of programs and services that let you run your own Platform-as-a-Service. It is open source licensed (Apache 2) and can even be run on your laptop.

With Cloud Foundry, you have access to a set of packages and programs that allow you to interact and deploy code with the same feel as PaaS. It will manage your code and let you scale it up and down in the ways you are used to with a Platform-as-a-Service.

Because it is an open source program, it is significantly different from Heroku, Google App Engine, or Windows Azure. Each of those is a hosted managed service: you do not get to look at the source code, nor do you get to modify those services. Essentially, they are take-it-or-leave-it situations, black boxes into which you enter your code, which is then deployed.

Cloud Foundry has many of the features of PaaS, but it is not a managed service. Like Apache, it’s a technology that you have to run yourself. However, it is a complex distributed system and is quite a bit harder to run than a typical system such as Apache.

It is not a system that you can sign up for publicly. If you want to sign up, you have to look for a public provider of Cloud Foundry. Their numbers are growing: AppFog is one, and VMware offers it as a hosted service so you can try it.

In contrast to Heroku, instead of using a git-deploy mechanism, Cloud Foundry created a REST API, a new way to think about deploying code. It uses a Ruby-based command line tool to deploy code. Because it is a REST API, it gives you the flexibility to make your own decisions about whether you want git integration, CVS, Subversion, Darcs, Mercurial, Team Foundation, or anything else. If you want a different kind of version control for your code, it doesn’t prescribe one for you and lets you use whichever one you want.

Cloud Foundry also made some other innovative decisions around how to support third-party services. With Heroku and other Platform-as-a-Service technologies, one of the quick benefits is the ability to provision services and have them tie into your application. Traditionally, the way that has happened has been by setting environmental values that are passed along to your application through the runtime. They can be read into the application to get the credentials for your database. Cloud Foundry supports a very similar mechanism, but it has wrapped the idea of services—like MySQL, Postgres, and Redis—into an abstraction that lets you bind services to and unbind them from applications; it keeps an environmental variable array available so that you can iterate through them programmatically.

Cloud Foundry also lets you bind a single data source to multiple applications, which is handy when you need to debug an application and determine its state—either in production data or as an audit system. You can bind your data source simultaneously to various different applications.

One of Heroku’s innovations is centered on a third-party add-on marketplace. Via this marketplace, Heroku can provision other cloud tools and, using the environmental variables, pass along the credentials for those tools to your application. Some PaaS platforms, like AppFog, have incorporated a similar idea, but Cloud Foundry does not currently have third-party integration built in.

Service binding is one of the few aspects within a portable Platform-as-a-Service that does actually require a difference in code. When you are trying to move an application from one Platform-as-a-Service to another, generally the part that will result in a difference is how it connects to the database or data sources. Often there are dissimilarities that do require some code—usually a small amount—to be rewritten.

CloudFoundry.org pushed the boundaries of Platform-as-a-Service by providing an open source tool set that any developer could use. It also pushed into new territory because it was not a managed Platform-as-a-Service. From the developer’s point of view this meant that before you could use Cloud Foundry, you would have to set it up yourself and then run it. If you were going to use it in production, you would have to set it up and run it in production, which, while offering a great amount of flexibility, cuts back on the ease of use typically associated with PaaS.

AppFog is a Platform-as-a-Service that is managed and maintained, and it incorporates Cloud Foundry technology. AppFog started as an independent startup and was acquired by CenturyLink in 2013.

One of the other innovations of Heroku is that it was entirely built on Amazon Web Services, and to this day it continues to run on AWS. This is very different from earlier PaaS providers such as Force.com, Google App Engine, and Azure. Each of these was built on top of its own platforms and infrastructures. Cloud Foundry has two components: the open source library called CloudFoundry.org and a proprietary hosted managed platform called CloudFoundry.com, which uses CloudFoundry.org code.

AppFog is a company that also uses CloudFoundry.org code and runs it on multiple infrastructures and public cloud systems. So, while it does run on Amazon Web Services, it is also compatible with OpenStack platforms like Rackspace, HP Cloud, and others. It can even run on private cloud instances of OpenStack and vSphere.

From a developer’s point of view, AppFog has many of the features of CloudFoundry.org that you’d find out of the box. But it runs on many infrastructures, letting you choose them and giving you the portability of those infrastructures, as well as the code. Additionally, AppFog has taken the ideas of other platforms, like integration with third-party cloud services, and incorporated those into its platform. The result: you can sign up and run your applications in any cloud infrastructure that you want, using a technology that you can run yourself, giving you the benefits you’ll find in other systems (like Heroku) that incorporate third-party add-ons.

There are other platforms that focus specifically on the infrastructure behind the PaaS and spend less time on the user experience. dotCloud is an example of a Platform-as-a-Service that innovated by being the first to support multiple languages and technologies, and it has popularized the idea of Linux containers with an open source project called Docker.

When dotCloud was released, Heroku had been focusing only on Ruby, Google App Engine only on Python, and Azure only on .NET. dotCloud came along and offered support for Python, Java, Ruby, and other technologies.

This popular Platform-as-a-Service has focused on creating a system that works though the command line, similar to Cloud Foundry. It has a Unix command line and an API to interact with that command line, enabling you to deploy your applications in multiple languages.

One of the differences between Cloud Foundry and dotCloud is how they approach language support. With Cloud Foundry, the entire system is an open source tool, which means that you can go in and change the way that applications are run and managed; management is tightly coupled to the Cloud Foundry tool set. dotCloud has abstracted the way that applications are run; you can manage the way they are run within the specifications while you deploy your application.

CloudBees is a Platform-as-a-Service that is focused specifically on Java. It has been built around Java tool sets and incorporates common tools used within Java platforms.

One aspect that separates CloudBees from other platforms is its integration with continuous integration tools such as Jenkins. In fact, CloudBees has hired some of the people that maintain Jenkins and has become a leader in the continuous integration space. This has given Platform-as-a-Service a new twist because it allows for systems and extends the broader view of PaaS. With other platforms, the idea is to take your code and deploy it into production; CloudBees incorporates more development tools to extend the purview of what it provides.

Instead of simply taking code and putting it into production, CloudBees provides a system that lets you test that code in a continuous manner, making sure that it works before it goes into production. It provides a longer pipeline before your code is deployed and extends some of the functionality for how a developer can work with her Platform-as-a-Service. To date, however, CloudBees still only supports Java and Java-enabled applications. So, while it has broadened what can be accomplished with a Platform-as-a-Service, CloudBees is still limited to just one technology.

Although historically there have been many different types of Platform-as-a-Service technologies, with more being born every day, there is the possibility for an emerging standard to appear around Cloud Foundry or OpenShift, a few of the open source options for PaaS.

There are several compelling reasons for this. The fact that you can run these technologies from your laptop is very compelling for developers trying to incorporate PaaS into their daily workflow. The other big plus for open source communities around PaaS is the fact that you can theoretically have choice between various providers with compatible PaaS options, or even run it yourself in production. In contrast, unless Heroku open sources its technology stack, you are tied to Heroku’s choice of infrastructure provider.

Taken together, these assets of open source PaaS offer an opportunity to create a standard around their APIs without the ability to lock anybody into a specific infrastructure or service provider. It also acts as an emerging standard for how to deploy applications in a standard way across infrastructures, both public and private.

We have already seen the start of using the Cloud Foundry API as a standard. AppFog uses it to deploy applications across Amazon Web Services, Rackspace, HP Cloud, and Windows Azure, which illustrates that one standard API can be used across different backends. The way that the developer interacts with these systems is though the Cloud Foundry API, decoupling the infrastructure implementation underneath from the API language that the developer uses to speak to it.

More and more PaaS technology is being open sourced every day. Cloud Foundry was one of the early leaders to do so, but Red Hat later open sourced OpenShift, GigaSpaces has an open source Cloudify offering, and even dotCloud has open sourced large chunks of its PaaS technology stack.

As you can see, there are a variety of PaaS providers out there, built for different needs and with different ideas in mind. When thinking about legacy applications and moving them to the cloud, it’s a good idea to understand the limitations of the platforms with respect to the needs of your applications. In the next chapter, we’ll take a deeper look at moving legacy apps to PaaS and provide solutions for some of the challenges you might encounter.

When working with IaaS, one has to assume that any server could go down at any minute, as they often do. PaaS offerings, which are typically built on IaaS, have usually thought out some of these potential problems for you. Building out N-tier application logic can be hard, and that is why PaaS can be so valuable; N-tier is built into PaaS from the start.

With PaaS, you don’t have to figure out how to configure Apache on 20 different servers; you don’t have to figure out how to load balance across those servers; you don’t have to worry about MySQL slaves and master-master replication. Nor do you need to be concerned about redundancy, heartbeats, and failovers, as you would with IaaS.

However, with PaaS, you still have to write your code with the assumption that any individual instance of your app may go down at any moment. That forces you to think about building applications in a way that isn’t consistent with some of the traditional methods of web development, especially for legacy applications. You will also need to take into consideration frameworks and content management systems (WordPress, Drupal, Joomla!) that haven’t yet gotten up to speed with this new way of thinking and haven’t yet incorporated ways to manage multi-instance applications.

We will cover specific examples of how to address these problems later in this chapter.

You have to make those changes yourself, and you have to start thinking not only about how your application will act if a few or even many of your instances go down, but also about how your application will act if the filesystem is not consistent across different instances.

Here are some common questions you will need to think about for legacy applications as related to the hard drive:

Another consideration when moving to PaaS is long-running processes. In traditional development methodology, there has rarely been a problem with long-running processes operating sequentially. Your application typically will just take longer to load, using a large amount of processing power up front, but this can be hidden behind the scenes with Ajax or some other frontend gimmicks. However, when you utilize PaaS, you have to think about long-running processes differently. In PaaS, long-running processes should be processed independently and are asynchronous from your main application logic. In fact, some PaaS providers enforce this by killing your main application if it runs for too long. Not all legacy applications were created to work that way.

These are just a few of the ways in which traditional development paradigms have evolved and how cloud paradigms are much different than the original ones. Now let’s put those ideas into specific contexts.

There are two essential kinds of storage for assets: blob (binary large object) storage, also known as object storage, and file storage. File storage is the familiar kind of storage system used in traditional development. Blob storage works differently. Blobs are more like a key/value store for files, and are accessed through APIs like Amazon S3, Windows Azure Blob Storage, Google Cloud Storage, Rackspace Cloud Files, or OpenStack Swift.

When a user uploads assets to your application, a temporary file is usually created and moved to a more permanent location in the filesystem. When using blob storage, instead of moving files to a folder, you upload the asset to its final location (usually through a REST API) and are given a unique URL to reference the asset from. Once it’s uploaded into the object storage mechanism, the API will give back the URL for that asset, at which point you can store the URL. Instead of storing the object on the disk, you now have a URL that you can reference; it’s been uploaded into a persistent storage mechanism.

One of the benefits of using an object storage system is that all those files that were uploaded are automatically replicated on many different servers (up to seven or eight different copies will exist in many different parts of the world). It’s very difficult to lose data and it’s much more persistent; the content is much less likely to suffer damage based on any disk failure. You don’t have to worry about backups as acutely as you would if your data were uploaded to your local disk.

There are even more added benefits depending on which object storage you use. Content delivery networks (CDNs) can speed up the delivery of your assets so that not only are they hosted in many different locations, but also, depending on where in the world you are, they can be served to you from the one that’s closest to you. This can make the whole experience of consuming your assets and downloading the web pages feel a lot faster.

Because of the redundancy and CDN considerations, blob storage is a good idea in general, but it also has the added benefit of providing more speed, reliability, and robustness to your website. And it’s not too difficult to implement. As you’ll see in these code examples, the amount of effort that’s required up front to deal with asset hosting is more than worth the investment in terms of what you get out of it.

Amazon has libraries for using S3 in Ruby, Java, Python, .NET, and mobile phones. Here is an example of how easy S3 is to integrate with a PHP application. This code will not work out of the box because it only contains the relevant snippets for understanding the flow of code. To get code that is fully ready to go, you will need to go to Amazon’s Sample Code & Libraries page, which has more detailed instructions for how to use the code. However, for the purposes of illustration, once the library is incorporated into your application it is not difficult to use:

<?php
// S3.php is available from Amazon's AWS website
if (!class_exists('S3')) require_once('S3.php');

// Amazon gives you credentials if registered for S3
// Best practice is to make these ENV vars in a PaaS
$s3 = new S3(
    getenv("AWS_ACCESS_KEY"),
    getenv("AWS_SECRET_KEY")
);

// A "bucket" is analogous to the name of a folder
// It is a way to collect similar things together
$bucket = "MyPaaSAppBucket";

// Create the bucket
$s3->putBucket($bucket, S3::ACL_PUBLIC_READ);

// Assuming the file is POST'ed as a form element
// called "file", <input type="file" name="file" />

// Name the uploaded file. Bad idea to pass the name
// like this without any validation.
$file_name = $_FILES['file']['name'];

// Upload the file
$s3->putObjectFile(
    $_FILES['file']['tmp_name'],
    $bucket,
    $file_name,
    S3::ACL_PUBLIC_READ
);

$url = 'http://'.$bucket.'.s3.amazonaws.com/'.$file_name;

Like Amazon, Microsoft has libraries for using its Blob service in Ruby, Java, .NET, Python, PHP, and mobile phones. Here is an example of how easy Azure Blob is to integrate with a Node.js application. Again, this code will not work out of the box; you will need to go to Microsoft Azure’s website for the code you need and more detailed instructions for how to use it. However, for illustration purposes, once the library is incorporated into your application it is not difficult to use:

// Azure in Node is available from npm install azure
var azure = require('azure');

// Azure gives you credentials if registered for blob
// Best practice is to make these ENV vars in a PaaS
// They will be called AZURE_STORAGE_ACCOUNT and
// AZURE_STORAGE_ACCESS_KEY

// Create a service and container to gather assets
var containerName = "myPaaSContainer";
var blobService = azure.createBlobService();
var container = blobService.createContainerIfNotExists(
    containerName,
    function(error){
        if(!error){
            // Container exists and is private
        }
    }
);

// The name of the uploaded object
var blobName = "myimage";

// The file name, possibly the uploaded temp file
var fileName = "/path/to/myimage.jpeg";

var blob = blobService.createBlockBlobFromFile(
    containerName,
    blobName,
    fileName,
        function(error){
          if(!error){
              // File has been uploaded
          }
    }
);

var url =
 "http://"  + AZURE_STORAGE_ACCOUNT + ".blob.core.windows.net/" + 
      containerName + "/" + blobName;

When integrating any blob functionality into your application, you will typically be doing various functions repeatedly, like uploading files and returning their corresponding URLs for storage in your database. To achieve maximum portability, it generally makes sense to add a layer of abstraction around this often-used code. That way, if you want to use a different object storage provider in the future, you can change your code mainly in one place rather than many.

You may organize these functions in a class if you are using an object-oriented language, or you may simply have some basic functions accessed globally.

The simple example class that follows is written in object-oriented Ruby. It contains some basic logic for working with Rackspace Cloud Files, but it could easily be ported to S3, Azure Blob, or any other object storage without affecting code that depends on it.

There are some libraries, such as Fog, that have this logic already encapsulated in them:

// Usage: o = ObjectStorage.new(container_name)
//        o.upload(file, blob_name)
//        return o.url
class ObjectStorage
    def initialize(name)
        @@connection ||= CloudFiles::Connection.new(
            :username => ENV["USERNAME"],
            :api_key => ENV["API_KEY"]
        )
        @container = @@connection.container(name)
    end

    def upload(file, blob_name)
        @object = @container.create_object(blob_name, false)
        @object.write(file)
    end

    def url
        @object.public_url
    end
end

When you’re dealing with a content management system (CMS), the process can be different. Systems like WordPress, Drupal, and Joomla! have plug-ins. Instead of rewriting code, you can install a plug-in, which may directly tie into blob services like S3. The plug-in upload mechanism stores the files directly into object storage and gives you back a URL. This improves the speed of the load time for your blog or CMS. Even better, it gives you a more scalable blog to which you can add more instances. When you load balance it to an instance that doesn’t have the uploaded content, you’ll never see the nefarious Error 404.

The following is a list of selected starting points for some of the most popular CMSs today. These URLs will have the latest code and documentation that will allow you to integrate with your applications quickly and easily:

In PHP, you can overwrite the session handler to use any technology you want through the session_set_save_handler() function. If you are using the Zend Framework, there is a simple way to connect sessions to a database like MySQL using Zend_Session_SaveHandler_DbTable. Other PHP frameworks have similar functionality built in, or you can write code yourself that will accomplish it pretty easily. Here is an annotated example from the PHP documentation for how to write sessions to files:

<?php
class MySessionHandler implements SessionHandlerInterface
{
    private $savePath; // where to save session files

    // initialize the session object and create a directory
    // for session files if necessary
    public function open($savePath, $sessionName)
    {
        $this->savePath = $savePath;
        if (!is_dir($this->savePath)) {
            mkdir($this->savePath, 0777);
        }
        return true;
    }
    // no need to do anything when you close out a session
    // object
    public function close()
    {
        return true;
    }
    // for any given session id ($id) return the data
    // stored in the session file on disk
    public function read($id)
    {
        return (string) @file_get_contents("$this->savePath/sess_$id");
    }
    // write session data to a session file
    public function write($id, $data)
    {
        return file_put_contents("$this->savePath/sess_$id", $data) === false ?
        false : true;
    }
    // when you want to delete a session, delete the
    // session file containing the data
    public function destroy($id)
    {
        $file = "$this->savePath/sess_$id";
        if (file_exists($file)) {
            unlink($file);
        }

        return true;
    }
    // garbage collect sessions objects older than a given
    // amount of time
    public function gc($maxlifetime)
    {
        foreach (glob("$this->savePath/sess_*") as $file) {
            if (filemtime($file) + $maxlifetime < time() && file_exists($file)) {
                unlink($file);
            }
        }

        return true;
    }
}

$handler = new MySessionHandler();
session_set_save_handler($handler, true);
session_start();

// proceed to set and retrieve values by key from $_SESSION

In Node.js, encrypted cookies can be implemented using a variety of npm modules. If you use the Connect middleware, galette and cookie-sessions are two plug-ins that give you encrypted cookie functionality.

In Rails, the default session mechanism is an encrypted cookie, but if you want to change it to a Mongo or MySQL service all you have to do is edit config/initializers/session_store.rb.

In Java, Tomcat has built-in clustering capabilities, where every session is replicated automatically to every Tomcat instance. This can be nice because enabling it does not require significant code changes; however, the downside is that managing and maintaining session replication can turn into a network overhead in this implementation and this Tomcat feature requires sticky sessions in the load balancer, which not every PaaS enables. If you want to try using encrypted cookies in Java, take a look at Marc Fasel’s SessionInCookie application and the associated blog post, which has more details.

Depending on individual circumstances, caching is a technology that may not need to be migrated from your legacy application into your cloud-based PaaS in order for you to move forward. Why? Because often caching is built in such a way that if a piece of HTML is missing—if it doesn’t exist on the disk, or doesn’t exist where it is expected to be—the system will compensate by regenerating the correct content.

For example, if you have three different instances of your code and the cache has only been populated to disk on one of those instances, when you happen to hit an instance that doesn’t have a cache yet the system will generate that code and then save it to the second instance; the next time a request comes in to the second instance, it won’t have to be generated again.

The biggest downside to relying on this is that it can lead to situations where a user sees different content when reloading a cached page. If one instance has a copy that was made a week ago and another has a copy made three days ago and another copy is fresh, every reload may present different information.

However, this is not always a problem, so from a caching perspective, migrating a legacy app is not necessarily going to create a poor user experience. However, anytime you put something on a disk, that disk can crash, or data might not be consistent across all the disks; what might be cached on one server might be different from what’s cached on another, which could result in an inconsistent user experience.

When moving legacy applications to PaaS, you can use the opportunity to implement best practices and create a central cache storage for your application, using SQL or NoSQL databases to store that data instead of a disk. So, instead of making calls to disk, you can use technology like memcached, Redis, MongoDB, or CouchDB. In some cases, you might cache the data directly into a SQL database, putting it into MySQL or PostgreSQL.

With the MySQL and PostgreSQL options, the upside is that you usually already have connections to your database that you can use and you don’t need external dependencies on yet another service. So if you’re not using memcached or another NoSQL service in your application, it may make more sense to simply use your MySQL database, since you already are using that for other aspects of your app. However, as you’re looking more and more into performance and scalability, the benefits of using memcached and other NoSQL value stores will become clear: much of the time data can be extracted far faster, especially with memcached. In NoSQL, you are usually storing that data right in the RAM, and that’s the fastest place to get it. In most SQL databases, frequently used data is also kept in RAM to an extent. If your databases do not exceed the limits of how much data is cached in RAM, you may not see a substantial difference using memcached or MySQL. However, as your datasets grow, this may become a bottleneck down the road.

One of the great benefits to using PaaS is how simple it is to add more services to your application as well. For example, if you were afraid of using MongoDB because you did not want to run and scale it, PaaS will do that for you, so you have more flexibility to try services that you otherwise might have stayed away from.

Implementing client-side integration with caching is generally a very easy process. In PHP, if you are on Ubuntu, all you need to do is run sudo apt-get install php5-memcached to install the client memcached libraries for PHP. Then you can use the following code to get and set values in the memcached key/value store:

<?php
$cache = new Memcached();

// memcached allows multiple servers, best to
// keep the names in environment variables
$cache->addServer(
    getenv("MEMCACHED_SERVER"), getenv("MEMCACHED_PORT")
);

// set
$cache->set("foo", "Hello World!");

// get
$cache->get("foo"),
?>

Caching with a NoSQL database like MongoDB is generally as easy to do as using a simple RAM hash system like memcached. This is because essentially, these are all basically key/value stores and caching is a primitive form of distributed key/value storage. (This is not completely true, especially when it comes to expiration of key/value pairs, but it can naively be treated as such for most uses.)

In Node.js, there is an npm module called mongodb that provides a mongodb client. Simply running npm install mongodb will install it:

// pass the connection string in through env vars
var mongourl = process.env.ENV_VARIABLE["mongourl"];
require('mongodb').connect(mongourl, function(err, cache) {
    var collection = db.collection('cache');

    // set
    collection.insert({ 
        key: "foo",
        value: "Hello World!"
    });

    // get
    collection.findOne({ key: "foo" },
        function(err, item) {}
    );
});

When integrating any caching functionality into your application, you will typically be doing various functions repeatedly, like getting and setting key/value pairs. For maximum portability, it generally makes sense to add a layer of abstraction around this often-used code. That way, if you want to use a different object storage provider in the future, you can change your code mainly in one place rather than many.

You may organize these functions in a class if you are using an object-oriented language, or you may simply have some basic functions accessed globally.

The simple example class that follows is written in object-oriented Ruby. It contains some basic logic for working with Redis but could easily be ported to MySQL, memcached, or any other technology that can be used with caching:

gem "redis"
require "redis"

// Usage: cache = ObjectCache.new
//        cache["key"] = "value"
//        return cache["key"]
class ObjectCache
    def initialize
        @connection = Redis.new(
            ENV["REDIS_SERVER"]
        )
    end

    def [](key)
        @connection[key]
    end

    def []=(key, value)
        @connection[key] = value
    end
end

Here’s an example. You have a long list of data, maybe RSS URLs. This data is processed through many high-latency API calls (regularly polling RSS feeds from various sources). Because that data needs to be presented very quickly, you don’t want to be gathering it while processing queries in real time as the user is viewing the data.

Another example is processing images or videos. When you’re uploading an image, an application may want to resize it, compress it, or do any number of other tasks. Depending on the size of that image, processing it can take a large amount of RAM, CPU, and time. The processing can take a long time (minutes or even hours), and a user of your application should not have to wait for your application to process the data in real time. Processing images and videos should be done asynchronously and the result should be pushed to the user as the processing finishes.

To accomplish this, you need asynchronous processes that will gather and calculate in the background, using as much time and as much CPU as needed. The data can be stored either in the database or in your caching mechanism. Once stored, it can be accessed quickly and directly in real time from the web frontend application.

The generic technique for setting up long-running processes is actually quite simple. Here is some pseudocode for before:

for each task in tasks
do
    // could take a while
    process the task
end

and after:

for each task in tasks
do
    // only takes a millisecond
    queue task for processing
end

The processing code will look like this:

loop
do
    grab task from queue
    process the task
end

As you become more familiar with incorporating background processing into your applications, you may want to get fancier with it. You can incorporate open source systems like Celery for Python, which provides an asynchronous task queue based on distributed message passing and also supports scheduling tasks at certain times. Celery uses RabbitMQ, Redis, Beanstalk, MongoDB, or CouchDB as a backend for its service.

In Ruby, there is a similar project called Resque backed by Redis. These projects have the added flexibility of giving insight into the health and state of your queue, which is critical as the scale of your applications grow.

Aside from open source projects, there are even some third-party services that specialize in background tasks, like Iron.io’s IronWorker. IronWorker has libraries in Ruby, Python, PHP, Node.js, Go, Java, and .NET, and unlike Celery it does not require you to have any integration with a service like RabbitMQ or Redis. It is a fully managed service that takes your processing code and runs it for you in the cloud on servers managed by Iron.io.

A common “gotcha” in dealing with databases from legacy systems is stored procedures. The problem with stored procedures is that they can be used pretty commonly within legacy applications. However, in many platforms, the hosted databases are not very friendly to stored procedures; with many PaaS providers, they are completely disabled, which can be a problem for legacy applications. It is usually not considered a best practice to use stored procedures; although they have been used in the past, the modern programming methodologies discourage their use.

Stored procedures are functions stored in the database itself that can be used as first-class citizens when doing SQL queries on that database. A trivial example of a stored procedure might be adding two columns together on a database; you can select that stored procedure and get the combination of those columns without having to do the processing in your code.

Of course, stored procedures can get a lot more complicated and offset much of the computational effort of processing data into the database instead of the code.

One of the big problems with stored procedures is that they create one-offs that are hard to remember and hard to keep track of. It is hard to remember what stored procedures are used and need to be maintained, which makes code harder to debug and especially hard to run tests against. When you are running a local version of the database—in addition to a QA version, a development version, and a production version—it is incredibly difficult and untenable to maintain, distribute, and change stored procedures across all of them all the time. The rise of unit testing was one of the nails in the coffin of stored procedures. The inability to easily and effectively run unit tests against stored procedures across all databases took them out of fashion.

If stored procedures are impossible to remove from your application, there are solutions. PaaS providers have started to look into third-party dedicated databases, and some even offer dedicated databases themselves. There are now providers that offer MySQL-as-a-Service on a dedicated basis, including Xeround and ClearDB. Even Amazon has a MySQL service called RDS, which is a dedicated and managed MySQL environment. Typically, when you have a dedicated MySQL instance, storing those procedures is allowed.

So, if you can’t get around the dilemma of stored procedures, there are ways that you can still migrate your legacy applications into the cloud. However, the solutions can get expensive, and it might be harder to set up slaves and ensure consistency across multiple databases as you grow.

One of the easiest traps to fall into when writing or rewriting your code is premature optimization: building features that you think are going to be needed or optimizing aspects of your app before they actually need to be optimized. However, the topics and actions we have discussed so far in this chapter do not fall into the camp of premature optimization. They really fall into the category of best practices, because any application that starts to grow is always going to need to employ PaaS.

Premature optimization is making an optimization that may or may not matter at scale. All of the topics we’ve covered in this chapter will always matter, and should be considered when you’re building your applications from scratch so that you don’t end up having to port more legacy code somewhere down the line.

Is it better just to throw out your legacy applications and start from scratch?

It depends. The considerations will be different for every application, for every developer, for every team. There are certainly going to be cases and situations where it makes more sense to redo your code from scratch. There will also be cases where you will not be able to do so, since you might be dependent on code from systems like WordPress or Drupal; you might be so dependent on legacy code that throwing it out and starting from scratch is simply not an option.

There are also cases in which an application has grown to a size that makes it very difficult to throw out all the existing code. Other projects that might have pieces of code that can be thrown out, enabling you to decouple and create smaller applications to do the services—file uploads, for example—independently of the main code itself. Again, it definitely depends on the situation.

Look for all the places where your code depends either directly on the disk or on any individual server. Consider storing in RAM data that is needed across many instances and auditing for every place that could possibly affect the user experience negatively.

Consider a common scenario for large businesses and financial or government institutions, where you’re building an application that has data-constrained portions that can only run in house. This data-restricted part of your application usually ends up being a small fraction of the app, perhaps 5% to 10%.

If you build your application monolithically, the entire application will have to be run in house due to the data constraints. However, if you build it to run as a distributed system, with many APIs feeding into a lightweight JavaScript frontend, or even a simple dynamic frontend that consumes other service APIs, you can still host 90% of your application safely in the public cloud. All the mundane pieces that do not interact with sensitive data can be run on commodity hardware that is cheaper to run in the cloud.

We’ve seen many successful examples of this modern service-oriented, API-driven architecture. We already mentioned Twitter, but Gmail also took a very API-driven, client-side approach, putting together APIs that interact with the mail and having the frontend JavaScript client consume it all. Apple did something similar with MobileMe: the backends are simple APIs, and the frontend is a thick, client-side application that handles much of the logic in real time. This enables more flexibility, more scalability, and more foresight, leading to better, more maintainable applications.

This approach of building many smaller services works especially well with Platform-as-a-Service. In fact, it is a best practice to do it this way with PaaS. Making small independent services that all tie together on the frontend is not only a modern approach to developing both web and mobile applications, but also ties in well when you are trying to decide how to incorporate a Platform-as-a-Service strategy.

JSON (short for JavaScript Object Notation) has emerged as a standard format for transferring data within API services, serving as an alternative to XML. JSON is used in a wide range of applications, including Gmail, MobileMe, iCloud, Twitter, LinkedIn, and almost every major website you’re likely to interact with. One of the reasons that it has been so predominant is because it is easy and natural for JavaScript on the web frontends to consume the JSON data. JSON has strong support on native mobile clients as well. The great libraries for parsing JSON within mobile and web APIs have made it a natural standard for generating and presenting the data for modern application design.

The JSON scheme is not hard to read, both for computers and for humans. Here is an example:

{
      "id": 1,
      "name": "Programming for PaaS",
      "price": 123,
      "tags": ["PaaS", "Programming"]
}

One of the nice aspects of the JSON format is how easy it is for web browsers to parse. This makes it a great format for Ajax programming techniques. Here is an example of how easy it is for a native JavaScript client like the one in your browser or in any Node.js application to parse:

var object = eval(text);

This is not the most secure technique (validating the text before executing it is always best practice). However, it shows the power of the JSON format.

REST (short for Representational State Transfer) is an architecture pattern (or style) for distributed systems like the Web. REST has become a predominant service design model, reusing HTTP’s basic vocabulary like GET, POST, PUT, and DELETE. Because REST uses simple HTTP commands, it uses much less bandwidth than services like SOAP that demand lengthy headers and heavy XML parsing.

The basic principle behind REST is to provide a shared network vocabulary for transferring resources in a standard and predictable format. What does that mean? Let’s look at an example of what a RESTful JSON service for serving and managing user data might look like:

With a RESTful approach, getting and managing services becomes predictable and straightforward. Creating and scaling any particular RESTful service is not usually very challenging.

For example, if your service is unlikely to get more than 100,000 rows in the next few years, then there is little need to worry about scaling beyond a traditional MySQL or PostgreSQL database table. These traditional SQL tables can easily scale to millions or even tens of millions of rows on a single server.

However, if you anticipate the service growing to 100,000,000 rows, you might want to consider a database better suited to highly distributed growth, like Riak or CouchDB.

A metaservice is a RESTful application for serving collections of data.

In slightly more detail, it is a lightweight application that consumes a core service (e.g., MySQL, MongoDB, Redis, memcached, etc.) and produces a REST API, which generally serves JSON or XML serialized data.

A metaservice is like a core service wrapped in REST with limited application logic specific to whatever the metaservice specializes in. Examples include a user registration metaservice, a commenting metaservice, a message metaservice, and a blog metaservice. Sometimes the same database serves various metaservices, but in other cases the metaservices will have their own databases and core services.

Traditionally, instead of building metaservices for data sources, you would build a lot of code that essentially did the functionality of REST, but mixed a bunch of services together, cross-function the logic, and, instead of generating simple JSON serialized objects, resulted in a complex mess of dynamically generated HTML, CSS, and JavaScript. When you wanted to swap out components, you found it difficult, if not impossible. When you wanted to scale components, they would be intertwined. The same table that would only need 100 records accessed frequently was on the same database as the one that needed to grow to 100,000,000 records, which would be infrequently accessed but needed to support fast indexed searching. This is the nightmare of scaling web applications in a traditional way—and it is a path that has been trodden by thousands of developers before you. Those developers usually ended up decomposing these applications into metaservices, so why not go with metaservices from the start?

A metaservice is built on top of the idea of a core service. It’s powered by these services—by the MySQLs, MongoDBs, and PostgreSQLs of the world. However, they are wrapped within a lightweight API that can still talk directly to the drivers and services. Instead of presenting HTML, or a finished frontend to be delivered directly to the user, these are typically much simpler. They simply generate JSON: serialized data structures built on the existing services. So, a metaservice delivers serialized data to be consumed by the client frontend, typically using a serialization format like JSON. These metaservices have become the building blocks of modern, scalable web architecture.

There are frameworks well suited to quickly generating RESTful applications in every language you can think of. Chapter 10 has a full list of frameworks specifically built for a wide variety of languages. No matter what language you use, you should be able to find an appropriate REST framework.

The one thing all of these frameworks have in common is that they make it easy to develop RESTfully routed URLs and provide structure to the code that responds to each HTTP verb (GET, PUT, POST, DELETE, etc.).

There are many libraries in every programming language built to consume metaservices. You give the library a RESTful URL, and it will model the result for you in your code. This lets you stitch together many metaservices in a lightweight, dynamic backend that can serve the compiled data to the end user. Here is a code example using Ruby’s ActiveResource library that shows an example of how easy these libraries can be to interact with:

class Person < ActiveResource::Base
    self.site = ENV["PEOPLE_REST_URL"] // Best Practice
end

ryan = Person.new(
    :first => 'Ryan',
    :last => 'Daigle'
)

ryan.save                # => true
ryan.id                  # => 2
Person.exists?(ryan.id)  # => true
ryan.exists?             # => true

ryan = Person.find(1)
# Resource holding our newly created Person object

ryan.first = 'Rizzle'
ryan.save                # => true

ryan.destroy             # => true

You can see how powerful REST clients can be. They can be consumed very similarly to core services like MySQL and PostgreSQL, and serve many more purposes as well.

This will be covered in Chapter 6.

Metaservices can be consumed directly in the browser. In fact, you do not need any frameworks at all to process a standard RESTful URL. Any browser-based Ajax call with an exec() function can do the trick:

var url = "http://example.com/users";
var req = new XMLHttpRequest();

req.onreadystatechange = function() {
  if (req.status == 200) {
    var json = req.responseText;

    // this is not secure, only
    // showing this for example
    var object = exec(json);

    // do something with
    // the object...
  }
}

req.open("GET", url, true);
req.send();

This code can be a little tricky and cumbersome, but some really great modern JavaScript frameworks have been developed that you can add to any website that will not only automate the consumption of these metaservices, but also display the data in a structured way. They include:

For a deeper discussion on how to select the proper JavaScript framework for your needs, see Steven Anderson’s blog post, “Rich JavaScript Applications—the Seven Frameworks”.

Impressive technologies like SproutCore and Cappuccino are able to provide building blocks to bind your data against. This is a well thought out and proven method for developing applications in modern desktop environments, incorporating data sources and data bindings.

As our JavaScript frontend client layers get thicker and thicker, we’re starting to see more and more composition of data sources in the frontend. Frontends are being presented through very dynamic, well presented, structured web interfaces.

Tools like SproutCore and Cappuccino provide building blocks, the foundational pieces that are tied together in a very standard way to build modern applications that feel like desktop applications on your web or mobile clients. In fact, SproutCore and Cappuccino are similar to using Apple’s Xcode or Microsoft’s Visual Studio. To a traditional web developer who has never created a desktop or native mobile application before, these tools can feel strange at first. The visual components are more strictly defined for you, and once you bind data sources to them, they seem to magically just work.

One of the benefits of using these technologies is that they are so prescribed, they have such a strong experience tied into them, that some of these clients can actually be compiled into native mobile applications. If you write your application in Cappuccino, for example, there are services like NativeHost that will compile your application without having to change anything to run in a desktop environment as a native app, which leads to a cross-media way of thinking about application development.

These technologies are so rich and becoming so well supported that we are seeing even large companies starting to use them. Apple has used SproutCore to build out its entire iCloud suite of web applications, supporting Mail, Contacts, Calendar, Notes, Reminders, Find My Phone, and iWork. NPR has built a beautiful Cappuccino-based player to stream its radio content. There are many new examples of adoption of these thick client interfaces every day.

This new form of development yields significant benefits in four important areas: agility, time to market, scalability, and interoperability.

One of the most vexing problems for enterprises and governments is how to realize the benefits of utilizing public cloud systems while keeping sensitive data restricted. Using the methods we’ve discussed in this chapter, businesses and governments can get the best of both worlds. They can enjoy the best agility and fastest time to market. They can utilize business-critical IT applications as services that are consumed in public cloud−hosted applications and mobile apps, which are delivered to their employees and customers in a safe and secure manner. This means they can start to experience the benefits that have already been realized by many smaller technology companies.

In addition, with metaservices, there can be independent teams working together in parallel on many different aspects of an application. Thus, tackling the development of large applications becomes a simpler problem of small teams focused on doing one thing very well.

A familiar activity involves taking a structure that has a username and a password, plus a list of friends encapsulating this data; you want to be able to send this data from a server to a client to be consumed by the end user. There are many ways to accomplish tasks like this.

XML is one common method that is prevalent within Java; it’s still a vital tool within many enterprise applications. JSON is a bit newer to the market; it’s a JavaScript representation of objects. JSON’s relationship to JavaScript is key in understanding why this format has taken off.

One of the most common ways that JSON is consumed is through a JavaScript client on the web frontend. Because of that attribute, it is very easy to turn JSON into JavaScript objects through the web client. Since the point of origin of many mobile applications is the Web, these JavaScript representations have transferred with them. They are much easier for humans to read and much less verbose. They also take up less data, another reason these types of objects have proliferated within mobile devices.

XML is very verbose, which can be good when dealing with complicated data. However, it will add significant bulk to your data packets, and in mobile development, where you have limited bandwidth and you have to deal with slow connections, transferring as little data as possible becomes ever more important. This is why many mobile applications have chosen JSON for encoding and transferring data.

For reference, JSON has the following basic data types available:

Native iOS applications in Objective-C can get data quickly and easily from metaservices. There are various ways you can approach this process, from building it yourself to leveraging open source or proprietary frameworks to help you.

The first step to writing the code yourself is leveraging iOS’s asynchronous network operations:

Here is an example of what that Objective-C code might look like in practice:

- (void)load {
  NSURL *myURL = [NSURL
     URLWithString:@"http://example.com/users"];
  NSMutableURLRequest *request = [NSMutableURLRequest
    requestWithURL:myURL
       cachePolicy:NSURLRequestReloadIgnoringLocalCacheData
   timeoutInterval:120];
  [[NSURLConnection alloc] initWithRequest:request
                                  delegate:self];
}

- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
    [mutableData appendData:data];
}

- (void)connection:(NSURLConnection *)connection
  didReceiveResponse:(NSURLResponse *)response {
    mutableData = [[NSMutableData alloc] init];
}

- (void)connection:(NSURLConnection *)connection
  didFailWithError:(NSError *)error {
    [mutableData release];
    [connection release];
    NSLog(@"Unable to fetch data");
}

- (void)connectionDidFinishLoading:
                   (NSURLConnection *)connection
{
    NSLog(@"Succeeded! Received %d bytes of data",
                                    [mutableData length]);
    NSString *jsonResponse = [[[NSString alloc]
                       initWithData: mutableData
                           encoding: NSASCIIStringEncoding]
                    autorelease];
    // Parse the jsonResponse and feed it to the UI
}

As of iOS 5, Apple added native parsing of JSON through the NSJSONSerialization class; however, there are some open source libraries that can parse JSON even faster in iOS, like JSONKit.

Once the data is grabbed and parsed, there are a number of ways to serve that data to the frontend user experience:

Apple’s Core Data framework is Apple’s standard way for iOS apps to persist data on phones. It is used widely for filling the UI components quickly and easily through many parts of the iOS experience.

// User.h
@interface User : NSObject
@property (strong, nonatomic) NSString *name;
@end

// User.m
@implementation User
@synthesize name;
@end

// MasterViewController.m

#import <RestKit/RestKit.h>
#import "User.h"

...

- (void)viewDidLoad
{
    [super viewDidLoad];

    RKURL *baseURL = [RKURL URLWithBaseURLString:@"http://example.com/users"];
    RKObjectManager *objectManager = [RKObjectManager
    objectManagerWithBaseURL:baseURL];
    objectManager.client.baseURL = baseURL;

    RKObjectMapping *userMapping = [RKObjectMapping mappingForClass:[User class]];
    [userMapping mapKeyPathsToAttributes:@"name", @"name", nil];
    [objectManager.mappingProvider setMapping:venueMapping
    forKeyPath:@"response.users"];

    [self sendRequest];
}

Android native applications use Java and can also get data quickly and easily from metaservices. As with iOS, there are various ways you can approach this process, from building it yourself to leveraging open source or proprietary frameworks to help you.

The first step to writing the code yourself is leveraging Android’s asynchronous network operations:

Here is an example of what that Java code might look like in practice:

// executed in a Service via new GetRESTData().execute();
// http://developer.android.com/reference/android/app/Service.html
private class GetRESTData extends AsyncTask <Void, Void, String> {

   @Override
   protected String doInBackground(Void... params) {
     URL url = new URL("http://example.com/users");

     URLConnection urlConnection = url.openConnection();
     InputStream in = new
       BufferedInputStream(urlConnection.getInputStream());
     BufferedReader reader = new
       BufferedReader(new InputStreamReader(in));
     String result, line = reader.readLine();
     result = line;
     while((line = reader.readLine())!=null){
        result += line;
     }
     in.close();

     return result;
   }

   protected void onPostExecute(String restResult) {
     // process the JSON string into a Java object
     // and persist it into a SQLite database
   }
}

Note that you should not implement Android REST methods inside activities. Activities are for user interface and user experience functionality. The code should always start long-running operations from a service; Android services were meant to run this kind of code.

Android has a native parser for JSON through the org.json.JSONObject class; there are also some open source libraries that can parse JSON in Android, like JSONLib, FlexJSON, and Gson.

Once the data is grabbed and parsed, it needs to be persisted immediately. SQLite is your best friend in Android. You should also use a sync adapter to execute regular checks for new data from your REST services. The sync adapter can change your data-grabbing process from a pull into a push architecture, which will save a ton of battery life.

public interface UserResource {
    @Get
    public User retrieve();

    @Put
    public void store(User user);

    @Delete
    public void remove();
}

ClientResource cr = new ClientResource("http://example.com/users/123");
// Get the User object
UserResource resource = cr.wrap(UserResource.class);
User user = resource.retrieve();

As seen in Chapter 5, building metaservices, which can power mobile or web frontends, is easy to do in Platform-as-a-Service. In fact, building applications in PaaS this way from the beginning is actually a best practice. These services have less code, are easier to maintain, and are easier to scale.

When you use a PaaS to build metaservices, deploying large N-tier clustered servers and managing them takes seconds, not weeks or months.

PaaS makes building and running metaservices faster and easier than ever before.

Scaling metaservices in PaaS is easy. If your app is modular and does not require constant disk access, you can very quickly and easily add more instances, which increases the concurrency levels dramatically. As thousands (or hopefully millions) of people start using your mobile applications, adding capacity is no longer a chore but an API call.

Many PaaS providers even have REST APIs, which you can use to automate the process of scaling.

You might only have 1,000 users, but those users might upload 100,000,000 pictures. Your PaaS provider can make it easy to manage and run the proper scalable backend service to handle both kinds of services fast and effectively.

Once you build your metaservices and launch them on a PaaS, they can be accessed through your iOS, Android, or Windows Phone smartphones and tablets. They can even power your web presence. This is a powerful way to maximize the efficiency of the resources you have when building applications.

Working with SQL and PaaS can save an impressive amount of time. By relying on expertise that hopefully has been invested in creating a scalable SQL solution for you, you’ll be able to work faster. But once again, there are several caveats.

You may need to consider the limitations on how many queries you’re allowed. There are many different ways to charge for SQL core services:

These are very different ways to price the service and can lead to drastically different bills depending on your specific use cases.

Your decision will be highly dependent on several factors, given the type of application you are going to build. There are a few things that can change the dynamics when choosing a managed PaaS core service or going on your own.

Within the next 12 months, which of these answers will most likely be true in your case?

If you answered (a) to 5–7 of these questions and (b) for the rest, you are a perfect candidate for most PaaS-managed core SQL services.

If you answered (b) to 3–7 of these questions, you will need to evaluate your PaaS options carefully and do load testing before committing to the PaaS vendor you select.

If you answered (c) to 2–3 of these questions, your best bet is to either run the core SQL service yourself if you are capable of doing so or select a provider that specializes in scaling the SQL service to the levels you need. You can still use PaaS for your application logic, but it is not a good idea to use it for your managed core data service if you are likely to hit these general guidelines.

Some applications will fit the mold and some will not. For example, consider a WordPress database. This can be a highly cacheable application, so you end up not hitting the database with every query. It can be cached within the PaaS application environment easily. It can be highly optimized and relatively inexpensive to run, and doesn’t usually require a lot of data to be stored.

However, when you have a PaaS provider that limits your concurrence on the database, it can be problematic if your blog or website is going to be handling a heavy load. Typically, blogs do not need to handle more than 10 requests a second—even that would be a generous amount of traffic. But there are times when you are going to want to ensure that you can deal with 1,000 requests a second. If your database is designed so that it can only do 10 concurrent requests, that is going to limit the ability to serve 1,000 people. Lots of those people are going to see error pages. The conclusion: knowing those limitations up front is important.

On the other hand, if you are being charged on a per-query basis and there is no limit to concurrence, you need to make sure that you optimize your code to minimize queries, which can get very expensive.

So, while you must keep close track of how you are being charged for your database, the potential benefits—the ability to save time and move quickly—are significant.

NoSQL is a type of key/value or document store database that is gaining popularity and has many forms, including MongoDB, CouchDB, Redis, Cassandra, and Riak. These technologies assist in scaling out in different ways than traditional SQL storage mechanisms.

The advantages of working with NoSQL and PaaS are similar to the ones you experience when working with SQL and PaaS, such as the ability to get started very quickly. You do not need to think about tasks like running your MongoDB service, managing it, or tuning it.

One of the benefits of self-managing NoSQL is that scaling out can be much easier compared to managing a MySQL, PostgreSQL, or traditional SQL database: you just add more virtual machines and tie those into the configuration. Not every PaaS provider allows you to grow quite as easily. It’s a good idea to understand your contingency plan in the event that you need to scale bigger than the NoSQL capacity allowed within your PaaS.

Within the next 12 months, which of these answers is most likely to be true?

If you answered (a) to 3–4 of these questions and (b) for the rest, you are a perfect candidate for most PaaS-managed core SQL services.

If you answered (b) to 2–4 of these questions, you will need to evaluate your PaaS options carefully and do load testing before committing to the PaaS vendor you select.

If you answered (c) to 2–4 of these questions, your best bet is to either run the core NoSQL service yourself if you are capable of doing so or select a provider that specializes in scaling the NoSQL service to the levels you need. You can still use PaaS for your application logic, but it is not a good idea to use it for your managed core data service if you are likely to hit these general guidelines.

Monitoring options in PaaS can vary greatly. Some PaaS providers give you deep insight and have monitoring built in, others require third-party integrations, and yet others provide little to no insight.

Like your email service, monitoring can be provided either by a third party or natively by your PaaS platform. Many times it is a combination of both. There will be a set amount of information that your PaaS platform will give you about your application; the monitoring will show you some statistics, give you some baseline information, and perhaps integrate with third-party monitoring services to give you deeper information. For example, New Relic and AppFirst, which are third-party SaaS services, will give you very detailed information about how well your application is performing and when there are errors, and can even notify you if the application is not working or hits certain limits. These services can sometimes tell you how long it takes for your application to respond to a user and give you averages and historical information.

Monitoring is important for another reason. Traditionally, PaaS has been extremely easy to scale horizontally and sometimes even vertically. The hardest part is knowing when to scale. The vast majority of PaaS services do not have an auto-scaling feature that decides to add capacity to your application for you. But if you have a proactive monitoring service that informs you when you are hitting some limits, or when your application is running slowly, you can take action.

With information from monitoring services, you can set thresholds and even make your own auto-scaling functionality within the PaaS environment. Alternatively, you can simply go into the console and move the slider up and say, “I need more resources right now.”

In any case, detailed information about monitoring is critical and should never be overlooked when running applications in PaaS. Much of the attraction of PaaS is that you don’t have to worry about the operations behind your application or about tuning and configuring a lot of settings. But ultimately you need to be accountable and know how well your application is performing. Monitoring is essential for doing that. It should never be skipped, and it should be included in every application you run in a PaaS environment.

Here is a list of a few popular monitoring services:

Services are the spice of life in applications. They can turn simple applications into interesting ones. They can add value and depth to your application, but every time you add a new service it adds a layer of complication to the running and managing of your application, along with a set of limitations that you should always be aware of.

There are certainly large benefits to services. Every time you are evaluating whether you should build it or run it yourself, you should always think about seeing if a managed service is a better solution for you, because a managed service will likely save you a lot of time and money. But every time you pick a managed service, be aware that it is probably going to be priced in various ways, even if it is the same type of service offered by different providers.

Know how your application works. Use that knowledge to think months or years ahead and evaluate whether a managed service will still be a good fit down the road. This is an exercise that should always be performed.

The responsibility of using managed services comes with a price. The price is paid by planning ahead.

In planning ahead for a PaaS upgrade, you should consider where your data is stored and how you are going to run the database yourself. For example, if your Platform-as-a-Service is hosted on Amazon Web Services in the US East data center, you might want to use virtual machines within that data center and manage MySQL yourself. You’ll have to spin up the virtual machines within AWS, which will give you a low latency between the application and its data storage; in return you will get very high access, high speed, and high performance since they are colocated in the same network facility. It’s difficult, but certainly achievable.

The same thing can be done in other hosting providers. You can find comparable solutions at Rackspace, HP Cloud, and Azure: if your PaaS runs in one of these infrastructures, you can spin up virtual machines within the same infrastructure and enjoy low-latency connections between your application and the data. You will not have to manage the application and the scaling of the application, but you will have to manage the database.

Alternatively, certain IaaS providers can manage your services. Sometimes they will offer even greater levels of control or different feature sets compared to PaaS providers. One example of this is Amazon’s Relational Database Service (RDS). It has a great deal of functionality and can be used as its own managed service outside of any PaaS. So, if you choose one PaaS to run your application, you can choose Amazon RDS on the same infrastructure provider to achieve low latency. Your application can talk to that RDS database directly. If you ever choose to move your application to a different PaaS provider that is also on AWS, you can remain with that same RDS, which could be talking to a completely different PaaS provider. This gives you a little bit of flexibility in where you run your application.

In summary, it’s important to think ahead and have plans on how to approach and get past the scalability limits of managing your data. As long as you have thought through these scenarios, it will be easy to get started with a managed service within the PaaS.

When considering a PaaS for managed services, it’s essential to evaluate the provider’s features and limitations. Here are some questions for you to ask when selecting a PaaS provider:

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:

With these open source PaaS libraries, the first thing any developer wants to do is get a local copy running. You can do this in a few different ways.

Cloud Foundry offers a product called Micro Cloud Foundry that you can use to run your own local cloud. It runs on a Mac, a PC, even on Linux—basically anything that can run VMware Player, Workstation, or Fusion. Micro Cloud Foundry contains all of the independent services, so you can run all of Cloud Foundry on a single virtual machine.

However, it does not have the sophistication of a production-ready Cloud Foundry. For example, Cloud Foundry knows how to make adjustments—like, if you have five applications running on a single machine and that machine dies, as long as there is a slack pool of other virtual machines whose job it is to run applications, Cloud Foundry can redeploy applications automatically onto the available machines.

Vagrant is an open source library that lets you set up customized virtual machines locally, quickly and easily. Red Hat has detailed instructions on how to set up an OpenShift instance, but this can be tedious and difficult to do on your own. An alternative is to leverage technology like Vagrant to do this for you. Others have already done this and open sourced the result.

Setting up local bootstrapped copies of PaaS libraries like Cloudify is even easier; they were built as private only PaaS solutions, which means they were intended to be easy to set up. Cloudify has some great documentation about how to get started.

Here are some resources to guide you:

PaaS libraries still need to be operated and maintained, and many open source PaaS libraries are limited in similar ways. As a developer, running a PaaS library can be hair-raising if you do not know what those limitations are.

One limitation is that a PaaS library usually can’t launch more IaaS servers for you. Even if you have a slack pool of app servers waiting for new code to be deployed, if every one of the slack pool machines dies, Cloud Foundry doesn’t know how to start more servers to add to the slack pool. It does not know how to operate the entire system and it doesn’t know how to monitor and maintain itself. This can be an enormous chore for a small or even a large company trying to run Cloud Foundry.

Monitoring, managing, and maintaining the components of a PaaS library can be a big challenge. But the technology itself represents what the future of PaaS might look like; it can be run in ways that are very distributed, and it can operate in the public and private clouds, even on a laptop. It’s important to understand that PaaS libraries deliver a high degree of flexibility, as long as you know how to harness that flexibility.

One reason that PaaS is so well suited to open source projects is because it handles a significant challenge. If one company was especially good at PHP or Python or Perl, the task of building a PaaS for PHP or Python or Perl alone might be manageable. But the task of writing a PaaS that runs on Python, Perl, PHP, Java, .Net, Node, and every other technology you can think of is a difficult one. Being able to run many different technologies and being able to be very good at those technologies is a major asset of PaaS.

This versatility draws on a key strength of the open source movement. The ability to build on the work of open source collaborators and their contributions to the community is a significant reason why open source works so well with PaaS.

In 2006, on top of virtualization came the next big step into the cloud: the application programming interface (API). APIs added a sophisticated layer of automation, enabling you to control, start, stop, and create new virtual machines through simple and real-time commands. First created by companies such as Amazon with Amazon Web Services, APIs paved the way for Infrastructure-as-a-Service, which heralded a lot of what we now consider cloud standards.

At this point in the history of the cloud, it was so easy to spawn a multitude of virtual machines that managing servers became a headache. With unlimited servers at your fingertips, how do you take care of managing them all? That is where DevOps came into play.

DevOps became a mainstream force around 2010. It arose from the need of developers to do their jobs faster. They were tired of waiting for operations to deploy their code. They were tired of not having tools to easily manage services. They were tired of having to do it all manually. Out of these frustrations, programmers moved into the cloud and became DevOps gurus. They built systems to manage and maintain infrastructure and to interact with servers in a programmatic fashion.

Important DevOps tools like Chef and Puppet were introduced, providing systems to manage thousands of servers, upgrade code, replace code, replace servers, deploy new servers into a template, and make modifications, all of which had been very labor intensive and difficult from a developer’s point of view. We even saw the rise of automated DevOps tools like RightScale and ScaleXtreme.

DevOps offers developers the most control out of all the cloud tools. The trade-off is that you still need to spend time building and managing operations; if things go wrong, you are still the go-to person. And so, DevOps is not the ultimate answer to the hopes of developers. Here’s why.

As a developer, you will most likely spend time writing code that works with Chef and Puppet, while your ultimate goal is probably to spend less time managing operations. If that is your goal, Platform-as-a-Service can handle operational tasks for you today, freeing up even more of your time. With PaaS, you do not have to write the Chef cookbooks or the Puppet scripts to manage servers. You can spend more of your time writing the code that interacts with your users.

DevOps technologies were—and remain—essential for application lifecycle management tools, which we’ll discuss in a moment. Application lifecycle management would not be possible without DevOps, so DevOps is not going to go away. DevOps is a core foundational technology, and there will always be a need for it in a cloud world.

DevOps tools are also a big part of how any Platform-as-a-Service runs under the covers. For platforms such as Heroku, EngineYard, AppEngine, and AppFog, DevOps tools are essential behind-the-scenes tools.

Thanks to DevOps, one can now manage thousands of machines easily, but one still sees the world through the glasses of infrastructure. Applications care more about services (e.g., MySQL and MongoDB) than the details (e.g., what version of libxml is installed across virtual machines). Managing services and applications remains outside the grasp of DevOps and even IaaS. The next layer of cloud technology is application lifecycle management.

App lifecycle management tools are typified by technologies like Cloud Foundry, OpenShift, and Cloudify. They are not yet really PaaS (though they sometimes claim to be), because they still need an operator to run them (hence not really removing the big pain of running operations yourself). However, they do provide a cornerstone to PaaS technology. These tools know how to start, stop, and deploy applications. They often know how to run and manage some of your services, like MySQL, as well.

App lifecycle management tools handle applications holistically, managing applications across many different servers, so an application can run on hundreds or even thousands of them. Traditionally, IaaS and DevOps tools have had trouble thinking in terms of applications—of the needs, resources, and services that span hundreds of servers. App lifecycle management understands applications, treats them from a services point of view, and knows how to manage, scale, and maintain them.

In many cases, you can run app lifecycle management tools on your own laptop. Cloud Foundry has a Micro VM that can do a proof of concept very quickly. OpenShift and Cloudify have similar tools. Taking app lifecycle management to the next level and building out a production-ready version of the same tool can be daunting; it often takes teams of 5–10 operations people and involves managing dozens or hundreds of machines, even for small production installations.

The benefits of app lifecycle management are great, though. Take, for example, a Drupal website that is going to be hit by massive traffic overnight. In this example, you’ll need to go from a single server to 1,000 servers to handle this huge influx of new users.

Before app lifecycle management, you would need to engage a team to manually figure out how to incorporate hundreds of new servers into the process. You would need to deploy the right code and take a very hands-on approach. It required significant human intervention and it needed to scale with human resources.

Even with DevOps, this can be a daunting task. How do you ensure that the servers that Puppet created are all working the way you expect them to? How do you maintain these servers? How can you see in real time how the application loads are affecting each server? These are only some of the shortcomings of DevOps tools.

An app lifecycle management tool such as Cloud Foundry changes all this. You can tell it that your application needs 1,000 more instances, and Cloud Foundry will do all the plumbing. It makes the changes necessary to run those applications across your servers. It greatly simplifies the process.

But there’s a hitch. You still need people watching and monitoring the app lifecycle tool itself. You don’t get rid of operations; you are simply shifting your attention from an individual application to the running of your lifecycle tool.

In our example, prior to the advent of app lifecycle management tools, when you needed to scale up the number of servers the development team would interact directly with the operations team to ensure success. Sometimes the same team, or even the same person, would be responsible for both, but the roles would be separate. The operations people would be in charge of manually figuring out how to hook all the servers together.

Now an app lifecycle management tool can do all that for you. It knows about the application, it knows how to execute the code, it knows how to add the servers and instances to the application. But the app lifecycle management tool itself needs operations. People are required to operate the tool. The difference is that it is an abstract tool into which you can put anything, any application. As a developer, it does not matter if the operations people running the tool are in-house and sitting right next to you, or if they are hundreds of miles away in a place like Portland, Oregon.

Thus we enter the realm of NoOps and Platform-as-a-Service.

The cloud has been instrumental in moving us away from a paradigm that involved significant expenses, not only in terms of buying servers, but also of running those systems, with all the personnel involved.

In the past, any startup would have had a similar experience. You would need to hire people to handle your core competency, and then spend millions of dollars to handle all of the data center and management pieces.

The central concept and the main benefit of the cloud, beginning with Infrastructure-as-a-Service, is to reduce the cost of buying data centers. You do not need to buy data centers anymore. But you still need operations people to run the servers that you are now renting.

NoOps fully removes the need for operations and development people to work hand in hand. Operational needs are still being fulfilled, but they are being accomplished independently of any individual application. NoOps refers to the idea of outsourcing operations roles and providing a way for developers to get their jobs done faster. Developers don’t have to wait for another team to deploy their code, and the systems that automate those processes for developers operate seamlessly.

NoOps is a controversial term, because some people read it as “No Ops,” suggesting that operations are no longer relevant. On the contrary, however, operations are more relevant and important today than ever. The intent behind the term NoOps is to highlight that from the developer’s perspective, you no longer interact as directly with the operating guts of running the application. It’s the same as how “NoSQL” doesn’t mean that SQL is no longer relevant, but rather that there is another way of approaching data storage and retrieval where a developer doesn’t interact with SQL.

Platform-as-a-Service outsources operations. It is not getting rid of operations, but decoupling them from development, so that you can get your job as a developer done easier and faster.

The original iterations of managed Platform-as-a-Service, which included systems such as Force.com and the Google App Engine, were very constrained. They required you to develop your code against their APIs, so that they only worked within their contexts. Their Platform-as-a-Service features were accessed only when you tied them directly to their systems. They promised that you could access special data and that you could take advantage of features like auto-scaling—but doing so could be difficult.

There were two downsides to early PaaS. The first was that you needed to learn a new set of APIs in order to program against them, so there was a learning curve just to get acclimated. The second downside involved portability. If you were to program against the Google App Engine, for example, it would be difficult to move your application and try it out on a different platform. There were upsides as well, though such as the extractive system data and the services that they provided.

Then new players began to arrive on the scene, and with their arrival came a movement toward platforms like Heroku and EngineYard. They broke the mold of saying that you needed to code against APIs. They said, in effect, “We are going to take your application as is. You don’t have to make any changes that work against proprietary APIs. You can run this code just as easily on your own hardware as you could on our systems, and you aren’t going to have to change your code to make that happen.” For developers, this was a revolutionary moment in the history of the cloud.

Initially, in order to provide their innovative services, these PaaS providers limited the language technology. Early users of Heroku and EngineYard, for example, could only pick Ruby. So while the upside was that you didn’t have to program against APIs, the downside was a restriction on what languages you could pick.

PaaS quickly evolved with the help of next-generation PaaS companies like AppFog and dotCloud, which were no longer tied to a single language. Today, many larger PaaS companies, and even older ones like Heroku and EngineYard, support many programming languages. This represents a significant transition from restrictive platforms to those that are more open.

Some PaaS companies are still tied to single programming languages, however, claiming that there is more benefit in having deeper domain knowledge for a single language.

A popular trend in PaaS with companies like AppFog is multi-infrastructure PaaS. This allows you to run apps in many different infrastructures at the same time, even operated by completely different companies. For the first time in history, you can easily run your app on Amazon Web Services and Rackspace at the same time. If Amazon Web Services goes down, Rackspace can act as a disaster recovery program that keeps applications up and running on a separate system. This has been a dream for most programmers that PaaS can uniquely fulfill.

Traditionally, shared web hosting has been the easiest way for web developers to get started. Examples include GoDaddy, Yahoo!, Comcast, and many ISPs to this day.

The central concept revolves around an FTP account. You get credentials for your FTP application server. That server hosts thousands, sometimes tens of thousands, of websites. Usually the server is large, but it can very quickly get bogged down. If one or two of those websites start to get popular, even with a powerful server, it might be enough to soak up all of the resources. The result: tens of thousands of websites could become very slow or might not even respond.

The upside to shared hosting is price. Shared hosting is cheap, sometimes even free. Also, it’s a hands-free account. You don’t have to do security patches. You don’t have to manage the software. You don’t have to know anything about how the software is written. All you need to know is how to write some HTML code; you hand it over, and everything else is handled for you. But because it’s so inexpensive, your provider can’t afford to handle things well at all times. It can’t scale. It can’t go beyond its capabilities, but it usually does work for simple situations.

While it’s an economy of scale for the hosting provider, it’s not a reliable system for putting up a storefront, a complicated website, or even a site that you want your clients to be able to reliably visit to get your contact information.

Another pitfall of shared hosting is security. Your code can be on the same system as over 10,000 other pieces of code. Keep in mind that a normal website can easily get hundreds of security attacks every day. Multiply that by tens of thousands of pieces of code that aren’t yours, and you can see the risks involved in running a production site on a shared system.

Despite its disadvantages, developers still find shared web hosting useful to host personal web pages, to put up simple ideas, and to try out new ideas. It’s useful for development when you’re not sure if you want to invest the kind of money it would take to run your own servers, and when you don’t need to scale yet. The trouble is that when you do need to scale, it can become a painful process to move from a shared to a dedicated system.

Developers, especially web developers, have traditionally used shared web hosting to get started because it’s cheap and easy. When they look to graduate beyond that, they often turn to dedicated web hosting. This could be as simple as hosting your own server at home using your Internet connection. But there are several other options that provide varying degrees of service and scalability.

Here is a generalized list of dedicated hosting options, sorted by decreasing order of control (and typically, performance):

Let’s now take a look at each of these in more depth.

Let’s return briefly to the example in which you’ve made a TV appearance and your website suddenly experiences a spike in traffic. The problem with dedicated hosting is moving from a single server to 100 servers. It’s a potential nightmare because you’ll need to hire a team of people to help manage those 100 servers. With Platform-as-a-Service, moving from a single server behind your app to 100 servers can take seconds. All you do is move a slider from the left to the right.

As you’ll see, Platform-as-a-Service can provide the power, speed, reliability, and scalability that you wanted with dedicated hosting, and yet be as simple to use as shared hosting. You might go so far as to say that Platform-as-a-Service is the developer’s Holy Grail of scalability and reliability.

This enhanced reliability comes courtesy of one of the key tenets of scalable architecture in the modern web development era: N-tier architecture.

With N-tier application architecture, you don’t put your app logic on the same servers as your database servers or caching servers or load balancers. You have different layers of servers that handle different aspects of the application independently.

You do this for horizontal scalability, so that you can add more capacity by simply adding more of a certain kind of service in parallel and then configuring the software to distribute the load. So now you have gone from having a single server to at least three or four layers of servers, or tiers. Within each of those tiers, you’re replicating for failover and high availability.

This architecture is what you usually end up piecing together when you are using dedicated servers. But every Platform-as-a-Service has N-tier built into it from the start. It’s packaged into the offerings as a de facto standard from the ground up, blending a best-of-breed approach to dedicated web hosting with a simple deployment strategy for deploying your code.

There are a number of different approaches to Platform-as-a-Service. Some vendors focus on a single programming language, meaning you’ll be restricted to working only with Java, or PHP, or Python, or Node.js.

Other PaaS vendors let you choose from a variety of different languages. On the one hand, a multilanguage provider has the benefit of being a one-stop shop. On the other hand, you will sometimes have a more highly tuned environment with a single-language PaaS provider. In general, the most widely used PaaS systems tend to be multilanguage.

One should also be aware of vendor lock-in issues. Some Platform-as-a-Service providers require you to program against their APIs, and once you have tied your code to their APIs it can be very difficult to move it anywhere else. If this is simply at the level of database services, your code can still remain quite portable. However, if there are custom libraries and custom code APIs, it can be problematic and sometimes impossible to compartmentalize these integration points to the point that you can quickly move your app to another PaaS provider.

Almost every Platform-as-a-Service provider lets you try it for free. Usually you can set up at least a few applications for free. This is a useful way for developers to get started and familiarize themselves with Platform-as-a-Service. Once you want to deploy a production application, there are many options, with pricing models that vary depending on which platform you choose. Rates for production-ready apps in PaaS can run from as little as $20 per month to thousands of dollars per month.

For example, with one leading PaaS service you can deploy applications for free, but when you want to scale those applications and add more instances behind them (making them production-ready), you start paying on a per-instance basis. Those instances can each cost $30–40 a month. If you want background processing, that is another $30–40 a month. So, with some Platform-as-a-Service providers, the price can grow quickly as your application needs to scale.

Other platforms have different pricing models. Some charge based on how many virtual machines you use. Others charge on a resource consumption model. With AppFog, you have a set amount of RAM; within that amount of RAM you can deploy as many applications, or as many instances behind those applications, as you want. The monthly fee is based on how much RAM you need, not how you use it. dotCloud has a similar model.

Several questions arise. Is Platform-as-a-Service a new concept? Or is it simply an extension of Infrastructure-as-a-Service? Is the “big idea” the concept of APIs with provisioning servers? Or is Platform-as-a-Service a new and separate kind of idea?

There is a strong case to be made that IaaS and PaaS are very different from one another and that Platform-as-a-Service is not a feature of Infrastructure-as-a-Service. Fundamentally, it comes down to what is important to each service.

What are the central concepts behind IaaS and PaaS? Another way to ask this question is this: what are their atomic units?

Let’s return to an earlier example: when you want to sequence DNA, you want to do it as quickly as possible, so you use low-level languages like C and Assembly to get as much performance as you can.

In PaaS, the tendency is more toward building out web applications, and latency is not as critically important. The quality that is valued more highly for the types of applications that run on PaaS is the ability to create things quickly and connect them quickly. The higher-level languages—the dynamic scripting languages like Ruby, PHP, Python, and Node.js—are better suited to this than some of the lower-level languages.

Thus, the tendency within PaaS is toward languages that a few decades ago were thought of merely as scripting languages. Now they have become powerful tools for businesses to power their applications. Facebook, one of the biggest sites on the Internet, uses PHP to power its systems. Yahoo! also used PHP. Twitter was initially built on Ruby. LinkedIn used Ruby, then changed to Node.js. So you can see a proliferation of web content being built on dynamic languages.

The new generation of languages is also breeding a new style of development: quick iterations on smaller sections of code, faster production of applications that are smaller and at scale. The applications that are generally being built are API-type applications. Examples of these kinds of applications (on a larger scale) include Gmail, Twitter, and MobileMe, which use APIs to communicate with their web frontends. Those same APIs can be used in the context of mobile applications, making sure that a mobile app can register users and that users can communicate with each other. This all must happen through APIs and backend services.

Managing the backend for a mobile application can easily take more time than building it in the first place, which is why Platform-as-a-Service is such a vital tool. If you have a mobile app that gets on the Apple App Store’s top 10 list, you need to make sure that your backend application can scale with the needs of your user growth and can handle millions of users accessing it from their phones every minute. Traditionally, this has taken armies of IT and ops people. Platform-as-a-Service gives you the ability to manage hundreds or even thousands of backends simply with a slider, rather than with a team of people.

In case this remains unclear, it should be stated that PaaS puts control and power into the hands of the developer. At long last, that pager has been rendered unnecessary. PaaS won’t eliminate code bugs, obviously, but hardware and infrastructure failure should not be concerns for developers anymore.

Launched in 2008, Force.com, Salesforce’s developer platform, allows you to build applications that extend the functionality of Salesforce, a very popular SaaS customer relationship management (CRM) sales tool. This was one of the first incarnations of PaaS as we know it today. Force.com inspired a generation of applications, and thousands of developers built new ways to access and analyze Salesforce’s rich dataset.

The Force.com Platform-as-a-Service provides Web Service APIs and toolkits, a user interface for building apps, a database for persistent data, and basic website hosting functionality. More recently, it has added mobile capabilities that make it easy to create mobile applications using the Force.com PaaS as well.

The downside to using Force.com is that you cannot build general-purpose applications using any programming language you want. Application logic is built and run using Apex, a strongly typed, object-oriented, Java-like language that runs on Force.com. The upside is that getting started creating new applications is simple and fast using the web-based interface. You choose the data types you want to collect, creating data structures that can autogenerate web and mobile interfaces for collecting that data.

On top of data input options, you can also add formulas, approval processes, email sending, and tests very quickly and easily. The Force.com PaaS even has its own Force.com IDE for developing, testing, and deploying applications quickly and easily.

When you work within the constraints of the Force.com platform, you do not have to worry about scaling or managing your application; Salesforce does that for you. This idea is the foundation from which PaaS has gained popularity.

As the Force.com platform has matured, more and more services have been added: one example is Database.com, a database service with custom APIs and data feeds for building applications used by around 100,000 businesses worldwide.

Google App Engine (GAE), also launched in 2008, was one of the very earliest forms of PaaS. Its promise was that you could tap into the vast power of Google, draw on Google’s computing resources, and use Google’s infrastructure and expertise in running and operating machines. The caveat was that your application would have to adhere to Google’s standards. Google has built not only an operations team, but also a set of tools and systems that work in a specific way—and they work that way in order to scale to “Google scale.”

What kind of scale are we talking about? A very large one in which you are dealing with many, many thousands of machines all working together to solve a single problem. When you are dealing with a scale as large as Google’s, the tools are very prescriptive; they need to be in order to process volumes of data that are so immense. Google literally processes the entire Internet. One of the central ideas of GAE is that if you adhere to its standards, you too could have that power inside your application, and only pay for the processing power that you use.

Here it becomes evident why GAE is non-portable. It has an existing infrastructure that you are allowed to tap into only if you play by Google’s set of rules. On the one hand, you have to write your code around Google’s expectations. On the other hand, if you do so, you gain the benefits of being able to run at Google scale.

Many PaaS platforms have limitations of various types. When you are dealing with a non-portable PaaS such as GAE, those limitations can be strict. You have to adhere very closely to them in order to take advantage of GAE’s features.

With GAE, there are limitations on access to the filesystem, on access to memory, on the amount of memory you can tap into, and on how long your processes can run.

These limitations can force a developer to think in different ways. For example, let’s suppose you have a website that needs to compile a large list of information and compute data for each item on that list. In a traditional hosting environment, when a user makes a request to such a site, delivering results can take a significant amount of time. All of the processing must happen before the response goes back to the user. And, depending on the complexity of this processing, it could easily take seconds.

This is where we encounter another of the limitations within GAE: there is a set amount of time within which your application must respond. If it doesn’t respond fast enough, GAE will kill the process.

But this can actually be a positive factor in the development of the user experience if the application is designed to know that it cannot live that long. It forces the developer to ask himself, “Instead of simply doing it the way I always have done it, how does Google want me to do it?” So, instead of compiling the list every time a user hits the website, you could create a cache and serve up the list from the cache. The cache could serve very quickly and provide a better user experience. In order to compile that cache in the background, you would have to use a different set of Google tools to do those calculations in a more scalable fashion, and then put those into the caching database.

GAE has a large following and a large developer mindshare behind it. Its promise—taking advantage of the power of Google—has helped make it a leader in the non-portable PaaS category.

Microsoft also thought very hard about how to build a Platform-as-a-Service. Its expertise with the .NET Framework led the company to consider the best way to accomplish this around .NET. In 2008, Microsoft launched Windows Azure.

The company set out to create a set of libraries. These were designed in such a way that if a developer were to incorporate them into her system, Azure would take advantage of those libraries in order to scale the system. Microsoft also provides standard services that can scale independently.

With Windows Azure, you have basic systems, like a message bus and queuing systems, and a variety of different options based on the specific needs of your application. These provide patterns for developers to build distributed applications that can interact with each other over networks. If you incorporate through the libraries the technologies and services that Microsoft has built, you can take advantage of the Azure system and be able to scale your application fairly quickly and easily.

Recently, Microsoft has taken steps to move away from a non-portable Azure system, decoupling some of the requirements that tie developers into required services. This has allowed expansion into different languages and technologies, taking Azure from a non-portable PaaS more into the portable realm, which requires no changes to the code in order for it to run. So, Azure is actually a system that started out as non-portable and has been moving slowly toward portability. In fact, Microsoft recently released a very portable version of its Platform-as-a-Service.

Although all of these PaaS options started out as non-portable, many of them are adding functionality that makes them more and more portable every day. GAE has released PHP support that requires fewer and fewer changes to work out of the box. Windows Azure has also released PHP support, and developers can do more without programming against the Microsoft APIs than ever before.

Heroku, founded in 2007, was one of the earliest companies offering a portable Platform-as-a-Service. Heroku saw what Force.com and Google App Engine were doing and concluded that forcing developers to write their code against its APIs didn’t make as much sense as just letting any code be written.

Heroku started out as a Ruby-only independent startup company, allowing Ruby code to be deployed in any form. It has since been acquired by Salesforce.com and has expanded its language offerings. However, Heroku still doesn’t let you write to the filesystem. The rationale is that this makes it easier to create more instances of your app (Heroku calls them “dynos”). If you were to upload or change a piece of code, it would only end up running on a single dyno, and if your application runs on 100 dynos, the uploaded file would not be propagated, leaving an inconsistent dyno. In order to prevent that problem, Heroku simply says that you cannot write to the filesystem (except for an ephemeral temporary directory).

As with Google App Engine, there is also a certain amount of time (although it’s more generous with Heroku) that an application can survive for before it is timed out. But there are also tasks that can run in the background and do some work that is asynchronous. These ideas were pioneered by Heroku and set some of the early standards for what can be done with portable Platform-as-a-Service.

A further comparison of Heroku to Google App Engine illustrates some of the key differences between portable and non-portable PaaS.

With Google App Engine, you have to be very strict about the code you are writing, making sure that it adheres specifically to Google’s APIs. With Heroku, the code you write—whether it is on a shared or dedicated host—is the same as it is on Heroku. The difference in portability has to do with writing your code against the provider’s system versus writing it in a generic way. The reason it becomes portable is that you can take that same code from Heroku and run it on your own systems without having to make major modifications to it.

One of Heroku’s other innovations revolves around deploying code. The early PaaS offerings, like Google App Engine, had programs through which you would deploy your code. Heroku took a more general approach and created a git-based deployment system (git is a source-controlled management tool that lets you keep revisions of your software over time, like CVS and other source-control tools).

At Heroku, when you commit your code into the git source control, pushing the code into Heroku triggers a deployment. It’s a very quick and easy way to allow developers to deploy their code, unlike trigger shell hosting systems that generally use FTP. With FTP, you have to look for files that have changed and make sure you upload them and sync them. But git will track the file changes over time and keep a history of those changes so you don’t have to go hunting for files that have changed. It identifies them and sends those files to the platform automatically.

Built by VMware, Cloud Foundry is a generational new technology that is centered around PaaS. A more recent creation than either Google App Engine or Heroku, it comprises a set of programs and services that let you run your own Platform-as-a-Service. It is open source licensed (Apache 2) and can even be run on your laptop.

With Cloud Foundry, you have access to a set of packages and programs that allow you to interact and deploy code with the same feel as PaaS. It will manage your code and let you scale it up and down in the ways you are used to with a Platform-as-a-Service.

Because it is an open source program, it is significantly different from Heroku, Google App Engine, or Windows Azure. Each of those is a hosted managed service: you do not get to look at the source code, nor do you get to modify those services. Essentially, they are take-it-or-leave-it situations, black boxes into which you enter your code, which is then deployed.

Cloud Foundry has many of the features of PaaS, but it is not a managed service. Like Apache, it’s a technology that you have to run yourself. However, it is a complex distributed system and is quite a bit harder to run than a typical system such as Apache.

It is not a system that you can sign up for publicly. If you want to sign up, you have to look for a public provider of Cloud Foundry. Their numbers are growing: AppFog is one, and VMware offers it as a hosted service so you can try it.

In contrast to Heroku, instead of using a git-deploy mechanism, Cloud Foundry created a REST API, a new way to think about deploying code. It uses a Ruby-based command line tool to deploy code. Because it is a REST API, it gives you the flexibility to make your own decisions about whether you want git integration, CVS, Subversion, Darcs, Mercurial, Team Foundation, or anything else. If you want a different kind of version control for your code, it doesn’t prescribe one for you and lets you use whichever one you want.

Cloud Foundry also made some other innovative decisions around how to support third-party services. With Heroku and other Platform-as-a-Service technologies, one of the quick benefits is the ability to provision services and have them tie into your application. Traditionally, the way that has happened has been by setting environmental values that are passed along to your application through the runtime. They can be read into the application to get the credentials for your database. Cloud Foundry supports a very similar mechanism, but it has wrapped the idea of services—like MySQL, Postgres, and Redis—into an abstraction that lets you bind services to and unbind them from applications; it keeps an environmental variable array available so that you can iterate through them programmatically.

Cloud Foundry also lets you bind a single data source to multiple applications, which is handy when you need to debug an application and determine its state—either in production data or as an audit system. You can bind your data source simultaneously to various different applications.

One of Heroku’s innovations is centered on a third-party add-on marketplace. Via this marketplace, Heroku can provision other cloud tools and, using the environmental variables, pass along the credentials for those tools to your application. Some PaaS platforms, like AppFog, have incorporated a similar idea, but Cloud Foundry does not currently have third-party integration built in.

Service binding is one of the few aspects within a portable Platform-as-a-Service that does actually require a difference in code. When you are trying to move an application from one Platform-as-a-Service to another, generally the part that will result in a difference is how it connects to the database or data sources. Often there are dissimilarities that do require some code—usually a small amount—to be rewritten.

CloudFoundry.org pushed the boundaries of Platform-as-a-Service by providing an open source tool set that any developer could use. It also pushed into new territory because it was not a managed Platform-as-a-Service. From the developer’s point of view this meant that before you could use Cloud Foundry, you would have to set it up yourself and then run it. If you were going to use it in production, you would have to set it up and run it in production, which, while offering a great amount of flexibility, cuts back on the ease of use typically associated with PaaS.

AppFog is a Platform-as-a-Service that is managed and maintained, and it incorporates Cloud Foundry technology. AppFog started as an independent startup and was acquired by CenturyLink in 2013.

One of the other innovations of Heroku is that it was entirely built on Amazon Web Services, and to this day it continues to run on AWS. This is very different from earlier PaaS providers such as Force.com, Google App Engine, and Azure. Each of these was built on top of its own platforms and infrastructures. Cloud Foundry has two components: the open source library called CloudFoundry.org and a proprietary hosted managed platform called CloudFoundry.com, which uses CloudFoundry.org code.

AppFog is a company that also uses CloudFoundry.org code and runs it on multiple infrastructures and public cloud systems. So, while it does run on Amazon Web Services, it is also compatible with OpenStack platforms like Rackspace, HP Cloud, and others. It can even run on private cloud instances of OpenStack and vSphere.

From a developer’s point of view, AppFog has many of the features of CloudFoundry.org that you’d find out of the box. But it runs on many infrastructures, letting you choose them and giving you the portability of those infrastructures, as well as the code. Additionally, AppFog has taken the ideas of other platforms, like integration with third-party cloud services, and incorporated those into its platform. The result: you can sign up and run your applications in any cloud infrastructure that you want, using a technology that you can run yourself, giving you the benefits you’ll find in other systems (like Heroku) that incorporate third-party add-ons.

There are other platforms that focus specifically on the infrastructure behind the PaaS and spend less time on the user experience. dotCloud is an example of a Platform-as-a-Service that innovated by being the first to support multiple languages and technologies, and it has popularized the idea of Linux containers with an open source project called Docker.

When dotCloud was released, Heroku had been focusing only on Ruby, Google App Engine only on Python, and Azure only on .NET. dotCloud came along and offered support for Python, Java, Ruby, and other technologies.

This popular Platform-as-a-Service has focused on creating a system that works though the command line, similar to Cloud Foundry. It has a Unix command line and an API to interact with that command line, enabling you to deploy your applications in multiple languages.

One of the differences between Cloud Foundry and dotCloud is how they approach language support. With Cloud Foundry, the entire system is an open source tool, which means that you can go in and change the way that applications are run and managed; management is tightly coupled to the Cloud Foundry tool set. dotCloud has abstracted the way that applications are run; you can manage the way they are run within the specifications while you deploy your application.

CloudBees is a Platform-as-a-Service that is focused specifically on Java. It has been built around Java tool sets and incorporates common tools used within Java platforms.

One aspect that separates CloudBees from other platforms is its integration with continuous integration tools such as Jenkins. In fact, CloudBees has hired some of the people that maintain Jenkins and has become a leader in the continuous integration space. This has given Platform-as-a-Service a new twist because it allows for systems and extends the broader view of PaaS. With other platforms, the idea is to take your code and deploy it into production; CloudBees incorporates more development tools to extend the purview of what it provides.

Instead of simply taking code and putting it into production, CloudBees provides a system that lets you test that code in a continuous manner, making sure that it works before it goes into production. It provides a longer pipeline before your code is deployed and extends some of the functionality for how a developer can work with her Platform-as-a-Service. To date, however, CloudBees still only supports Java and Java-enabled applications. So, while it has broadened what can be accomplished with a Platform-as-a-Service, CloudBees is still limited to just one technology.

Although historically there have been many different types of Platform-as-a-Service technologies, with more being born every day, there is the possibility for an emerging standard to appear around Cloud Foundry or OpenShift, a few of the open source options for PaaS.

There are several compelling reasons for this. The fact that you can run these technologies from your laptop is very compelling for developers trying to incorporate PaaS into their daily workflow. The other big plus for open source communities around PaaS is the fact that you can theoretically have choice between various providers with compatible PaaS options, or even run it yourself in production. In contrast, unless Heroku open sources its technology stack, you are tied to Heroku’s choice of infrastructure provider.

Taken together, these assets of open source PaaS offer an opportunity to create a standard around their APIs without the ability to lock anybody into a specific infrastructure or service provider. It also acts as an emerging standard for how to deploy applications in a standard way across infrastructures, both public and private.

We have already seen the start of using the Cloud Foundry API as a standard. AppFog uses it to deploy applications across Amazon Web Services, Rackspace, HP Cloud, and Windows Azure, which illustrates that one standard API can be used across different backends. The way that the developer interacts with these systems is though the Cloud Foundry API, decoupling the infrastructure implementation underneath from the API language that the developer uses to speak to it.

More and more PaaS technology is being open sourced every day. Cloud Foundry was one of the early leaders to do so, but Red Hat later open sourced OpenShift, GigaSpaces has an open source Cloudify offering, and even dotCloud has open sourced large chunks of its PaaS technology stack.

As you can see, there are a variety of PaaS providers out there, built for different needs and with different ideas in mind. When thinking about legacy applications and moving them to the cloud, it’s a good idea to understand the limitations of the platforms with respect to the needs of your applications. In the next chapter, we’ll take a deeper look at moving legacy apps to PaaS and provide solutions for some of the challenges you might encounter.

When working with IaaS, one has to assume that any server could go down at any minute, as they often do. PaaS offerings, which are typically built on IaaS, have usually thought out some of these potential problems for you. Building out N-tier application logic can be hard, and that is why PaaS can be so valuable; N-tier is built into PaaS from the start.

With PaaS, you don’t have to figure out how to configure Apache on 20 different servers; you don’t have to figure out how to load balance across those servers; you don’t have to worry about MySQL slaves and master-master replication. Nor do you need to be concerned about redundancy, heartbeats, and failovers, as you would with IaaS.

However, with PaaS, you still have to write your code with the assumption that any individual instance of your app may go down at any moment. That forces you to think about building applications in a way that isn’t consistent with some of the traditional methods of web development, especially for legacy applications. You will also need to take into consideration frameworks and content management systems (WordPress, Drupal, Joomla!) that haven’t yet gotten up to speed with this new way of thinking and haven’t yet incorporated ways to manage multi-instance applications.

We will cover specific examples of how to address these problems later in this chapter.

You have to make those changes yourself, and you have to start thinking not only about how your application will act if a few or even many of your instances go down, but also about how your application will act if the filesystem is not consistent across different instances.

Here are some common questions you will need to think about for legacy applications as related to the hard drive:

Another consideration when moving to PaaS is long-running processes. In traditional development methodology, there has rarely been a problem with long-running processes operating sequentially. Your application typically will just take longer to load, using a large amount of processing power up front, but this can be hidden behind the scenes with Ajax or some other frontend gimmicks. However, when you utilize PaaS, you have to think about long-running processes differently. In PaaS, long-running processes should be processed independently and are asynchronous from your main application logic. In fact, some PaaS providers enforce this by killing your main application if it runs for too long. Not all legacy applications were created to work that way.

These are just a few of the ways in which traditional development paradigms have evolved and how cloud paradigms are much different than the original ones. Now let’s put those ideas into specific contexts.

There are two essential kinds of storage for assets: blob (binary large object) storage, also known as object storage, and file storage. File storage is the familiar kind of storage system used in traditional development. Blob storage works differently. Blobs are more like a key/value store for files, and are accessed through APIs like Amazon S3, Windows Azure Blob Storage, Google Cloud Storage, Rackspace Cloud Files, or OpenStack Swift.

When a user uploads assets to your application, a temporary file is usually created and moved to a more permanent location in the filesystem. When using blob storage, instead of moving files to a folder, you upload the asset to its final location (usually through a REST API) and are given a unique URL to reference the asset from. Once it’s uploaded into the object storage mechanism, the API will give back the URL for that asset, at which point you can store the URL. Instead of storing the object on the disk, you now have a URL that you can reference; it’s been uploaded into a persistent storage mechanism.

One of the benefits of using an object storage system is that all those files that were uploaded are automatically replicated on many different servers (up to seven or eight different copies will exist in many different parts of the world). It’s very difficult to lose data and it’s much more persistent; the content is much less likely to suffer damage based on any disk failure. You don’t have to worry about backups as acutely as you would if your data were uploaded to your local disk.

There are even more added benefits depending on which object storage you use. Content delivery networks (CDNs) can speed up the delivery of your assets so that not only are they hosted in many different locations, but also, depending on where in the world you are, they can be served to you from the one that’s closest to you. This can make the whole experience of consuming your assets and downloading the web pages feel a lot faster.

Because of the redundancy and CDN considerations, blob storage is a good idea in general, but it also has the added benefit of providing more speed, reliability, and robustness to your website. And it’s not too difficult to implement. As you’ll see in these code examples, the amount of effort that’s required up front to deal with asset hosting is more than worth the investment in terms of what you get out of it.

Amazon has libraries for using S3 in Ruby, Java, Python, .NET, and mobile phones. Here is an example of how easy S3 is to integrate with a PHP application. This code will not work out of the box because it only contains the relevant snippets for understanding the flow of code. To get code that is fully ready to go, you will need to go to Amazon’s Sample Code & Libraries page, which has more detailed instructions for how to use the code. However, for the purposes of illustration, once the library is incorporated into your application it is not difficult to use:

<?php
// S3.php is available from Amazon's AWS website
if (!class_exists('S3')) require_once('S3.php');

// Amazon gives you credentials if registered for S3
// Best practice is to make these ENV vars in a PaaS
$s3 = new S3(
    getenv("AWS_ACCESS_KEY"),
    getenv("AWS_SECRET_KEY")
);

// A "bucket" is analogous to the name of a folder
// It is a way to collect similar things together
$bucket = "MyPaaSAppBucket";

// Create the bucket
$s3->putBucket($bucket, S3::ACL_PUBLIC_READ);

// Assuming the file is POST'ed as a form element
// called "file", <input type="file" name="file" />

// Name the uploaded file. Bad idea to pass the name
// like this without any validation.
$file_name = $_FILES['file']['name'];

// Upload the file
$s3->putObjectFile(
    $_FILES['file']['tmp_name'],
    $bucket,
    $file_name,
    S3::ACL_PUBLIC_READ
);

$url = 'http://'.$bucket.'.s3.amazonaws.com/'.$file_name;

Like Amazon, Microsoft has libraries for using its Blob service in Ruby, Java, .NET, Python, PHP, and mobile phones. Here is an example of how easy Azure Blob is to integrate with a Node.js application. Again, this code will not work out of the box; you will need to go to Microsoft Azure’s website for the code you need and more detailed instructions for how to use it. However, for illustration purposes, once the library is incorporated into your application it is not difficult to use:

// Azure in Node is available from npm install azure
var azure = require('azure');

// Azure gives you credentials if registered for blob
// Best practice is to make these ENV vars in a PaaS
// They will be called AZURE_STORAGE_ACCOUNT and
// AZURE_STORAGE_ACCESS_KEY

// Create a service and container to gather assets
var containerName = "myPaaSContainer";
var blobService = azure.createBlobService();
var container = blobService.createContainerIfNotExists(
    containerName,
    function(error){
        if(!error){
            // Container exists and is private
        }
    }
);

// The name of the uploaded object
var blobName = "myimage";

// The file name, possibly the uploaded temp file
var fileName = "/path/to/myimage.jpeg";

var blob = blobService.createBlockBlobFromFile(
    containerName,
    blobName,
    fileName,
        function(error){
          if(!error){
              // File has been uploaded
          }
    }
);

var url =
 "http://"  + AZURE_STORAGE_ACCOUNT + ".blob.core.windows.net/" + 
      containerName + "/" + blobName;

When integrating any blob functionality into your application, you will typically be doing various functions repeatedly, like uploading files and returning their corresponding URLs for storage in your database. To achieve maximum portability, it generally makes sense to add a layer of abstraction around this often-used code. That way, if you want to use a different object storage provider in the future, you can change your code mainly in one place rather than many.

You may organize these functions in a class if you are using an object-oriented language, or you may simply have some basic functions accessed globally.

The simple example class that follows is written in object-oriented Ruby. It contains some basic logic for working with Rackspace Cloud Files, but it could easily be ported to S3, Azure Blob, or any other object storage without affecting code that depends on it.

There are some libraries, such as Fog, that have this logic already encapsulated in them:

// Usage: o = ObjectStorage.new(container_name)
//        o.upload(file, blob_name)
//        return o.url
class ObjectStorage
    def initialize(name)
        @@connection ||= CloudFiles::Connection.new(
            :username => ENV["USERNAME"],
            :api_key => ENV["API_KEY"]
        )
        @container = @@connection.container(name)
    end

    def upload(file, blob_name)
        @object = @container.create_object(blob_name, false)
        @object.write(file)
    end

    def url
        @object.public_url
    end
end

When you’re dealing with a content management system (CMS), the process can be different. Systems like WordPress, Drupal, and Joomla! have plug-ins. Instead of rewriting code, you can install a plug-in, which may directly tie into blob services like S3. The plug-in upload mechanism stores the files directly into object storage and gives you back a URL. This improves the speed of the load time for your blog or CMS. Even better, it gives you a more scalable blog to which you can add more instances. When you load balance it to an instance that doesn’t have the uploaded content, you’ll never see the nefarious Error 404.

The following is a list of selected starting points for some of the most popular CMSs today. These URLs will have the latest code and documentation that will allow you to integrate with your applications quickly and easily:

In PHP, you can overwrite the session handler to use any technology you want through the session_set_save_handler() function. If you are using the Zend Framework, there is a simple way to connect sessions to a database like MySQL using Zend_Session_SaveHandler_DbTable. Other PHP frameworks have similar functionality built in, or you can write code yourself that will accomplish it pretty easily. Here is an annotated example from the PHP documentation for how to write sessions to files:

<?php
class MySessionHandler implements SessionHandlerInterface
{
    private $savePath; // where to save session files

    // initialize the session object and create a directory
    // for session files if necessary
    public function open($savePath, $sessionName)
    {
        $this->savePath = $savePath;
        if (!is_dir($this->savePath)) {
            mkdir($this->savePath, 0777);
        }
        return true;
    }
    // no need to do anything when you close out a session
    // object
    public function close()
    {
        return true;
    }
    // for any given session id ($id) return the data
    // stored in the session file on disk
    public function read($id)
    {
        return (string) @file_get_contents("$this->savePath/sess_$id");
    }
    // write session data to a session file
    public function write($id, $data)
    {
        return file_put_contents("$this->savePath/sess_$id", $data) === false ?
        false : true;
    }
    // when you want to delete a session, delete the
    // session file containing the data
    public function destroy($id)
    {
        $file = "$this->savePath/sess_$id";
        if (file_exists($file)) {
            unlink($file);
        }

        return true;
    }
    // garbage collect sessions objects older than a given
    // amount of time
    public function gc($maxlifetime)
    {
        foreach (glob("$this->savePath/sess_*") as $file) {
            if (filemtime($file) + $maxlifetime < time() && file_exists($file)) {
                unlink($file);
            }
        }

        return true;
    }
}

$handler = new MySessionHandler();
session_set_save_handler($handler, true);
session_start();

// proceed to set and retrieve values by key from $_SESSION