Monthly Archives: January 2014

Recent commentaries by cloud industry luminaries Reuven Cohen & Krishnan Subramanian address key issues related to relative importance and potential longevity of an independent Platform-as-a-Service (PaaS). In his commentary, Reuven poses, “Do consumers really care about the difference between IaaS and PaaS?” The answer to this question is most likely, no, but that doesn’t eliminate the need for distinction, it merely is a matter of how best to deliver the value of cloud computing to users.

In his commentary, Krishnan does an excellent job of exploring one way to classify PaaS as either service or container orchestration. However, in some ways, the distinction introduces more confusion. For example, his use of Docker illustrates how convergence of IaaS and PaaS actually makes sense for the industry and, thus, diminishes his key point that there’s value in the cloud application layer existing as a distinct layer within the cloud stack.

Ultimately, I don’t believe either piece truly makes the case for the importance of independence between IaaS and PaaS, which has to do with the ability to optimize for economics of the cloud. Consider a converged IaaS/PaaS environment. IaaS should be optimized for the management and delivery of virtual application infrastructure, e.g. networking, storage and compute. In contrast, PaaS requires optimization for scalability and availability of applications. Moreover, each application requires optimization in different areas, for example, some require high number of storage I/O per second while others, such as Hadoop, rely on the ability to “spin up” and reclaim thousands of virtual servers.

Operations staffs are having a difficult enough time just trying to deliver a functioning IaaS to their end users with a self-service interface. Expecting that IaaS to also support every type of application that application development might ever think of is unreasonable and would drive deeper in operations-related engineering, which is one of the drivers for the high cost of IT. PaaS provides the right level of distribution of responsibility within the enterprise. A well-designed and operated PaaS should provide the appropriate services on which a PaaS could be layered. In turn, the PaaS could then extend the features of IaaS to ensure appropriate support for storage and network performance to operate the application as part of the deployment.

Indeed, if convergence is to occur in the industry, it is PaaS that should expose IaaS functionality and not the other way around. Assuming advancement of software-defined data center (SDDC) architecture, the PaaS should be able to program and configure the necessary infrastructure required for the deployment and management of an application over time. Hence, the application package will become the primary descriptor for the required infrastructure required to operate the application and the SDDC will provision as requested or deny the request for resources. Thus, rendering invalid the need for a self-service portal for provisioning virtual servers and, instead, relying on the cloud application architecture to consume resources as needed.

To lower IT operational costs and/or to become more agile, the business must simplify the processes to deliver and manage infrastructure and the applications running on that infrastructure. Focusing on one without the other is simply applying yet another band-aid to an already hampered environment. Delivering IT as a service requires transformative efforts across all of IT and a re-evaluation of the metrics currently used to judge success. Achieving these goals demands a new platform and approach to delivering data and applications to users.

I was recently reviewing a reference architecture for Infrastructure-as-a-Service (IaaS) and was confounded by the sheer complexity still required to deliver what amounts to a starting point for the higher level task of deploying software. Perhaps I set the bar too high, but if I were a CIO, any new infrastructure investment I made today would need to be part of a self-aware automatically elastic resource pool. That is, when I plug in the new hardware (e.g. server, storage, network) I’m asked a couple of basic questions about allocation and voila the hardware is automatically incorporated into one or more resource pools. Moreover, there’s software that sits on top of that pool that allocates it out to users on a metered basis. Any further time spent on operational configuration, engineering and deployment is simply wasted effort.

This vision of elastic and automated configuration is not a pipe-dream otherwise it would be too costly for a business like Amazon to deliver its service at the price point that it does. If Amazon required the amount of human involvement in managing the infrastructure that most IT organizations currently require the cost of delivering their EC2 and S3 services would not be sustainable let alone continue to shrink.

As CIO of Company A, it then occurs to me, I have two choices: a) change the way I operate to look more like Amazon, or b) let Amazon do what they do best and subscribe to their services. The former is a daunting task for sure. Transforming IT to deliver as a service has an impact deep into the DNA of the business itself. There’s a whole lot of risk and no guarantee of success. Moreover, the key metric to demonstrate success is elusive at best as it needs to be a combination of productivity, costs and agility weighted against a number that is very difficult to compute based on the current architecture. Hence, how can I demonstrate to executive management and the Board that their investment in transformation was money well spent? The latter is interesting, but I need to overcome internal perceptions surrounding lack of security and the issues related to CapEx versus OpEx spending. Either way, or maybe I choose a combination of both in a hybrid architecture, all I have to show at the end of the day is a better way to allocate infrastructure for purposes of deploying and managing applications; at which point we encounter a whole new set of complexities.

One of the biggest hurdles surrounding application management is the diversity and lack of integration of the application stacks. Consider a basic financial application workload that is used companywide. There’s a database, which must be able to handle hundreds of transactions a minute. There’s the application itself which is comprised of some core executable modules and a bunch of business rules that are defined within the application. The core executables probably run in some form of middleware that enables it to scale, which is a separate layer that must be individually deployed and managed. Of course, this is the bare minimum to make the application work. There also needs to be some security layers made up of anywhere from five to ten applications and tools for managing disaster recovery, high-availability and extracting data for external reporting. All these layers must be integrated to work seamlessly. Moreover, this is just one of many applications an enterprise operates.

Now, imagine that entire integrated application stack just described is a complete package (workload) that must now be made to work with a given hardware infrastructure, usually chosen by a separate team that has little to no experience with the application architecture or worse selected by procurement off an approved vendor list. Moreover, it requires a combination of skills from both application and operations teams to figure out how best to scale the application over time as demand rises. As George Takei, of Star Trek fame likes to say, “oh myyy”! In short, there’s just too many moving parts requiring too much human intervention and too much engineering and configuration relative to the value received. It’s no wonder business is seriously considering alternative means of acquiring IT services, such as Software-as-a-Service (SaaS). For this reason over the next few years IT must and will start to seriously consider Platform-as-a-Service (PaaS).

Most times I recommend evolution over revolution as it is usually more palatable by the business. However, continuing to deliver IT in this manner is unsustainable and is not delivering the agility and speed require by the business. PaaS changes the way we think about building applications and leveraging PaaS capabilities will require applications to be rewritten or migrated. These applications will not directly implement a unique instance of application infrastructure, but will leverage services that are designed to meet stated service levels. In turn, this simplifies the deployment and operation of that application as well as opens the architecture up to leverage services with better economics over time. It will remove the requirement for an infrastructure and operations team to figure out how to optimize a selected set of hardware to meet the goals of a single application and let them focus instead on how to deliver services.

Moreover, PaaS delivers a shared common platform, which is where PaaS becomes such a critical component to tying together ITaaS, IaaS and DevOps into a singular goal of design, build, test, run and terminate. IaaS is merely a commodity layer that offers high value compute services and can support the selected PaaS. DevOps provides the framework and structure for configuration of the application support services, such as networking, security, authorization, backup, etc.

In the end, instead of multiple disjointed teams each focused on their own specializations, there will be a single team focused on the goal of delivering IT services to the business. This is all driven by the focus and perspective fostered through a move toward PaaS.

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Perficient and does not necessarily reflect the views and opinions of Perficient nor does it constitute any official communication of Perficient.