Cloud Vendor Lock-in

I often here the comment made that 'We do not want to use Azure and be locked-in to one vendor'. Let me show you why that is not really an issue if you design your architecture smartly.

Cloud vendor lock-in

Vendor lock-in is a topic you should be concerned about if you make decisions on cloud or data platform vendors. The unspoken truth is that vendor lock-in is a complicated topic riddled with its own enigmas. If vendor lock-in is a concern for you, I have some unique solutions. And you may be surprised about my conclusions.

What is vendor lock-in? Everyday your developers write software that targets a given platform. That platform could be Oracle DMBS, Microsoft .NET, or an open source technology like Python. If your application can’t run without that platform, then you are locked-in to that platform. If the platform is managed by one vendor then you have vendor lock-in. That vendor licenses and supports that software for you.
Even if you run certain kinds of Open Source Software (OSS) you may experience vendor lock-in. It’s disruptive if, for instance, you want to move your Hadoop stack from Cloudera to Hortonworks. This is a much more mild form of vendor lock-in than the outright licensing of a software stack, but it’s still vendor lock-in

Most companies, probably yours too, like to standardize on one, or a few, enterprise vendors. Standardization is viewed as a good thing by decision makers because it simplifies:

your environment. It’s easier to integrate and interoperate among fewer vendors’ stacks.
your staffing. Hiring good DBAs is easier if you deploy to fewer DBMS stacks.
your vendor relationships. There’s fewer of them. That gives customers a slight pricing advantage during price negotiations.

A company should seriously consider becoming a “cloud-first” company. I prefer using the cloud for new projects because it allows me to focus my attention on your business problem solution (the “Development”) and less on the “care-and-feeding” of the IT infrastructure (the “Operations”). I prefer Azure since I am an ex-Microsoft employee, but all public clouds work equally well.

Why Azure?

Most of my customers like Enterprise Agreements (EAs). It’s nice to have one bucket of “IT Cloud Spend” that every department can leverage. Microsoft offers Azure subscriptions and customers can usually get a discount and access to resources to help with cloud migrations (call me and I’ll help you navigate the offerings). If this isn’t appealing to your company, maybe due to concerns about cloud vendor lock-in, there are also Pay-As-You-Go (PAYG) offerings, just like other cloud vendors.

CapEx vs OpEx

Even if your company has already committed to the Microsoft stack (.NET/SQL Server/Windows), it’s difficult to pay the up-front costs (Capital Expense or CapEx) for additional SQL Server core licenses for unproven projects that you may want to start now but may not reach GA. Today, companies, and Wall Street, don’t want to see big capital expenditures for long-term software licensing. The cloud allows you to rent-a-license and only pay for what you use, when (and if) you use it. This turns software licensing into an Operational Expense (OpEx), which is a lot easier for your CFO to swallow.

Under certain circumstances Microsoft will allow you to use your purchased software licenses in Azure, allowing you to be charged only for the compute. This is the Azure Hybrid Use Benefit and it can save you big bucks.

Anecdotally, I find that all customers are over-spending on both hardware AND the licenses they need to make that hardware useful. That’s flushing money down the toilet. In the public cloud we can right-size your environment using judicious monitoring and save you money.

Central IT vs LOB Departments: A study in WANTS and NEEDS

For years there was a push/pull relationship between a company’s IT organization and its lines-of-business. Central IT WANTS a simplified architecture that can be standardized and supported by fewer vendors and staff. The LOBs NEED to “git er done” and deliver software that solves a problem, and that sometimes means standardization suffers.

I see less of the “push/pull” with the public cloud. If Central IT dictated the use of the “Microsoft Stack” in the past, the LOBs have more freedom of choice in public cloud where Linux is a First Class Citizen. It requires much less Ops Guys to spin up a solution in the public cloud than in your data center. Both parties win.

Can my packaged application run in the public cloud?
This is a common question. The short answer is, “if it can run in a VM, it can run in the cloud!” The longer answer is, it really depends on your licensing arrangements. Many vendors discourage running their software in anyone else’s cloud except their own (THAT sounds like vendor lock-in to me). These vendors even invent their own confusing terms like “hard vs soft partitioning” (ahem, Oracle) to dictate where you can and cannot run their software. Then they change their policy later by redefining the meaning of their made-up terms.
As for bespoke (in-house developed applications), again, “if it can run in a VM, it can run in the cloud”. But that doesn’t always mean it will be cost-effective or performant. I provide Cloud Readiness Assessments that will help you understand what it will take to move your app to the cloud…in a supportable, cost-efficient manner.

“Isn’t ‘using Microsoft Azure’ the epitome of vendor lock-in?”

I don’t think so. Certainly there is a history/perception of The Evil Empire, which culminated in anti-trust lawsuits.

But I don’t see this with today’s Microsoft. Here’s a few examples to ponder:

SQL Server 2017 runs on Linux. Microsoft has not open-sourced its eponymous database manager, but the fact that it can now run on something other than Windows is something unforeseen by anyone just a few years ago.
Microsoft has embraced OSS. There is no “Microsoft Linux” offering. That would encourage further vendor lock-in. Microsoft has partnered with Red Hat so that if you run RHEL in Azure and you need support, there is a RHEL engineer sitting with the Azure engineer, on the phone with you. Other cloud providers offer their own branded Linux images, customized to their cloud, which sounds to me like a form of unacceptable vendor lock-in.
- Can you run those images in your data center?
- Do they have the support of a major Linux vendor?
- What’s in those images exactly?
There is no “Microsoft Hadoop”. In Azure you can run Cloudera, Hortonworks HDP, MapR, or roll-your-own. If you want a PaaS offering optimized for Azure then I recommend HDInsight, which is an optimized-for-Azure version of Hortonworks’ HDP. If you outgrow HDInsight then Hortonworks HDP is a binary, drop-in replacement (ie, no vendor lock-in).
I’m writing this article on a MacBook Air using Microsoft Word while I have a Xamarin app compiling in Visual Studio Code on my Chromebook. That doesn’t sound like vendor lock-in to me. That sounds like a partner with a healthy ecosystem.

Let’s face facts – Using any cloud vendor incurs some vendor lock-in

If you use Azure SQL Data Warehouse you risk some vendor lock-in because this offering doesn’t exist in Microsoft’s on-prem software portfolio, nor in any other cloud. But you run the same risks if you use AWS Redshift as an alternative. As I’ve said before, if you develop to a “target stack” you have some amount of lock-in. Even if you use OSS, there is still lock-in, just in a different form.

Cloud Services Come in 3 flavors

When you think about the cloud, you need to think about services.

Service Name	What it is	Example	Pros	Cons
IaaS	Infrastructure-as-a-Service. You run your application in a VM	SQL Server running in a clustered VM environment	Avoids cloud vendor lock-in	You are responsible for all Ops.
PaaS	Platform-as-a-Service. The cloud vendor manages the platform for you	Azure SQL Database	Less Ops work. Vendor handles upgrades, HADR, perfromance	Sometimes PaaS has fewer features
SaaS	Software-as-a-Service. You rent the entire software stack from the vendor	Salesforce	One-stop shopping for all of your needs. You assume the solution is turnkey.	Least flexible. The epitome of vendor lock-in.
CaaS	Containers-as-a-Service. You run your containerized applications wherever you want	Docker running your entire application	Out of all options, has the least cloud vendor lock-in	You still manage vendor relationships for the applications run in the containers

I prefer the Containers-as-a-Service model for new development work. With IaaS there is a lot of overhead just running the VM. That’s wasted money. There is less overhead when you run containers. Each cloud vendor has a more-or-less standard way of running and managing containers. This gives you the most flexibility in deployment options. However, there are often hidden costs if you use “managed container” offerings from your cloud vendor.

“We’ve been burned by vendor lock-in. How do we avoid it as much as we can in the cloud?”

Customers ask us this every day. They want peak value without being locked-in to any single cloud vendor…or Public Cloud in general. The question really is, “what is the minimum I need from my cloud vendor to be successful”. Said differently, what exactly is the cloud

Offering	Purpose
Software-Defined Networking	SDN is the ability to configure VNets, subnets, IP address management, peering, load balancing, firewalling, security, and VPNs. Even 5 years ago this meant expensive hardware and Operations Staff to configure everything. Today, your cloud vendor should provide this to you in a portal experience or scripting. And the charge is nominal. No more expensive routers and switches!!!
Software-Defined Storage	You want your storage managed in one centralized place. You don’t want disk over-allocated to VMs like you did with your SAN. The storage needs to be optimized for the use case too. Cloud storage comes in 2 flavors
Block Store (Amazon EBS and Azure Blob Storage using Page Blobs)	This type of storage presents itself to the consumer as a standard storage system like iSCSI. The focus is on performance and scalability. Data is stored in fixed-sized blocks just like you would on a normal HDD.
Object Stores (Amazon S3 and Azure Block Blobs)	With object stores you address files directly, similar to a fileshare, using similar commands and hierarchical folder structures. A REST API is available. Cloud vendors supply storage that is optimized for different workloads and IOPS, latency, and bandwidth needs. Your cloud vendor should make all of this auditable and simple.
Compute: IaaS and containerization	All cloud vendors support running VMs which enables “lift-and-shift” workloads from your data center. Containerization using Docker and Kubernetes or Mesos is a plus.

That’s the bare minimum you need from your cloud vendor. Any other services, such as the ability to run “server-less architectures” (AWS Lambda and Azure Functions) is a definite plus. These services are inexpensive to run, are fast to develop and deploy, and can be rewritten quickly to use another vendor’s offerings if needed later. But we are starting to slowly journey down the path to vendor lock-in again.

“We use ‘free’ OSS, we have no vendor lock-in”

Be careful. “Free” has two different meanings. Free as in beer means the software is gratis in terms of licensing costs. But that also means you are at the mercy of the OSS community to give you any support you may need. Or you need to pay a vendor for support and services. Software under this model is usually distributed under the Apache, BSD, MIT, or similar licensing schemes. Software licensed this way tends to be free as in speech too. This means that you can do almost anything you want with the software, including modifying it to fit your needs and redistributing it, with a minimum of restrictions. I’ve written about the pitfalls of certain OSS “licenses”. Pro Tip: if you are using GPL software…understand the pitfalls and click that link.

Even with OSS software there is still lock-in, just not necessarily traditional vendor lock-in. I can help you navigate these landmines. Caveat Emptor.

“Cloud vendor lock-in isn’t a priority for us, but if it was, we definitely would NOT use Azure. “

Unfortunately I hear this a lot, and it frankly scares me. Occasionally I even hear “anything but Azure”. This is very short-sighted. As mentioned already, there are a lot of reasons why running in Azure provides the least vendor lock-in exposure for your company.

Think carefully about your industry. Does your cloud vendor compete with you in your industry today? Might they become your direct competitor in a year? Do you really want your cloud provider to be your biggest competitor? I’ve done SO MANY engagements where AWS was the cloud vendor. But for various reasons each was FORCED to move some of their infra to a different public cloud provider. This is the primary reason why any company with a public cloud presence needs to be cogent of vendor lock-in and should have a hybrid cloud strategy in place.

Picking a cloud vendor is much more than just going with the cheapest offering. Over time, as a cloud vendor’s market position improves, and that vendor needs to show better quarterlies to Wall Street, the natural tendency is to invoke “monopoly pricing power”.

What is your contingency if your cloud bill suddenly goes up 20%? Are you able to quickly lift-and-shift your cloud portfolio back to on-prem or to another public cloud provider?

For all of these reasons I prefer solutions that are cloud-agnostic. This avoids vendor lock-in and allows you to pivot quickly if your business environment suddenly needs you to move to another provider. I work with all of the major cloud vendors (Azure, AWS, GCE) but I make sure that my customers are aware of the technology choices they are making. We want to make sure our solutions are as portable as YOU need.

Give me a call and I can help you with your Cloud Journey. ›

Thanks for reading. If you found this interesting please subscribe to my blog.

Dave Wentzel 2018-03-23 CONTENT
azure cloud