Chapter 6
The Truths Behind Multicloud That Few Understand
Get your facts first, then you can distort them as you please.
— Mark Twain
Multicloud can make things much easier for a business, or it can become just another thing to be fixed, or it can be the thing that puts the business out of business. This chapter delivers factual multicloud information without the added spin from cloud and technology providers. We focus less on what multiclouds are but on what they should be, and less on what doesn’t work but what does. We also impart some pragmatic advice about how enterprises can find true business value in these complex monstrosities.
The goal is to find the best business value rather than the buzziest technology. Although the best route to success could initially cost more, it can take you to a place where the business value is obvious. It could even change your business from fair to good, and then to great, and then to a disruptive innovator that can lead your market. The alternative is to become a fast follower, where mediocrity becomes the dubious reward.
The presence of multicloud in all our futures makes this perhaps the most important chapter in the book.
Hybrid Cloud Realities
To understand where multiclouds come from, let’s look at the first complex cloud computing architectures that emerged back in 2008 in the form of hybrid clouds. Industry and government organizations initially defined hybrid clouds as public and private clouds paired to work together to provide the best of both worlds. You could have a private cloud running in your data center, perhaps hosting sensitive data or applications that required specialized processing. You could also run applications and store information using the exponential resources of a public cloud provider. The idea was that you could move applications and data sets in and between private and public clouds as a hybrid cloud configuration, and your hybrid cloud would ride off into the IT sunset, ready to deal with any business problems you tossed at it.
Unfortunately, that’s not the way it worked out. Private clouds proved to be the Achilles’ heel of hybrid clouds that eventually drove today’s shift to multicloud. As you can see in Figure 6-1, interest in private clouds shrank relative to the growth of public clouds. This happened for a few reasons. Initially, both had parity of features, such as just providing basic storage and compute. Many private clouds were open-source systems that could not keep up with the explosion of features and functions in public clouds. Public clouds quickly grew to what they are today: one-stop shopping for most IT needs, including storage, compute, analytics, AI, IoT, management, governance, security, and…you get the idea. It just made no sense to move to a private cloud when all indicators pointed toward that becoming obsolete technology.
FIGURE 6-1 Traditional hybrid clouds were paired private and public clouds. An explosion of features and capabilities in public clouds caused interest to shrink in traditional hybrid clouds when the private clouds could not keep up. Meanwhile, the interest in public cloud computing continued its steady growth.
Of course, the old school naysayers pointed out potential public cloud security issues, claiming that in no world would their data be more secure running on hardware they did not own. That concern proved to be unfounded. As more R&D dollars were spent on public cloud-based security versus that of traditional systems or private clouds, it became less secure to host data within traditional data centers versus public cloud providers. Public cloud providers then and now get more R&D love from the technology providers and thus have the best of most systems, including security. So, with the security factor no longer working for the private cloud argument, interest in private clouds fell relative to public cloud growth that still dominates today (see Figure 6-2).
FIGURE 6-2 Private and public clouds had feature parity when cloud computing first became a thing. Over the years, public clouds outspent private clouds on R&D. Most private clouds are open-source systems sold by integrators and small cloud companies, whereas private clouds are multibillion-dollar mega companies. Naturally, the momentum was on the side of public clouds.
Despite its decline, we did learn a few things from the use of hybrid cloud computing:
The choice of services (private and public clouds) provides the advantage of flexibility. If one service does not work, the other likely will. One can back up the other, and we can also leverage them for different purposes.
The ability to choose different services for different purposes means we’re not locked in to one specific cloud platform. We can mix and match private and public cloud services to provide the most agility and flexibility.
Hybrid clouds make operations much more complex. We needed to replicate tools across private and public cloud platforms, and we had to maintain two different sets of skills in the organization. Operations were more costly and complex.
Hybrid cloud computing is still around today, but it has evolved. Today, any local system that’s paired with a single public cloud is called a hybrid cloud whether it’s a true private cloud or a mainframe; it doesn’t seem to matter. The idea is that a private and public cloud work together to process applications and store data. Although it’s not like the earlier definitions of hybrid cloud, it’s a legitimate architectural pattern that’s perfectly fine to use today.
The Move to Plural Public Clouds
So, why the sudden move to multicloud? While it might seem as though multicloud suddenly showed up as a new cloud computing concept overnight, it’s been steadily growing and evolving for years. Like most things that become famous, it didn’t just happen overnight. People just finally noticed.
I have a saying about multicloud: Whether it’s found on purpose or by accident, multicloud is an inevitable reality for most enterprises.
In its most simplistic form, multicloud leverages more than a single cloud provider, meaning two or more public cloud providers. While private clouds can be part of a multicloud, most multiclouds leverage multiple public cloud providers such as AWS, Microsoft, and Google. Or even those three and Oracle and Alibaba. Don’t fall into the semantic arguments that are taking place around the definition of multicloud; it’s just any cloud deployment that leverages more than one public cloud provider.
In the beginning of multicloud, many enterprises leveraged a single cloud provider and slid into multicloud almost by accident. There were always exceptions being made as developers and end users found some vital public cloud service that was not part of the preferred cloud provider’s services for the enterprise. Ta-da. The enterprise became a multicloud user. In many of my clients’ enterprises, IT denied that the other cloud(s) existed. A network scan will reveal other clouds in use on the enterprise network. Ta-da again. The enterprise has a multicloud.
Multicloud followed the same pattern of adoption we saw in the “IT Showdown” movement when employees used their company credit cards to adopt SaaS-based systems, typically to circumvent corporate IT because they were sick of hearing “No.” This is how many companies first entered the cloud. IT got dragged in kicking and screaming when their outlaw users adopted cloud for them and then pushed the resulting problems back to IT when administration and security of those SaaS clouds got too hard and too costly.
Adoption of multicloud followed much the same patterns, but now IT is usually aware that it’s happening, either on purpose or not. “Not on purpose” means that a series of exceptions were made to leverage cloud services from other IaaS cloud providers other than the IT-set standard. So, Cloud A could be an enterprise’s primary provider, typically with many past press releases to promote the “partnership.” The new normal is that the number of other IaaS public cloud providers in use is in double digits. Moreover, clouds are still being added to the mix because specialty cloud services are needed that the existing cloud service provider can’t supply for one reason or another.
Okay, yes, it’s safe to admit that we’re all multicloud. Now what?
Obviously, “on purpose” is the way you should adopt any technology, multicloud included. It shouldn’t just happen, but instead unfold around a well-thought-out plan that includes sub-plans about how to deal with security, governance, operations, and so on, across each cloud within a multicloud. If you fail to create and follow a plan, you’ll likely have to solve the same problems twice. Once in quick reaction to an urgent need, such as a security breach or outage. Twice when you realize a comprehensive multicloud plan is required to deal with the complexity and heterogeneity that multicloud brings. We cover the downsides and the upsides of leveraging multicloud later in this chapter.
Best-of-Breed?
The typical battle cry of those who need to leverage clouds other than the approved enterprise standard is the fact that they need to leverage best-of-breed technology. This means a technology is identified as the most optimal solution for a specific problem or set of problems. For example, a special-purpose database built specifically for manufacturing that’s needed to support a manufacturing application. Or a proprietary medical application and database that’s needed for internal R&D. Or it might be a system built to provide current information about legal regulations and business requirements within certain territories and/or countries. These products are typically found within the walled garden of one cloud provider, but not others.
The pushback is, if we allow exceptions, then we’ll end up with a “complex mess” of many different cloud services that must be maintained with the right staff skills to support them. They also need to be secured and governed to meet the standard of the company, and perhaps laws and regulations.
If the previous arguments and costs are presented prior to leveraging a “nonstandard” cloud, and the ROI proves the exception benefits greatly outweigh the costs, then the exception should be made. Unfortunately, most users who need the exceptions don’t realize the domino effect of their choices, and they instead tend to ask for forgiveness rather than permission. Hello, complexity.
Because complexity is the primary downside of leveraging more than one cloud, this chapter suggests ways to mediate complexity and make multiclouds work in cost-optimized ways. This is perhaps the most important lesson that I can convey in this book.
To understand the reasons we leverage best-of-breed technology, it’s best to look at two common problems and solutions, as depicted in Figure 6-3 and Figure 6-4. In Figure 6-3, it’s assumed that those who build innovative solutions within an enterprise are limited to cloud services from one specific provider. As the need for innovation rises, the ability to leverage best-of-breed technology is limited to the cloud services included with the “preferred cloud provider.” In turn, this limits the “Business Innovation Supported” and diminishes the level of “Business Value Created” as a direct result of limiting the use of best-of-breed technology—in this case, cloud services that are not offered by an enterprise’s preferred cloud provider.
FIGURE 6-3 Leveraging a single public cloud provider limits the technology we can use. This leads to less optimized solutions than if we had access to more cloud services or best-of-breed technologies that could create more innovative solutions.
Of course, the preferred cloud provider may also offer the best-of-breed services needed by the innovator, but this will not always be the case.
Figure 6-4 models a problem where the “Need for Innovation” is the same, but there are no limitations on the use of best-of-breed technology or, in this case, public cloud services from any public cloud on the market. This allows developers to find optimal cloud services for the problems they want to solve versus making do with services that happen to be available from a single IT-approved cloud provider. Thus, the ability to “Leverage Best-of-Breed Technology Available” raises the levels of “Business Innovation Supported” and, more importantly, increases “Business Value Created.”
FIGURE 6-4 When leveraging a multicloud, you have access to more cloud services and thus more cloud technology, such as specialized analytics, AI, and high-speed computing. You can use whatever services you need to optimize your business solutions, which will support more innovation and thus grow business value. These are the primary reasons we leverage multicloud.
Of course, the specific business involved determines the amount of value available to create. Best-of-breed flexibility will result in the most benefit for companies that need unfettered innovation to increase business value. For instance, best-of-breed flexibility is highly valued by companies in the tech and financial services, where innovation can make or break an enterprise’s ability to grow value in that sector. Best-of-breed flexibility will be less of a value driver for a tire manufacturing company that does not plan to change products or increase future capacity. Thus, we’re back to the often-used answer: It depends.
Price
The price argument for multicloud is tougher to make. I’ve heard several variations of the rationale to leverage multicloud because of cost. They come down to
The ability to put yourself in a better position to negotiate with the public cloud providers. Because there is an established relation with at least one other provider, you can threaten to give your business to that provider if the current provider doesn’t come down in price or provide better terms.
The ability to leverage best prices for specific services as you need them, which allows you to compare prices in real time. For example, if you need to leverage 100 terabytes of storage, you’re automatically routed to the least-cost service that provides the same record of performance. Cloud service brokers (CSBs) automate this process for you. This can also automate specific cloud cost optimization, where an application load is rehosted with a mix of compute and storage services that are optimized cross cloud, which provides more possibilities for optimization because you’re using two or more providers.
The reality is that most or all price benefits from leveraging multicloud are quickly eaten up by the additional cost of running a multicloud deployment. We cover that later in the chapter. The bottom line is that cross-cloud automation is not much of a benefit unless you have a specific way of leveraging multicloud to gain discounts that justify the time and cost of getting those discounts. Cost is a benefit that you should look at but is rarely the only reason enterprises move to multicloud.
Business Realities
As with any technology, multicloud needs to live up to some business realities. First, multicloud is more expensive than single cloud deployments for obvious reasons. As you can see in Figure 6-5, the more public clouds you deploy, the more it will cost:
Operations require management of more moving parts (cloud services), so the cost of operations skyrockets as you obtain specialized skills and tooling.
Cloud FinOps (Cloud financial management operations) also become more complex, and thus present missed opportunities for cost optimization across a multicloud.
Overly complex multicloud deployments increase security and outage risks, for which there is a clear cost.
FIGURE 6-5 Even with complexity mediation, the cost of multicloud will always be higher. The added costs of operations, security, and heterogeneity also contribute to the cost of complexity. Base your case for multicloud on the soft values that multicloud can provide, such as support for innovation as presented in Figure 6-4.
Many are quick to point out that multicloud doesn’t need to cost more if we properly account for operations, security, FinOps, and governance. While I agree with this statement in principle, the practical reality is that we can reduce the cost impact of multicloud, but we can’t eliminate it. That’s why I get concerned when I hear multicloud being promoted to save money. It doesn’t. However, there are other factors to consider that can counteract or surpass the additional costs.
The ability to drive more innovation and speed within a business is the core reason to move to multicloud. Depending on the type of business involved, these benefits can return 20 times that of the investment. They can also offer a strategic advantage to a company that wants to become a disruptor, and not be disrupted. A good way to prove this business case is to look at the most innovative and successful enterprises in the marketplace. When asked, most will credit a culture of innovation, and few limits to the technologies the innovators can leverage. This means access to all best-of-breed, which results in multicloud 100 percent of the time.
The concern here is that business leaders will get sticker shock when they look at properly planned multicloud and may outlaw multicloud altogether to avoid the complexity and the costs it will bring. Although I can see the scary nature of the additional costs, I also see advantages that are too great to ignore. I’ve watched short-sighted executives avoid multicloud for the wrong reasons and then wonder why other more aggressive and innovative businesses beat them in the marketplace. These days, if you’re unwilling to weaponize technology to take your business to the next level, you’ll fail. Full stop.
Multicloud Upside Realities
Multicloud benefits should be beginning to form in your head at this point in the chapter. Now it’s helpful to understand what’s being said in the marketplace and talk about what’s true and what’s not, because the amount of misinformation in the cloud computing space is becoming a problem. Yes, cloud computing professionals can disagree on issues, but facts are facts. Instead, marketing narratives are taking over technology realities.
Let’s look at some of the realities of perceived benefits and then the upsides, considering that they naturally lead to a discussion of the downsides. Indeed, most multicloud upsides become the downsides. How can this be true? It’s a matter of understanding that most benefits and costs of multicloud are a set of trade-offs that need to be carefully considered well beyond the PowerPoint presentations of vendors and analysts who often have hidden agendas. Complicating this issue, the same people may get some of this right as they demonstrate some advantages of multicloud. Too often they fail to cite all the upsides and downsides that need to be considered. That oversight does not help build a multicloud strategy based on pragmatic reality. So, let’s share some secrets here that are rarely discussed.
Lock-in Realities
“Multicloud avoids lock-in.” That phrase is often sold as an upside to multicloud, and you can kind of see the logic here, but the reality is far more complex. If you have a multicloud that’s made up of more than a single public cloud provider, then you have access to different native cloud services and can thus avoid lock-in. Right?
Wrong. There are shades of gray. First, it’s easier to move from one cloud provider to another if that cloud provider is already onboarded as part of your multicloud deployment. So, if you build applications and databases on AWS, which is part of your multicloud along with Microsoft and Google, then it will naturally be easier to move those applications and databases between public clouds that your multicloud already supports. This is just a reality, and it’s an upside, but not by much. You’re not actively avoiding lock-in; it’s just a by-product of preexisting relationships with other cloud platforms that makes moving applications and data a bit easier.
Second, you don’t really avoid lock-in. If you use a cloud provider’s native features to localize applications and databases, then moving to another cloud means the code and databases still need to be modified to accommodate another cloud provider’s native cloud services. You’re just moving from one walled garden to another. You must adapt application processing, governance, security, database access, and so on to accommodate the “new” public cloud provider’s services. Of course, we can use more portable technologies such as containers and build applications that take a least common denominator approach to development, which allows for better portability.
However, containerization of more traditional applications costs more time, money, and risk. Leveraging the least common denominator approach means that your application will provide substandard performance on all platforms, albeit the application will be much easier to move between platforms. When given the choice, most will want native performance and not want to sacrifice that performance for platform portability that they’ll likely never utilize.
There is always a way to toss money at an architecture to avoid lock-in, which will resolve parts of the problem. However, tossing money at the problem means that the business case for building portability takes a hit, considering that you’re spending more resources to achieve it. Most applications and databases are neither business critical, nor will they ever move. This is how the upside of avoiding lock-in becomes a nonissue. We talk more about this when we hit the downsides of multicloud a bit later in this chapter.
Power of Choice
By far, the largest upside of multicloud is choice, which allows the use of any cloud service, for any reason, for any purpose. Although I already introduced this benefit earlier, it’s helpful to have a deeper understanding of the core choice benefits.
Multicloud provides the ability to leverage unique services to create innovative systems that can take the business to the next level. Figure 6-4 depicted the relationship between access to the most types of cloud services with the ability to quickly build solutions that are unique and innovative. More access drives more innovation and thus more business value.
Leveraging these services puts volatility into a single domain, the domain of each service. As we learned back in the days of service-oriented architecture (SOA), and now the use of microservices, it’s better to leverage reusable services than re-create the same service each time you need that function or feature. Multicloud can provide the maximum number of service choices, and it promotes the use of services by its ability to find specific solutions to problems. Thus, if we promote the use of services, we promote sound application development that allows us to get to innovations faster. That’s the choice value point in a nutshell.
Of course, choice is an upside and a downside. Many CIOs point to the cloud’s abundance of choices as the reason that heterogeneity and complexity become problems. Indeed, many short-sighted CIOs restrict the use of cloud services, both in a multicloud and even within single cloud deployments. These restrictions are their sincere attempt to deal with complexity issues and promote the use of standard services with easy-to-define levels of required support and skills. CIOs may feel good about this decision, but the restrictions could ultimately kill many businesses that require innovation to remain competitive. Although this might not doom the tire company in Ohio, a bank or health-care company that needs to leverage technology as a true force multiplier would see its value drop like a rock.
Figure 6-6 depicts a single cloud deployment, a simple structure that provides only those services that are native to the specific public cloud provider or third-party services that can run on that provider. Thus, you have access to a finite number of development platforms, databases, AI systems, storage services, compute services, and other services that are a part of the walled garden of that specific provider.
FIGURE 6-6 A single cloud deployment, while better than most traditional systems, limits cloud users and developers to a finite number of services. The impact of this limitation depends on the needs of the specific business.
An argument can be made that most major public cloud providers offer a wide-enough variety of choices to promote innovation. Indeed, when you add up the native services and those that can be found in the third-party marketplaces, you’ll see an impressive number of available services. The trouble arises when you consider the true value of best-of-breed, where many of those public cloud services have unique advantages if they run on a specific cloud, such as AI, analytics, development, and other features that some clouds might do better than others. Limiting choice means an underoptimized solution, such as an application that uses a cloud-native first-generation AI system that is 50 percent less effective in forecasting market demand than a non-cloud native third-generation system. The application that’s native to your cloud won’t bring the maximum amount of business value back to the business.
Figure 6-7 is a multicloud that depicts some of its advantages and limitations. There are more boxes, thus more services to choose from. Moreover, there are more core services such as storage, compute, AI, and development services that we consider foundational to most applications that we use these services to build. This is not about one specific service, but picking services that have many interdependencies on the native cloud platforms that combine to provide value.
FIGURE 6-7 Choice relates to best-of-breed and thus the ability to enhance innovation. This is the single highest reason that enterprises move to multicloud. They have access to more services, including types of services, that are provided by different public cloud providers. However, if you must figure out operations, security, governance, and so on, for each cloud, that additional complexity costs more time and money. You’ll see the connections later in Figure 6-10.
Let’s say you have a database running on a cloud provider that is tightly coupled to the native serverless development systems and high-performance storage systems. All are native to a specific cloud. You measure the value of a service not only by the service itself, but by the collection of services that are part of a specific cloud provider. Remember that the same systems function differently on different cloud platforms. Although the same third-party vendor could provide databases, AI systems, and data analysis systems, their performance depends on how that cloud’s services leverage native cloud services to work. The results range from “I can’t tell the difference” to “This is a huge difference that will make or break the solution.” Because the same technologies run differently on each cloud, they provide different value drivers.
The Need to Own Your Destiny
Another primary multicloud driver (and a secondary upside) is the concept that if you leverage a multicloud, you control more of your destiny. This need for control comes from some real fears that you’re at the mercy of a provider if you bind all your IT to a single cloud. You will march along with their evolution and hope they make the right choices.
For example, if you leverage a single cloud provider for development, databases, and AI services, then you’re stuck with where that provider takes that technology over time, and even their business success. They might make some dumb decisions about the technology to invest in or have some business issues such as a major lawsuit they are unlikely to win due to a security breach. You’re on that ride with them. That is, until you invest in decoupling your applications and data from that specific cloud and move them to a new cloud that may end up doing some of the same things.
Don’t go too Chicken Little here; these extreme scenarios are unlikely to happen. However, many boards of directors get unnerved when an enterprise is tightly coupled to another company that may end up deciding your destiny without your control or consent. Therefore, many enterprises move to multicloud without even considering the best-of-breed benefits we’ve already covered. If you need peace of mind that another company won’t make key business decisions for you, owning your own destiny could be a core upside value to leveraging a multicloud.
Risk Reduction
Risk is a cost. It’s time to analyze and commodify the actual and potential risks of multicloud based on each specific use case. The devil you know is easier to deal with up front than waiting to deal with inevitable problems down the road.
There are a few schools of thought here. First, multicloud is risk adverse for many of the reasons we just covered in the previous section. We maintain more fine-grained control over what services we leverage (or not), and we do not couple enterprise IT to a single cloud provider that could end up making bad moves and make the enterprise depend on a weak player.
For these reasons, many enterprises look at multicloud as risk adverse because they can take control of how and what cloud solutions are built, as well as manage major services such as security and governance using a layer that spans all clouds rather than use unique tools that work only for a specific cloud provider.
Of course, risk runs in both directions. Yes, we remove the risk that we’re locked into a single company that may end up becoming a weaker player in the marketplace or do other things that make it less useful to the business. The other side of the argument is that the use of multicloud itself presents risk, which we cover in the next section. Again, look for the trade-offs. It’s never one extreme or another, but shades of gray.
Security Issues
Multicloud is harder and more costly to secure than a single cloud deployment. However, it does have certain advantages that you need to consider as a true upside. First, to do proper multicloud security, you need to build a security layer that spans all clouds within your multicloud. Although this common service is more costly to implement and operate, it could end up being the better solution considering that you can also add your traditional systems under this security layer, and even edge computing systems.
This solution provides a net-new security layer that’s typically better than your existing legacy system security. The net-new security layer solves the security problem for your multicloud and can span other enterprise IT systems as well. Indeed, I recommend that this always be looked at as an approach. The added expense could be offset by maintaining one rather than two separate security deployments. There’s also the fact that cloud-ready security finds more R&D dollars from the technology industry, which means better security. Finally, a net-new security layer reduces security complexity because you use a single layer of abstraction and automation to deal with all security.
Governance Issues
Many of the same benefits apply to governance as well. Multicloud governance can include traditional systems under the same multicloud governance framework. In this case, multicloud governance maintains centralized policies and policy management, and again deploys a holistic governance framework using abstraction and automation that spans all traditional and cloud-based systems.
Ops Issues
Operations in a multicloud deployment present a few challenges, but there are upsides to consider as well. Again, we can extend our operations framework and technology stack to provide operations management to all existing systems, cloud and not cloud, that span the entire enterprise. This is the objective of most enterprises but is something that was unachievable in the past. Operations tools did not support enterprise-wide operations and management, although many said they would. Now we have better tools with better funded R&D. Yes, they focus on the cloud, but they also support more traditional systems. They can even support bespoke systems that many enterprises leverage for some critical business purpose, such as the AI systems leveraged by ride sharing application providers.
Of course, there are vast differences between a system or applications that run in a data center and those that run in public cloud-based systems. The idea is to leverage whatever native operation you may need by using those tools and abstraction and/or automation layers that can hide the complexity of all those native systems. This is a common theme: We control multicloud ops by dealing with complexity and heterogeneity via an automation mechanism that removes humans from the operational complexity that they just can’t deal with at scale. If we successfully implement automation, then we have a better chance of making any complex distributed system work effectively, including multicloud.
Multicloud Downside Realities
Remember, for each downside there is a counterbalancing upside. Yes, complexity is an issue, but there are solutions to complexity that allow it to be easily mitigated and holistically managed. It’s also true that multicloud costs more, but the costs can be managed by making better architecture decisions and weaponizing automation technology to reduce the human operator costs and the number of security and governance mistakes those operators will make. Of course, the benefit is more choice, thus agility and access to best-of-breed components to build the most business-optimized solutions.
Cost of Complexity
As you can see in Figure 6-8, complexity typically goes up by adding more systems to a deployment, such as a multicloud that may include traditional systems as well. Many multiclouds will reach a tipping point where the value of adding additional systems can’t be cost justified because unchecked complexity drives costs up to an unaffordable level.
FIGURE 6-8 As we add more systems (and cloud services), cloud or not, the amount of complexity rises. This complexity adds to the cost of operations, security, and governance. Many deployments reach a tipping point where adding more systems generates more complexity than can be cost justified.
Unchecked or unmanaged complexity drives up costs (see Figure 6-9). The more complexity, the more those systems cost to operate and manage. A deployment will reach a point where adding more systems will drive complexity into negative values. Each dollar spent past that tipping point will cost more than any business value it generates. Negative values can be offset only by soft values such as agility, innovation, compressed time to market, and other attributes that provide true business value to your specific business.
FIGURE 6-9 As we spend more money on computing, cloud and not, we increase complexity. At a certain point, complexity reaches a tipping point. From that point onward, additional money spent on cloud and other systems (hard costs) has a diminished or negative value returned to the business. Post-tipping point spending must be offset by soft value business benefits such as agility and innovation.
Here we greet the true downside of multicloud. The complexity increases with the cost of operating and managing that complexity. Multicloud leads to architectural complexity, which leads to more costs, which leads to a tipping point of value. However, complexity can and should be managed. Complexity is unavoidable, but effective management is the only way to obtain multicloud’s potential value. We talk about this later in the chapter.
Cost of Heterogeneity
Heterogeneity and complexity are similar, but it’s helpful to define how heterogeneity affects the amount of complexity that occurs.
For example, an enterprise may leverage 20-year-old LAMP (Linux, Apache, MySQL, and Python) stacks, and 90 percent of the enterprise’s core business systems use that specific technology stack. Let’s say you move the LAMP stacks and business systems to a multicloud deployment that spans AWS, Microsoft, and Google public clouds. The resulting multicloud becomes a complex distributed type of deployment, but it’s much easier to operate because it’s homogeneous in nature. You leverage basically the same platform on three different cloud brands. Of course, each version (in this case, a traditional LAMP stack) that runs on each platform operates a bit differently on each cloud, even though they are basically the same. The more homogeneous the applications’ platforms, the easier it is to operate those platforms in a multicloud—for example, running the same Red Hat Linux version on each cloud platform and leveraging the same open-source database.
Sadly, the world does not always work that way. Most of the deployments you’ll deal with involve very heterogeneous systems that support the application and data deployment and run across public cloud providers that are heterogeneous unto themselves. Thus, less homogeneous technology stacks that you deploy to a multicloud become more complex and costly platforms to operate once deployed. Both homogeneous deployments and heterogeneous deployments on multiclouds are complex in nature, but heterogeneous deployments will always outstrip homogeneous deployments in complexity and costs to operate.
Lock-in
Lock-in still exists within multicloud, albeit moving to other clouds is easier because you have a preexisting relationship with other providers via a multicloud deployment. However, those who think that a multicloud eliminates or reduces the downsides of lock-in don’t fully understand their multicloud. An optimized application or data set deployed on a specific cloud provider will leverage the native features of that provider. A move to another cloud provider within our multicloud still requires us to refactor the code and change the data to work well on the new cloud provider. That’s the definition of lock-in and is thus a clear downside of leveraging a multicloud.
As covered earlier, there are ways to minimize lock-in and make applications more portable. These methods include the use of containers and writing applications that do not take advantage of a specific cloud provider’s native features. However, these options cost more money to leverage, depending on the applications themselves. So, the same downsides exist in some form if you leverage multicloud or not.
Security Issues
Security is more costly to operate for a multicloud because we must deal with more than one cloud platform, and the goal is to deploy security as a set of cross-cloud services. Multicloud security requires a common directory system to support identity and access management (IAM) security, common encryption services, and common systems to support multifactor authentication (MFA).
Complexity unto itself is a security limitation. Most deployment teams use whatever native security services are provided by each cloud provider to deploy multicloud security. Many of the same people must run those security services and multiplex between specific native security systems, which often leads to confusion about which native system interfaces they’re using, which leads to mistakes that raise the risk of a breach.
We should also consider other issues, such as user access, as well as miscellaneous controls that may be needed. Also, the need for visibility and observability, such as having insights into what’s going on now, in the past, and what will likely occur in the future. Also, application hardening, or the ability to bring security to the application level, thus fighting off breach attempts from within the application, not just on the platform where the application is running.
A common security service(s) that spans all clouds in a multicloud deployment is the best approach. However, this typically requires highly skilled security architects to knit together a solution that allows a multicloud to operate using a better security solution than a single cloud deployment, and it should certainly be better than traditional security. No matter how creative you are at building multicloud security, know that it will end up costing more money to build and operate than single cloud deployments. We touch on this issue more in the next section.
Governance Issues
Basically, the same issues that we should consider around security for a multicloud deployment apply to governance as well. Instead of managing authorization across a complex distributed deployment (that is, a multicloud), you must instead manage everything from policies that may relate to a single microservice running on a platform within a single cloud, to common policies that may span all clouds and all services.
The goal is to build a governance stack that provides service governance, resource governance, cost governance, and usage governance services that are configurable to enforce policies that exist for one service or 10,000 services that run across a multicloud deployment. Governance is obviously more expensive and complex for multicloud deployments. In the next section, we talk more about finding common ways to implement governance that spans clouds.
Ops Issues
Operations is a major downside of leveraging a multicloud for reasons I’ve previously covered. Complexity means many more moving parts. Those parts need to be monitored, maintained, backed-up, and updated. Those and many other operational types of processes need to work together to keep all the cloud platforms working with little or no downtime.
Multicloud operations are costly and risky. Seamless multicloud ops don’t just happen. They require a lot of forethought and planning. Many teams approach multicloud operations in tactical ways, using whatever native operations tooling is available on each cloud provider. That approach will run your deployment into a complexity wall that will quickly lead to platform performance issues and outages because the humans who operate the vast array of native ops tools can’t keep up.
This is another problem that requires a cross-cloud solution, an operations layer that sits above rather than within specific cloud providers. Abstraction and automation can hide the complexity from the humans, and they can leverage advanced features such as AI and automation of operational services to achieve a multicloud operational state that’s pretty much hands off.
Key Concepts for Multicloud Success
Now that we understand the challenges of deploying and operating a multicloud, and some of the approaches that will likely overcome these challenges, let’s dig deeper into specific approaches to a multicloud deployment that will optimize its use. The goal is to leverage a multicloud deployment using approaches and technologies that minimize risk and cost and maximize the return of value back to the business. Everyone will eventually move to a multicloud deployment, and most have no idea how to do this in an optimized way. In other words, the deployment won’t be successful. Again, the concepts presented in this chapter are perhaps the most important in this book. Applied correctly, they will lead to successful multicloud deployments.
Remember that most enterprises won’t increase their operations budget to support a multicloud. The key themes are to not replicate operational services for each cloud provider, which is the way teams typically approach multicloud today. That architecture won’t scale, and you will just make the complexity worse. Eventually, you’ll run into complexity issues such as security misconfigurations that lead to breaches or outages due to systems that aren’t proactively monitored. If these issues go unresolved, chances are good that your multicloud deployment will be considered a failure in the eyes of the business, or more trouble than the cost to deploy it.
So, do not replicate operational processes such as security, operations, data integration, governance, and other systems within each cloud. This replication creates excess complexity. Here are some additional basic tenets to follow:
Consolidate operationally oriented services so they work across clouds, not within a single cloud. This usually includes operations, security, and governance that you want to span all clouds in your multicloud deployment. Because it can include anything a multicloud leverages, it works across all clouds within a multicloud deployment.
Leverage technologies and architectures that support abstraction and automation. This removes most of the complexity by abstracting native cloud resources and services to view and manage those services via common mechanisms. For instance, there should be one way to view cloud storage that could map down to 20–25 different native instances of cloud storage. Because humans do not need to deal with differences in native cross-cloud operations (security, governance, and so on), abstraction and automation avoid excess complexity.
Isolate volatility to accommodate growth and changes, such as adding and removing public cloud providers, or adding and removing specific services. When possible, place volatility into a configurable domain (see Figure 6-10) where major or minor clouds and cloud services can be added or removed to meet the exact needs of the business.
FIGURE 6-10 The only way to effectively leverage multicloud and not increase complexity (and the costs of having too much complexity) is to place complexity into a domain. Leverage cross-cloud tools to deal with mechanisms that were once native to each cloud, as depicted in Figure 6-7. Although difficult to accomplish, it’s the only option to build a multicloud that provides best-of-breed services with the least amount of complexity. This approach maximizes business value and minimizes risk.
As illustrated in Figure 6-10, move as much as possible above the clouds to work across the clouds. Typical services such as security, operations, and governance should repeat across public clouds, or any service that can normalize complexity. This approach removes services that can operate only on a single cloud deployment and instead deploys services that work across cloud providers.
Figure 6-10 depicts what is often called a “supercloud” or “metacloud.” A metacloud puts most multicloud complexity into a domain. Services such as operations, security, and governance, as well as a few other common services, are now in a single layer. The metacloud controls the lower layers. In Figure 6-10, you can see that all boxes are connected to Cloud A, Cloud B, and Cloud C. This allows us to control the multicloud as if it were a single cloud deployment. Many types of manual operations become automated in the metacloud, which leads to improvements that typically result from eliminating human errors.
Figure 6-11 depicts another way to look at a multicloud deployment. It’s a good reference point when you build and deploy a multicloud for your enterprise. It’s all about building the cross-cloud layer, a.k.a., the metacloud, which is where the magic happens. The metacloud layer pushes as much as possible into cross-cloud operations. These services include anything that can move from a service that’s repeated within each cloud to a common service for all clouds.
FIGURE 6-11 It’s all about building cross-cloud services that eliminate specific native solutions for each cloud and instead leverage common services that run across all clouds through abstraction, or the metacloud. This is how multicloud works at scale.
Call to Action
What strikes me is that no architectural trickery or gimmicks are required to do multicloud the right way. The solutions described here involve good old-fashioned architectures that eliminate as much redundancy as possible. What may come as a surprise is that traditional approaches can solve the complexity problems introduced by multiclouds. The elimination of redundancy always was and probably always will be the best approach to reduce architectural complexity.
With that said, few multicloud design and deployment teams implement the forethought and planning processes necessary to deploy a multicloud that returns value to the business. They could be part of a “rush to the finish” culture, or key members of the team might lack the required knowledge, or the budget lacks the resources to hire the right team members. If any of those examples or other barriers describe your enterprise, someone must first understand the scope and implications of a multicloud deployment to justify the planning processes, budgets, resources, and staff required to do the multicloud job right the first time. If you’re reading this book, you’re probably that person.
A successful multicloud deployment requires careful planning and detailed research to compile a realistic “big picture” of a multicloud deployment. The new metacloud needs to eliminate redundancy by including cross-cloud approaches and technology that puts complexity in its place. Abstraction and automation should hide much of what makes the same or similar things complex.
Cloud computing will only become more complex over time. All enterprises will need to address complexity at some point as cloud computing becomes more widespread and becomes just everyday computing. Those who “kick the can down the road” to avoid solving the complexity problem until they can find a magical solution will spend at least twice as much time and money to redeploy and redefine the correct solution. Worse, the solution will become harder to define and harder to deploy as time goes by, and the deployment will ultimately hit a complexity wall. I would rather you and your business not go through that pain.