IaaS Is a Stepping-Stone on the Path to PaaS

The more I think about infrastructure as a service (IaaS), the more I realize that it's merely extending a suboptimal computing model indefinitely. While you no longer have to manage as much physical hardware, you still have to manage virtual servers. You're also still tied to the limitations of server hardware--there's only so much CPU and RAM to go around. IaaS offers some benefits for legacy applications like server consolidation, fault tolerance and improved time to recovery, but unlocking the potential of cloud computing means doing something new, like platform as a service (PaaS).

Server virtualization decoupled the OS from hardware, making server creation easy--but IT still has servers to manage and maintain. Applications are installed on servers, which brings you back to the same monolithic mess you had before server virtualization. The benefits of virtualized servers are incremental and really aren't going to have a significant impact on IT or IT operations. The layering of more and more automation to continue keeping the tightly coupled OS+application model appear more agile and flexible, but it hides the fact that IT is clinging to a legacy past and not moving forward.

You will get real agility with PaaS because it decouples applications from servers--physical and virtual--and offers nearly unlimited scalability because you can distribute applications across many servers. You can have extreme high availability because application instances within tiers can remain running even if one fails. You can also achieve true application mobility since you can move an entire application or just a single tier elsewhere.

We've already seen the benefits of service-oriented architectures (SOAs), in which applications are modular and SOA services are interconnected creating fault-tolerant apps. With a PaaS model, that modularity is extended to potentially run services anywhere. I say potentially because applications often use PaaS-specific feature like storage and database APIs, which aren't portable across services (although those service can be abstracted, too).

The point is that PaaS lets you do things that the IaaS model doesn't. You can make an IaaS cloud behave like a PaaS cloud by making applications modular and using SOA, but you're still tying your applications to an OS and the OS to a hypervisor. PaaS can help you break that dependence.

Currently, moving to a PaaS model takes significant investment in development because enterprise applications haven't been architected to be fully modular and fault tolerant, or to scale dynamically. In all honestly, it will take years for many of your enterprise applications to be PaaS-ready, but you can start now with your IaaS applications and be prepared for the eventual migration.

Here's what you need to demand from your application vendors:

1. Make sure the application is modular and that each component can scale up and down independently, and that application state is shared among many modules. You may scale up or down using a load balancer, or the application can do so--but in either case, the adjacent components need to support the scaling, as well.

2. The application should be fault-tolerant independent of the underlying hardware. If one component in a tier fails, the remaining components should be able to pick up the work. If a dependency fails, the system should be able to start a new instance of the required service and continue processing automatically.

3. You should understand your end-to-end latency requirements and know if there are any timing requirements between components. Knowing both means you can decide in the future whether you can place modules in far-flung places like other data centers or a public cloud.

4. Make sure there are no static identifiers like IP addresses anywhere in the application. For example, static IPs--which show up quite often--mean you can't move applications around easily.

5. Make sure your applications are using openly supported interprocess communications and don't require proprietary protocols or compiled libraries. The RESTful model is poplar today because it's open, extensible and widely supported.

Vendors always tell me they will build features that customers demand, so I think you need to be demanding. Even if they can't rebuild their applications out of the gate, make sure they have a roadmap to do so and make sure they stick to it.