The only certainties in life are death, taxes, and cloud lock-in. Let’s look at the reasons behind lock-in reality and why it’s so difficult to avoid. Credit: Thinkstock I’ll admit I felt a bit vindicated by this article about “embracing the discomfort” with cloud vendor lock-in. This is a reality I’ve stressed for years as organizations move to single and multicloud deployments. My viewpoint is not the result of a bunch of external research, but the realities of seeing lock-in as a fact of many cloud deployments past and present. Lock-in is a very old problem, by the way. Back in the day, we had numerous 32-bit operating systems on PCs, including many Unix flavors, Windows, and even OS/2. There was a call to build applications that could operate across platforms, which would thus avoid vendor lock-in. As somebody who reviewed development and deployment tools as well as target operating systems, I found myself knee-deep in the lock-in dilemma. I noticed right away that those who tried to build software that ran on all platforms using any number of API translation layers and OS emulators usually ended up with software that operated poorly on all platforms. Those who built applications using the native features of the platform had much better, more-responsive software that took less time to build. This fundamental trade-off of avoiding vendor lock-in remains the core issue today. Granted, now the game is a bit different with higher stakes. Many cloud providers offer the same operating systems and processor options, the same databases, and even the same ops and security tools. So, why is vendor lock-in still a trade-off? As an aside, if you just announced that you’re off to build systems that completely avoid vendor lock-in, I will wish you good luck. However, unless you want consistently crappy applications, you’ll have to leverage native security, native infrastructure as code, serverless systems, etc., that are usually supplied by different providers as native services, which is why you’re on a public cloud in the first place. If we move to the most feature-rich public cloud platforms, it’s to take advantage of their native features. If you use their native features, you lock yourself in to that cloud provider—or even lock yourself in to a subplatform on that cloud provider. Until there are alternatives, you better get used to lock-in. I get it. Lock-in means placing major bets on specific technology providers, in this case, the cloud providers. The potential nightmare scenario is that a vendor’s prices might get substantially raised at any time, and budgets are tightly coupled to the pricing whims of the primary public cloud provider. Companies are afraid the public cloud provider might decide to get into their customers’ market (which is happening), or have reliability problems, or get purchased by a competing company, or go bankrupt, or do something else to create problems. Obviously, one or more of those things could happen, but for most companies, the risk is extremely low. At the very worst, you would deploy an egress plan that I advise everyone to have anyway. An egress plan outlines other platforms you can move to in the event of a crisis and how you would make that move. Yes, it’s a bit of hassle and money, but it’s often worth the peace of mind. You’ll preemptively mitigate the dangers and have a clearer understanding of the risk of lock-in and how to minimize potential impacts. Is lock-in good? No, but it can’t be entirely avoided. Adjust your thinking a bit and understand that it’s all a matter of managing the risks and trade-offs. Related content feature What is Rust? Safe, fast, and easy software development Unlike most programming languages, Rust doesn't make you choose between speed, safety, and ease of use. Find out how Rust delivers better code with fewer compromises, and a few downsides to consider before learning Rust. By Serdar Yegulalp Nov 20, 2024 11 mins Rust Programming Languages Software Development how-to Kotlin for Java developers: Classes and coroutines Kotlin was designed to bring more flexibility and flow to programming in the JVM. Here's an in-depth look at how Kotlin makes working with classes and objects easier and introduces coroutines to modernize concurrency. By Matthew Tyson Nov 20, 2024 9 mins Java Kotlin Programming Languages analysis Azure AI Foundry tools for changes in AI applications Microsoft’s launch of Azure AI Foundry at Ignite 2024 signals a welcome shift from chatbots to agents and to using AI for business process automation. By Simon Bisson Nov 20, 2024 7 mins Microsoft Azure Generative AI Development Tools news Microsoft unveils imaging APIs for Windows Copilot Runtime Generative AI-backed APIs will allow developers to build image super resolution, image segmentation, object erase, and OCR capabilities into Windows applications. By Paul Krill Nov 19, 2024 2 mins Generative AI APIs Development Libraries and Frameworks Resources Videos