Meeting the challenges of multicloud [Q&A]

Businesses have been using the cloud for many years, but only in more recent times have we seen the rise of multicloud as companies seek to spread their public cloud workload.

Why has multicloud become such a popular strategy and what challenges does it present? We talked to Pavel Despot, senior product manager at Akamai, to find out.

BN: Why have companies turned to multicloud as a go-to strategy?

PD: Multicloud is undoubtedly the direction many companies are going. Our research shows that about 30 percent of customers use multiple clouds for their public web workloads. There are a few reasons for this trend. The most common is adding another provider to take advantage of a particular compute offering or location. Business needs might mandate workloads deployed in a specific area or require specialized application logic that the current cloud provider doesn't offer, requiring another one to be added.

Another factor is developer familiarity and preference. When asked to deploy a new service, teams often default to a cloud with which they're most comfortable. If that preference is for a different provider, you find yourself in a multicloud architecture. Lastly, acquisitions are a significant driver of multicloud. Consider all the business systems and infrastructure that come with an acquisition -- cloud workloads are a part of that infrastructure. The effort to migrate those workloads can be substantial, pushing down the priority and leaving critical business components distributed across multiple clouds.

The 'strategy' part is where it gets interesting. Strategy implies an intentional, coordinated action plan with identified outcomes and KPIs. The ad hoc path to multicloud described above doesn’t fit that description. Many enterprises are becoming more deliberate, though. Cloud Centers of Excellence are increasingly being convened by organizations needing a more purposeful and structured approach to cloud services. Their role is to lay a framework for evaluating, architecting, and operating in a multicloud environment. You need to have a plan to call it a strategy.

BN: What major issues are arising from patchwork multicloud environments?

PD: Multicloud environments will experience challenges in development and operations mainly due to the technical differences between providers. Take computing resources, for example. All clouds offer generic virtual machine and container services. These services are a good choice if the workload requires portability across clouds because they tend to be more portable. Cloud providers also offer proprietary compute services -- like customized Kubernetes clusters and serverless functions. These are far less portable but can provide unique capabilities compelling enough to justify the lock-in. Developers and architects in a multicloud environment need to consider that tradeoff carefully during the design phase since it can be challenging to refactor once deployed.

Operations and monitoring is also more challenging in a multicloud environment. Every cloud offers logging and monitoring services, however, unlike compute, there aren’t many standards for logging. As a result, these services vary by provider -- forcing IT to support multiple tools and processes. That problem can grow as applications become more distributed and ultimately result in isolated data lakes that provide very little actionable insight.

BN: In what ways can companies overcome the complexities of multicloud?

PD: Deliberate planning and communication can help teams overcome the complexities of multicloud. Organizations vary in cloud maturity, but few can honestly say they've arrived. What does 'arrived' even mean in that context? Without a plan, companies have no destination or direction. In multicloud infrastructure, that means unmitigated sprawl that impacts cost, operations, and security.

Organizations should start their planning with simple questions -- the destination. "What do we hope to achieve from moving workloads to the cloud?" Capex reduction? Cost savings? Agility? Operational efficiency? Any of these are valid, long-term business goals.

Once you have a destination in mind, you stand a better chance of getting there if you have a path -- the how. "How do we reduce costs in the cloud?" "How do we maintain feature velocity?" As it turns out, multicloud is a frequent answer for both. Still, everyone needs to be aware of their circumstances and understand why.

Once you have the destination and a plan to get there, it's important to tell everybody -- communication. Developers, QA, sysadmins, product managers, and IT staff all need to understand the shared vision, best practices, recommendations, policies, and logic. It prevents different groups from making the same errors, and ensures that those making technology decisions have the right business goals to prioritize.

BN: Is multicloud one size fits all? How can a company decide what multicloud strategy is right for it?

PD: Not surprisingly, multicloud is not one size fits all. Enterprises vary in business goals, technical expertise, and regulatory requirements resulting in too many permutations to make any blanket suggestions. Luckily, planning is a perfect starting point for the decision process. Remember, multicloud isn’t a goal, it's a means to an end. You're unlikely to see ‘increase the number of cloud vendors’ as a goal. Even in cases where a second provider is mandated, the desired outcome is usually redundancy or risk mitigation, not multiple clouds for their own sake.

It's also important to remember that strategies have to adapt and evolve. Business realities impact goals. Constantly evolving cloud offerings offer new tools to achieve these goals more efficiently or at a lower cost.

BN: Do multicloud strategies post any security risks? If so, what are the top risk factors?

PD: Deploying multiple clouds, consisting of numerous regions and VPCs, geometrically increases the number of security solutions to be purchased and maintained -- as well as the amount of potential risks. Keeping web application firewall rules, access control lists, bot protections, and other controls current with a constant stream of CVEs are challenging enough. Doing so across multiple security solutions that are managed and configured differently increases the challenge exponentially. That’s why planning your end state is so important.

Step one in cloud security is familiarizing yourself with the Shared Responsibility Model. Type the name of a cloud provider plus that phrase into your favorite search engine, and you’ll see its standard practice. The idea is that cloud PaaS and IaaS service users are responsible for securing the workloads.

There's complexity in the term 'securing' in practice, however. It's unlikely anyone would deploy a WAF to protect an object store hosting static site assets. What if that object store was serving licensed media or software, though? In that case, security means ensuring that only validated users can access that content. Similarly, security in an eCommerce application means preventing exploitation of customer data and account security. In other words, every public web application component requires a specific combination of security controls based on its business function. That requirement creates sprawl even if we stay within a single cloud provider, since most security services are particular to a region or VPC.

Photo Credit: Stokkete/Shutterstock