Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
Explore our extensive library of experience reports.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
Weekly discussion around “Deming’s Journey to Profound Knowledge” with author John Willis.
VIRTUAL — Helping leaders succeed and organizations thrive (formerly DevOps Enterprise Summit).
Venue: Fontainebleau — Helping leaders succeed and organizations thrive (formerly DevOps Enterprise Summit).
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
November 1, 2021
This post has been adapted from the 2021 DevOps Enterprise Forum guidance paper by Satya Addagarla, Anderson Tran, Mik Kersten, Rob Juncker, Betty Junod, and Sasha Rosenbaum.
Multi-cloud has become the buzzword du jour in cloud infrastructure as either the result of vendor marketing or a reality that enterprises find themselves in organically. In this section, we will provide guidance for evaluating tolerance for lock-in and maintaining focus on the highest value when using multiple clouds.
The reality for the vast majority of enterprises will be, at a minimum, the active use of two clouds for IaaS (infrastructure as a service) and the conversion to SaaS to replace a portion of their existing on-prem independent software vendor (ISV) or custom applications.
Organizations are increasingly working with multiple cloud providers. A recent Gartner survey of public cloud users finds 81% of respondents using two or more providers.
But what are you trying to achieve by using multiple clouds? Should your strategy be designed around avoiding vendor lock-in or to select best-of-breed services? Is it a fad or even worth the effort? Even with the breadth of cloud services available today, most enterprise cloud strategies start with the vendor selection instead of mapping the capabilities needed to the services available.
Avoiding vendor lock-in is a common refrain from vendors as a case for using many clouds, viewed negatively as a vector for financial and technical risk. Meanwhile, using the term all-in is viewed positively to indicate an organization’s commitment to deep specialization in a specific cloud’s infrastructure, APIs, and operating model.
The fear around lock-in is based in the loss of negotiating power and application portability. Lock-in is a more nuanced discussion around the requirements for the application and system components weighed against available services, SLAs, and cost to deploy and operate the application.
Adrian Cockcroft categorizes a set of business and technical lock-ins in this talk about Vendor Lock In. It is important for enterprises to understand the potential areas of lock-in and evaluate their tolerance and ability to change the state of the lock-ins under their span of control as they consider their cloud deployments.
Business Lock-In
Not likely to change once in place.
Technical Lock-In
Can be changed with a varying degree of engineering time and effort.
Soft Lock-In
Systems can be built to avoid being affected by these.
Legal: Regulatory compliance restricts the deployment or data to a specific location or security clearance, limiting the possible providers.
Interface: APIs and query languages differ between components increasing the switching costs.
Implementation: Occurs when the standard interface doesn’t match its implementations. This can be avoided by testing against several implementations.
Political: A business partnership or financial investment prevents the use of certain vendors.
Proximity: When systems make assumptions on how long operations take, leading to latency intolerance, and requires components to be physically close.
Web Service: If some parts of an app are built with a specific vendor’s web service. In this situation, the rest of the application may move, but this specific component will remain and continue to be accessed through the web service.
Financial: When vendor evaluations are negated by existing enterprise license agreements (ELA) contracts with a preferred vendor.
Deployment Architecture: When assumptions are made about a system layout, scale requirements, and special hardware needs that may not be supported across different regions or vendors.
Data: If there is too much data to be moved effectively with the available bandwidth. There are a range of approaches available to address data mobility.
Management: Executive relationships influencing purchasing decisions that override other considerations.
Beyond the different types of lock-in, the risk of lock-in should be evaluated by application. For mature and stable applications, where the majority of the engineering effort is focused around maintenance, keeping that application in a single cloud can be the right balance of effort to value. For applications that are in active development and continuously updated with global deployment requirements, more effort to work across different clouds will result in higher value.
An area of consideration is around the toolset surrounding your cloud infrastructure. When thinking of a mono-cloud approach, ask yourself if you are artificially avoiding an entire ecosystem by only evaluating those offered by your cloud provider.
While it may be convenient to choose infrastructure and tools from a single provider, the evaluation and use of third-party tools can provide greater flexibility at the cost of more up-front effort.
As an example, investing in cloud agnostic tooling to manage the API layer, CI/CD pipeline, and provisioning automation provides for greater flexibility in using different cloud providers when needed. Additionally, when looking at various app and data components, selecting open-source packages with broad ecosystem support adds to your optionality on platforms and cloud providers.
Application portability from one cloud to another is often cited as the multi-cloud utopia, moving running applications as needed to get the best “just in time” cost and performance without disrupting a customer’s transaction. In reality, most optimizations come in the form of right sizing, different types of instances, and contract terms with the provider. The promise of portability is centered around different technical requirements for deployment flexibility and consistency, simplifying scalability, and reliability.
The level of “portability” (aka cloud agnosticity) that you need will dictate the level of technical investment in layers of abstraction and cloud agnostic ecosystem components and tools. Even with this investment there will be differences in many processes to provision, configure, and deploy, as how you configure the infrastructure plumbing is different across cloud providers. It is critical to evaluate the level of need on an app-by-app basis and understand if the resulting value is worth the investment.
The following case studies illustrate three real world scenarios for using multiple clouds, the driver, and the resulting engineering investments
At the KubeCon EU 2019 Panel Discussion Going Multi-Cloud for Realz, Umair Mufti, Data Services Manager at DreamWorks, states that multi-cloud means to their business the ability to hire the talent anywhere around the world and provide them with their custom environment and shared data for the movie or show they are working on. Due to the collaborative nature of the project, consistency in tools and data is paramount among the artists working on the movie. The infrastructure is not the priority. The value is in the content layer that is facilitated by the custom apps which may be deployed on AWS, Google, or a local datacenter.
When cloud exits or repatriation happen, they often make the news, as in the cases of companies like Target and Dropbox. But while they are not common, it is a strategic business decision.
In the case of Target, Amazon’s entrance into groceries turned a vendor into a competitor and fundamentally changed Target’s cloud strategy. They decided to exit AWS and invest in open-source abstraction layers like Kubernetes, Docker, and Spinnaker. This allowed for the ability to deploy and run apps using the application abstraction layer that is common among different cloud providers, providing them the flexibility to deploy their critical customer facing ecommerce and in-store workloads on three platforms as needed. This example highlights the investment in cloud agnostic abstraction layers and their prioritization to high-value applications that directly impact revenue across a very distributed landscape of physical stores and digital (web/mobile) customer experiences.
The use case of running the same production service and data in an active/active state across multiple cloud providers and availability zones that simultaneously accept traffic is an even rarer unicorn in the multi-cloud universe. PagerDuty has spoken publicly about their multi-cloud architecture, engineering investment, and the lessons learned over the years. Running the same service simultaneously across multiple clouds has made the PagerDuty team invest in building, operating, and maintaining the infrastructure plumbing directly so they can have a high level of control versus using the services directly available from each cloud provider outside of raw compute resources.
You will need to consider if the value of your business is in the engineering custom infrastructure in addition to the differentiated value of the apps and services you deliver on top of it. The answer will vary from company to company and from app to app. When considering the level of cloud agnosticity required, enterprises will need to weigh where they perceive their value is. Is it best served in building application business logic or in building differentiated infrastructure? And which applications require this capability and for what purpose?
Our recommendation in pivoting from a multi-cloud to an omni-cloud approach is to consider the cloud utility by application, the objective and key result desired, and its alignment to the business. This allows teams to avoid a “one cloud fits all” or “all clouds fit all” type of dogmatic thinking that limits the decision-making process. Omni-cloud lets the business and application needs drive the infrastructure decisions.
Most organizations should select a primary provider for general purpose infrastructure on which to operationalize processes and then evaluate abstraction layers and ecosystem tools that allow for a level of consistency they would like to achieve across deployments. Having a preferred cloud provider streamlines onboarding, training, and operations. Abandoning dogmatism decreases the flow time from idea to product deployed and value back to the business.
Select the abstraction layer and ecosystem components that you want to invest in that are common across clouds for optionality with a level of consistency. Investment in cloud agnostic workflow and management tools will preserve the ability to choose best-of-breed services and clouds by application, while still maintaining enough control and governance over configurations and policies.
Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.
Welcome to the twelfth installment of IT Revolution’s series based on the book Investments…
In today's fast-paced and ever-evolving business landscape, organizations are constantly undergoing transformations to stay…
Holy cow, Enterprise Technology Leadership Summit Europe Virtual is happening next week, and I’m…
Welcome to the eleventh installment of IT Revolution’s series based on the book Investments…
