When it comes to cloud and application strategic decisions, one of the common conversations that we are having with clients is: How can we avoid vendor lock-in? 

This is not a surprise, as it has been one of the major concerns for IT decision-makers for years. Playing in a closed ecosystem (including now Cloud) puts companies in weak negotiation positions.

In the best-case scenario, you will see their monthly/annual costs increase at the vendor's will. Or, in the worst, their value proposition will fail, and your business will be trapped in a proprietary platform you need to spend millions to reverse engineer and migrate.

These are the technology trends for 2021 to ensure your company doesn't end up in a toxic relationship with a cloud/low-code vendor:

  • Design your own Engineering Experience
  • Create abstraction at both platform and application levels
  • Add cloud-native technologies to your strategy, agenda and radar
  • Platform provisioning automation

Design your own Engineering Experience

We see more and more companies design and build their own Engineering Experience: A way of work that is flexible enough to meet business speed needs, but also to make key design decisions without compromising the company's future (neither technically nor financially).

Engineering Experience covers not only the traditional development or architecture aspects, like patterns, solution design, best practices, programming languages or technologies but also how they intertwine with the wider Business vision and the Solution Lifecycle Management: Requirement gathering, planning, budgeting, build (both application and platform), test, release and operate.

It is important that this process is coherent, comprehensive, consistent, and flexible enough to meet business needs in time and on budget, but also to be friendly to the people that are part of it. Bad Engineering Experience leads to low-motivated professionals and undesired attrition, increasing costs and delaying project plans.

As it may sound complex and expensive, many companies completely avoid the Engineering Experience, getting distracted by the siren calls of the cloud and low-code vendors buzz, lock-in themselves in not only to a platform but also to specific solution architectures that you can drag, drop and customise with few lines of code. Only time will tell if this short-term strategy will be cost-effective in the long run.

Remember, "Culture eats strategy for breakfast". And Engineering Experience is all about the culture around how business needs are turned into actual solutions.

Abstraction at both platform and application

With the right people and culture in place, we see more and more companies creating abstraction at both platform and application layers, as the first and main action to prevent vendor lock-in. 

"The king is dead. Long live the king!" Kubernetes is becoming the de-facto solution to run workloads (taking the role Virtual Machines once had), becoming the core platform abstraction piece, decoupling most of the application components from the cloud vendors, and also serving as the foundation to other abstraction projects. Like KEDA, an open-source project that allows you to host both Azure and AWS functions in Kubernetes, using the same SDK and most capabilities that cloud vendors offers, but without being locked to the PaaS service.

Modern PaaS and SaaS providers, like Cluedin (A cloud-native Master Data Management solution) are building their solutions natively on top of Kubernetes, allowing them to run their solution in any vendor (AKS, EKS, Rancher, Redshift...), achieving the so desired cloud independence.

Add cloud-native to your strategy, agenda, and radar

Some of the technologies mentioned earlier can be classified as "cloud-native". Rather than tactically choose some of them, companies are creating a full cloud-native agenda, identifying core business problems related to the pre-cloud era, and strategically championing the technologies they need to adopt.

In this context, technology radars are your friends. Ensure you understand what is coming (and more importantly what is being brought to the table), identify a business case or pain point, and see how the technology offering and the business demand match.

Continuing with Kubernetes as the core building block, there are some cloud-native initiatives to extend it, to not only provide all the cluster common resources (Pods, Services, Load Balancers, Network rules...) but also the wider infrastructure applications need to run, like databases, cache, queues... 

The sidecar pattern is proving to be an effective solution to cloud vendor lock-in. Kubernetes enables engineering teams to adopt this pattern easily, with production-ready open-source initiatives like Dapr.

And last but not least, don't forget about communication and observability. Cloud platforms (and their abstractions) require clarity on how things communicate internally, what's happening and where. Dapr, or Istio (which also uses the sidecar pattern) combined with data collection and presentation solutions like Elastic can help you with that.

Platform provisioning automation

If you want to play across different cloud providers, automation is key for your strategy to thrive.

Infrastructure-as-Code (IaC) is one of the key elements, with an interesting shift from proprietary languages. Predominantly, from Terraform's owned Hashicorp Configuration Language, or HCL) to common programming languages like C#, Java, TypeScript, or Python, with Pulumi leading the charge. Terraform is trying to keep its leadership position in the IaC arena with the Terraform CDK initiative. A bit late maybe?

Also, using Custom Resource Definitions and solutions like Kubeform, or vendor-specific solutions like Azure Service Operators for Kubernetes, is now possible to provision a whole platform without leaving the comfort of Kubernetes YAML. Combined with ArgoCD, this combo can provide amazing platform abstraction and delivery speed.

IaC should be streamlined with the wider Engineering Experience initiatives, ensuring a smooth transition from business needs to tangible assets.

Conclusions

Cloud and low-code vendors alike appeal to the lack of engineering capabilities to sell their PaaS/SaaS, hassle-free solutions. However, the price an organisation is paying is not only the current license costs but is also the lock-in to their solutions. In the best scenario, vendors will tend to increase their license and service costs at their will, as your company's negotiation position will be extremely weak due to the lock-in. And in the worst, their commercial proposal will fail and your business will be trapped in a proprietary solution you need to spend millions to reverse engineer and move away.

Instead, you can design an Engineering Experience that ensures you can streamline technology and people, meeting business needs and expectations, in budget, and on time.

With the right people and culture in place, breaking the lock-in from the vendors is key for your company's P&L in the long-run. Define a clear technology strategy and roadmap for your organization. Put Kubernetes as the core building block and abstraction technology, as most cloud providers and on-premises software vendors support it, and combine it with other cloud-native technologies, and initiatives that give you enough freedom to move between vendors.