Earlier this week, Amazon removed Parler from its platform. As a company hosting a network service on a cloud provider today, should you worry about such actions from cloud vendors? And what steps should you be taking now?
In this post, we’ll explore some of the risks associated with being tied to a single vendor, and the costs involved in breaking the dependency. I’ll also give some recommendations on low hanging fruit.
Ultimately, how far down the vendor neutrality path you want to go is a company specific risk mitigation strategy. In this post, we’ll explore the raw information, but deeper analysis would be based on your company’s specific situation. As usual, if you would like more direct help from the team at FP Complete in understanding these topics, please contact us for a consultation.
Vendor neutrality is not a binary. There are various levels on a spectrum from an application that leverages many vendor-specific services to an application which runs on any Linux machine in the world. Achieving complete vendor neutrality is almost never the goal. Instead, most companies interested in this topic are looking to reduce their dependencies where reasonable.
To be more concrete, let’s say you’re on Amazon, and you’re looking into what database options to use in your application. Your team comes up with three options:
Option (1) provides no vendor neutrality. If you, for any reason, decide to leave Amazon, you’ll need to rewrite large parts of your application to move from DynamoDB. This may be a significant undertaking, introducing a major barrier to exit from Amazon.
Option (2), while still leveraging an Amazon service, does not fall into that same trap. Your application will speak to PostgreSQL, an open source database that can be hosted anywhere in the world. If you’re dissatisfied with RDS, you can migrate to another offering fairly easy. PostgreSQL hosted offerings are available on other cloud providers. And by using RDS, you’ll get some features more easily, such as backups and replication.
Option (3) is the most vendor neutral. You’ll be forced to implement all features of PostgreSQL you want yourself. Maybe this will entail creating a Docker image with a fully configured PostgreSQL instance. Moving this to Azure or on-prem is even easier than option (2). But we may be at the point of diminishing returns, as we’ll discuss below.
To summarize: vendor neutrality is a spectrum measuring how tied you are to a specific vendor, and how difficult it would be to move to a different one.
The current situation with Parler is an extreme example of the advantages of vendor neutrality. I would imagine most companies doing business with Amazon don’t have a reasonable expectation that Amazon would decide to remove them from their platform. Again, this is a risk assessment scenario, and you need to analyze the risk for your own business. A company hosting uncensored political discourse is in a different risk category from a someone running a personal blog.
But this is far from the only advantage of vendor neutrality. Let’s analyze some of the most common concerns I’ve seen for companies to remain vendor neutral.
There are many more examples, this isn’t an exhaustive list. What I want to motivate here is that vendor neutrality isn’t just a fringe ideal for companies afraid of platform eviction. There are many reasons a normal company in its normal course of business may wish to be vendor neutral. You should analyze these cases, as well as others that may apply to your company, and assess the value of neutrality.
Vendor neutrality does not come for free. A primary value proposition of most cloud providers is quick time to market. By leveraging existing services, your team can offload creation and maintenance of complex systems. Eschewing such services and building from scratch will impact your time to market, and potentially have other impacts (like increase bug rate, reduced reliability, etc).
I often see engineers decrying the evils of vendor lock-in without taking these costs into account. As a business, you’ll need to find a way to adequately and accurately measure these costs as you make decisions, instead of turning it into a quasi-religious crusade against all forms of lock-in.
With these trade-offs in mind, I’ll finish off this post by explaining some of the most bang-for-the-buck moves you can make, which:
The hardest lock-in to overcome is dedication to a proprietary tool. Without naming names, some large 6-letter database companies have made a great reputation of leveraging lock-in with major increases in licensing fees. Once you’re tied into that model, it’s difficult to disengage.
Open source tools provide a major protection against this. Assuming the licenses are correct—and you should be sure to check that—no one can ever take your open source tools away from you. Sure, a provider may decide to stop maintaining the software. Or perhaps future releases may be closed source instead. Or perhaps they won’t address your bug reports without paying for a support contract. But ultimately, you retain lots of freedom to take the software, modify it as necessary, and deploy it everywhere.
There has long been a debate between the features and maturity of proprietary versus open source tooling. As always, we cannot make our decisions in a vacuum, and the flexibility of open source is not the be-all and end-all for a business. However, in the past decade in particular, open source has come to dominate large parts of the deployment space.
To pick on the example above: while DynamoDB is a powerful and flexible database option on AWS, it’s far from unique. Cassandra, Redis, PostgreSQL, and dozens of other open source databases are readily available, with companies offering support, commercial hosting, and paid consulting services.
We’ve seen a major shift occur as well in the software development language space. Many of the biggest tech companies in the world not only use open source languages, but provide their own complete language ecosystems, free of charge. Google’s Go, Microsoft’s .NET Core, Mozilla’s Rust, and Apple’s Swift are some prime examples.
Far from being the scrappy underdog, we’ve seen a shift where open source is the de facto standard, and proprietary options are viewed as niche. You’re no longer trading quality for flexibility. You can often have your cake and eat it too.
I decided to give one open source player its own subsection in this context. Kubernetes is an orchestration management tool, managing various cloud resources for hosting containerized applications in both Linux and Windows. The first notable thing in this context is that Kubernetes has effectively supplanted other proprietary and cloud-specific offerings. Those offerings still exist, but from a market share standpoint, Kubernetes is clearly in a dominant position.
The second thing to note is that Kubernetes is a tool supported by many of the largest cloud providers. Google created Kubernetes, Microsoft provides significant support, and all three top cloud providers (Google, Azure, and AWS) offer native Kubernetes services.
The final thing to note is that Kubernetes really goes beyond a single service. In many ways, it functions as a cloud abstraction layer. When you use Kubernetes, you often times write your applications to target Kubernetes instead of targeting the underlying vendor. Instead of using a cloud Load Balancer, you’ll use an ingress and service in Kubernetes. This drastically reduces the cost of remaining vendor neutral.
As a plug, in our own Kubernetes offering, we’ve focused on combining commonly used open source components to provide a batteries-included experience with minimized vendor lock-in. We’ve already used it internally and for customers to easily migrate services between different cloud providers, and from the cloud to on-prem.
Some cloud services provide an interesting combination of delivering high value with minimal lock-in costs. The greatest example of that is blob storage services, such as S3. The durability and availability guarantees cloud providers offer around your data is far greater than most teams would be able to provide on their own. The cost of usage is significantly far lower than rolling your own solution using block storage in the cloud. And finally: the lock-in risks tend to be small. There are tools available to abstract the different vendor APIs for blob storage (and we include such a tool in Kube360). And even without such tools, generally the impact on a codebase from blob storage selection is minimal.
Another example is services which host open source offerings. The RDS example above fits in nicely here. We generally recommend using hosted database offerings from cloud providers, since the cost is close to what you would pay to set it up yourself, you get lots of features quickly, and migration to a different option is trivial.
And one final example is services like load balancers and auto-scaling groups. These are services that are impossible to implement fully yourself, would be far more expensive to implement to any extent using cloud virtual machines, and introduce virtually no lock-in. If you’re moving from AWS to Azure, you’ll need to change your infrastructure code to use Azure equivalents to those services. But generally, these can be seen at the same level of commodity as the virtual machines themselves. You’re paying for a fairly standard service, you’re rarely locking yourself in to a vendor-specific feature.
In previous discussions, the topic of vendor neutrality typically introduces the two confusing terms “multicloud” and “hybrid cloud.” There is some disagreement in the tech space around what the former term means, but I’m going to define these two terms as:
Multicloud is a much easier thing to attain than hybrid cloud. Hybrid cloud introduces many new kinds of distributed systems failure models, as well as risks around major data transfer costs and latencies. There are certainly some potential advantages for hybrid cloud setups, but in our experience the much lower hanging fruit is in targeting multicloud.
Summing up, there are many reasons a company may decide to keep their applications vendor neutral. Each of these reasons can be seen as a risk mitigation strategy, and a proper risk assessment and cost analysis should be performed. While current events has people’s attention on vendor eviction, plenty of other reasons exist.
On the other hand, vendor neutrality is not free, and should not be pursued to the detriment of the business. Finding high value, low cost moves to increase your neutrality is your best bet. Such moves may include:
If you would like more information or help with a vendor neutrality risk assessment, we would love to chat.
If you liked this post, you may also like:
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
