29 Aug Journey to the Cloud
The need to develop a Cloud Strategy is one of the most pressing challenges for today’s IT leaders. This episode explores what goes into developing a good one. Please remember to subscribe to this channel. You can find out more about me at https://www.garethbarr.com/, and can read this article at https://www.garethbarr.com/journey-cl…
One of the most pressing challenges for today’s IT leaders is the need to develop a Cloud Strategy. Let’s explore this further, starting with the basics…
What actually is a Cloud strategy?
Simply put, a Cloud strategy is a plan or approach for how and when an organization will leverage the Cloud. Sounds pretty straightforward, right? Well, if it really were that simple, most companies would have one already – but, according to Gartner, they don’t.
As you may remember from one of my earlier articles, Strategy and the Art of War, a strategy involves making difficult decisions, choosing where to invest time/effort/money and where not to, knowing that choosing one path may actually block off another path – i.e. choosing which battles to fight!
A simple example of this is the decision of whether or not to use Platform-as-a-Service (PaaS) components. By doing this, you can potentially create a product or service much more rapidly, and spend much less effort managing and operating it. However, PaaS offerings are generally not portable between different providers, which exposes you to vendor lock-in risk. So the trade-off is speed combined with vendor lock-in vs flexibility and independence.
So why is a Cloud strategy important?
This is the era of digital transformation (which I define as “Using technology to change or reimagine the way products and services are delivered”), and many companies have already experienced the reality of “disrupt or be disrupted” in this marketplace.
Startups and established companies have both used technology to change the way their business is done, and had a major disruptive effect across the industry – whether that is Uber/Lyft, who effectively disintermediated traditional taxi companies by connecting supply (drivers) to demand (passengers) cutting out the taxi companies, or Apple, who did much the same thing with the music industry. For more on disintermediation, click here.
Companies that are not looking at ways to transform their business model using technology are effectively just waiting for someone else to come along and “move their cheese”. It should therefore be clear that a strong business strategy must be tightly underpinned by a strong technology strategy to ensure the long-term viability of an organization, but how does that relate to the importance of a Cloud strategy?
Cloud’s importance to technology strategy
Organizational agility – the ability to rapidly go to market with new product or service offerings, to change the way services are structured and delivered, and to enter new markets or regions – is increasingly critical.
Businesses have benefited from management and automation of business processes, relying on technology for everyday activities for many back- and front-office functions. Yet, in many cases, organizations have become frustrated with their IT teams’ ability to react to changing business needs. The process automation that started out as a benefit, if badly engineered, can end up as more of an organizational strait-jacket.
Cloud can offer many potential benefits, including:
- An opportunity to accelerate the pace of change and empower the IT and business teams to react more effectively to changing demand.
- A whole new set of capabilities, like commodity machine learning, voice recognition, serverless computing, and even quantum computing – many of which may have been previously unavailable to all but the largest of organizations.
- A lower barrier of entry for adoption of new technologies.
- The ability to reduce the time and money spent on run-the-shop, freeing up resources for innovation and transformation activities.
- The potential for greater reliability and security than most companies would be able to achieve without Cloud.
- A more predictable and consistent set of operating costs, and the ability to easily show or charge costs back to consumers.
As we can see, Cloud has a massive potential benefit, but it also has the potential to be an existential threat if you ignore it while your competitors leverage it effectively. It is the IT equivalent of the invention of the repeating rifle: it gave a decisive advantage to any side using it, and you didn’t want to be on the side that wasn’t!
So to sum up, businesses that don’t have a strong digital agenda laid out in both business and technology strategies, are going to get disrupted, and any robust technology strategy must include at its core a strategy for Cloud, even if that strategy is not to use Cloud, because your strategy will need to compensate for the technological advantages that your competitors will have from their use of Cloud.
Even aside from the critical business need for it, there are still many technical, financial, and security reasons why a strong Cloud strategy is necessary. Without a clear plan for how to approach the Cloud, you run the risk of:
- Having a potentially runaway IT operational budget while getting no incremental benefit. As an example, many simple Commercial Off The Shelf (COTS) software solutions are more expensive to run in the Cloud using IaaS, and deliver no recognizable benefit to running them on-premise
- Exposing your organization to increased risk through a lack of understanding of the shared responsibility model and the need to design security controls and resilience into your Cloud-based solutions. It isn’t just set it and forget it.
- Having no vendor exit plan because you unintentionally developed against Cloud-specific components, limiting your application portability.
- Stuck in arguments with your security and data protection teams about how to manage and protect your data that is spread across Clouds and protected with different controls in each space.
So how do I create a Cloud strategy?
Gartner does a good job of laying out the basics of this in their Cloud Strategy Cookbook, though some of this may be a bit much for smaller organizations. If you don’t have a Gartner account, you can download the same document here for free, if you’re prepared to share some personal info. (Note: I’m not affiliated with this site.)
There are generally many different factors that go into when and how you will use the Cloud, and these all start with having a clear understanding of the overall business objectives.
Cloud Design Principles & Considerations
While it is often tempting to just say your Cloud strategy is “Cloud First”, that is a massive oversimplification, and not that helpful. For example, would you choose Cloud First even if it is more expensive? Less secure? Less reliable? It is unlikely that the answer will ALWAYS be to put things in the cloud. Gartner calls this out, stating “You generally don’t get a lot of benefits from doing lift-and-shift migrations”. It is, however, important to have some guiding principles. In that context, where it’s defined as a preference for Cloud solutions, all else being equal, “Cloud First” can make a lot of sense, but might still not be enough.
It is also important to understand your preference and capabilities regarding buy vs build. In most Enterprises, I have generally preferred buy over build, but that is not always the best choice. A Cloud startup might well decide that its business processes are so integrated into its offerings that it should build out much of the supporting systems, so it has ultimate flexibility. Another interesting example of this is Tesla, who made the perhaps controversial choice of building their own Enterprise Resource Planning (ERP) system. While many companies would consider this to be a non-core capability, Tesla appears to have viewed this back-office system as a critical part of its integrated operation, and a potential differentiator.
The business’s approach to financial considerations is also very important. Many companies appreciate the fact that Cloud shifts costs from Capital Expenditure (CapEx), where you buy and install equipment then depreciate it over the life of the asset, to Operational Expenditure (OpEx), where you are paying for a service as you use it, but this isn’t universal. There are companies who prefer the flexibility of being able to adjust their operating costs by doing things like reducing support headcount, or choosing to extending the lifecycle of existing assets to defer upcoming costs. These are options that are not available when paying line items of service consumption on a Cloud bill.
Pace layering or Bimodal IT is an important consideration when evaluating workloads for Cloud migration. If this is not a concept you are familiar with, you can find more information here and here, but it boils down to an understanding that there is a difference between systems of record such as an Enterprise Resource Planning system, or an Order Management System, and systems of engagement such as a customer-facing portal or new technology tool, with the fundamental premise being that you may allow more architectural flexibility in tools and platforms that are systems of engagement than you might in systems of record, as the latter are by definition, critical to the daily functioning of the business and less open to experimentation. The relevance of this concept to Cloud is that customer-facing or experimental software is a great match and easy sell for Cloud technologies, where companies might be more cautious with systems of record.
Different Cloud Types
I would personally recommend being a bit more nuanced around the types of Cloud when talking about a Cloud Strategy. For example, when we say “Cloud First” are we talking about Software-as-a-Service? Platform-as-a-Service? Infrastructure-as-a-Service? Serverless computing? Virtual Private Clouds? Hybrid Cloud? The truth is that all of these are relevant in some way, which is why it makes sense, in my opinion, to treat them each discretely.
In this model, I consider Serverless computing and Containers (e.g. Docker) to be a variant of PaaS, and tend to lump Virtual Private Clouds and Hybrid Clouds into the IaaS bucket. I recognize that this isn’t entirely accurate, as several providers offer PaaS components on-premise, but from a design decision and responsibility model, they are similar enough in my mind to not warrant separation.
Some of these areas are fairly simple. For example, most companies are already using some element of SaaS, and this is a fairly straightforward approach to understand.
Considerations for this model should include things like:
- Exit strategy – What happens if you want to change vendor? Can you get the data out in a meaningful way?
- Integration capabilities – An isolation solution on its own island is rarely very useful. Having the ability to interconnect it with other systems will be critical.
- Upgrades and currency requirements – SaaS solutions generally have regular upgrades, and even though the software is upgraded for you, it still often requires testing to ensure that customizations, configuration and integrations don’t break. Sometimes you are required to go through this cycle within a fixed period of time from their release, and you have to commit to stay no more than 1 or 2 versions behind the current release.
- Vendor capability and service level – In this model, you are largely in the hands of your supplier. Their ability to deliver a reliable and secure service is essential, and most contracts do not even consider covering consequential damages, such as loss of revenue or reputational damage. Any refunds are usually capped at the amount paid for the service.
- Regulatory & Compliance posture – Financial services companies and state and local government organizations are taking an increasingly aggressive look at how their suppliers are providing services to them, and protecting their data. It is important to ensure that these SaaS providers are meeting any applicable requirements that could be placed on your organization by these entities.
Infrastructure-as-a-Service is also fairly well understood, but as mentioned before, often has little direct financial benefit if simply lifting and shifting.
Examples of where IaaS can really benefit companies are:
- When they have a seasonal fluctuation in demand that must scale to meet the need, but doesn’t warrant the steady-state cost of the maximum capacity.
- When the need for flexibility and agility outweigh the consequence of cost
- When you want to be able to start small and cheap, but rapidly scale out to meet demand.
- When you can completely eliminate, or avoid the need for, maintaining data centers.
- When your clients are looking for you to meet certain stringent requirements for data hosting.
- When you have a strong need to stay Cloud-neutral, or be able to run the same workload in multiple different Clouds and/or onsite. Note, this requirement might be better met using Containers.
The critical thing to note about IaaS is that it still requires a lot of technical expertise in both design and operation. There is a frequent misunderstanding that putting something into the Cloud automatically makes it highly secure, highly available, and highly scalable. This couldn’t be further from the truth. A lot of the same design and implementation challenges exist in the Cloud as in an on-premise datacenter. Most of what has been taken care of for you is the physical provisioning piece. Everything else requires careful design and planning, e.g;
- If storing government data, you cannot just rely on the FedRAMP-certification that your provider has. You will inevitably need to configure and manage many additional the controls yourself, on top of the Cloud provider’s controls.
- If you need an application to be highly available, you need to understand and design around the inherent failure domains in your chosen provider – e.g. AWS uses availability zones, and ensure that your implementation can survive the lost of an entire zone.
- Patching, systems management, change control, monitoring, incident management, and many other important areas are still directly your responsibility.
Platform-as-a-Service is probably the most complex of the Cloud offerings, as it is frequently proprietary to the specific Cloud provider, though there are examples of services that are cloud agnostic, even if the interface to manage them isn’t.
As an example, many database systems are offered as PaaS, and can be relatively easily migrated between Clouds, or even potentially to an on-premise offering. AWS RDS MySQL is an example, that could be moved to Azure MySQL. Even examples like Amazon Aurora, which is proprietary to Amazon but compatible with MySQL, can potentially be migrated fairly easily, but things get much more proprietary when you start to delve into things like Machine Learning, and some of the development and storage options that are not cross-compatible.
This isn’t to say that PaaS is bad. As a matter of fact, it can actually be a very compelling approach for the right situations, giving distinct competitive advantage if used right. The important thing is to be deliberate and aware of where you are making choices that will lock you in, and having a fallback/exit plan worked out in advance.
Some recommendations for PaaS are:
- Have a list of pre-approved PaaS components and standard configurations, available for your developers, so they can ensure they are not accidentally committing you to a technology you do not have an exit plan for.
- Have a strategic position, guided by your broader business strategy, on how close you want to, or can, get integrated with any one provider.
- Consider the use of the Adapter Pattern where you are deciding to use a proprietary service. This can make it easier to switch out the code to a different provider at a later stage.
- Potentially have a guiding principle to avoid vendor-lock-in unless the value exceeds a critical threshold. e.g. “The Machine Learning component is the secret sauce in our app, and is not something we would want to change rapidly.”
Because of the inherent complexity of these various Cloud options, it makes sense to approach the application of a Cloud strategy on a workload-by-workload basis. To be specific, you should not just say, for example, “All finance applications should go to the Cloud”, but instead do a careful analysis of your workloads, clearly understanding the criticality, sensitivity, architecture, and function of each workload, before making a decision on where its target state should be. This is where the Cloud Design Principles help, but I would recommend that they be differentiated based on the Cloud type. For example:
- SaaS first – for Systems of Record, when provided by tier 1 & 2 companies
- PaaS first – for Systems of Engagement
- Cloud-managed container services for COTS where possible – cheapest location
- All user-based authentication must be through enterprise identity store
(Obviously, a full list would be more comprehensive, and aligned to your company’s business and technology strategy)
In that example, assuming that your firm is using something like SAP as an ERP, it would be probable that the target state for that would be SaaS, as long as the host was Tier 1 or Tier 2 according to your standards.
Most important of all, a Cloud strategy needs to be focused on outcomes. What is the organization trying to accomplish, and how do you measure success. Without this, any strategy is basically going to be a write-only document (i.e. one that never gets read or used).
So, to wrap up…
You need to have a strong Cloud strategy, and to do this, you need to:
- Clearly understand the business and technology strategy and objectives
- Be clear on the risks you are prepared to take, and the bets you will make. Are you all-in on Microsoft? Do you want stay Cloud-neutral? There are trade-offs in every decision, but you need to be deliberate about it.
- Create – and repeatedly vet – a list of Cloud Design Principles. These will be foundational in your workload placement decisions, so it is important these deliver the right outcome.
- Make sure you have a clear strategy for identity and access management. That is beyond the scope of this article, but is a critical factor to continued security as your data and applications move to the Cloud.
- Don’t forget to design/integrate support models for each of these Cloud types (or components for PaaS).
What are your thoughts and recommendations on moving to the Cloud? Did you create a robust strategy first? Or did you just end up there and it all worked out OK? Maybe you think Cloud is just an overpriced way of outsourcing! Whatever your thoughts, I would love to hear them. Please comment below, and I will respond as soon as I can.