September 19, 2014 | Written by: Manish Gupta
Share this post:
This is the second part of my series on cloud brokerage, and in this post I’ll discuss a variety of application stacks on which consumers can run their workloads.
In my initial post, I introduced what I mean by a workload or application stack and a management stack. In subsequent posts, I’ll discuss challenges associated with choosing an application stack and factors that affect the migration and management of a workload onto a target cloud so as to support service contestability, and I’ll close with an architectural overview.
Application or workload stacks that cloud consumers can construct today
The software stacks you deploy as part of your application or workload will depend on what cloud service or delivery model you choose. A cloud consumer can have multiple applications to run and each of the applications can be comprised of multiple application or workload stacks. The subsequent figure shows some typical software stacks.
Business process as a service or software as a service
Starting from the right side of the figure, the first stack corresponds to a business process as a service (BPaaS) or software as a service (SaaS) model. Both come with predefined service level agreements (SLAs), allowances for customization and so forth. This model saves the consumer from having to build, buy or manage the required software. The consumer typically gets a standardized package that allows for rapid go-to-market; in fact, this model is one of the fastest. But by choosing this model, a consumer relinquishes control of the architecture of the underlying infrastructure that supports the application, as well as control of the application itself!
The application stack shown in light green is the configuration profile that allows the consumer to alter the look and feel or some functionality of the service or any non-functional behavior. The level of customization is typically limited.
IBM has been ramping up its SaaS portfolio, and one can get a complete picture at the IBM Cloud marketplace.
Middleware as a service, database as a service or storage as a service
The second application stack from the right corresponds to middleware as a service (MaaS), database as a service (DaaS) or storage as a service In these models, the provider relieves the consumer of the arduousness of managing the versions, patches, license management, tuning and scale out for the middleware or database.
In a storage as a service model, the provider supplies an object store as a service that can be accessed by the application at the REST application programming interface (API) level. If a consumer chooses to create an application using this stack, the consumer has to provide the application software, which should be compatible with the middleware service supplied by the provider.
The consumer has control of the application architecture but has no control over the middleware, database or underlying infrastructure. In some cases, the health, availability and other elements of the management stack for the middleware or database container may be supplied by the provider, while in other cases only a partial management stack may be supplied. Thus, it becomes very important for a budding consumer to understand clearly what is included and what is excluded from the overall service description.
Examples of service providers that follow this model are: IBM Bluemix, IBM SoftLayer Object Store, IBM Cloud Managed Services for Oracle or SAP, Microsoft Azure and Google Storage Cloud.
Infrastructure as a service: Operating system
This is a model where the provider grants capability to deploy a virtual machine from a given catalog of operating systems and also provides availability SLAs for the guest OS. A front-runner in this category is IBM Cloud Managed Services. A consumer does not have much flexibility in terms of the architectural control up to the OS, as IBM Cloud Managed Services would not allow any changes in the storage, network or hypervisor architecture—it is a black box to its consumer. The consumer has to support only the middleware/database and the application. The application stack that the consumer has to provide comprises all the elements above the OS, with some allowance for the consumer-specific OS configuration.
Infrastructure as a service: Hypervisor
This is similar to the IaaS—OS model described previously, but the provider allows the consumer full control of the guest OS that can run within virtual machines. The provider has SLAs up to the hypervisor, but is not responsible for the management of the up time of the OS or any component above that. The provider may offer service add-ons at an additional charge.
For example, the basic virtual machine that is deployable on the IBM SoftLayer public cloud comes with a principal level of monitoring, but it can be enhanced by paying an additional monthly fee to employ an advanced monitoring service. A consumer enjoys tremendous freedom in deciding the OS and the middleware to run an application, yet also has to tackle the problem of identification of a management stack that would guarantee a service level for the application.
Examples of service providers for this model are the IBM SoftLayer public cloud, AWS EC2 and AWS EBS.
This is a term we use specifically for the model where the provider supplies a highly available data center network and a catalog of bare metal servers, mass storage, vLANs, firewalls, load balancers and so forth. This helps the consumer create a dedicated private cloud (albeit hosted on the provider’s data centers) in a matter of hours, without making any capital expenditure. An example of such flexibility can be seen in IBM private cloud capability on SoftLayer. Obviously, this flexibility comes with a larger responsibility to identify the management stack for the overall application.
The left-most delivery model (which I’ve left unnamed) provides the maximum flexibility in terms of architectural control to the consumer. In my humble opinion, this really corresponds to a private cloud on the customer’s or provider’s premises. For example, IBM Strategic Outsourcing could manage a private cloud on- or off-premises with the consumer’s choice of hardware and software (subject to the constraints, if any, from the provider). The consumer would typically own the hardware and software. The management stack provider may bring in some of its own tools and best practices to manage the cloud. Furthermore, the cloud service may offer different varieties of IaaS, MaaS, DaaS and SaaS to its users. The consumer has to make an upfront investment to set up the cloud, and the cost of management could be higher than the rest of the options we discussed.
As seen from the above discussion, it can be a challenge to decide whether to place all applications on the same cloud or to distribute them over multiple clouds. This is exacerbated by the different packaging formats for the application and middleware stack. In my next post I will discuss these challenges in detail.