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.