The Cloud Isn't Everything -- You Need a Guide
DoD best practices can be useful in guiding enterprise cloud decisions.
You may not worry the same way the U.S. Department of Defense does, but many of its cloud concerns are relevant to most, if not all, organizations that are considering or using cloud services. Among the major considerations? Security and availability.
DoD Guide to the Cloud
The Defense Information Systems Agency (DISA) has compiled a 23-page collection of best practices discovered during cloud pilots conducted for the benefit of the DoD community. DISA published the document, "Best Practices Guide for Department of Defense Cloud Mission Owners," in August.
As suggested in the title, this document is meant to be a guide, is not a policy statement. (But security mandates do come in the DoD Cloud Computing Security Requirements Guide.Compliance with the SRG is a DoD requirement for cloud solutions, including both for commercial- and government-provided offerings.) The guide does not compare offerings or promote any particular vendor or provider. It is the result of cloud investigations with an eye toward providing insight into potential problems and sharing recommendations, suggestions, and solutions.
How Much Cloud Do You Want?
You can receive IT services from the cloud via the software-as-a-service (SaaS) model. A variety of cloud communications providers offer unified communications in this model, or UCaaS.You can go in the other direction, too, and use the cloud as an asset of servers and network connections. This is called infrastructure as a service (IaaS). Or, you can go with a hybrid approach, where some of the functionality is in the cloud and the remainder is performed on premises.
The decision on cloud should come down to business objectives and technology. Then which type of cloud your organization adopts, and at what rate, will depend on cost, security, IT staff support, functionality, and availability.
While the graphic below provides a breakdown on XaaS offerings, the guide focuses on IaaS, where the organization can run its own software like a UC package and have direct control of the hardware.
The Cloud Means Shared Responsibility
Shared responsibility is at the heart of cloud implementations. How much work should move into the cloud? What control will be available to you? How reliable is the cloud and the access network? What happens in the event of an operational or security problem? How will the cloud provider resolve these problems, and how quickly?
The shared responsibility is what makes the cloud decision difficult. In most cases the cloud will be less expensive to use. It may offer technology and services that do not exist in the organization. CAPEX becomes OPEX, and often makes the cloud a good financial decision as well.
But cloud failures are inevitable. You can estimate the cost of a failure, but you will not know the ramifications until you experience the downtime. IT's responsibility, then, is to decide the level of availability required for each application: high, moderate, or low. Differentiating on the availability level may provide cost benefits, with some cloud providers offering lower prices for lower-level availability requirements. On the other hand, the XaaS may have only one level. The organization should create a mechanism to track needed availability for different users; this can lead to greater satisfaction.
The guide mentions three types of failures to take into account:
- Application Failure - Everything works except the software in use. Fault-tolerant application design should be built into the application.
- Server Failure - The server can fail or be misconfigured. A load-balancing configuration can spread the workload across multiple servers as a way to operate successfully during this situation.
- Data Center Failure - This is the biggest disaster. The cloud service should be configured with the data in a separate data center in a different zone where the workload is split in two or more zones.
Don't accept the cloud provider service-level agreement on availability as a given -- and make sure you read the caveats (disclaimers) in the cloud agreement. Are they acceptable for your organization? What some cloud users may not realize is that the scenarios covering cloud availability may have security vulnerabilities when compared to a single server performing all the work. So check on the security capabilities of each of the failure response methods.
Lessons From the Guide
To wrap up, here are a few lessons learned:
- Regardless of type of cloud service in use, the provider will offer a range of design choices. Do not be overly concerned and worry about selecting the wrong type. You can usually change the design in or near real-time.
- The guide states: "When deploying a web front end server, it can be discovered by web crawlers like Google and Yahoo! Upon discovery, the web crawlers can hit the site hard and eventually bring the site down. The remedy is the placement at the root site level of a robots.txt file, which deterred or deflected web crawlers." For more information on how to build a robots.txt, including syntax and format, the guide recommends the information found here.
- Determining bandwidth requirements can be difficult when usage-based billing is applied. Most organizations will have little or no real-world experience on which to base their bandwidth requirements. The guide cited one example in which the estimated 500 GB in traffic per month turned out to be closer to 2 to 5 TB per month. With that in mind, the recommendation is to multiply the initial estimate by four, and review bandwidth usage at least quarterly.