Hacker News Reader

I think perhaps not all vendor lock-in is created equal. I too shudder at the thought of walking into another Oracle like trap, but it's also an error in cognition to make the assumption that all vendors will lock you in to the same degree and in the same way.

I guess the part of us that is cautioning ourselves and others are aware of the pitfalls, but others also have valid points around going all in.

There is a matrix of different scenarios let's say.

  You can go all in on a vendor and get Oracled.
  You can go all in on an abstraction that lets you be vendor agnostic and lose some velocity while gaining flexibility.
  You can go for a vendor and perhaps it turns out that no terrible outcome results because of that. 
  You can go all in on vendor agnostic and have that be the death of the company.
  You can go all in on vendor agnostic and have that be the reason the company was able to dodge death.

Nobody can read the future and even "best practices" have a possibility of resulting in the worst outcomes. The only thing for it is to do your homework, decide what risks are acceptable to you, make your decision, take responsibility for it.

Vendors have 2 core requirements to continue operating: get new customers and keep the existing ones. Getting new customers requires constant innovation, marketing spend, providing value, etc. Keeping existing customers only requires making the pain of leaving greater than the pain of staying.

Sure. And from even from that you still can't infer what outcome will materialize. If you made the technically correct decision and your business went under because of it, that is still gonna hurt no matter which way you look at it. Hence the advice is do your homework, figure out which risks are acceptable to you, make your choice and take the responsibility. There is no magic bullet to picking the right option. Only picking the option you can live with because that's what you're going to have to do regardless of the outcome.

You might know all the theory on aviation and be a really experienced pilot and one day a sudden wind shear might still fuck you.

> all cloud providers have an exorbitant premium when it comes to running Windows on their VMs

Speaking from first hand running-a-cloud-platform experience, it's because running Windows on a cloud platform is not easy, and comes with licensing costs that have to be paid to Microsoft for each running instance (plus a bunch of infrastructure to support it). It's not even a per-instance-per-time-interval cost, there's all sorts of stuff wrapped up in it and impact the effective cost. It requires a bunch of administrative work and specific coding to try to optimise the costs to the cloud provider.

In addition, where Linux will happily transfer between different hardware configurations, you'll often have to have separate Windows images for each hardware configuration, so that means even more overhead on staffing both producing and supporting. So e.g. SR-IOV images, PV images, bare metal images (for each flavour of bare metal hardware), etc. While a bunch of this work can be fully automated, it's still not a trivial task, and producing that first image for a new hardware configuration can take a whole bunch of work, even where you'd think it would be trivial.

> Oracle succeed by being only slightly cheaper than migrating your entire codebase

Amdocs, ESRI, Microsoft too... Their commercial strategy is a finely tuned parasitic equilibrium.

Sales training that emphasizes knowing one's customer is all about that: if the salesperson understand the exit costs better than the customer, he is going to be milked well & truly !

I'm thinking that the sales side may benefit from hiring people with experience in the customer's business to game the technical options in actual study... I guess they do it already - I'm not experienced on the sales side.

I know whole bunch of people who complain about Oracle lock but fine with moving everything to DynamoDB/Lambda

>keep your transition costs low

For me this is key.