How can you evaluate vendor lock-in risks in cloud architecture?

Building a Cloud solution to be modular and support multiple cloud providers is not only good for avoiding lock-in, but also a good strategy for a disaster recovery plan.

Valorar una migración a la nube siempre es un tema delicado. Mas allá de las modas que muchas empresas han seguido (el mercado, ya se sabe...), la decisión de moverse a la nube, de una forma total o parcial, siempre debe ser una decisión muy estudiada, bajo un programa global que garantice la consecución de los objetivos prefijados. La nube tiene múltiples implicaciones críticas para cualquier negocio (operaciones, costes, capacitación del personal, ... ) y como cualquier gran proyecto, debe estudiarse de forma adecuada.

Como es habitual tratar de no dejarse llevar solo por los casos de éxito. Es un cambio de paradigma que si bien tiene muchas ventajas conlleva algunas limitaciones. Mi recomendación es iniciar con un proyecto no crítico pues las limitaciones se encuentran en el andar.

From my point of view there are a few "details" we ca look into it, to evaluate vendor Lock-In risks. - What do they offer? First understand what the vendor offers (services, product′s) then verify is they are specific services or product's, or are widely supported? - Reassess the customer/vendor relationship to ensure the business goals are aligned. - Understand the terms and conditions of the services provided. - Costs, in case of migration to another solution or another provider, analise the "hidden" costs

Check whether it's a genuine business need ..and is it addressed through vendor lockin first ? whether that can be achieved in any other way within the landscape from the vendor system /application itself

For Cloud Provider Comparison these points should be checked; Features Prices Service Level Agreements (SLAs) Support Reputation For Cloud Service Comparison these points should be checked; Compatibility and Interoperability Portability Standardization Cloud-Agnostic Tools and Frameworks Abstraction Tools Multi-Cloud Deployment

I really like most of the thoughts shared here , they are all valuable and insightful . Yet , I would add a very important element coming out from on the ground experience , which is your internal power : have you created a skilled and competent team to take you through the cloud journey and provide you with the needed flexibility for manoeuvring and adopting a good cloud strategy ? That is a key element to avoid supplier lock in or even to reduce your business costs .. Get back directly to me for more real cases that are linked to the above

To prevent vendor lock-in with cloud solutions, focus on a universal architecture. Opt for commonly supported services across major providers like AWS, Azure, GCP, or on-premises systems. Use universally compatible components like AWS EC2/Azure VMs for compute tasks, AWS S3/Azure Blob for object storage, and widely supported databases like Postgres or MySQL. This approach ensures portability across platforms, including GCP and Oracle Cloud. For event streaming, avoid exclusive reliance on provider-specific services; instead, choose solutions like Managed Apache Kafka for broader compatibility.

Escolher servi?os que n?o te deixe preso a um único fornecedor de modo que n?o tenha a capacidade de conseguir migrar para outro provedor caso seja necessário

In my experience, it is useful to go in for a multi-cloud approach. - Diversify across multiple providers for increased flexibility - Embrace interoperable solutions and standardized interfaces to ensure portability, empowering your business to pivot between providers while retaining control. This, of course, comes with its own sets of challenges - interoperability issues, and the need for people with expertise on multiple cloud technologies, a well-executed multicloud approach remains pivotal in mitigating the risks associated with vendor dependency in the cloud space.

Microservices or event-driven architecture alone will not solve the problem. If you are convinced that vendor lock is a risk you cannot afford, you need to build a facade between your applications and cloud services. This facade acts as a proxy, allowing you to prevent vendor lock from spreading through the system. By taking a plug-in approach to implementing this mechanism, you can make the transition from one solution to another less painful. However, you often have to sacrifice the unique functionality offered by vendor services. In this case, you must weigh the pros and cons to make a decision.

Emphasizing modularity and flexibility in your cloud architecture proves instrumental in mitigating vendor lock-in risks. By avoiding tight coupling of components and services to any particular cloud provider or platform, you enable adaptability and reduce reliance on proprietary features. Adopting loose coupling strategies, such as microservices, containers, APIs, and event-driven architecture, plays a pivotal role. These techniques facilitate the isolation of dependencies, reducing the scope of necessary changes during migration or integration. Furthermore, they empower you to leverage the optimal features and services offered by various cloud providers without sacrificing functionality or performance.

To maintain cloud independence, use the same techniques from prior systems, such as hardware abstraction layers. Define a common interface for _what_ your system is doing, with pluggable back-ends that express that in a cloud-specific way.

In achieving a vendor lock-free environment, the effort is substantial, involving limited service options and extra investment in development, design, and delivery. However, the flexibility gained is invaluable. Companies should aim for minimal reliance on specific cloud services and favor universally available services for easier portability. For high SLA demands, consider an active-active setup across multiple clouds for enhanced resilience and risk distribution.

Today it's even pretty convenient to design a multi cloud platform with OpenTofu etc. I think that most of the self contained services are way cheaper than the cloud managed service but it's better to pay attention to all the aspects of the service so if you chose hosting your own PostgreSQL instead of using RDS than you should probably make sure you're setting backups on a timely fashion and that you can actually restore from them, I'm not saying it should be very complicated but it does require handling the service from all different aspects. Lambda for example is pretty cheap when it comes to doing some tasks once in a while but for 100% usage EC2 is way cheaper yet doesn't allow parallel processing the way Lambda does.

I think the most important thing is to have a recovery plan. Start by deciding what you need to achieve, which capability do you need available first, and what are the dependent systems you need to supply that capability. Then you need to look at options to reduce the dependencies, so you can make your capabilities available faster. This also helps when you have smaller incidents, when you don’t have a full outage of an entire region or similar. Systems need to perform a graceful degradation. And to be able to perform the recovery, you need a backup. But the recovery is the main feature you want. You don’t want backup, you want restore.

Important part of your backups testing is to test it outside the service provider environment, e.g test recovery on your on-premise or other service providers environments in case you have sudden decision or incident that force you to leave the current provider.

At Prizsm Technologies Ltd., we have developed a new paradigm in cloud data storage that disaggregates information (files, objects, blocks, etc.) and randomly distributes bit-level data across multiple cloud service providers' storage endpoints. Our homomorphic transformation algorithm creates redundancy across the endpoints to ensure continuity if an endpoint becomes unserviceable and fails. As well as technical failures, you may fall-out with a service provider due to SLA issues or a ramp in charges. If this is the case, you can simply walk away. The random collection of binary digits, ones and zeros, they retain, cannot be used to keep you hostage as they are worthless and without meaning. Just like pulling an HDD out of a RAID array.

Another aspect to consider is DR concerns. For example, where are the backups are physically stored, if something happen to the vendor physical storage how long it would take them to upload your recovery on an alternate site. What are the vendor SLA agreement.

The distinct use cases should be evaluated separately. Backup and restore may be offered by your cloud platform, subject to log retention limits. Data extraction options should be explored (and exercised) in light of the access requirements, as database images, data synchronisation, XML extracts etc all provide different access capabilities and corresponding costs. Archiving is similar. The major cloud platforms have spawned a marketplace of data extraction, backup and archiving tools that extend basic platform capabilities, but each must be evaluated as well.

Before even diving into any technical architecture aspects, the legal team and attorneys, alongside with the compliance officers, should review any and all clauses very carefully and consider what the legal implications and rammifications of a support contract entail, including jurisdictions.

If this sounds like a lot of work, it is. Cloud platform specialists can monitor license and contract changes, but the contunuing assessment of 'fitness for purpose' is likely to require a small working group of platform specialists and business stakeholders, including representation from the executive sponsors thru to product owners and administrators. This is not often done, in my experience.

Continuous monitoring and evaluation of your cloud architecture serve as pivotal steps in proactively addressing vendor lock-in risks and recognizing potential opportunities. Tracking cloud usage, performance, costs, and user satisfaction against predefined business objectives allows for informed decision-making. Regular reviews of cloud contracts, policies, and Service Level Agreements (SLAs) are crucial. Moreover, soliciting feedback from stakeholders, customers, and partners is invaluable. Incorporating their suggestions and expectations into the cloud strategy ensures that it remains aligned with evolving needs and fosters a collaborative approach toward reducing vendor lock-in risks.

Ter planos sólidos de backup e recupera??o é uma medida de seguran?a fundamental para qualquer arquitetura de nuvem. Isso inclui a implementa??o de backups regulares de dados e a configura??o de ambientes de recupera??o de desastres. Essas medidas garantem a continuidade dos negócios e a integridade dos dados no caso de falhas ou interrup??es do servi?o. Além disso, os planos de recupera??o devem ser testados e atualizados regularmente para assegurar que sejam eficazes e estejam em conformidade com as políticas de governan?a de dados da empresa.

After transitioning to the cloud, it's crucial to monitor your resources, components, and designs. This not only helps identify vulnerabilities but also ensures updated components that minimize the risk of lock-in within cloud architecture. This also provides grow opportunities taking advantage of cloud services. Monitor also will help to reduce costs and understand better the information workflow of cloud platforms. At the end in my perspective cloud architecture need to support the business model and without monitoring you won’t have a clear path of the business needs or even you are able to support.

Vendor locking, per se, it's not something bad. In an ideal world, it is something to be avoided for various reasons like lack of flexibility or interoperability, or the high switching costs. But we are far from an ideal world, and companies have sometimes important reasons to fall into that: higher delivery times on a specific technology, a great deal on the pricing, ... It is a matter of the right balance, in the end. And ensuring that it fits the long term strategy is key to ensure that no matter what you choose, you won't regret it in the long run.

Define what an OPEN cloud architecture would look like and compare possibilities against it to understand risks and trade-offs.

I would consider the following to mitigate risk of cloud vendor lock in: 1. Assess Needs and Service Compatibility: Evaluate current/future technology requirements and service/API compatibility with other providers. 2. Data Portability and Contracts: Examine ease and costs of data migration and terms of service for data portability and exit strategies. 3. Multi-Cloud or Hybrid Strategy: Consider the feasibility and benefits of using multiple cloud providers or a hybrid approach. 4. Regular Review and Market Trends: Continuously reassess vendor lock-in risks and monitor the cloud provider's market stability and trends on a monthly basis.

There are certain situations where Vendor lock in risk simply cannot be avoided. A very good example is having Data warehouse and ETL pipelines implemented on a particular platform. Therefore, choosing a Vendor for your Data warehousing needs must be done with a long term goal in mind. Also it is important to evaluate support for third party integrations such as Data lakes. Choose a vendor that gives the most options for integration with solid documentation and tech support. Also evaluate compliances offered out of the box such as HIPAA (is applicable).

Recently I encountered one vendor who was offering retro-cloud experience where they gave the customer the option of self hosting. And while this goes against the narrative of the cloud gurus, it does help alleviate the loss of control that most customers feel about their platforms when they are totally cloud based. The vulnerability of companies to cloud based providers is enormous. Consider recent news stories of companies being de platformed because of their values being deemed incongruent with the cloud providers values. In at least one case a company was given just 30 days to relocate. How many companies can successfully relocate readjust in 30 days??