Table of Contents for

Programming for PaaS

With colocation, you usually buy your servers yourself. Then you ship them to a high-bandwidth data center where you pay a monthly fee. The colocation facility gives you Internet access and sometimes will even help debug or restart a server. But in addition to the up-front costs of the machines, you are responsible for maintaining and managing the servers.

The term “managed server” is a bit of a misnomer. In reality, the management of the server can be quite limited. If the RAM becomes corrupt, they will replace it for you. If there are hardware issues, the provider will replace your hardware. But while they replace disks or RAM, they do not replace your data, so it’s critical to make sure that you have off-site backups.

There are various benefits to using managed servers. Often you do not have to buy the servers yourself; you lease them from the same provider that is hosting and managing them. They are faster than some of the other dedicated alternatives, as well as more reliable and more robust. Managed servers can and do die, but they usually don’t die very quickly. You generally have to wait for a disk failure, which on average could take a year or two. Compare that to the ephemeral servers on Amazon Web Services, which could die in a matter of days or weeks. The downside is that provisioning new servers can easily take anywhere from weeks to a month.

Virtual private servers, or VPS, are similar to managed servers, but virtualized. In desktop environments, you may be familiar with Parallels, VirtualBox, and Fusion. For server-side virtualization, the tools of the trade (known as hypervisors) include XenServer, KVM, Virtuozzo, Vserver, and Hyper-V.

Virtualization allows large servers with many terabytes of RAM and hundreds of processor cores to be subdivided into smaller virtual servers with gigabytes of RAM and one to four cores. This makes these servers a lot easier to start, run, and replace than non-virtualized dedicated servers.

Virtualization technology allows for each virtual machine to act independently of one another in terms of security, isolating processes and tenants in a much more comprehensive way than sharing servers through multitenant shared hosts all on a single Apache instance. Each virtual machine has its own root account and, if compromised, does not have access to any other of the virtual machines.

The downside to VPS can be that since the underlying physical resources can be shared, you can still run into issues where a neighboring tenant is hogging your CPU or disk I/O, which can slow down your applications unless you plan for these kinds of inconsistencies.

IaaS is like an on-demand elastic VPS with an API. It is the fastest version of dedicated web hosting in the sense of provisioning. But it is still considered to be dedicated web hosting because you still get root access. The largest effective difference from other kinds of hosting is that you can go from requesting new servers to having them up and running in about 30 seconds. They can be dedicated real servers, but usually are virtual servers. Virtualization is accomplished with software that ranges from VMware’s vSphere to Xen from Citrix all the way to Microsoft Hyper-V. The most popular Infrastructure-as-a-Service is Amazon Web Services, which uses Xen to virtualize its hardware.

With IaaS, what you get are dedicated servers with dedicated IP addresses. They start out as a blank slate, so you have to do all the system administration: install the software, install Apache, configure Apache, secure the server, tune the server, tune Apache, tune MySQL, add the accounts, distribute passwords, set up SSH, put the SSH keys in, install the packages, upgrade the packages, and make sure your app works with the versions of software included on the machine.

The benefits of IaaS are the ability to provision as many servers as you need and the ability to do so very quickly on demand. The downside is that those servers are generally slower than their dedicated alternatives. They also offer less performance and they are less reliable, so they tend to be ephemeral, meaning that they go down without notice. You have to design your system to be able to handle servers dying at will, adding a layer of complication.

The cost structures for the various forms of dedicated web hosting are vastly different.

In the colocated version, you have the initial fixed costs associated with buying the machines. You’re only renting space in the colocation facility, though, so the ongoing costs are significantly lower compared to similar IaaS usage. Many large applications go the colocation route, investing in their own hardware to take advantage of the monthly cost savings. This is also known as increasing capital expense (capex) in order to reduce daily operating expense (opex). Colocation costs vary but can start at around $1,000 per month for a rack, which can hold up to 16 servers. Keep in mind, however, that you’re still in charge of maintaining and managing the machines. You will need to go in, install the machines, wire them together, and maintain them in person as they fail.

On the other end of the spectrum is Infrastructure-as-a-Service. With IaaS, you pay an hourly cost based only on the resources you need (also known as increasing opex to reduce up-front capex). Generally there are a wide variety of different combinations from which to pick, including different CPU speeds, disk sizes, and I/O performance.

Since IaaS is typically priced by the hour and has no long-term commitment, it’s very handy for cases in which you need to provision many servers and use them for a short amount of time—performing a vast calculation over a specified amount of data, for example. How would such a scenario impact your budget?

Let’s suppose you’re going to sequence DNA. You have a set problem and you have a set piece of data. Using Infrastructure-as-a-Service, you can spin up a thousand servers, sequence the DNA over a set period of time, and then shut the servers down. You only pay for the hours that the servers were running. Instead of buying a thousand servers that sit around doing nothing after you’ve finished sequencing the DNA, you set up only what you need for the time you need it.

Web applications tend to live much longer than a DNA sequencing can take, which might on the surface seem to favor capex over opex, because you can make long-term commitments. This can make IaaS seem economically unfavorable for hosting web applications. However, web applications might experience spikes. If you’re preparing to go on a talk show or a news program, you need to be prepared to handle the resulting traffic to your website. With a colocated facility, you would have to order the servers, wait a few weeks, then bring them in and have them configured, which could take another few weeks. With Infrastructure-as-a-Service, you can make an automated API call 24 hours a day and add a thousand servers to your system that can be available within minutes. After the traffic diminishes, you can deprovision the servers and only have to pay for the time that you used.

The general problem with Infrastructure-as-a-Service is that since the servers are ephemeral, you need to have some kind of persistent block storage so that you can keep your data. For example, if you have a MySQL database and the server goes down, you don’t want to lose that data. You must have the data persisted on block storage or some other similar persistent storage technology. These and other services add additional hourly charges.

Infrastructure-as-a-Service is an à la carte system. You can add services as you need to and then pay for them on an hourly basis.

An atomic unit is the least divisible unit of interest for an entity. What is the least common factor? What is the base indivisible aspect that people care about? In math, it’s numbers (or even more fundamentally, sets). In physics, it’s equations. In chemistry, it’s molecules. In biology, it’s cells.

This applies in the business world, as well. For McDonald’s, it’s hamburgers. For Barnes & Noble, it’s books. For Coca-Cola, it’s a can of Coke. It is the base unit that the company cares most about.

Figuring out the atomic unit for a company is both enlightening and limiting. Enlightening because it gives you a focus—it lets you rally to what you are good at—and limiting because it is incredibly difficult to be as good at selling anything outside the purview of your atomic units. Few companies who try to have multiple atomic units are able to succeed.

The atomic unit does not have to be as specific as the examples just given. For Amazon.com, it’s anything you can warehouse and ship in a box. For Netflix, it’s digital media in various forms. For Procter & Gamble, it’s household items.

When it comes to sorting out atomic units, there is a major amount of confusion in the cloud. Part of the reason for this confusion is that many different companies who sell many different atomic units are being grouped together. One way to make sense of it all is by understanding the atomic units of these companies at a generic level.

For Infrastructure-as-a-Service, the atomic unit is resources. By resources, we mean servers, disks, networks, and IP addresses. IaaS is all about providing these resources on demand. For example, when you look at Amazon Web Services, all the tools center around resources, all the documentation is about resources, all development is focused on resources, and the main thing people use it for is resources. Other IaaS examples include Rackspace, GoGrid, and Joyent.

For Platform-as-a-Service, the atomic unit is applications. What is an application? It’s a system. It’s a combination of code and all the services that communicate with that code at any point in time. It is not a resource. In fact, an app is composed of many individual resources all tied together. The amount of effort required to connect those resources together is often underestimated. That’s why companies hire IT departments and why system administrators are always in demand. Going from a single host running Apache and MySQL all in one to a system architecture with separate load balancers, caching servers, app servers, and database servers with redundancy and failover involves a lot of work, both up front and later on in maintenance.

The other thing that PaaS does is configure and manage IaaS from an apps perspective. Tools like Cloud Formation are great, but they approach IaaS management from a resources perspective. Apps see the world in a much different way than resources do.

Apps, unlike resources, do not tend to come and go frequently. The need for on-demand hourly pricing, while highly useful for IaaS, is not as important with this model, except when you temporarily burst app usage or you’re in a test/dev scenario.

In short, Platform-as-a-Service providers deal with code and services. The responsibility of those providers is to manage and maintain the code, to run the services, and to make certain that the connections between everything remain up and running at all times.