There's been a lot of discussion on the Internet about the definition of Platform-as-a-Service. Here's just a few very active Twitter discussions to illustrate the level of activity and passion over the topic:
This is just a few of the hundreds of tweets returned when I queried "Paas" and "definition". The interesting thing is that the sheer breadth of the discussion makes it very difficult to nail down exactly what it is.
Gartner Group's method of responding to the madness was to develop their own taxonomy of PaaS, which seems to have been very helpful for them in organizing their research, but, in contrast to many other things Gartner has led on defining, their PaaS taxonomy has not really caught on with the cloud community. The Gartner taxonomy breaks things out based upon the primary functionality of the platform, such as application development, business process management and event processing. However, this dichotomy actually impairs their ability to abstractly define the essential characteristics of a PaaS.
At a minimum, PaaS is a cloud service model and as such should meet the NIST essential characteristics for cloud computing, which are:
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service
The question then becomes what are the essential characteristics that follow on from these? Some that come to mind include:
- Support binding and unbinding from composable multi-tenant services. This binding can be explicit as it is with some of the container-based PaaS or implicit through the use of APIs.
- Enforce scaling of platform services. In the case of container-based PaaS, the user has the option of having their application also participate as a service and, thus, be managed by the container's scaling capabilities.
- Ensure appropriate authorization for use of given services.
- Provide a means for monitoring and ensuring the health of the platform and its services.
Putting the above list together was an exercise in remaining non-exclusionary. It's easy to think about all the great capabilities that container-based PaaS provides and add those to the list, but container-based PaaS is not always the best option for existing workloads that were developed as silo applications stacks. It also doesn't account for the platforms that deliver platform extensibility, such as Force.com and NetSuite.
To keep me pure of heart, I leveraged my three archetypes of PaaS that I presented in my PaaS workshops at Cloud Connect. These are presented as follows:
Application Infrastructure Platform
As much as I would have liked to add characteristics, such as, manages application lifecycle, supports routing of messages into and across services, etc. that clearly would have been establishing a bias toward container-based PaaS. The above archetypes provide a wide berth against which to select the best architecture for a given cloud application and keeps the established characteristics to those items that are common across all PaaS archetypes.
I will admit I have been a strong opponent of those listing roles and organizations as DevOps. Primarily because DevOps is a way to do something and creating a role DevOps Engineer is just putting lipstick on the pig for those looking to hire a Linux Sysadmin or infrastructure script coder. Likewise, the DevOps organization is a somewhat more likeable term, but still ambiguous at best. It’s either the organization that is helping to redefine IT by having development and operations individuals work together on the same team, which is really just IT using a different process and should go away once it succeeds, or it’s the infrastructure team trying to sound cooler and more sexy.
Today, however, I had a bit of epiphany about using DevOps with regard to a title or role in an organization. I was thinking about a project I was on where we used agile Scrum methodology. On that team we had a Scrum Master whose job it was to orchestrate the agile process and helped the team to move through the various stages of the agile process. This was a very important role that analyzed the velocity of the project, helped to prioritize stories and figure out how many points would be finished in each sprint.
This particular project also leveraged a process of continuous build, which meant that someone had to manage the establishment of the code repository and develop the automated test and build processes. This was a critical aspect of ensuring that every developer was checking in code that passed unit testing. Once a day there was also an integrated build, which would deliver a working version for testing, hopefully.
It’s this supportive environment that ensures that the development team is indeed able to complete their sprints and deliver high-quality software at the end of the process. So, if DevOps is an agile methodology, then who is responsible for clearing the hurdles for the development and operations teams to work more closely together? Who is responsible for instituting the tools that will help automate the collaboration between these two teams?
The people I speak to that are moving to DevOps (or helping businesses move to DevOps) all claim that it’s currently working one of three ways:
- DevOps is really infrastructure/data center led and they select the tools and DevOps is really about automation of provisioning
- DevOps is really development driven and the application development team is selecting the tools, which are really just extending current agile approaches
- The development and operations teams are evaluating together and struggling to select a single platform that meets both of their interests
All this brought me to the realization that successful DevOps implementations will require a DevOps Master. This individual, like the Scrum Master, is responsible for implementing the necessary processes and procedures that will allow these two teams to do their individual tasks and yet have their work culminate in a high-quality production delivery. The DevOps Master will choose the platform(s) to enable this collaboration and manage the individuals who will set up the environment. In essence, they will build the bridge that development and operations will use to facilitate communication and automation of the design, build, test, operate process.
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.
In the early part of 2013, EMC announced a new storage virtualization product called ViPR that delivers a software interface to block, object and HDFS storage services layered on heterogeneous storage. As part of that announcement there was an architectural discussion regarding how ViPR would be providing these services to applications that entails breaking out the design into two components: the control plane and the data plane.
The control plane provides common interfaces for provisioning, policy & management while the data plane provides interfaces for data access from applications. In separating out these two layers, EMC creates an architecture that is agile and enables new services to be added over time without impacting production services. Since ViPR is focused on storage, it will, unfortunately, never be expanded to encompass an entire cloud management stack. However, the architecture is interesting and aspects of it lend itself to building a best-of-breed cloud management platform.
Starting with the control/data plane concept, I broke apart the cloud into multiple planes and then focused on how the layers would communicate to enable a cloud management platform that inherently scaled in and out as well as up and down. Figure 1 illustrates the outcome of this effort and each plane is described in more detail below:
Application Plane – This plane focuses on the deployment, lifecycle and management of the running applications. In today’s lingo, this is part of the Platform-as-a-Service (PaaS) architecture. The thing about PaaS is that services need to be designed to “plug-in” to the PaaS container in order for them to be made available to the applications. In this architecture, the application plane now has a common interface to manage the data plane and the compute plan. Hence, those services are now available to the application regardless of their underlying location or implementation.
Data Plane – Since this is a comprehensive cloud management platform, I’ve moved the data plane out up in the architecture to become an aggregation layer for all types of data including databases, files, as well as, operational information created by the compute and control planes. Through these two layers’ designs, I can now build business applications as well as a single pane of glass to manage my entire cloud regardless of the physical components that make up the cloud infrastructure.
Compute Plane – This plane manages the resources for operating the application and data planes. The integration of the application and data planes no longer need to rely on a single hypervisor to support its cloud design which provides tremendous freedom for the cloud applications and data to migrate where the economics (performance, costs, etc.) are best.
Control Plane – This plan implements the interfaces for operations staff to configure and operate the underlying hardware platforms that comprise the cloud infrastructure. It implements governance and access controls as well as supports policies for deciding where resources should be allocated from when requested from the compute plane. The compute and hardware planes together deliver a consolidated and unified cloud resource pool regardless of the underlying componentry.
Hardware Plane – This is the physical equipment that will comprise the cloud infrastructure resource pool.
Figure 2 illustrates how the integrated stack would look and how the planes communicate to drive independence and agility.
While this is all conceptual, it follows many of the existing patterns from building Service Oriented Architectures (SOA). What’s really interesting to me about this architecture is that everything above the control and hardware planes can scale out in a common manner with a single set of tools and interfaces, hence, driving toward single pane of glass. It also puts a lot of emphasis on good administration of the control plane so that applications perform and that regulatory concerns and risks are mitigated.
On the surface it looks to be a chicken and egg problem. Is cloud driving IT transformation or is IT transformation driving cloud’s growth? The movement to cloud requires a shift in approach for many IT organizations for how to deal with procurement, management, security, etc. In some cases, public cloud offerings are driving IT to change how it delivers services as the business has access to options that don’t require IT’s participation in order to acquire.
The truth is that IT organizations can build and deliver private cloud offerings without changing how they operate internally. Often, these efforts result in less than stellar adoption by the business. Without transformation of the business and operational processes, cloud is just another silo that increases operational overhead and often acts to “prove” the businesses’ point that IT is too slow and difficult for the needs of today’s businesses.
Alternatively, changes in operational and business processes without incorporating cloud computing can still yield significant advantages for the business in lowering operational overhead, reducing risk and, most importantly, fostering a change in how IT is perceived by the business. The movement toward delivering IT as a Service provides certain key advantages:
- It exposes the complexities for delivering a highly-available, resilient and recoverable system to the business. These costs are often masked or hidden making IT look more expensive when compared to other options—especially public cloud—when in fact adding the same services to the competitive options results, many times, in an overall lower total cost of ownership.
- It spells out for the consumer the expectations and ensures appropriate communications. When consumers know what to expect they are less irritated by what they perceive to be an inability to deliver. A good analogy here is waiting at the gate in the airport for a delayed flight. In cases where the airline continually updates the passengers there is less anxiety and aggression toward the airline workers.
- It builds trust. The biggest argument I have heard against moving to a shared services model run by a single IT organization is a lack of trust for that organization to deliver. In business with multiple divisions, there is often a hesitancy to allow a “corporate IT” to build and operate a shared infrastructure due to past failures and a demonstrated inability to deliver on time and in a timely fashion. In businesses where these organizations introduced governance boards and demonstrated small successes based on shifts toward ITaaS, attitudes shifted quickly as the divisional IT groups recognize the benefit of leveraging economies of scale across all divisions.
- It simplifies the life of the operational staff. In businesses where IT is spending 75% of their time putting out fires and rarely being able to take on new projects, shifting to ITaaS has simplified the operational environment, delivered greater reliability, reduced the number of individuals required to participate in troubleshooting and root cause analysis, and shifted time back to focus on the backlog of outstanding requests. In turn, the perception of the business is that these IT organizations became more responsive and relied less on identifying “shadow IT” solutions.
This list is just a fraction of the complete benefits for moving to ITaaS and, interestingly, none of the benefits mentioned the word cloud. Does this mean that cloud isn’t really all that important? No. It just means that the transformation toward ITaaS should be viewed as a higher priority for IT than building or moving to cloud. Indeed, in many respects, cloud success is predicated on this transformation. Certainly, cloud technologies can be applied in the data center to simplify data center operations, but the savings and benefits of this activity quickly plateaus and is short-lived if the IT organization continues to operate in a traditional manner.
If I were an acting CIO/CTO today, my first action would be to develop a business plan to take to management to request investment in transformation. This investment is critical as the funding is above and beyond what most IT budgets today can accommodate. The additional funds would then be used to develop a team—using both internal and external (consulting) resources—to develop a roadmap for the transformation, develop new processes and define how to transition to the new processes. I’d also ensure that this team included financial analysts to help develop accurate cost models to be able to show back to management how their investment will result in reduced operations costs and marketing staff to help advertise the benefits back to the business as well as keep them informed of how these changes will result in a more agile organization to support their needs.
Moving to ITaaS is not as painful as difficult as it may seem. It does require an acceptance that this transition will not occur rapidly and that no one expects to “eat the elephant in one bite”. It’s a very repeatable methodology that most organizations can follow with success. Most importantly, and perhaps most importantly, it requires that management be pragmatic with regard to the cultures and staff that will attempt to ensure status quo and make sure to allay fears and concerns of these individuals through training and support, but be willing to remove venomous individuals who continually act to stand in the way of the transformation.
I was recently reviewing some sales and marketing materials regarding building out Infrastructure-as-a-Service (IaaS). Part of these materials included attributes of IaaS, one of which is multi-tenancy. Having been working with some large enterprise customers lately around private cloud, this attribute really got me thinking.
In most cases for the enterprises I have been working with, the private cloud is about agility and the workloads are all owned and related to the same business line. From the macro perspective, there is effectively one tenant, yet from a micro perspective (workload) there are multiple tenants that may require some isolation for purposes of service level and resource management.
Why is this important? Multi-tenancy is expensive. It requires additional resources and overhead to manage including encryption and key management, isolation across network, compute and storage, and additional support for tenant management. Remove this overhead and those physical resources can be focused on workloads instead of overhead.
Further confusing the issue is the duality of the use of private cloud to describe physicality and consumer models. Private cloud when described through its physicality typically is represented as “on premise” either in the customer’s data center or a third-party hosting co-location facility. However, the cloud being a business consumer model, I like to describe it based on the consumption model as anything that has a single tenant (macro) is a private cloud. Hence, in order to move away from describing private cloud by its physicality requires that we establish a macro and micro representation of tenancy. That is, by recognizing at a macro level that there is only one real tenant consuming the private cloud, then many of the multi-tenancy features can be minimized in favor of greater use of resources for workloads.
For enterprises that are operating as a shared IT services provider across multiple divisions that have various legal and operational requirements for security and isolation, where the cloud exists on premise or in a co-location scenario, secure multi-tenancy will be a requirement. However, using the existing cloud computing vocabulary, it may be more effective to identify these types of clouds as community clouds instead of private cloud since all the tenants have a shared common interest. In this way, once again, we can describe the appropriateness of multi-tenancy by consumer instead of physicality.
With many of my clients looking to develop private cloud, success will be predicated on developing and delivering the right features and functions. Identifying the real consumer for the cloud service and an understanding of the relationships between the workloads can go a long way to using either using axe to kill a fly or falling prey to an inadequate service level model. By identifying private cloud as a single tenant at the macro consumer level and a community cloud as multiple related tenants at the macro consumer level, we have a model that ensures regardless of the physical infrastructure deployment we are providing the appropriate features and capabilities.
I’ve been granted an incredible opportunity. Over the past three and a half months I have gotten to lead a real world large-scale delivery of a cloud solution. The final solution will be delivered as Software-as-a-Service (SaaS) to the customer via an on-premise managed service. While I have developed SaaS/PaaS (Platform-as-a-Service) solutions in the past, I was fortunate enough to have been able to build those on public cloud infrastructures. This has been a rare glimpse into the “making of the sausage” having to orchestrate everything from delivery of the hardware into the data center in four countries to testing and integration with the customer environment.
All I can say about this opportunity is that the term, “it takes a village” applies well. I thought I’d share some important generalities about this type of effort. It’s important to note that this is a Global 100 company with data centers around the globe. Regardless of what the public cloud providers are telling the world, this application is not appropriate for public cloud deployment due to the volume of data traversing the network, the amount of storage required, the types of storage required (e.g. Write-Once-Read-Many), level of integration with internal environments and the requirements for failover.
The following are some observations about deploying cloud solutions at this scale:
- Data Centers. As part of IT-as-a-Service (ITaaS) we talk a lot about convergence, software-defined data centers and general consolidation. All of this has major implications for simplifying management and lowering the total cost of ownership and operations of the data centers. However, we should not forget that it still takes a considerable amount of planning and effort to bring new infrastructure into an existing data center. The most critical of these is that the data center is a living entity that doesn’t stop because work is going on, which means a lot of this effort occurs after hours and in maintenance windows. This particular data center freezes all changes between mid-December till mid-January to ensure that their customers will not have interrupted service during a peak period that includes major holidays and end of year reporting, which had significant impact on attempting to meet certain end-of-year deliverables. On site surveys were critical to planning the organization of the equipment (four racks in total) on the floor to minimize cabling efforts and ensure our equipment was facing in the right direction to meet the needs for hot/cold isles. Additionally, realize that in this type of business, every country may have different rules for accessing, operating in and racking your equipment.
- Infrastructure. At the end of the day, we can do more with the hardware infrastructure architectures now available. While we leverage virtualization to take advantage of the greater compute power, it does not alleviate the requirements around planning a large-scale virtual environment that must span countries. Sometimes, it’s the smallest details that can be the most difficult to work out, for example, how to manage an on-premise environment, such as this one, as a service. The difficulties here is that the network, power, cooling, etc. are provided for by the customer, which requires considerable efforts to negotiate shared operating procedures, while still attempting to commit to specific service levels. Many of today’s largest businesses do not operate their internal IT organizations with the same penalties for failure to meet a service level agreement (SLA) as they would apply to an external service provider. Hence, service providers that must rely on this foundation face many challenges and hurdles to ensuring their own service levels.
- Security. Your solution may be reviewed by the internal security team to ensure it is compliant with current security procedures and policies. Since this is most often not the team that procured or built the solution, you should not expect that they will be able to warn you about all the intricacies for deploying a solution for the business. The best advice here would be to ensure you engage the security team early and often once you have completed your design. In US Federal IT, part of deployment usually requires that those implementing the system obtain an Authority to Operate (ATO). Quite often, medium- and large-sized businesses have a similar procedure; it’s just not spelled out so succinctly. Hence, these audits and tests can introduce unexpected expenses due to the need to modify the solution and unexpected delays.
- Software. Any piece of software can be tested and operated under a modest set of assumptions. When that software must be deployed as part of a service that has requirements to meet certain performance metrics as well as meet certain recovery metrics in the case of an outage, that same software can fall flat on its face. Hence, the long pole in the tent for building out a cloud solution at this scale is testing for disaster recovery and scalability. In addition to requiring time to complete, it often requires a complementary environment for disaster recovery and failover testing, which can be a significant additional cost to the project. I will also note that in a complex environment software license management can become very cumbersome. I recommend starting the license catalog early and ensure that it is maintained throughout the project.
- Data Flow. A complex cloud-based solution that integrates with existing internal systems operating on different networks across multiple countries will have to cross multiple firewalls, routers and run along paths with varying bandwidth carrying varying levels of traffic. Hence, issues for production operation and remote management can be impacted by multiple factors both during planning and during operation. No matter how much testing is done in a lab, the answer seemingly comes down to, “we’ll just have to see how it performs in production.” So, perhaps, a better title for this bullet might be “Stuff You’re Going To Learn Only After You Start The Engine.” Your team will most likely have a mix of personalities. Some will be okay with this having learned from doing similar projects in their past, others will not be able to get past this point and continually raise objections. Shoot the naysayer! Okay, not really, but seriously, adopt this mandate and make sure everyone on the team understands it.
- Documentation. I cannot say enough about ensuring you document early and often. Once the train is started, it’s infinitely more difficult to catch up. Start with good highly-reviewed requirements. Review them with the customer. Call to order the ARB and have them review and sign off. This is a complex environment with a lot of interdependencies. It’s not going to be simple to change one link without it affecting many others. The more changes you can avoid the more smoothly the process of getting a system into production will be.
Most importantly, and I cannot stress this enough, is the importance in building a team environment to accomplish the mission. Transforming a concept into a production-ready operational system requires a large number of people to cooperatively work together to address the hurdles. The solution as designed on paper will hardly ever match perfectly what is deployed in the field for the reasons stated above. This project is heavily reliant upon a Program Management Organization with representatives from engineering, managed services, field services, product and executive leadership to stay on track. Developing the sense of team within this group is critical to providing the appropriate leadership to the project as a whole. Subsequently, we also formed an Architecture Review Board (ARB) comprised of key technical individuals related to each aspect of the solution to address and find solutions for major technical issues that emerged throughout the project. In this way we ensure the responses were holistic in nature, not just focused on the specific problem, but also provided alternatives that would work within the scope of the entire project.
For the 1st time in my life after owning three homes I am in the position of having to replace my air conditioning unit. The company I chose to purchase and install the new unit told me the name of the manufacturer for the unit and I set out to read up on customer reviews about that manufacturer. I found one site that had over 1,000 reviews with a high majority of them being negative (highly unsatisfied). As I began to read through the reviews, one thing became readily apparent, those who understand heating, ventilation and air conditioning (HVAC) praised the unit while customers sweating their … well you know what … off, were highly disappointed.
Having worked on installing new HVAC systems in both of my prior homes I was able to assess that the positive reviews were most likely correct. Frankly, the key theme that iterated through the reviews was if you select a knowledgeable and qualified installer, the unit will work perfectly an if you select an unqualified installer chances are you will have issues with the unit as soon as a week into use. The reason I agree with the positive reviewers was because I have some understanding of the components and common elements of these systems. They’re not plug-n-play. You cannot just put the new unit in place of the old unit and expect everything to work as expected. For example, most new units use a new type of refrigerant and if you don’t properly evacuate the system the older refrigerant will corrupt the new compressor likety-split.
This led me to think about how many customers are dissatisfied with their IT systems and actualizing the promises of cloud computing. Gartner Group has introduced the world to the “trough of disillusionment”, in which technology doesn’t live up to the promises of vendors, analysts and pundits. Service Oriented Architecture (SOA) is a perfect example of this trend. I developed a Platform-as-a-Service (PaaS) for supporting retail and supply-chain industries back in 2005. I leveraged a solid SOA design and the system was incredibly agile and allowed us to develop new business services in weeks instead of months. However, for many, SOA was a complete flop. Here, like with the HVAC units, I blame the installer.
It’s very likely that we will enter the “trough of disillusionment” with regard to cloud computing as well. Many that have jumped on board the public train early are now beginning to see issues with costs and controls and are considering how to move off public cloud to private cloud environments. Others have jumped on the private cloud bandwagon based on promises of lower IT costs only to learn that there is an initial investment that sometimes masks future costs savings. Moreover, those costs savings are now being shown to plateau, which doesn’t answer the need for continually shrinking IT budgets. Once again, with all these disillusionments I blame the installer because I’ve seen multiple customers achieve concrete benefits and goals from cloud computing that met or exceeded their expectations.
So, whether shopping for a new HVAC system, getting your car fixed, or selecting a strategy and direction for your IT organization, keep in mind that you get what you pay for and if you are not happy or the system doesn’t work as planned, it might be a problematic component, but often times, it’s the installer!
There’s been a lot of discussion about what makes cloud computing different than other forms of computing that have come before. Some refer to the set of attributes set forth by NIST, while others rely on less succinct qualifications simply satisfied to identify network accessible services as cloud, and others define cloud by applicable business models. In the past, I have written about scale as a common abstraction based on upon some of these other definitions. However, more recently, I’ve come to the realization that we need to define cloud by where it’s going and not what it is in its infancy.
Cloud computing is following in the vein of the automobile and fast food industries. These industries introduced their first products with little to no customization and then changed and competed on value based upon significant customization. The automobile industry started out offering only a black Ford Model T and today allows buyers to order a completely custom designed car online delivered to their home. Likewise, cloud computing started out as vanilla infrastructure services and is rapidly moving towards greater levels of customization. Ultimately, cloud computing will not be defined by service model monikers, but will be a complete provision, package and deliver (PPD) capability facilitating control over the type of hardware, operating systems, management systems, application platforms and applications.
When building a new home, buyers go through a process of choosing carpeting, fixtures, countertops, etc., but ultimately, their expectations are that they will be moving into a completed house and not showing up to a pile of items that they then need to further assemble themselves. This is the perspective that we should be applying to delivery of cloud computing services. Consumers should have the opportunity to select their needs from a catalog of items and then expect to receive a packaged environment that meets their business needs.
Much of today’s cloud service provider offerings either approximate raw materials that require additional refinement or are a pre-configured environment that meets a subset of the overall requirements needed. The former approach assumes that the consumer for these services will take responsibility for crafting the completed service inclusive of the supporting environment. The latter approach simplifies management and operations, but places restrictions on the possible uses for the cloud service. Both of these outcomes are simply a result of the level of maturity in delivering cloud services. Eventually, the tools and technologies supporting PPD will improve leading to the agility that epitomizes the goals for cloud computing.
Meeting the goals for PPD entails many prerequisite elements. Chief among these is automation and orchestration. Cloud service providers manage pools of resources that can be ‘carved’ up many different ways. Due to the complexity in pricing and management, most cloud service providers limit the ways this pool is allocated. As the industry matures, service providers will improve at developing pricing algorithms and have greater understanding for what consumers really need. Meanwhile, we will see great improvements in cloud manager software that will facilitate easier management and allocation of resources within the pool allowing for much more dynamic and fluid offerings. Coupled with automation and orchestration, cloud service providers will find it easier to offer consumers greater numbers of options and permutations while still being able to balance costs and performance for consumers.
Defining cloud computing by its nominal foundations is akin to specifying the career choice for a young child. Infrastructure, platform and software services illustrate possibilities and solve some important business problems today. However, most businesses still find cloud environment too limiting for their mission critical applications, such as manufacturing and high-volume transactions. It won’t be long, though, before users can specify the speed of the network, the response requirements for storage, the security profile, number and types of operating system nodes and quality-of-service parameters that the environment must operate under, among many other attributes, and have the service provision, package and deliver to us our requested virtual environment. This is what we should be using as the profile by which we define cloud computing.