The effect of PaaS on cloud delivery models

It seems rather straight-forward that as cloud computing adoption increases and the state of the art evolves, we will see a natural move by consumers toward cloud services that provide a higher level of abstraction. Discounting cloud-based software services (which I believe constitute the largest concentration of hype-generating service providers), many cloud service consumers do their drinking from the cloud infrastructure services fountain. This is to say that a large number of consumers in the cloud deal with services where the unit of work is a server, block of storage, networking subnet, or some other kind of basic compute resource.

The natural move then is to raise the level of that unit of work to the applications that utilize those compute resources. In other words, a shift that many believe will occur over time leads us from cloud-based infrastructure services (IaaS if you prefer) to cloud-based platform services (PaaS). At the risk of understating such a shift, this is huge and has many implications to both providers and consumers.  From a simple standpoint, this transformation will mean an increase in complexity for cloud service providers and a decrease in complexity for cloud service consumers.

The increase in complexity for the cloud service provider is attributable to many different factors:

- Providers must effectively manage raw compute resource AND the application platforms on which user applications rely

- Providers must provide an extensible framework that allows applications services to plug in seamlessly

- Providers must translate a user’s application service-level requirements into a set of deployed infrastructure and runtime policies

- Providers must enable security mechanisms in the context of applications

You could go on and on about the requirements for cloud platform service providers that add up to the increased complexity over cloud infrastructure service providers. By no means am I saying being a cloud-based infrastructure service provider is trivial. Being a cloud-based infrastructure service provider is hard, but being a cloud-based platform service provider is harder.

It is this increase in complexity that leads me to an interesting question: What effect will the move towards Platform as a Service have on cloud delivery models? I ask this question with an open mind because unlike some, I subscribe to the concept of multiple delivery models for the cloud. That is right, I “believe” in the on-premise/private cloud, and in some cases, the on-premise approach to clouds is exactly the right thing. However, the difficultly associated with delivering a PaaS framework makes me wonder how this translates to the on-premise cloud landscape.

Absent a pretty nice and robust management wrapper around the PaaS framework, the complexity of standing one up for the typical enterprise use case seems pretty daunting. Consider a single element of the PaaS solution: software infrastructure it utilizes to provide applications services. These infrastructure bits come in the form of application servers, web servers, data caches, security services, etc. If a user wants to stand up a PaaS solution entirely on-premise, does this mean they are responsible for acquiring the infrastructure software bits and figuring out how they plug into the framework? Do they have to figure out how to denote that it should be a shared vs. a dedicated service? I would think the answer is yes to both of these questions, and to me, that alone sounds like quite a bit to ask.

If I were to answer my own question about the effect of PaaS on cloud delivery models, I would say that this gradual move toward PaaS would spur on the move to hybrid delivery models.  It is a simplification of the complexities of enterprise application environments to say that PaaS means a wholesale move to the public cloud. In many cases, I believe it will make sense for the PaaS framework to exist on the public cloud where a provider manages its construction, availability, scalability, and the required maintenance. In turn, the PaaS framework may use both on-premise and off-premise infrastructure clouds to host the application environments it creates based on user requests. This affords users flexibility without sacrificing the simplification that PaaS promises. What do you think?

Reporting for the cloud

Normally when you read or hear someone talk about application environments running on cloud platforms a lot of focus is put on provisioning and elasticity. Mainly the claims are that you should be able to very quickly provision full application environments on the cloud platform and that those environments should grow, and shrink, based on the demands on the system.

I certainly have no argument that those capabilities are important functionality for a cloud platform, but based on some recent conversations with several different users I’m beginning to think we aren’t talking enough about another important feature for these solutions. That feature is the degree to which the application environments running on cloud platforms can be audited.

Auditing of the application environments running in a cloud has many facets, but let’s just consider it as it relates to one of the basic tenets of cloud computing: utility-based pricing. If you are thinking of either using or constructing a cloud application platform within your enterprise, chances are utility-based pricing is important to you. You either expect to be charged for only the resources you use, or you want to allocate costs back to teams or users based on usage of your platform. Your usage charges may be for the number of hours that an environment runs in the cloud (the Amazon EC2 pricing model), or it may mean something even finer-grained such as paying for the utilization of compute resources like CPU, memory, and storage. Any way you account for usage, the implication is that the cloud platform, or associated tooling, provides or enables you in some way to extract and filter the relevant data about the environments running on said platform in order to produce meaningful reports.

The best-case scenario is that the cloud platform directly provides you with your reports. For instance, if you decided to charge for use of your cloud platform solely based on usage hours, then the cloud platform solution might provide you with a report that showed the breakdown of usage hours for each user or team over a specified period of time. In this case, you don’t have to do anything to extract, filter, or otherwise massage the data. You tell the solution you want a usage report, and it gives you just what you need.

Obviously, this turnkey reporting capability is not likely to be there for everything you need because there is no way for a solution provider to anticipate and provide every meaningful report for every user right out of the box. What do you do when you encounter a solution that you otherwise like, but doesn’t necessarily give you the reporting you need right out of the box? Simple. You ensure that the cloud platform solution provides a mechanism by which you can extract audit data to support your own custom reporting.

The solution may enable you to extract data by providing a robust CLI, REST interface, web services interface, or query building capability. Regardless of the data extraction interface, if custom reporting is important to you, you’ll want to ensure that not only can you extract the data, but that you can also filter and shape the data to fit your needs. If you can’t filter the data, you’re left with little more than a pile of meaningless bytes and bits. Just as importantly, if it looks too hard to filter the data, you’ll want to consider whether it’s worth the investment to write the necessary data mining logic.

The bottom line is that when you look at a cloud platform solution, be sure to look past that solution’s approaches to provisioning and elasticity. Take a hard look at how it helps you to audit the application environments it will support. It’s better to understand and accept those capabilities upfront instead of being disappointed once you put the solution in place.