2

Consider a greenfield development situation where cloud tools are being considered vs. in-house solutions, in the vein of AWS SQS vs. self-hosted Kafka, ECS vs. Mesos-Marathon, Lambda/Azure Functions vs. Whisk vs an array of custom APIs/services.

All else being equal (financial cost, technical expertise, etc.), how can the cost of vendor lock-in be fairly gauged when deciding whether or not to use cloud services beyond basic VM and storage products? I have seen in several cases, where fears of vendor lock-in closed the argument on using higher-level cloud services without even allowing for a technical or financial evaluation of their value to the project.

Of course there is a cost to using vendor-specific services, but that cost can't possibly be so large as to eclipse all other software development costs. Avoiding higher-level cloud services seems, IMO, to be an argument akin to "let's build a completely abstract ORM in case we need to swap out database products."... aka YAGNI.

Self-sufficiency is often the road to poverty, and all software is dependent on many other layers to be successful: Docker, Linux, npm, gcc, and dozens and dozens of others, but these are rarely looked at as "lock ins". The costs of doing anything internally, can be significant, including:

  • Lost time to market
  • Resources devoted to maintaining internal and non-revenue generating services
  • Higher operational costs

So, what is the right way to fairly evaluate cloud services, acknowledging the cost of vendor lock-in as one component in product strategy, without allowing it to dominate other concerns?

|improve this question
2

It depends on the importance of the software using the services. In this sense it is not any different from any other type of technology "lock-in" (not necessarily vendor specific). If the software is extremely important to the owners, financially or otherwise, risk mitigation would include isolation layers, especially for the "higher level" services that may not be available in all situations.

YAGNI rightly recommends against writing extra code that may never be used. On the other hand, if you see the cloud service vendor choice as a source of risk, it should be addressed, like any other risk. Ideally your automated tests then work with more than one vendor, and are regularly tested that way.

|improve this answer
  • Yes. I almost always look at it as a risk and cost and market question rather than a feature question, so YAGNI rarely becomes part of it. Evaluating whether or how much to depend on a particular database or on the windows or linux platform is a similar choice. – joshp Feb 15 '17 at 23:59
  • My concern is that upper management waved away any serious consideration of Lambda, SQS, Google ML, and others in a very broad stroke under the "vendor lock-in" argument prior to the project's inception. Running our own messaging/queues has little business value compared to the "real" code that will run on top of it. I would prefer that code to be making money as soon as possible, which I believe can be best done on the cloud (at least at first), so the question was trying to get at how to seriously consider the cost of vendor lock-in, not just having it dismissed a priori. – Dan1701 Feb 16 '17 at 5:29
  • @Dan1701 maybe the real problem is not a concern for vendor lock-in, but the not-invented-here syndrome. – Frank Hileman Feb 17 '17 at 17:11
  • That's possible, but I view vendor lock-in as a legitimate concern, albeit overemphasized (IMO), so was trying to figure out how to correctly factor it into project planning. If we're at the point of fighting not-invented-here, then it's already a losing battle, I think. – Dan1701 Feb 17 '17 at 18:42
  • 1
    @Dan1701 perhaps present "vendor lock-in" as a risk, and "invented here" as a cost and a risk (reinventing the wheel badly). – Frank Hileman Feb 17 '17 at 23:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.