In a recent eBook, Gartner highlighted a handful of pervasive myths about the cloud: from “the cloud isn’t secure,” to “pure cloud deployments are the only viable option,” to “you can start implementing cloud technology without a strategy.” Left unexamined, these myths—and myriad others like them—can all easily set new infrastructure investments up for failure. At the same time, they’re not all equally pernicious.
From our perspective, the idea that you can dive into a cloud deployment without a defined strategy is the most worrisome of the bunch. Why? Because it’s simply not accurate. Successful cloud migrations and modernization efforts require more than just a strong will—they require technological expertise, they require buy-in from multiple touchpoints in and out of the IT department, and they require a clear roadmap with measurable metrics for success. Without those critical elements, you run the risk of a costly, ongoing boondoggle. Rather than reining in costs and powering a more modern, responsive technology stack, you’ll find yourself throwing good money after bad to solve problems that could have been avoided at the outset.
In other words, you need a documented cloud strategy. And what form should that strategy take? One option is to create a cloud strategy document.
1. Summary, Vision, and Outcomes
A cloud strategy document is pretty much what it sounds like. It’s a place for you to give an overview of how the cloud factors into your enterprise’s ongoing strategic initiatives, how you plan to get there from your current IT deployments, and what decision making heuristics you’ll use along the way. This shouldn’t come from a CIO’s head sui generis, but should instead be informed by discussions with stakeholders across multiple departments, plus cloud experts who can give detail to the exact ins, outs, and pitfalls that accompany each phase of the cloud lifecycle.
The purpose of getting all of this information into one document is twofold: to gain buy-in for your cloud migration plans, and to use as a touchstone throughout the process. There’s no way to cover everything that will happen from the word “go,” but you can create something that will help your colleagues to coalesce around your vision of digital transformation, making it that much more likely that your projects will come off and you’ll be able to modernize your stack while keeping costs under control.
So, fittingly, the first section of the cloud strategy document will start with a high-level summary of the project, what the aims of the project are, and how you plan to implement and measure the effects of the relevant changes. This include a sketch of your current IT landscape, your vision for the future of your stack, and a brief rundown of how each strategic initiative relates to corporate goals, plus the way the cloud factors into those initiatives and goals.
This is your chance to get everyone on the same page, so be sure to define your terms (you might lay out the difference between public, private, and hybrid clouds, the different cloud service models, NIST definitions of various technical terms, and more) and hammer home what you consider to be the most important points and the guiding principles that you’ll rely on as you move ahead.
2. Workload Inventory
In the next section of the document, you give a more detailed plan that covers the cloud migration on a workload by workload basis. Step one is to develop an inventory that lists out each and every workload within your existing technology stack. For each workload, you’ll want to give a full rundown of the costs and billing, the relevant vendor, the owner, any security and compliance requirements, plus a general rating of how suitable it is for the cloud. Something with unpredictable swings in data consumption or extremely seasonal processing needs (e.g. supply chain planning software for an automaker) could be a good fit for the cloud, whereas a stable, predictable application might be fine as-is, provided it’s appropriately provisioned.
All of this should be done with an eye towards categorizing each workload in terms its long-term migration status. Depending on how each workload slots into the larger framework, you might take one of a few paths in terms of application migration strategies:
- Rehost, i.e. “life and shift” the application to the cloud with minimal changes;
- Replatform, or make some alterations to make sure you’re gaining the benefits of your chosen cloud service;
- Refactor, i.e. make significant changes to the application before you migrate it;
- Phase out, meaning that you don’t see a future for that application going forward.
There might also be workloads that you see no reason to change, or applications that need to be replaced with a similar offering from a new vendor (either in the cloud or not), or applications that need to be rebuilt from scratch. Denote these workloads as well. Based on the information you collate here, you can begin to set priorities for what will be migrated in what order.
3. Cloud Governance
You need a strategy for how you’re going to get from your current IT status quo to the cloud-enabled future—whatever that means to you—but you also need to give thought to how you’re going to make decisions once your cloud applications are up and running. Especially when it comes to cost management, you’ll have to take a proactive approach throughout the entire lifecycle of a given deployment, including monitoring your usage on various instances, tracking the performance of your applications, etc. This brings us to cloud governance, which is perhaps the biggest and most daunting part of the cloud strategy document. This can and should include tentative answers to a whole host of different questions:
- How will different datatypes be classified, and how will those classifications be defined?
- What regulatory concerns apply to which datatypes, and how will they be addressed?
- What is your disaster recovery plan, and how does it vary by application, datatype, etc.?
- What is your data security or application security threat model, and how will that translate into specific policies?
- Do certain datasets or datatypes have to reside in particular geographies (e.g. because of GDPR requirements)?
- What cost control levers do you have across your deployment, and who owns them?
- Are there particular policies in place for incident management, change management, capacity management, etc.?
- What are the basic principles and structures of your desired cloud architecture?
You’ll want to provide as much detail here as possible, again so that others can use the document as a reference in the future. This will potentially require deep dives into the minutiae of everything from billing structures to new regulatory restrictions. If you don’t have the in-house expertise to handle all of this—and most businesses don’t—this is section is a prime opportunity to bring in a cloud expert who can help inform your governance and architecture decisions. Already at this stage of the process you might be thinking about who, exactly, will be doing what with regards to the modernization project, and how you’re going to stretch your capacity to cover all of the work—if that’s the case, it doesn’t hurt to be proactive about involving future migration and management partners.
4. Roles and People
Speaking of capacity: one of the most important steps here is to figure out who’s going to be responsible for what, and where the gaps are in available capacity and existing expertise. Start by listing out all of the roles (e.g. CIO, infrastructure manager, etc.) and giving a brief sketch of what they’re going to be responsible for. Ideally, the steps you’re taking throughout your digital transformation will give IT more of an ability to actively create value for the company as a whole, and your document should reflect your current thinking on that score, i.e. what your vision is for the futures of your different teams.
On a practical level, you’ll want to be sure that a number of specific responsibilities are accounted for and assigned to particular teams or individuals, e.g.:
- Who’s in charge of cloud vendor management?
- Who’s in charge of change management?
- Who owns which assets?
- Who’s in charge of incident response?
- Who owns the budget levers that we discussed above?
In all likelihood, your exact answers here will adapt and change over time. The goal as you’re putting an initial document together is just to make sure that nothing flies under the radar. The last thing you want is to make the switch to Azure and realize several months later that your bills have skyrocketed because no one has been managing unused instances.
5. Technology Roadmap
In this final section, you get a little bit deeper into the questions of implementation and integration that will define your actual cloud journey on an ongoing basis. This is where you’ll lay out the different project milestones, metrics for success, and criteria for completion. Even if you’re only undertaking a small fraction of your larger digital transformation, you’ll want to be explicit about what the priorities are for migrating different applications and workloads and what dependencies exist between them.
This section can also include your technical or budgetary requirements, your funding sources, and your initial assessments of prospective cloud providers. Ideally, this can work as a jumping off point to create tactical plans for the actual migrations—which will involve translating this high-level work into the thousands of individual tasks that comprise even a small migration project. Here, you’ll start to get a sense of what the gap really is between your internal capacity and budget realities and the amount of work that needs to get done.
Calculating TCO
At numerous points throughout the cloud strategy document, cost and TCO considerations will inevitably crop up. But how do you actually estimate what your TCO is going to be for a particular cloud service or platform? For starters, the various cloud providers all offer their own calculators for how much you might expect to pay on an ongoing basis:
Each of these tools can give you both a useful baseline and the basis for price comparisons (which will naturally factor into your cloud provider decision making process), but the Azure TCO calculator is in some ways the most interesting conceptually. It lets you plug in specific numbers for everything from hardware, software, and electricity to IT admin labor costs and specific storage-related costs. If you spend a few minutes playing around with the functionality based on your baselines, it’ll spit out direct cost comparisons for TCO 5 years out between Azure and on-prem storage and computing.
Here, two things might occur to you: First, because there are so many parameters to consider, the only way to get a robust, accurate estimate is to go in with a high baseline level of knowledge about your existing infrastructure and the way that you expect to architect your cloud deployment. In other words, you may need to take any sort of direct TCO comparison derived that way with a grain of salt, unless you’ve got a lot of cloud management expertise on tap.
Second, if you run through the calculations, you might notice that they don’t seem to take into account the lessons we learned from Gartner above. For instance, there’s likely going to be a period where you have both cloud infrastructure and physical infrastructure operating in parallel. An experienced team that’s performed migrations and modernizations in multiple different IT environments will be able to minimize the length of time that takes, but there will still be a period where you’re paying for cloud services while still operating on-prem servers. This means that your cloud TCO includes some physical computing and physical asset maintenance costs during the migration period.
By the same token, Gartner suggests that you’re probably going to wind up overpaying when you finally make the cutover and you’re trying to right-size your deployment, set up your reserve instances, etc. This means that the TCO you calculate up front will either reflect an overly conservative number—or it will show a number that’s much lower than your real costs. And this is before we even get into the question of whether your migration timeline is reasonable—considering that half of migration face delays due to lack of skills, this is something that you need to consider.
Hidden Cost Levers in Cloud Migration and Management
We’ve seen some of the ways that TCO calculations aren’t as straightforward as they may seem—but what about the costs themselves? Gone are the days when the cloud is automatically the cheaper option, but public cloud deployments are still going to represent the most flexible and dynamic options. The question is how to leverage that flexibility into the ideal balance between cost management and application performance within the context of technology stack modernization. Here, Gartner points out a useful distinction between cost reduction and cost optimization:
- Reduction: This is just what it sounds like—you make adjustments that don’t impact the actual architecture of the deployment in order to minimize your monthly AWS or Azure bill. This includes things we’ve mentioned, such as right-sizing and scheduling, and other techniques like finding programmatic discounts, paring down unused resources, powering increased efficiency through DevOps, etc.
- Optimization: This involves actually changing your architecture in order to organically drive down costs. Adjusting your data storage policies, for instance, can help you change the way people use your cloud infrastructure in a way that lowers your billing. So can setting up autoscaling, modernizing your platforms, etc.
In an on-premise deployment, these considerations don’t exist in the same way. You can more or less tally up the cost of hardware, software, electricity, IT labor and other costs—taking into account the need for periodic upgrades and updates—and go from there. You may need to adjust over time, but you’ll be working within a framework that’s pretty familiar to IT generalists. With the public cloud, there’s an inherent level of complexity that makes it difficult to even reach an initial estimate for those who don’t have a lot of existing cloud experience.
This is all before we even get into cost comparisons between on-prem and hybrid clouds (the preferred deployment method for more than 70% of CIOs) or private clouds. These tend to be more expensive than public cloud deployments, but they also provide advantages in terms of how much control you have over your data and processes. Here, a similar set of questions and concerns will apply. And, again, it will be difficult to get an accurate read of the likely cost implications over the next 3-5 years if you don’t already have a strong familiarity with the cost reduction and optimization levers we alluded to above.
How Managed Services Can Help
Let’s take a step back for a second. We sketched out a lot of complexities and grey areas above, and it might be offering a somewhat daunting picture of cloud migration and management, at least from a budgetary perspective. In reality, all we’re trying to suggest is that real cloud experts need to be brought in as stakeholders from the very first step in order to ensure that you’re looking at each stage of the process with the relevant context and background information. Whether you’re just starting to consider the feasibility of modernizing your technology stack, or you’re deciding between different providers and need to understand what your deployment will actually look like down the line, there’s value to be had in bringing in an expert advisor. Sure, some businesses already have experts on staff—but for those that don’t, it’s an important starting point even for the sorts of hypothetical TCO calculations we’ve been talking about.
Once you’re already reaching outside your organization for support, there’s actually a lot that a managed cloud solution provider can do to help you keep your TCO down right from the get-go. This starts with larger architecture questions and can continue, based on your precise needs, with rapidly scalable migration support, cloud infrastructure management, and even outsourced DevOps. By relying on the experience and expertise of a team for whom cloud deployment is routine, you can modernize more quickly and configure your initial deployment more accurately—and, as we’ve seen, both of those benefits can have a big impact on your TCO.
Learn More About Intertec's Cloud Solutions:
Intertec’s teams have hands-on experience in developing and migrating applications on leading cloud platforms. In addition to design and development, we provide a complete range of application testing, deployment and ongoing support services, including managing physical infrastructure and offering outsourced DevOps teams. Go ahead and schedule a meeting with us here to learn more!
