Technical Implementations

If you're used to a traditional IT environment, you're probably also used to having to maintain a traditional IT environment. That means installing machines, updating software, monitoring everything, and fixing anything that goes wrong.

Even at the highest levels of customization, what you put on the cloud will require less maintenance than what you have on-premises. That is because your Cloud Service Provider (CSP) will be taking care of at a minimum your infrastructure and, in some cases, everything down to the code. Just like with compliance, the level of maintenance required of you depends on how deeply you've adopted cloud — and if you can customize it, you're probably responsible for it.

Every solution is unique, but as a general guiding principle, here's the type of maintenance you'll be responsible for in every cloud service model:

Maintenance is a shared responsibility between the Cloud Service Provided (CSP) and the agency, and you should never assume something is (or isn't) your responsibility. Every FedRAMP authorized CSP should have what's called a "customer responsibility matrix" that will spell out who's responsible for what and in which contexts. Ask your vendor to share theirs with you, and keep it on hand in case questions arise down the line. Also ensure you review and understand all Service Level Agreements (SLAs).

Cloud migration is not a "one and done" process — an agency isn't on-premises today and on the cloud tomorrow. In fact, some of the most successful agency transitions are designed from the start to be small, agile, and modular. By piloting and iterating over time, teams can develop the routines that work for them, while at the same time minimizing risk and building buy-in for the entire migration process.

Everyone's modernization is different, but there are some best practices that hold true across agencies. Below is an overview of what you should keep in mind as you plan your migration, or bring on third parties to help the process along.

• Start small. Think about your first transition as a pilot — a chance to get the lay of the land, to learn and make mistakes, and to see how long things take. Many cloud solutions will let you test out their services for free; for example, GSA's cloud.gov offers a free sandbox space to anyone with a valid federal e-mail address.
• Whether you're handling your agency's transition yourself or bringing in a vendor to support, getting a sense of how to deploy applications in the cloud can be useful for anyone expecting to manage anything more custom than software as a service (SaaS). Even deploying a "Hello, world!" is a step towards that understanding.
• Work backwards. By the time you're migrating actual programs you should already have completed your audit of existing IT resources, as well as rationalizations and risk assessments. Pick something simple and low risk for your first real migration or deployment, not a mission critical service. That way, your inevitable learning curve won't interfere with your agency's mission.
• Refine your processes. Don't just move things to the cloud — pay attention to the way you move them. Keep track of every step along the way, and at the end of each migration, talk with your team about what worked and what didn't. By experimenting with different ways of doing things, and by replicating your successes, you'll be able to make each migration process a little better than the one before it. Think about which manual processes can be further automated.
• Celebrate your successes. Not everyone understands cloud, its value, or why it is worth using the technology. Every time you successfully migrate, merge, or shut down a system, it represents a small step towards improving the overall effectiveness of your agency. The potential cost savings from optimization efforts can enable further cloud transitions. Be sure to share any progress made towards increasing your FITARA score or meeting DCOI targets.
• Closeout and multiply your return on your cloud successes with identifying how you can redeploy the agency's IT resources that have become available with moving to the cloud, this includes IT hardware that can provide increased capacity to other systems and your personnel that can now support other on going or new efforts. If you can not re-utilize your IT hardware, ensure the IT hardware is appropriately decommissioned and disposed of per agency's policies.

Scaling is one of NIST's five essential characteristics of cloud. A true cloud environment will be able to quickly provision anything you ask for (as long as the requirement is in scope of the service procured) — you should never "run out" of resources. This is different from reaching a cap; a cap is an imposed limit that can be lifted - service caps are not hard limits to what's possible.

Cloud computing empowers agencies to scale as needed. Scaling can reduce latency and increase capacity when demand requires, as in the instance of tax season for the IRS. Agencies can scale up in advance of the busy season and scale down when the rush is over.

Scaling doesn't have to be a manual process. Properly architected applications can support Elasticity - Elasticity is the ability to grow or shrink infrastructure resources dynamically as needed to adapt to workload changes in an autonomic manner, maximizing the use of resources based on demand. The more resources you use, the more expensive your bill, so you should be able to cap your auto-scaling based on a specific dollar amount. And of course, if you're using a software as a service (SaaS) solution, elasticity shouldn't be something you need to think about at all.

Through the 2000s, releases of software were infrequent and painful because there was no way to guarantee everything would work like it was meant to. Thankfully, things have changed — thanks to cloud computing, test environments can be quickly deploy in the cloud and software releases tested and vetted prior to release to the production environment.

A test environment is exactly what it sounds like: a cloned version of your production environment, a "mirror universe" that exists completely separately. You can deploy anything you think is production-ready into the test environment and see what happens — no matter what happens, your entire production system is completely untouched.

Some of this is possible on-premises or in private clouds, but it's considerably more difficult. With private clouds on premises you will have to effectively run a second private cloud test environment consisting of separate hardware, operating systems, virtual machines, etc.

In the cloud, your test environments can mimic your production environment in every way except their capacity. (There's no point to making them completely identical — you can do all the tests you need in a fraction of the space.) The disposability of cloud makes it possible to stand up environments only when you need them and then destroy them as soon as they are no longer required, freeing up your resources to be used elsewhere the rest of the time.

It's easy to create and then get rid of a new cloud infrastructure, but it's difficult to make sure the data you use within it is appropriate. For example, if your production environment processes personally identifiable information (PII), you shouldn't replicate that data without tight controls and a well-thought-out plan for who gets to access it. A simpler choice is to create a mock dataset that can be used in your test environment — that way it doesn't matter who accesses it, and you don't need to worry about any sensitive information potentially being exposed.

Your agency has probably invested significant resources in on-premises IT. Cloud migration doesn’t have to waste those investments. A well-designed on-premises IT and cloud solution, a hybrid cloud, can actually augment and expand your on-premises IT, acting as a beneficial initial step in your transition.