TechTarget recently ran an article titled \u201cCloud vendor lock-in fears dwindle for enterprises.\u201d\r\nReally? That runs completely counter to what we hear from our customers and from partners like Packet.\r\n\r\nThe article claims vendor lock-in is not a major concern for decision makers formulating cloud migration strategies. \u00a0Let\u2019s take a closer look.\r\n\r\nShould You Be Concerned About Cloud Lock-In?\r\n\r\nIn short, absolutely.\r\n\r\nPlease, DO NOT IGNORE the lessons learned over the years about the dangers of vendor dependence. \u00a0Since the early days of the mainframe computer, proprietary vendors have hindered the pace of innovation and impaired business results.\r\n\r\nThe cloud is no different\u2014don\u2019t believe the smoke and mirrors. \u00a0First-generation cloud vendors are trying to lock you in as well.\r\n\r\nIt is all too tempting to take the path of least resistance and place all your bets on one of the major public cloud providers. They have so many services to offer! (BTW\u2014it\u2019s a psychological trap, see our post \u201cJust What the World Needs: Two More Tiers of Storage\u201d)\r\n\r\nAs we\u2019ve written in other posts, cloud lock-in is just as real as traditional software or hardware vendor lock-in, although you often don\u2019t feel the full costs until months after deployment.\r\n\r\nAll of the hidden expenses (API calls, egress fees, etc.) imposed by first-generation cloud providers\u2014expenses you never had to pay with on-prem implementations\u2014quickly add up as you scale your deployment. And by then, it\u2019s too late. You\u2019re committed to a certain path, with certain budget expectations, and it may be too difficult and cost-prohibitive to change course.\r\n\r\nThe main reason? Near total lack of interoperable standards between public cloud providers. Carl Brooks, analyst at 451 Research, sums it up well in the TechTarget article, saying "The fact is that all the major cloud platforms operate differently, so when you pick one, you're basically picking a team."\r\n\r\nAnd a team that is incompatible with every other team out there, playing a different sport with different rules.\r\n\r\nIn the public-cloud world, the lack of industry standards makes choosing different cloud providers for different capabilities a challenge. \u00a0This often leads to extreme options\u2014\r\n\r\ngo all in with a single vendor or build out a completely redundant implementation with a second vendor for failover or as an escape hatch should a relationship go sour.\r\n\r\nBut as the meme goes...\r\n\r\n\r\n\r\nBoth best-of-breed AND cost savings, that is.\r\nDo You Have One Strategy for All Situations?\r\nIf your strategy is to use best-of-breed technology to assemble the right infrastructure for a specific workload, it\u2019s perfectly valid to hunt for capabilities that may be difficult to replace\/duplicate, in the interest of gaining a competitive edge, accelerating time to market, etc.\r\n\r\nThis is true whether your implementation is on-prem, cloud-based, outsourced, SaaS, etc. On the other hand, there are plenty of business requirements that do NOT warrant using highly specialized or cutting-edge solutions that are only available from one provider.\r\n\r\nShould you really embrace the entire stack from a single vendor just to take advantage of their speciality services? While it\u2019s convenient, what are the risks? It\u2019s not as though the cloud has eliminated all technology risks. So what risks remain, and how are you going to address them?\r\n\r\nWhether you\u2019re worried about it or not, if you go with a single cloud provider you are in fact tying yourself to that vendor, with all that entails. \u00a0From the transfer fees to get your data back out (for any reason, including no longer being a customer of the vendor, extended downtime of the provider, etc.), to the closed APIs that your solution is built on that would require varying levels of refactoring (at the least), to blowing it up and trying again in order to deploy on another cloud.\r\n\r\nToday, you can easily swap out compute, storage and networking components in your data center. \u00a0Why should the cloud be any different? Shouldn\u2019t you be able to decouple cloud compute, storage and networking services?\r\n\r\nWhile true multi-vendor industry standards are rare in the public cloud world, one AWS API has emerged as a de facto standard that can help you improve choice. \u00a0The AWS S3 storage API is supported by a wide variety of providers, including Wasabi.\r\n\r\nThis de facto standard API lays the foundation for best-of-breed, multi-cloud implementations that can help you avoid lock-in and reduce risk. \u00a0With a multi-cloud architecture you can pick the best cloud provider for a particular function (compute, storage, networking, etc.) based on price, performance, features or whatever attributes are most important to you.\r\n\r\nFor example, you can use Wasabi as economical, simple and reliable active data storage for your AWS Elastic Compute Cloud (EC2) workloads. \u00a0Wasabi offers direct, high-speed connectivity to AWS and other popular IaaS and PaaS solutions through partnerships with leading colocation, carrier hotel and exchange providers like Equinix, Flexential, Limelight Networks and Megaport. These private network connections avoid internet latency and bottlenecks, providing fast and predictable performance. \u00a0And unlike with first-generation cloud providers, we have no charges for egress or API requests.\r\n\r\nMoving to the cloud? Don\u2019t repeat past mistakes. Avoid vendor lock-in and build it your way with a best-of-breed, multi-cloud strategy.\r\n\r\nLearn more in our Wasabi for Multi-Cloud Compute Environments blog.