Chapter 3. The Cloud Operation Journey
Over the last few chapters we have covered what cloud is, and how it changes IT operational and consumption models that businesses have become accustomed to. Unless you are starting a brand new business, it is very difficult to flip the switch and move to a fully automated and orchestrated cloud environment. More than anything, the adoption of cloud is both a journey and a process. In this chapter we will discuss some good practices and tactics that are necessary to implement to start benefiting from cloud today.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 3-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
Caution
The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.
1. What is shadow IT?
a. Unauthorized use of public cloud resources for corporate software development purposes
b. IT services that have been compromised by an attacker
c. Authorized use of public cloud resources that is charged via a credit card
d. A public cloud offering
2. What are some of the issues with shadow IT?
a. Higher costs
b. Data privacy
c. Compliance and security
d. All of the above
3. What best describes the difference between cloud automation and orchestration?
a. Automation is easy and orchestration is hard.
b. Automation is focused on tasks and orchestration is focused on processes.
c. None of the above.
d. All of the above.
4. What is the value of standardization for cloud offerings?
a. Consistency
b. Lower total cost
c. Speed
d. All of the above
5. Which item best describes workflow from a cloud perspective?
a. Workflow is the execution and automation of business process.
b. Workflow must have flow charts and solid documentation to function.
c. Workflow should be loosely coupled to process for maximum agility.
d. None of the above.
6. The role of culture is crucial in cloud because:
a. Culture is not an issue for cloud.
b. A rigorous culture is necessary for success in cloud.
c. A fun culture is important.
d. Cloud changes how people and systems interact.
7. What is Cisco Domain Ten?
a. The next version of Domain Nine
b. A framework that is useful in guiding an organization in its cloud transformation
c. A marketing plan to help business leaders understand cloud
d. None of the above
8. At what level is virtualization addressed in Domain Ten?
a. Domain 3
b. Domain 5
c. Domain 2
d. All of the above
9. Which domains are the user portal reliant upon being in place?
a. Domains 3 and 4
b. Domains 1 and 5
c. Domains 5 and 6
d. All of the above
10. Automation and orchestration are covered in which domain?
a. Domain 3
b. Domain 6
c. Domain 7
d. None of the above
Foundation Topics
Embracing Cloud
The business climate today requires businesses to continually innovate and move faster than they ever have before. Your company has to find a way to get closer to customers, lower costs, and deliver a better service than your competitors. For many companies that means they have to reinvent themselves on a continual basis to maintain relevance. The disruption caused by new and nimbler competitors has proven to be a real threat for even the largest and most established companies. A small company with a hot new application can capture a surprising amount of market share in a very short time. This threat of digital disruption is requiring a very different way of thinking when it comes to IT and applications. Implementing a cloud operational model and technologies can allow your company to compete in a business environment that rewards speed to market. Ultimately, fast always wins the race.
It is important to recognize at the beginning that cloud is a different IT delivery model from the traditional one that many companies follow. Cloud requires a shift in thinking away from a device-centric approach to application delivery, to one that is focused on the offering of a service. Do your users care which server their application sits on? Do they know if it’s in your data center or sitting in someone else’s out on the Internet? The use of the service is what really matters to your business, and regardless of how the service is delivered, it must be high quality and reliable. The service can reside within your data center, where you maintain and operate it, in a public cloud provider, where you leverage their infrastructure, or as a Software as a Service (SaaS) application that you simply use. This services-centric approach is one of the reasons why more and more businesses are turning to SaaS to reduce the complexity and cost of maintaining some applications.
The SaaS consumption model can satisfy business and user needs while netting the saving from a provider’s lower cost model. Consider email, for example. It is an expensive application to run, not only from a compute and storage perspective, but also in terms of the manpower needed just to keep it operating. With all of the security patching, operating system updates, database maintenance, and configuration requirements, those tasked with keeping email up and running have little time for anything else. Email is a crucial tool for business, no doubt about it, but the cost of offering this service is fairly high. By outsourcing email to a SaaS cloud provider, companies no longer have to dedicate so much time, energy, and resources to delivering the service. The business gets the service it needs, but at a lower cost. Engineers can now work on new projects that help the business serve its customers better.
Shadow IT
More and more we are seeing services that were traditionally run in house moving to a cloud provider. Lines of business have found it quicker to just contract for a service themselves and bypass traditional IT. Why? Because in many cases it is faster than waiting for a traditional IT shop to get a new application rolled out. IT is inundated with a backlog of work from just keeping existing systems up and running, often preventing IT from moving as fast as the business needs. This disconnect has caused numerous problems and tension within the business. Delays rolling out new projects that allow the business to generate more revenue have caused lines of business to go out on their own and embrace external cloud service providers. With all of the advances in self-service offerings and on-demand access to resources and capabilities, it is little wonder that businesses are struggling with “shadow IT,” where internal IT is bypassed entirely. While this may seem like a quick fix, it really exacerbates the problem. Some of the major issues of shadow IT are
Compliance and governance: Complying with PCI, SOX, HIPAA, and the rest of the alphabet soup of regulations that IT organizations have to ensure they are compliant with can be a real challenge in a shadow IT world. Lack of compliance can be very costly, and if you aren’t in full control of your IT environment, it can be easy to run afoul of these regulations. Without the appropriate data protection controls in place, your business can be at considerable risk from shadow IT.
Technology and management silos: Who manages the service? In a shadow IT situation, it becomes the responsibility of the part of the organization that signed up for the service. It’s not a full-time job and often the people responsible for managing the service are not trained to do it properly. Things like single sign-on and other services also will not be available without getting IT involved, so you will have separate account access and passwords that need to be managed.
Application portability: Moving your application from one cloud provider to another can be very difficult or, in some cases, impossible without rewriting parts of the application. Many cloud providers have lots of advanced features that you can use as a service within your application, but those services are only available if you are their customer. This can act as a lock that will prevent you from negotiating better rates, or finding a different provider. Lines of business may not understand this impact when building applications in the cloud on their own.
Data privacy: Who can see the data, and where is it stored? This has always been a major concern for businesses considering a move to the cloud. They are still responsible for keeping information safe, but now they don’t get full visibility into the data protection controls that their provider has implemented.
Higher cost: Shadow IT can get expensive really fast. One of the benefits of having a centralized purchasing process is that you can leverage volume discounts and track and monitor overall usage costs. By going off on their own, each department will be a separate “customer” to the provider, resulting in serious duplication of effort and less optimization of resources.
Lack of consistency: If the accounting department needs project management software, for example, they will go out and get whatever they feel meets their needs. If another group, like HR, needs the same software, they will not be privy to the fact that accounting already has an application that they could simply use. Instead, HR may pick a different platform, which may be more expensive and totally incompatible. This lack of consistency can interfere with business logic and make it harder for different groups within the same business to work together.
The Journey Starts Here
To stay relevant and help the business better achieve its goals, an IT organization is going to have to embrace a mixture of public, private, and hybrid services. Some applications will be better suited for running on premises and others will work fine in a public cloud. There will also be a need for applications that are in a private cloud and a public cloud for scaling and better geographic performance. The key is to catalog the capabilities and requirements of existing and new applications and match them to the delivery model that makes the most sense. In this way IT becomes a broker of services and can begin to embrace cloud as a business enabler, as discussed in Chapter 2, “Cloud: A New Operations Model for IT.” Through this approach, IT becomes a better business partner and can be a driving force for better business results. IT has to move away from being just a cost center and become a new business-acceleration engine.
Unfortunately, there is no magic cloud bean that you can plant in your data center. Realistically, you need to expect a multiyear journey as you change how you operate IT services and implement a robust cloud infrastructure. That’s not to say that your company can’t benefit today from cloud capabilities; it is just not going to happen all at once. How fast your organization can transition to cloud depends on its size and appetite for change. A large enterprise with thousands of applications will take longer than a small organization to transition due to the complexity of the environment of a large business. You must consider the fact that you are in effect rewriting the rule book for how you deploy, maintain, and operate business applications. You also must consider the various departments and divisions that will need to be included to ensure that they are not unduly impacted by the move to the cloud. Regardless of the size of the organization, it is wise to start your cloud journey on small, focused areas of the business that can handle the changes that cloud will require.
In Chapter 1, “An Introduction to Cloud,” you were introduced to IaaS, PaaS, and SaaS as deployment models for cloud services. There are many existing applications and services in your business for which you can find opportunities to take advantage of cloud practices and deployment models. Some good areas to look at are
Collaboration applications: These applications allow for internal collaboration between employees and external collaboration with customers. There are numerous SaaS offerings as well as cloud-friendly private options like Cisco Spark.
Business support applications: These apps are important to the business but often are expensive to run and require dedicated expertise. Examples include email, marketing, CRM, and sales apps.
Customer-facing web applications: Dynamic scaling and availability can all be increased by moving these services to a cloud environment.
Branch office infrastructure services: Telephony, Wi-Fi, and networking can all be moved to the cloud to simplify management and support. Cisco Meraki is a prime example of leveraging the cloud to reduce cost and ease administrative burden.
Disaster recovery services: You certainly could build a dedicated backup site, but it often makes more sense financially to use a cloud provider to handle these services.
Development test environments: This is one of the most useful areas to use cloud. Developers need access to test environments that closely resemble production, and they often need these test beds on demand. Implementing cloud can help keep them from trying to solve this need themselves (shadow IT).
File storage: File storage is a necessity for every one of your users. With good Internet access, a centrally managed cloud storage solution is a very effective way to provide this service at a lower overall operational cost.
In the next section we discuss Domain Ten, a full framework for cloud adoption that Cisco has built. It is a fantastic resource for planning and developing your own journey to the cloud.
Cisco Domain Ten
Domain Ten is a framework that can be useful in planning an organization’s cloud transformation. It consists of ten key elements that cover everything from the infrastructure all the way to organization and governance. The intent of the framework is to map businesses-specific desires and outcomes to the cloud capabilities IT can offer, which can be very valuable in creating a road map for planning a transition to a public, private, or hybrid cloud. The best part of Domain Ten is that it builds capabilities in a natural way, from the infrastructure components to operations and governance. By ensuring each domain is adequately cared for, you will minimize gaps that often cause cloud projects to fail. Cisco even offers a fee-based assessment service that will map your environment and give you recommendations on what you need to do next. Figure 3-1 shows a graphical representation of the Domain Ten framework.
Domain 1: Unified Infrastructure
There are two primary components of Domain 1: infrastructure, which includes the servers, network, and storage, and environment, which consist of the space, power, and cooling capabilities within the data center. The infrastructure forms the foundation for the resource layer on top of which your cloud environment will be built. The goal is to standardize on hardware components to make it simpler to add capacity and maintain the data center in as much of a plug-and-play fashion as possible. If you need more compute, simply add another server and add it to the pool of resources at the infrastructure layer. The same thing applies to both network and storage. It’s just easier and often more cost effective to manage a consistent set of hardware components. While a single set of standard components may not be feasible, the goal is to minimize the number of unique components as much as possible. By doing this you are able to more easily pool like resources, which is an essential foundation for virtualization and allows for dynamic provisioning. In addition, it is important to have infrastructure that is designed from the ground up to operate as a system, which will help simplify operations, lower overall costs, make virtualization and automation less complex, and help transition legacy systems to a modern architecture.
Environmental factors dictate the amount of resource you can host within your data center. Network infrastructure takes up space, needs power, and has to be kept cool to operate adequately. You must plan out your growth strategy to take these factors into consideration. High-density computing requires less space but significantly better cooling, and your existing data center design can easily become overutilized.
Domain 2: Abstraction and Virtualization
Virtualization allows for better utilization of data center resources by enabling you to run on a single server multiple workloads that in the past would require a dedicated server for each. Most organizations have made the shift to virtualization technologies in their data centers, and it is not uncommon to see 70 to 90 percent virtualization of applications. The benefit of virtualization is that it allows a common set of resources to be used in very efficient ways. Server virtualization has driven advances in storage and network virtualization as well. Storage virtualization combines physical storage from numerous storage devices to appear as one device, with scalable capacity. Network virtualization combines available network resources into a single pool of resources that can be redeployed in real time to meet user demand. CPU, memory, network, and storage can be added or subtracted as the application needs it, either with the click of a button or automatically. The flexibility, scalability, and resource pooling afforded by virtualization are core tenets of building a cloud infrastructure.
Abstraction provides a logical representation of the physical hardware underneath. By making this separation, you remove the traditional dependencies of specific hardware such as drivers and low-level device control code. Anyone who has had to load server-specific drivers in an operating system knows how painful it is if you have to move that application to a new server (even from the same vendor). Abstraction removes those problems and allows the application and operating system to be very portable. The independence from the hardware enables an organization to be flexible and to support many different types of internal customers. Users don’t care which server their application is running on in the data center. They just want it to be fast and always available.
There are many different technologies that you can choose to enable virtualization. Microsoft, VMware, KVM, and Docker containers are all viable platforms to run your virtualized environment on. Each has its own specific pros and cons. It is important to standardize as much as possible to simplify the administrative burden. A multi-hypervisor environment doesn’t have to be a bad thing, but you have to plan for the differences in architecture for things like QoS, policy, security, and metrics.
Another important aspect of Domain 2 is understanding the types of virtualized workloads that are going to be required. Some applications work very well in a virtual environment, whereas others require all of the CPU and memory a server can supply and, as such, work best on a dedicated physical server. Will your organization be virtual only in your cloud offerings, or offer bare metal as an option as well? In the public cloud you often must use virtualization in a cost-effective manner. These decisions will impact the types of offerings your organization will be able to provide within the service catalog.
Figure 3-2 shows Domains 1 and 2 and their functional relationship in the Domain Ten framework.
Domain 3: Automation and Orchestration
What is the difference between automation and orchestration? While they are similar concepts, their scope is ultimately where the core difference lies. Automation is accomplished on a task or a function without human intervention. When you open your garage door, the light comes on automatically and shuts off after a period of time. While this is a very simple example of automation, it highlights one of its most important values. It is great for repetitive and monotonous activities. If you had unlimited money, you could hire someone to flip on the light switch and then turn it off when you went in to the house. Could you even imagine how boring and wasteful that job would be? Unfortunately, there are a lot of similar activities that you must endure today within IT. From a speed perspective, a human being could never accomplish the same task as quickly as a computer. Computers are excellent at executing repetitive tasks quickly and consistently. Human beings, on the other hand, do a poor job with repetitive tasks, often introducing inconsistencies, which prevents standardization. The speed you get from automation is substantial. Automation technologies also don’t have to take days off for vacations. They work around the clock, on holidays, and on weekends without getting tired, like the good robots that they are.
Orchestration is the sequential coordination and direction of automated processes. Continuing our garage light example, orchestration is a layer above automation that takes inputs from tasks and acts on the bigger picture. Using orchestration, I can detect that the garage door light automatically came on and infer that the owner of the home was coming inside. That trigger from the light could be used to kick off a workflow that lowers the temperature in the home (in summer), turns on the hallway light, and plays some music. Orchestration is the “brains” behind cloud, and is used to translate complex workflows into something actionable. It also is the mechanism used to tie business logic to technology.
Domain 3 is where IT begins the cloud journey in earnest. What starts as a desire to make managing all of the complexity of a traditional data center easier can turn into a need for automation technology that can remove as much manual work as possible. It doesn’t take long to figure out that many IT processes are filled with repetitive tasks that don’t add value and suck up way too much time and energy. If you are manually provisioning infrastructure today, using automation technologies will seem like magic.
In simple terms, orchestration is the logical sequencing of automated tasks. Think of a conductor of an orchestra, responsible for ensuring that a melody is created from the sound generated by each of the instruments. Orchestration applies workflow and business logic to automation technologies to produce the same effect in IT. The full life cycle of an application can be orchestrated from provisioning, patching, and decommissioning without a single human being having to touch the infrastructure underneath.
Orchestration requires customization to be truly effective. While there are many good products from Cisco to help right off of the shelf, the real power comes from mapping IT’s workflow into instructions that the automation/orchestration tools can follow. This means that you have to understand and document the various processes you want to automate. It’s time consuming but worth it. You simply can’t have a functioning cloud environment without this step.
Figure 3-3 shows Domain 3 in the Domain Ten framework.
Domain 4: User Portal (Self-Service Portal)
The user portal is the way in which your internal customers will interact with IT in a functional cloud environment. There are typically two main components: the customer portal itself, which is a web page that allows for the ordering of IT services, and the workflow and backend systems that are responsible for delivering the requested services through automation. The user portal is the face of IT and, as such, needs to be easy to interact with and request services from. It’s essential that the interface be built from the user’s perspective and hide as much of the backend complexity as possible. Bob in accounting doesn’t need to know what VLAN his accounting server needs to be in, for example; the system should automatically determine that as part of the service delivery.
Role-based access control is another important aspect of this domain. Who can access what services? If you are a developer, you need access to different services than those an office administrator needs access to. Is there an approval process and, if so, who needs to be part of that process? How is software licensing handled? You could easily run out of licenses without a way to automate the delivery and reclamation of unneeded applications. All of these types of questions need to be explored for the customer portal to be effective. (Domains 9 and 10, discussed later, cover security and governance in more detail and from a top-down perspective.)
Domain 4 is tightly coupled with Domains 5 and 6 because it can be thought of as a presentation of the service catalog and financial chargeback/showback models in use. The self-service portal is responsible for providing cost estimates, delivery times, and service operational status. The user simply needs to know what their requirements are so that they can select the best offering from the service catalog.
Domain 5: Service Catalog
The service catalog is a map for your cloud. It will describe all of the various services IT will offer. It is like a menu in a restaurant; whatever is in the catalog is something that the end user can order. As mentioned in the prior section, the self-service portal is where this information will be displayed, and it may also include details about the financial obligation tied to the service. The concept of the service catalog was covered in Chapter 2. Domain 5 is about the creation of an effective service catalog, in which one of the most important aspects is the standardization of IT offerings.
The service catalog needs a ruthless level of standardization to be effective. Without standardization you simply cannot offer a viable self-service cloud offering. An easy way to better understand the role of standardization is to look at the construction industry. There are two types of home builders: custom builders and spec home builders. Both will build you a house, but in very different ways. The custom builder offers the most options. If you can draw it on paper, the custom builder can potentially build it for you. You will get exactly what you want, from the type and brand of hardwood floor to the color of the bathroom toilet paper holder. It is completely customizable. It can also become very expensive really quickly. That Italian marble you want might be very difficult to attain and be at a premium price because it is not as commonly bought. The builder is going to pass that cost on to you, inflating your ultimate bill. A custom home will also take longer to build. All of the detail work requires extra time and added labor to complete. These builders don’t often build a large number of homes in a year, so they need to make as much as possible on the ones they do build, which inflates the cost even further.
The spec home builder, on the other hand, has a very different business model. They typically have a limited set of floor plans, with four or five models at most, which makes building each home simpler. They also offer a specific set of customized options (colors, carpet types, tile, etc.) that are pre-priced and able to be added to the home easily. These builders are looking to minimize the variability between homes so that they can build them faster, taking advantage of consistency to drive down the cost of building. All of these factors give the spec home builder the ability to better anticipate their potential profit and build a larger number of homes.
Traditional IT processes build custom apps, whereas the cloud model looks to deliver spec apps for all the same reasons that spec home builders choose to deliver spec homes. It is less costly and faster to deliver something that you can replicate, where all of the nuances of the platform and configuration are already worked out in advance for you. If you want to move fast, you have to be ruthless in defining the standard offerings within your service catalog. If you remove as much variability as possible, the process of accounting for the true cost of the offering is dramatically simpler.
Standardized offerings are also much easier to automate. Automation can handle some variability, but the more you add, the more complex the logic becomes and the more potential that exists for failures to creep into the equation. Complexity is what you are trying to remove with cloud, not add it back in. The service catalog isn’t just a one-time exercise, but rather needs to change based on new technologies and services being offered. The self-service portal represents the service catalog to the end user and should enable easy changes to service details and map back to the associated workflows necessary for delivery.
Domain 6: Financials
The financials domain is the area in which you define the mechanism and cost structure for usage-based IT chargeback and showback. This will allow your users to pay for the services and resources that they request from the user portal. Because cloud is based predominantly on a utility model, just like electricity, you are charged for the amount you use.
In cloud you pay for the CPU, storage, and bandwidth used by your applications. The hard part of creating these cost models is to define a realistic “cost” for the service. You have to factor in the cost of hardware, power and cooling, network infrastructure, and software, as well as any labor or administration costs associated with provisioning the service itself. Even if the service is fully automated, there is a cost associated with building and maintaining the service that needs to be accounted for.
Chargeback is important to pay for a service, but what about the question of whether or not a service needs to be in house or moved to the public cloud? This almost always comes down to a question of cost and risk. Is the security risk sufficiently high to justify the additional cost of hosting the service within your own data center, or is it so much cheaper in the public cloud that it is worth the risk of not having complete control over the application? To answer this, you need to have a solid understanding of the real costs of the application or service, as detailed earlier, to get an apples-to-apples comparison. You can, of course, choose a hybrid approach, in which case you should have a strategy that supports the coexistence of private and public cloud solutions. This way, a workload or application can be appropriately placed based on its technical and business requirements, and taking into account any trade-offs in flexibility, security, and costs.
Domains 1 through 6 are the foundation of a cloud environment, and are what is needed to provide Infrastructure as a Service. IT is opened up like an online retailer, enabling users to consume services as if they were buying books or toasters. A private cloud doesn’t have to be the only service offered; you can augment with public cloud services and capabilities too. Figure 3-4 shows Domains 4 through 6 as the combined user portal.
Domain 7: Platform and Data
Platform in cloud refers to the selection of software elements that sit on top of the infrastructure and run the applications themselves. There are typically three components that make up the platform domain:
Operating systems
Middleware
Database
All of these components are provisioned through the user portal and built on demand. If a developer needs an operating system and a database for her new application, she can simply select it from the catalog and provision the infrastructure and software needed for it automatically. This capability is in essence a Platform as a Service.
The platform domain is one of the most important to create strong standards for. If IT customers can choose any OS combination, with any CPU or storage requirement they see fit, then the ability to automate simply disappears. You have to decide what you will and will not support so that you can provide consistent and replicable offerings. The benefit is the ability to move away from manual and custom provisioning into a highly automated cloud environment.
Domain 8: Applications and Analytics
Applications are what run and support the business, and it is IT’s job to make sure they are available and operating as they should. An application can be a home-grown custom app, an off-the-shelf commercial app, or a SaaS app. The goal of this domain is to build an application strategy to determine the best deployment model that meets the needs of the business. All applications need to be assessed for cloud readiness. Many legacy applications are just not a good fit for a cloud environment because they were not developed to take advantage of cloud infrastructure and may need to be rewritten (modernized) or upgraded.
Many businesses are still reluctant to host the most sensitive of data in the public cloud and, as such, tend to keep applications used in HR and accounting, for example, in house. Really, any application that stores personally identifiable information (PII), doesn’t have a web front end, or needs direct access to backend processing/mainframe will need special attention when considering a move to a public cloud.
Beyond the security concerns of data privacy, there are a number of application characteristics that need to be considered before moving into a cloud environment. First and foremost, was the application built to allow for portability? Older applications were conceived and architected before virtualization was a viable option. Their inherent architectures just don’t do well when virtualized.
Maybe some of the components are looking for specific pieces of hardware, like a crypto card, meaning they will continue to need dedicated hardware until they are rewritten or retired.
Where data is stored can also be a challenge for legacy applications. If your application needs data access to production systems, this could be problematic if hosted in a public provider. The application would have to either replicate the data over the Internet or pull the data directly from the production data store. Both of these can be design nightmares if not properly planned for.
Hosting the application yourself, migrating to the public cloud, or using a SaaS offering are a few of your choices. This analysis of your applications is the first step in determining the viability of migrating an app to the cloud. Figure 3-5 shows the Domain 7 (PaaS) and Domain 8 (SaaS) layers.
Domain 9: Security and Compliance
While cloud security and compliance sit in Domain 9, they apply to the entire cloud stack. Securing the provisioning process and safeguarding the various components of the cloud environment must be planned out and implemented. Every industry has specific regulations and laws that businesses need to comply with. Documenting and implementing the necessary security controls and safeguards keep data safe, and your CEO out of the newspapers.
Domain 10: Organization, Governance, and Operations
Organization, governance, and operations comprise the tenth and final domain of the Domain Ten framework. This domain details how the business will structure IT groups and departments, the safeguards and enforcement of corporate standards, and operational processes and procedures. Because you don’t operate a cloud the same way you do a traditional IT environment, your staffing and skill requirements will be different. Do you train existing resources, or hire someone new? Governance issues will always pop up as you embrace cloud. Who gets access to what? What services should be put in the service catalog? Last but not least is the need for strong operational models that fit cloud. Ideally you will have significant automation within your cloud, because manual processes just don’t work in a cloud model.
The role of culture and organizational structure in cloud is very important to its success. Cloud changes how applications, data center infrastructure, and devices interact with each other, but it also changes how people interact with IT as well. Automation is king and manual interaction is avoided at all costs. This is a very different environment than many people and IT organizations are used to. When you move to a cloud operational model, you just can’t continue doing things like you used to. Change is hard and can be difficult for an organization to embrace. Do you rip off the bandage or pull it off slowly? That’s up to the individual organization to decide. While change often is easy to implement, making it stick can be very difficult if your own people are resistant to it.
The various teams that have been built up over time in an IT organization are often in their own silos. Developers, security groups, storage administrators, and infrastructure teams are insulated from the needs of the other groups within IT. Cloud changes all of that, by breaking down many of those barriers. People have to work together because the systems are integrated.
A workflow is the execution and automation that follows a specific set of procedures and activities in order to accomplish a business process task. Think of all of the processes you follow on a daily basis. From brushing your teeth to making breakfast. More than likely you follow a routine that you have developed over time. This routine is a workflow. In IT there are many different workflows used to keep the lights on and the data center infrastructure running. When building a cloud environment, the goal is to leverage automation and orchestration as much as possible to accelerate activities and minimize the amount of effort needed. In order to automate your cloud environment, you have to document and codify your workflow processes.
A workflow is not just a combination of technical steps, but is also inclusive of the business process. Deploying a new server would include purchasing and acquiring the server, asset tagging, and depreciation accounting in addition to loading software and physically installing it. Complete workflow documentation is essential to successful cloud automation because it provides you all of the details necessary to implement the workflow in your cloud orchestration software, such as UCS Director. Workflows help you build the automation rules for your self-service user portal.
When you document a workflow, the goal is to leverage the lean techniques discussed in Chapter 2 to identify the minimum set of instructions necessary to achieve the desired outcome of the workflow. Simplification and optimization can be the benefit of this process, because they will also remove excess complexity in your automation scripts, which means less to troubleshoot.
When documenting the workflow, you start at the beginning and finish at the end result. In the middle will be all of the steps needed to move your process along to its desired result. You may also have decision questions that occur throughout the process that cause you to need to accomplish different activities. For example, say you want to document the process of mailing a letter. Your first step is to write the letter, the second step is to put it in an envelope, the third is to put a stamp on it, and the fourth is to drop it in the mailbox. Pretty simple, right? What if you don’t have stamps? Step 3 could then represent a decision step where you first check if you have stamps. If yes, then you put a stamp on the envelope. If no, then you need to create another set of steps for acquiring stamps. This is the same methodology that you will use to create automation workflows within UCS Director. Figure 3-6 shows an example workflow decision tree.
By automating workflows, you can greatly reduce the time it takes to process the task and also reduce the potential for errors that could be introduced in a manual process. The best part of a workflow is that it provides a level of visibility and assurance that every step in the process is followed consistently every single time. From a security and compliance perspective, this is a fantastic benefit, because so many security issues occur from people just not following standard practices. With automation, you can build the level of security required into the workflow itself, making it easier to pass security audits.
Figure 3-7 shows the final two domains.
Cisco Domain Ten is a good high-level framework that can help ensure all of the right components are in place to have a successful cloud environment. Each organization will have different cloud needs, so Domain Ten should not be looked at as a one-size-fits-all solution. Maybe IaaS is all you are interested in deploying today. The most important thing is that to get there, you need all of the first six domains in place. By focusing on thinking through and developing the right foundation for the next building block, you will greatly increase your chances for success.