After my previous posts on PaaS, JP Morgenthal (Twitter: @jpmorgenthal) and I have had some offline conversations. The discussion resulted in JP putting together the following blog post. He has graciously allowed me to post it here at ServiceMesh.com. It should be noted that the issues JP identifies below are largely restricted to public PaaS. Private PaaS can avoid these issues through private deployment location choices. With that said, take it away, JP…
The common definition and reference architecture for cloud computing lists three service models: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS). Each of these models fosters a different relationship between the consumer and the cloud service provider. Ultimately, these models define how much control the consumer will have over the running of their service.
To illustrate how these service models relate to issues of governance, let’s look at the requirements for data sovereignty—the rights over the data based on geographical control of locale. Data sovereignty is growing as a concern for many users given recent events regarding the US Federal Bureau of Investigations (FBI) seizure of multitenant hosting servers.
Cloud service providers are finding solutions that satisfy their clients’ needs to this issue. Most often, these solutions are provided through community clouds or offered up as a configuration option. In spite of these options, there are holes. With SaaS, for example, there’s little governance control that a consumer can exert over where their data resides and where the process that is touching their data is running unless the vendor provides this a specific configuration option.
In contrast, IaaS solutions offer users tremendous control over these factors. Indeed, IaaS providers typically place the responsibility for control over these issues onto the user to the point where it’s a requirement for the user to force operating across geographies. That is, the user must select the specific data center location in which the computation and data will reside. Tools like the ServiceMesh Agility Platform provide policies to automate these decisions as part a complete governance strategy. Thus, IaaS and SaaS show the two extremes with regard to governance controls— consumer managed or provider managed.
Unfortunately, PaaS, the middle child in the as-a-service family, results in the need for greater cooperative position between consumer and provider. Unlike SaaS, which only allows governance controls that the provider offers, and IaaS, which offers great flexibility in governance over the cloud environment, PaaS is effectively a SaaS that must act like IaaS. That is, since PaaS typically has a utility billing model akin to IaaS, businesses expect to implement controls that will limit their exposure, but it’s virtualized nature means those controls must be exposed from the PaaS itself.
Let’s explore this need with a concrete example. With SaaS, scalability and elasticity are implicit in the design of the application, which is typically measured on a per user basis. Hence, costs are controlled by controlling the number of seats purchased. IaaS, on the other hand, offers scalability and elasticity architecturally, but it must be operationally enforced by the consumer. Therefore, consumers can create more machine instances to improve performance, but it is either managed by operational control package or directly by the operational staff. Thus, costs are managed through explicit operational controls.
With PaaS, scalability and elasticity are implicit in the value proposition of the platform that measures process execution and resource consumption. However, there is little in the way of control over where the process will run, how effectively your process will run, who can access my running processes, how much disk space can a single process use, how long your process will run and how many processes can a single user occupy. Thus, a single bug could result in tying up all available processes, and if dynamic controls are on, creating more processes and then tying up those as well resulting in unexpected exorbitant costs. PaaS consumers must have the ability to govern at the level I’ve just described.
Note, these issues can be overcome through labor, design, etc., but they can all result in significant unplanned and unexpected expenses with regard to your cloud computing effort if ignored. Since the PaaS takes away some additional layers of control away from the consumer in return for simplified operations and deployment, it is critical that the PaaS environment embed the necessary governance knobs into the platform so that consumers can avoid some of these operational issues. These knobs would allow users to take actions, such as automatically terminate processes that are running beyond normal limits, determine if they will allow a single user to execute over multiple processes or determine if they want to allow instances based on who the user is and not arbitrary limits. Moreover, the knobs could be configured by the operations staff responsible for deploying and managing the application in the cloud and automated with policies using a cloud platform such as Agility.
It is an unfortunate fact that PaaS requires a greater balance of power and control to be reached between the cloud service provider and the consumer than either IaaS or SaaS. Until PaaS platforms allow consumers to define policies that control the PaaS’s behavior with regard to their application, consumers will be at a greater risk using them and they will never achieve their full value as a service model.
Comments are closed.