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?