Build it, Rent it, or Buy it, Three types of private cloud for government

There are two kinds of clouds we can build “behind the fence”, private cloud and community cloud. Private clouds can be on or off-premises. The primary characteristic of private clouds is that they are dedicated to one customer. There might be sub-organizations but all users would be from the same agency. The value cloud adds in this scenario is around simplification, agility, standardization and better utilization of resources. Even though we might not have the massive scale-out options a public cloud can offer, the users and administrators still get self-service, processes are automated, few administrators are required and standardization occurs because culture shifts from a “what do you require” to a “here are your options” model. All in a secure dedicated environment.

In some agencies this can generate huge cost savings because there are fewer platforms and software environments to maintain. Administrators are happier because they are automating manual processes, including security configuration and approvals. Infrastructure costs go down because workloads are scheduled and stacked more densely so utilization goes up. Users are happier because new environment stand-up shifts from taking weeks or months to taking hours.

There are a few different ways government can implement a private cloud. The first and least desirable is to build it themselves. In the “roll your own” scenario, government IT folks define services in some interesting and agency-specific way, stitch together “best in class” components themselves with spaghetti code, develop automation workflows in multiple tools, then pray. This approach is often attractive to IT shops that have a big investment in legacy tools and are most comfortable doing things the way they have always been done. The problem with this approach is that it doesn’t scale, cannot be easily federated with other environments and becomes exponentially more difficult to maintain as it grows in complexity.

The next approach to private cloud is for the government to pay a system integrator to build or rent them a private cloud. Today’s system integrator community has quite a few big brains and is doing some of the most cutting edge work there is in government IT, especially in the intelligence community. Some have well developed methodologies for delivering private cloud and impressive past performance. Others have data centers where they host vast swaths of government IT and can carve out dedicated environments that are capable of running classified workloads. The challenge with the integrator approach is simply to ensure that the integrator doesn’t take the roll your own approach described in a previous paragraph. It’s best to assume they wouldn’t, but there are a number of government IT shops out there which have been run by integrators for so long, it’s difficult to tell the difference between contractors and government employees. These incumbent teams know how to shape and win government contracts. Agencies just need to be able to ensure they getting the real shift that cloud promises.

The third and final type of private cloud is the engineered stack. This approach leverages cloud platforms engineered by vendors to provide pre-integrated cloud computing environments. The solution provider has done the work of connecting the moving parts and supports the entire cloud environment as a product. Sometimes this is called “cloud-in-a-box”. Some examples are HP CloudSystem Matrix, VMwarevCloud, Microsoft Private Cloud Fast Track, IBM PureFlex System, Oracle PrivateDatabase Cloud. The advantages of this approach include speed of implementation, turnkey delivery, less complex support model, the ability to leverage existing enterprise license agreements and deep integration into the vendor’s other products. It’s hard to compare these solutions apples to apples. Some provide narrow but deep integration in a particular IT tower such as virtualization and don’t do so well serving up cloud services outside their wheelhouse. Others can provide very broad sets of cloud services but require paid consultative engagement to realize their full benefit.

For government IT, the challenge with many of the engineered stacks is accreditation. As I mentioned earlier all government IT solutions must meet agency and government-wide security standards before they can be utilized. These standards were historically defined for component parts not solutions. Applications and hardware were “certified”, usually at the cost of the vendors, so they could be added to approved product lists for a particular agency. As agencies move to cloud models where components are not so important, agencies expect to see the same kinds of certifications on solutions that they saw on individual applications or hardware components. This works ok if you are inside a particular IT tower like storage or virtualization because those stacks are usually based on discrete products from a single vendor, but when you start to do more interesting things with cloud, the lines are blurred. A single cloud service could consist of multiple component services. Think about DevOps Platform as a Service, multi-vendor Database as a Service or Virtual Desktop as a Service. These services all require different kinds of servers (physical or virtual), different kinds of storage (SAN, NAS, iSCSI), network controls (physical, virtual, load balancing, data), security controls (firewalls, IPS, access controls), configuration management, etc. A virtualization vendor may be very good at controlling some of these components as they apply to virtual infrastructure but maybe not so good at reaching out of the virtualization stack to provision applications, databases, networks or physical servers.

This is a new paradigm for government IT security teams. They are used to testing, locking down and certifying individual pieces of the puzzle. All their processes are around discrete components. Now they are being asked to test and accept a “black box” for a service. Naturally they come back and say “Is it on the Approved Products List (APL), is there a Certificate of Networthiness (CON), is it FIPs 140-2, is it Common Criteria Certified, has it been through DIACAP, can it do PL3?” The answer is complicated. Maybe some or all of the components of the service are but now the Designated Approving Authorities (DAA) are being asked to evaluate the solution as a whole. Do they have to go through the accreditation process from scratch for the solution? Will vendors invest in the 1-3 years and millions of dollars to go through certification of an integrated solution that is still in a maturing market? All these questions often lead government entities to decide real cloud, in the commercial context, is a bridge too far and that maybe they will pull back to a much lower level solution, call it cloud and declare victory. There are government teams tackling this problem and many are doing it with a community cloud approach. I’ll talk about that in the next post.