A traditional business strategy for technology companies has long involved vendor lock-in. Once a company chose a solution, they were often stuck with that vendor for other solutions because it was difficult to integrate best-of-breed multi-vendor software packages. This resulted in a need for interoperability within the systems, and it was anticipated that that strategy would be extended to the cloud, with each public cloud vendor expecting customers to expand their cloud relationship over time, exclusively. But that’s not what happened.
It turns out that REST and cloud-native solutions such as containerization are equalizers, and the cloud has become fertile ground for best-of-breed integration. With built-in support for hybrid solutions (combined on-premise and cloud, or multi-cloud architecture), it’s straightforward and efficient to implement a multi-cloud strategy where a service from one vendor is integrated with services from one or more additional vendors (or private cloud) into a holistic solution that meets users’ needs, economically.
Some examples of cloud vendors offering a wide array of services.
Have a Plan for Your Multi-Cloud Architecture
Nothing is free or easy, however. Before an organization embraces a multi-cloud approach, a deliberate and well thought-out implementation strategy needs to be decided that takes more than cost into account. As with any form of architecture, your multi-cloud architecture should be based on selections using measured and well-informed selection criteria. The factors to be considered include:
- Provider Selection – The top public cloud vendors and plenty of others beyond the obvious ones have excellent, specialized solutions.
- Services Selection – Sure there are infrastructure services (IaaS) and platform services (PaaS), but there are also point solutions to consider integrating (i.e. Slack, social media platforms, Git repositories, and so on).
- Costing – With Microsoft, Amazon, Google, IBM and others offering similar sets of services, choosing based on price and pricing model is reasonable.
Your choices could include any combination of options within these selection criteria, and should be based on an organization-wide strategy.
You Also Need an Implementation Strategy
Your selection strategy for choosing the right cross-section of cloud services for your solutions can vary, and include the following:
- Developer-led Strategy – Here, development considers service choices based on technical criteria needed to build the solution. Operations, in turn, needs to provide the general pool of resources required to implement this strategy, especially when it involves private cloud or on-premise infrastructure integration. However, it’s primarily a lead developer or technical manager making the decisions on how to best choose services from different vendors using development-oriented goals (e.g., programming language/platform support, familiarity with a technology such as a database, or purely performance).
Pros and cons – As a developer, I can attest that sometimes development makes technology choices based on ease of implementation, simple curiosity, or to gain experience with something new and popular. This can actually be very positive. For instance, basing decisions on ease of implementation can save time and effort, and allowing development to embrace new technology can empower growth, improve morale and, in turn, increase productivity.
- Operations-led Strategy – If you depend on operations to create hardened and vetted infrastructure, it makes sense to let them pick the services based on management criteria and maintainability. Although seemingly related to the technical criteria developers use, these can differ quite a bit. For instance, operations staff may consider services based on their uptime history, ability to integrate with a management dashboard, or how well it integrates with existing on-premise infrastructure.
Pros and cons – This strategy may result in a more consistent, reliable, or available solution for the customer and the enterprise. It can also be cheaper to maintain. But, this decision may be at odds with development and could drive a wedge between the groups. This strategy may also result in a less diverse implementation, as it can often be easiest for operations staff to work with a single vendor, negating the benefits of an otherwise multi-vendor strategy.
- Feature-led Strategy – Choosing cloud services based on how well the features fit with what you’re building.
Pros and cons – Cohesiveness in focus and offerings can turn a cloud vendor into a strong ally in meeting your product needs. It can also provide fast and practical options in terms of expanding your solution’s feature set. However, making the vendor relationship a priority could cause you to overlook your customers’ needs
An approach that combines some degree of each of the strategies listed, usually makes the most sense, which is also the premise for a multi-cloud solution in the first place. You can be flexible in your decision-making; e.g., choose a service based on development language support in one case, and a second service for its track record of high availability in another.
No matter what strategy or combination of strategies you implement, your architecture should have written guidelines in place to help make company-wide choices, reach consensus among teams (i.e. development and operations), and leverage feature-rich services if your product team and customers have prioritized them.
If possible, have operations and development involved from the start. After all, it’s called “DevOps”, not “Dev / Ops” (with a barrier in between) for good reason. Balancing the benefits of technology-based choices with business or feature-based choices can result in an economically viable solution, helping to create market sustainability.
The Risk of No Strategy
Consequences of not having a well thought-out multi-cloud implementation strategy can include:
- Infrastructure Sprawl – The result of implementing non-cohesive solutions that require one-off hardware choices, or additional computing resources based on non-optimal software packages.
- Not leveraging best of breed services – This may seem like an obvious consequence, but without a deliberate strategy of due diligence, and understanding your options and your objectives, you can’t make the right choices for the right reasons.
- Technical debt – Choosing the wrong solution may require you to refactor later, implement missing features yourself that were otherwise available, work around bugs or reliability issues, or worse.
- Falling behind the competition – Losing customers to the competition that consistently wins in the market.
- Inefficient Disaster recovery – Equally devastating as falling behind the competition. We’ve all heard of Netflix and the benefits of their well-planned multi-cloud strategy driven by their Chaos Monkey and Chaos Gorilla toolsets and testing strategies. Having a multi-cloud strategy can provide a cost-effective disaster recovery benefit on top of the other benefits presented here.