Secure Environment for Federal Government Cloud Pilot

How is the Federal government hoping to achieve the $12 Billion in projected annual savings?  This projection was quoted by the MeriTalk Cloud Computing Exchange and published today by Forbes.com, and it doesn't seem too optimistic given that the Federal government is already saving approximately $5.5 Billion per year.

These savings have been achieved by individual agencies adopting cloud solutions, but such organic growth will only go so far.  In order to expand this in a generic and scalable manner, the Federal government would need a secure environment to test the cloud and run pilot programs.

Key features of such an environment:

1. Multi-provider provisioning and compliance

Agencies should be able to provision resources across cloud providers without having to worry about vendor lock-in.  This would require the use of a brokerage platform that enables auto provisioning across providers.  Monitoring would also be necessary to ensure the providers maintain SLA compliance, failing which they would be quarantined.

2. Fed certified cloud providers
The list of cloud providers should include those that are FedRAMP certified, or at least FISMA compliant.  Agencies should be able to compare providers side by side and pick the best-fit provider.  This requires standardization of cloud offerings and pricing models.

3. Integration with existing data centers private / hybrid clouds
Agencies should be able to interoperate between the cloud and their existing data centers and private clouds.  This provides a backup plan in case the cloud solution does not succeed.  For this feature, the test environment would need to be agnostic across VMware, Xen, Hyper-V, vCloud Director, etc.

4. Connectivity to existing security frameworks
The test environment should be integrated with the security frameworks currently used by the Federal government.  In this way, valuable resources need not be wasted in re-designing a security framework that is already very efficient.  Instead, resources can be assigned to enhance the existing framework with intrusion detection and intrusion prevention features.

5. Complete cost transparency
First of all, agencies should not be required to sign multi-year contracts with cloud providers.  Secondly, the cost of cloud services should be visible at the highest level so that budgets may be allocated based on resource requirement.  This allows complete auditability as well.

6. Recalibration based on historical data
Cloud usage data should be constantly correlated with cost to ensure that cost is minimized without impacting mission goals.  This requires the test environment to be powered by advanced analytics engines for continuous recalibration through command and control.

All the above features would need to be tested by the Federal government through a pilot program before executing any major cloud migration initiatives.  If successful, the test environment can then be established as the official government cloud portal which is bound to be successful because it has been built on NIST standards and governed through strict monitoring and compliance.

Gravitant published in latest Gartner Report

What makes a Cloud Services Broker (CSB)?
Gartner identifies three primary roles that qualify a company to be a CSB:

• Aggregation (across VARs, IT distributors etc)


• Integration (with SIs etc)


• Customization (for SIs, PS etc)

"As both an enabler and a cloud brokerage, Gravitant pulls together a number of the capabilities that IT organizations, VARs and SIs, and public cloud providers can use to extend the value of their offerings." - Daryl Plummer (Gartner Analyst)

Full report here...

Part 2 - Your application would be a GREAT FIT in the Cloud if...

1. Your application is fairly isolated from other applications

Typical examples of isolated applications are CRM, messaging, and other custom built applications.  On the other hand, traditional ERP applications are tightly woven with others and hence might require re-architecting the application to fit the cloud.

Alternative: In most cases your application is probably somewhere between isolated and completely integrated with other applications.  In this case, here are some options based on the nature of the dependency:

1. Communication channel dependency - Create a distributable communication channel that is secure
2. Architecture dependency - Make a copy of the shared layer for the cloud
3. Single sign-on security - Upgrade single sign-on to support remote sign-on

If none of these options are feasible, then either both applications would need to be migrated to the cloud or both should remain as is.

2. Your application architecture is cloud friendly

Any application on an x86 platform would work well in the cloud regardless of the operating system.  If the application is on some platform other than x86 and you still want to go cloud, then you would need to re-architect the application to the x86 platform before you begin migration.

Also, if the online-architecture is web based or client server, then your application is more cloud friendly.  Moreover, if the online-architecture is heterogeneous from the batch-architecture, then your application is even more cloud friendly.

Alternative: If your application is on any other platform (such as Sun Sparc, Power PC, or Mainframe), then it might be a better candidate for managed hosting.  Another reason to opt for managed hosting is if your servers require software licenses that can only be tied to physical cores.

3. Your application security requirements are satisfied by FISMA compliance

Some cloud providers are FISMA (Federal Information Security Management Act) certified which ensures they are satisfying all the Federal security standards as measured by NIST.  In addition to FISMA compliance, security can be further enhanced by engaging managed services for security on the cloud (like netForensics).

Alternative: If it is necessary for all the data and/or hardware to be located on-site, then a private cloud or a public/private hybrid may be an option.

<- Back to Part 1 - Your application may NOT YET be ready for the Public Commodity Cloud if...

Creating a Virtual Machine on/off schedule

“Wouldn’t it be nice to have a schedule to automatically turn VMs on or off at certain times of the day?” I’ve heard this from many of our clients, and this is definitely an interesting optimization problem.  Since most providers price by VM hours, one always needs to make sure not to end up with VM sprawl.  The fact that licensing on these VMs are also priced by the hour doesn’t help either.  So, yeah VM scheduling would be great but where do we start?

Actually, it isn't very complicated because most of us use load balancers anyway.  The load balancers are monitoring VM utilization (through connection count) and can thus keep track of times when all the VMs are underutilized.  Dr. Zarifoglu, in his load balancing article, identified thresholds for turning VMs on or off based on the workload.  So, turning one or more VMs off is simply an additional step after load balancing!

This leads to two possible approaches for VM Scheduling:
Dynamic scheduling – where VMs are automatically turned on or off based on demand and threshold policies, or
Static scheduling – where one would simply monitor VM utilization over time and come up with a user defined schedule that doesn’t change.

Obviously, the best approach would be to have a hybrid solution where the static schedule is automatically modified at fixed time intervals (say weekly) and is executed only after being approved by an administrator.  See Gravitant’s CloudMatrix – Policy Manager for more details on managing VMs in the cloud.

Caveat

The caveat is that most cloud providers don’t allow simply turning VMs on or off (except for OpSource and Terremark).  Most providers will charge for stopped VMs as well, unless the VM is ‘deleted’.  So, an alternate process for turning a VM off (with the expectation of turning it on again at some point in time in the future) is to first create an image of the VM and save it in the backup storage space, and then ‘delete’ the VM.  In order to turn this VM back on, a new VM needs to be created and then the image from backup storage needs to be installed on the new VM before it can become functional.

Alternatives

As a result, the process of turning VMs on or off may be not be time and cost efficient.  However, here are a few alternate ways to do this:
(1) Go with a cloud provider like OpSource that allows VMs to be turned on or off at the click of a button and doesn’t charge for VMs that are turned off. (Note that there is a small fee for storage space occupied by the VM).
(2) Go with a cloud provider like Terremark that doesn’t even price by VM.  However, they would still charge for the OS licensing and storage if the VM was turned on at any point in time during the month.
(3) Go with any cloud provider but subscribe to an automated backup and restore service. Gravitant expects to provide this capability in its CloudMatrix console in early 2012.

For more information, go to www.gravitant.com.

Part 1 - Your application may NOT YET be ready for the Public CommodityCloud if...

1. Your application demand is very stable and doesn't fluctuate much
If your servers are not under utilized, then you are better off keeping things the way they are, unless you want to plan for disasters or other unplanned events.  This is because cloud pricing models are geared for elastic computing. It would be more expensive to provision 4 VMs than to run 4 servers in-house.  The benefits of provisioning fewer VMs and using burst capabilities will only be realized if such demand fluctuations are expected.

Alternative: Look for cloud providers (like Terremark) that price by usage (regardless of the number of VMs provisioned).

2. Your application's licenses can only be tied to physical cores
Many software licenses have not yet made the shift to the world of virtual machines.  For example, Oracle licenses can only operate on a fixed physical core, whereas virtualization technology was developed precisely to separate the physical layer from the software layer.  If Oracle is installed on a VM, the VM would be assigned to certain physical core(s) at one point in time and some other core(s) at some other point in time, which would violate Oracle licensing rules.

Alternative: Look for cloud providers (like Savvis) that have managed hosting servers which share a VLAN with their cloud.  In this way, Oracle can be installed on the managed hosting server while the rest of the application can be deployed on the cloud.

3. Your application stores a very large amount of data on the cloudWith storage disks getting cheaper by the day (1TB for $80), it is becoming increasingly cheaper to store large amounts of data in-house rather than pay for cloud storage every month.  This is because cloud storage is typically priced per GB per hour.


Alternative: Share data storage with other customers using Symform (or any other similar technology) that breaks up the data into a number of encrypted parts and then stores them in the other customer's data centers.  This gives the benefits of elasticity without paying too much for it.  It also increases security of data in the cloud because no one can use the data without having all the parts and being able to decrypt all of them.

4. Your application transfers a large amount of data in or out of the cloudMost cloud providers price their bandwidth by GBs transferred per month.  This would be very costly for applications that stream large data files on a regular basis.

Alternative: Look for cloud providers that price by Mbps of dedicated network throughput.  This is typically found in enterprise cloud providers like Savvis and Terremark.

5. You do not have the capability of managing your VMs any better than you do your serversThe ease of provisioning VMs as and when necessary can also lead to VM sprawl if not managed appropriately.

Alternative: Subscribe to a cloud management console that can not only auto provision VMs when necessary, but also schedule VMs to be turned off after use.  Gravitant's cloudMatrix uses predictive analytics to create dynamic workload schedules that change over time based on historic demand trends.

Go to -> Part 2 - Your application would be a GREAT FIT in the Cloud if...

Cloud Computing - 58% Average Savings Per Month

Application: CRM
Environment: Production
Capacity: 40 Web/App Servers, 12 DB Servers, 8 VPN Servers, 5TB Storage, 10 Mbps Bandwidth
Demand: 1000 concurrent users, 3.0% growth per year


Scenario results from CloudWiz:


To run additional scenarios (for free), please go to http://www.gravitant.com/cloudwiz-home.html

*Note that these results are simply for comparison and decision support.  All cost and savings results are based on publicly available data, and Gravitant is not responsible for any discrepancies in the numbers shown above.  To increase the accuracy of the results from CloudWiz, please contact us to schedule a calibration meeting with our Professional Services group.