Establishing Your Cloud Strategy (Google Cloud Adoption Series: Part 1A)
You Need a Strategy
Every organisation of any significant size needs an IT hosting strategy, right? And if you’re here, then it’s likely that you want your hosting strategy to be cloud-centric.
But why do you need the strategy at all? Here are a few questions that the strategy should answer:
- Where are we going? What is my target state?
- How does it align (or not) to my organisation’s overall business strategy?
- How will this target state help my organisation? How will it benefit our customers / users / stakeholders?
- How will we get from here to there? Once we know this, we can determine the delta.
- What is included in the scope of my strategy? What interrelated and interdependent items do we need to tackle?
(Note: if you ignore these interdependencies, your strategy will be costly to deliver at best, and doomed to fail at worst.) - What capabilities will we create that we don’t currently have? And which capabilities will we no longer need?
- And the same questions for our technology products.
- Which cloud provider(s) will we use? Why?
- What is the roadmap and sequencing for arriving at our target state?
- How soon can we expect to achieve some value?
- How does it effect our people and teams? Our organisation structure? Our talent and retention? Our morale?
- Our operating model?
- Does it look feasible?
- Assuming we don’t yet have the skills in-house, who should we partner with? And if we have an existing patner running our legacy IT infrastructure for us, are they an expert in cloud? And is it really in THEIR best interests to help us move it all to cloud?
- Can we afford it?
- Are there other things we should be spending our money on instead?
- Are there things that we should pause or even abandon, if we execute this strategy?
- If we DON’T do this, what is the likely long-term outcome? (Can we continue to meet customers’ expectations? Can we innovate fast enough? Can we grow? Are we throwing away money on licenses and extended support? Are these costs spiralling? Do we have vendor lock-in challenges? Do we love our commercial vendors? Do our engineers enjoy building on our platform? How is morale? Are we able to process our ever-growing data fast enough to allow timely insights and actions? Are we leveraging AI like everyone else, or are we destined to follow the dinosaurs?)
- When we’ve delivered on this strategy, what have we enabled? What comes next?
You Need An Enterprise Cloud Architect
For the avoidance of any doubt: these are the kinds of considerations that will be front-and-centre for any competent Enterprise Architect. Leading the creation of a cloud strategy is the purview of an experienced architect that has a strong understanding of cloud, infrastructure and technology, but who is also well-grounded in enterprise architecture.
This is not simply a technical exercise.
What Does a Strategy Look Like?
Your strategy needs to:
- Be compelling for C-levels and other senior execs. So the top-level strategy should not be overly technical.
- Compelling for infrastructure managers, product owners and engineers who will ultimately be impacted in some way by the strategy. Do bear in mind that many of these existing stakeholders may not be receptive to the idea that you’re presenting a new way of doing things; and that much of what they run today will become obsolete.
- Answer the questions I listed above.
The primary folks you need to convince are your C-levels and senior execs. Once you have their buy-in, they will endorse the strategy and then push it, top-down. (I should say: this particular page is not intended to tell you how to do enterprise architecture, or how to manage stakeholders.) In my experience, these stakeholders will not read long documents. So my recommendations:
- Create a 15-slide (maximum) version of your strategy. This is for your C-levels.
- You can add appendix slides if you like.
- You can provide additional artefacts with more detail. But don’t try to sell your vision and strategy by sending a 50 page document to your CTO! This approach will probably fail!
Answering the Questions: The Value of Cloud
I will now describe the many benefits and selling points of cloud. All the information that follows will help help you underpin your strategy, your business case, defining related strategic activity, and then the steps that will follow, once the strategy is agreed.
The picture above shows you some of the standard benefits you can expect from consuming public cloud. Let’s dive into these in a bit more detail.
Agility
Cloud is FAST. My very first exposure to cloud was building myself a working, publicly accessible Apache webserver in a VM. The whole process took me about 2 minutes. It blew my mind. But building VMs is just IaaS; this really is the tip of the iceberg. Sure, you can build working VMs in seconds, rather than days or weeks (depending on your current on-prem processes). But you get much more cloud agility and value when you leverage managed services.
And most importantly, you should automate from the start. The importance of this cannot be overstated!! Yes, experiment using the Cloud Console (the GUI), but once you’re beyond experimentation for any given solution, you should deploy ALL of your infrastructure in the cloud using declarative infrastructure-as-code (IaC). Using IaC, you can achieve consistent, repeatable, predictable deployments of cloud components and services. An environment that used to take several weeks (or months) to build on-prem, and require three or four different teams? Now you can build an entire environment in a minute or two.
Here’s another agility win: no more hardware lead times! You don’t need to order physical servers. You don’t need to wait for them to be delivered, and you don’t need to install them.
Stability and Consistency
Because you are now provisioning your environments with IaC, you now have guaranteed repeatability and consistency. You can build your Dev, QA and Prod environments to look identical (except for scale). If an environment in the cloud is broken, you don’t waste your time fixing it. You just redeploy it. 2 minutes later, you have a fresh working environment!
Not only are all your environments consistent to each other, but you can also be sure they are consistent to your high level design (which is essentially your specification), and to your low level design, which is actually the IaC itself! Why? Because the IaC provides the detailed description of what your infrastructure should look like. So it is, in itself, self-documenting detailed design!
Reduced Ops
You can now provision all your infrastructure instantly, on-demand, in the cloud. So you no longer need resources to:
- Rack and stack physical servers.
- Install and manage a hypervisor environment, like VMware or Microsoft Hyper-V.
- Install physical routers and switches, and connect them.
- Install and manage an on-premises SAN.
And, through managed services (which you should definitely be using), you no longer need resources to, for example:
- Install, manage and patch databases.
- Install, manage and patch your Kubernetes environment.
Opex, Not Capex
Since you no longer need to buy and install your own hardware, your infrastructure costs shift towards pay-by-consumption. You only pay for what you use. And as such, your costs become operating costs, rather than upfront capital expense.
This is considerably lower risk for the enterprise. You no longer need to guess what your peak infrastructure needs will be over the next year or two, and pre-emptively buy hardware on that basis. And you no longer need to think, “What if I buy this thing, and I no longer need it in a year’s time?”
PAYG and Elasticity
Great, we’ve established that we can now pay for what we use. Aka, pay-as-you-go. (PAYG.) One huge advantage in cloud is elasticity. I.e. the ability for your infrastructure to scale on-demand and dynamically, in response to your demand.
For example, let’s say you have an application server behind a Google Cloud Load Balancer (which is also software-defined), servicing an Internet-facing web application. And then you decide to run a marketing campaign, or push some advertisements. Suddenly, you find you have 100x as many users. No problem! Google Cloud scales up the number of application servers you have to meet the demand. And when demand drops, it automatically destroys the excess. But you’re only paying for the resources you have deployed!
One caution: you can really only leverage PAYG alongside scalability, if you’re not also paying commercial licenses to cover your expected maximum demand. These licenses tend to cost a lot more than the infrastructure. But more on this later!
Unlimited Scale
Whilst elasticity refers to the cloud’s ability to scale up and down in response to your real-time needs, scalability refers to the cloud provider’s capacity to service your demand, no matter how great your demand. Okay, it’s true that the cloud provider’s capacity isn’t really unlimited. There are scenarios where a cloud provider might temporarily run out of a particular type of resource in a particular region. But it’s generally fair to say that Google Cloud has a lot more “spare” infrastructure resources than you can provide in your own data centres. And more importantly, when you’re not using it, you’re not paying for it.
Whereas in your own DCs, you obviously have to pay for all infrastructure “headroom”, whether you’re using it or not. (And license it!!)
Transparent Billing and Cost Attribution
In traditional enterprises with on-premises infrastructure, it is extremely difficult to:
- Have visibility of the costs of infrastructure, at any sort of granular level.
- Be able to report on the costs of the infastructure that underpins a given application or service. (Show-back.)
- Be able to charge a service fairly for the infrastructure they’re consuming. (Charge-back.)
These challenges often result in some pretty woeful outcomes. Let me describe a scenario. Does any of this sound familiar…?
- Your enterprise doesn’t really understand the true costs of infrastructure, at application or service level. (They only have the macro costs.)
- Furthermore, your enterprise doesn’t have a way to charge projects based on ongoing physical infrastructure requirements. Rather, your enterprise only allows projects to pay for the capex purchase of any additional physical infrastructure that is required.
- Application x is being built and deployed to our on-premises infrastructure. It is moderate in size. It needs a few dozen VMs across a two or three hosts. Fortunately, there is spare capacity in the existing estate. So application x is deployed, and Project x does not have to pay for any infrastructure.
- We now have a new business case for application y. It’s a small business case, requiring relatively little spend, and with a reasonable ROI. The application will be small, requiring maybe two or three small VMs on each of three hosts.
- Unfortunately, the infrastructure is now full. And what’s worse… Application x actually used up the headroom!
- So, Project y are told: “You will have to pay for the provisioning of three new physical hosts, as well as associated VMware licensing, and RHEL OS licensing. That will be £120K please.”
- Outcome: Project y is no longer viable!! It’s business case no longer stacks up. So the project is abandoned.
This unfair situation arises when an enterprise forces the next new project to pay for new infrastructure, whenever the existing infra is full.
In cloud, this is easily remedied. Cloud billing, dashboards, analytics and FinOps tools allow an organisation to see exactly what each resource is costing, and furthermore, which applications are consuming those resources. (Though you do have to implement — and mandate — sensible design choices around how you “label” your resources.)
You can make this information visible centrally. But you can also give visibility to application teams and product owners. Nothing is more effective at motivating an application team to manage and optimise their infrastructure costs, than actually showing them how much their application is costing! What’s more, you can add some gamefication.
More on FinOps later.
Ubiquitous Connectivity
This is one of the core tenets of cloud. I.e. the idea that you can access your services at any time, from anywhere, using any device. So long as the user has an Internet connection.
Of course, “any time, from anywhere, using any device” may not be true for your organisation. For example, you might:
- Decide that only client devices that pass a posture check (i.e. to validate the client device is not compromised) can access your application.
- Decide that users can not access your services from certain geographic locations.
- Decide that certain data is only accessible from certain geographic locations, e.g. if you have data sovereignty challenges.
But these are decisions you choose to make, in order to meet the security and compliance challenges of your organisation. But the cloud makes “any time, anywhere, any device” possible.
And what’s more, when done properly, the user experience should be consistent, painless, and transparent. The user should not need to know or care where your organisation’s application is running. They shouldn’t need to execute any special applications to get to one service versus another. More on this later, when we talk about ZTNA.
Secure
One significant benefit of adopting Google Cloud is that Google takes care of a lot of security for you. Whereas on-premises, you were responsible for all elements of security, when you deploy your workloads to Google Cloud, you only need to handle your concerns within the overall security shared responsibility model.
Think about the things that you no longer need to do, because Google will do it for you…
- Google have state-of-the-art datacentres with strong physical security, including biometrics, cameras, laser perimeters, and metal detectors. Fewer than 1% of Googlers will ever enter a Google data centre, and all access is tracked. It’s very likely that their data centre security is better than yours!
- Google staff are thoroughly vetted and security trained. All access by Googlers requires MFA.
- Google runs its infrastructure on its own custom-designed chips and ASICs, with tamper-proof security built-in.
- All data stored on Google is encrypted at rest. By default, this uses Google-managed encryption keys (GMEK) with AES-256 encryption. But if you want more control, you can supply and even manage encryption keys yourself.
- Google constantly monitors its infrastructure for attacks.
- Google has a bug bounty program, offering substantial rewards for anyone that can hack their infrastructure.
- Google Cloud products routinely undergo verification and audit of security controls, and consequently, Google Cloud and its products are certified against multiple global standards, including GDPR, PCI-DSS, and HIPAA.
But ultimately, organisations own their own data, and must take steps to ensure that their services and data are appropriately secured. Google provides a plethora of security technology and tools, to ensure that you deploy your own services and data securely.
Other Opportunities
In the next chapter, I’ll cover off some other opportunities (or mistakes!) that should be considered as part of your strategy. At the very least, they may be related, interdependent strategies.
Series Navigation
Before You Go
- Please share this with anyone that you think will be interested. It might help them, and it really helps me!
- Please give claps. You know you can clap up to 50 times, right?
- Feel free to leave a comment 💬.
- Follow and subscribe, so you don’t miss any of my content. Go to my Profile Page, and click on these icons:
