Computing Deployment Models And Cloud Traceability

In a previous post we talked about balancing computing architecture and operational management choices. We built a model that defined four computing styles: legacy IT, outsourcing, private cloud and public cloud. In a subsequent post we refined this model to include four hybrid solutions: hybrid architecture, hybrid operations, hybrid cloud and hybrid hosting. We introduced the concepts of dedicated (private) and shared operations and the concept of dedicated (private) and shared infrastructure. This post further segments computing infrastructure deployment into several models by matching computing layers with dedicated and shared infrastructure. These models scale from full deployment control to full deployment elasticity. This is not to say that there can be no elasticity when one is in full control of all computing layers. However, building a fully controlled and owned elastic deployment model is expensive compared to buying elastic compute options as a service. Also, arguably a single tenant model can never be as elastic as a multi-tenant model.

The computing layers we define in our model are, from the bottom to the top:

Datacenter infrastructure, which includes power, cooling, cabling, and racks. Physical computing, which includes servers, storage, networks, and firewalls. Virtual computing, which includes virtual machines, virtual storage, and virtual networking. Software development infrastructure, which includes software development tools. Software applications which include business apps like CRM, ERP, and BI. And, last but not least, business process, which includes business processes such as procurement, sales, finance and marketing. The layers depend on each other and form the computing stack. There can be no software application without the support of physical computing. There can be no automated business process without software. The value of the computing layer to the business increases from top to bottom, with business process activities being the most valuable.

The deployment models that result from mapping dedicated and shared infrastructure versus computing deployment options are by now familiar, they range from on-premise to hosting to SaaS and BPaaS:
On-premise, where the complete computing stack is deployed in a dedicated fashion. Co-location, where the bottom (data center infrastructure) layer of the stack is shared. Of course, one can co-locate servers, but also a complete cloud infrastructure. Hosted, in which dedicated (servers or cloud) or shared physical computing infrastructure (web hosting) can be rented. IaaS, where virtual computing infrastructure can be rented on-demand, e.g. the Amazon elastic cloud. PaaS, where a software development environment can be rented on-demand, e.g. Microsoft Azure. SaaS, where a software application can be rented on-demand, e.g. Salesforce or Webex. BPaaS, on-demand business process infrastructure based on shared computing infrastructure, e.g. payroll or HR or other business processes. See the figure below for the graphical representation.

As stated before, the level of control is highest with on-premise deployment. The level of elasticity is highest with a BPaaS deployment. Dedicated infrastructure delivers more control, shared infrastructure delivers more elasticity.

As highlighted in our recent post on the future of business computing, enterprises are slowly adopting deployment options that are delivering more elasticity and are prepared to give up control to gain agility. Already, co-location and hosting are tried and tested deployment styles. Also, demand for SaaS solutions is growing. The METISfiles believes that this trend will continue and that by 2020 it is quite possible that the bottom three layers of the computing stack have merged to form a single compute entity.

Cloud Traceability

A new computing value and supply chain is emerging as deployment models are becoming more elastic. For instance, a BPaaS vendor can take services from a SaaS vendor that is running its infrastructure from another IaaS vendor that has co-located its cloud in another vendor’s datacenter. Just like in food safety where the EU is regulating food traceability (from the farm to the fork), enterprises should track deployment options from the data center to the business process to make sure the value chain is uncompromised.

What about your deployment models? How elastic is your IT? Have you got cloud traceability? Can you show cloud traceability in your cloud offerings? Let us know!

Share and Enjoy:
  • Facebook
  • Twitter
  • Google Bookmarks
  • email
  • LinkedIn
  • RSS

About Pim Bilderbeek

One Response to “Computing Deployment Models And Cloud Traceability”

Read below or add a comment...

  1. The savings are in the multi-tenancy sharing. The big questions are around trust – as always.