3 years ago

Category: Data, Redis, Kubernetes, Infrastructure, ansible

These flagship services work nicely with other services on the platform but often limit interoperability with other public clouds, creating cloud vendor lock-in. There is a case to be made for embracing lock-in: it allows a company to boost productivity and provide value to their users faster. At Render, we are building a new cloud platform bootstrapped over multiple public clouds, with plans to add on-premises workloads, and it’s essential for us to avoid locking ourselves into a single provider.

One without cloud lock-in on the left and one which embraces cloud lock-in on the right.

Our team had prior experience with it, and picked it over other orchestrators for its rapidly growing community and pace of development, despite its shortcomings.

It might appear that we’ve avoided cloud lock-in by embracing Kubernetes lock-in. But this is where our UX decisions help: we’ve chosen to avoid becoming yet another managed Kubernetes platform and instead have focused entirely on making Render a UX-focused platform without exposing Kubernetes to our customers.