Infrastructure scalability is not the greatest challenge cloud service providers face in the data center, and this is especially true for midsized providers. Even among cloud
Seamless cloud services depend upon cloud automation, a mechanism that enables customers to provision or decommission services through a self-service portal at any time -- without any intervention by the cloud provider. Each service request would trigger multiple changes in the cloud provider's environment, such as reconfigurations of networking devices, new virtual machines (VMs), new virtual disks and backup configurations. All these changes must be coordinated and executed automatically and in the correct sequence. In other words, they must be orchestrated.
Amazon 'a masterpiece' of cloud automation and orchestration
Whenever I describe the cloud services taxonomy, such as the difference between Infrastructure as a Service (IaaS) and Platform as a Service (PaaS), I draw a picture of a typical Web-based application and point out the various interfaces that a provider could "cloudify." That is, I identify the elements the provider could modify to build a cloud service. For example, a MySQL database used by popular open source solutions could be turned into Database as a Service. This is then the inevitable follow-up question: Is this a classic case of cloud washing, or is there a fundamental difference between the two services?
There are significant differences between traditional Web hosting and cloud services. Cloud services are elastic, meaning they can be deployed on demand. Cloud services are also scalable in that an application is not limited to a fixed number of physical servers. Additionally, cloud services are provisioned immediately -- meaning when a customer needs them, not a month later. In other words, enterprises must be able to deploy new services without the cloud provider's intervention. This is what made Amazon Web Services (AWS) so popular.
AWS is a masterpiece of cloud automation and cloud orchestration. Customers may use a Web portal or application program interface (API) to provision new VMs, block storage, object storage, load balancers and database servers at any time. These resources are available to the customer within seconds, thanks to cloud automation. Cloud orchestration tools ensure that any changes made to Amazon's servers, storage and network are completely transparent to the customer.
Cloud orchestration and automation pivotal to XaaS
In the case of Infrastructure as a Service (IaaS), customers must be able to do the following without assistance from the cloud provider:
- Create new VMs and start or stop existing ones.
- Create new logical disks and back up, expand or compress existing ones.
- Create and manage virtual networks and connectivity to the outside world.
Vendors have developed cloud orchestration and automation software, such as VMware's vCloud Director and BMC Software's Cloud Lifecycle Management, to address most of these challenges. Automated provisioning is also an important part of the open source OpenStack architecture; however, OpenStack is still missing a true virtual networking component.
Another example of the importance of cloud automation and cloud orchestration lies in virtual desktop infrastructure (VDI) technology, which is the foundation for cloud-based Desktop as a Service (DaaS) offerings. But it takes way more cloud automation to build a successful DaaS solution. Cloud providers must support the following:
- Automated provisioning of new users, which is particularly important for business customers looking to outsource their IT services.
- Automated provisioning of new software packages on existing virtual desktops and associated license processing.
- An app store-like interface that enables users to deploy new applications on demand.
- Comprehensive monitoring from the perspective of customers and the provider.
Cloud automation and cloud orchestration tools that provide self-service capabilities to customers are critical to having a successful deployment and growing a customer base.
Most VDI offerings, such as VMware View or ThinApps, focus on implementation of specific technology. There are only a few solutions on the market that can offer a true self-service portal for DaaS customers that provides all the above-mentioned features. Such a portal provides users with total control of their virtual desktops, enabling them to provision new applications as needed. Cloud automation and orchestration tools perform all the required changes to the VDI environment -- new VM creation, new virtual disk creation, installation of ThinApp applications -- in the background with no operator intervention.
Cloud automation and cloud orchestration tools that provide self-service capabilities to customers are critical to having a successful deployment and growing a customer base. It would be difficult to market something as a "cloud service" if changes to the service cannot be done immediately, or if the service can only be reconfigured manually by the service provider.
Cloud orchestration and automation are part of a bigger picture
Ultimately, however, cloud orchestration and cloud automation are two pieces of a much broader picture. When planning or designing new cloud services, don't start the discussion with the data center technologies -- or even worse, specific vendor hardware offerings. Start from the business end by asking the following:
- What are the services we're planning to roll out?
- What is our unique business proposition (or, where are we better than Amazon or Google)?
- Do we have the sales force to sell these services (or, what is our go-to-market strategy)?
- How will we implement cloud orchestration and cloud automation technologies to develop a self-provisioning portal?
- What are the technology requirements of the services we're planning and of the self-provisioning portal?
- What would be the ideal data center design to support these requirements?
- What are the appliances we could use to build the required data center?
For whatever reason, the cloud services discussions commonly start at the last question -- especially when the decisions are vendor-driven -- and the first six questions aren't addressed until after the hardware has been ordered. Don't fall into the same trap.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Check out his IOS Hints blog.
This was first published in October 2011