Ask anybody about Oracle features, they'll tell you for days about how their feature velocity and set is great. But then ask them how much their company has been absolutely rinsed over time and how the costs increase annually.
Oracle succeed by being only slightly cheaper than migrating your entire codebase. To offset this practice, keep your transition costs low.
--
Personal note: I'm currently experiencing this with microsoft; all cloud providers have an exorbitant premium when it comes to running Windows on their VMs, but obviously Azure is priced very well (in an attempt to entice you to their platform). Our software has been built over a long period of time by people who have been forced to run Windows at work -- so they built it on Windows.
Now we have a 30% operational overhead charged from microsoft through our cloud provider. But hey.. at least our cloud provider honours fsync().
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.
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.
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.
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.
For me this is key.
Yeah I know I am showing my age....
Vendor lock-in was just as much of a problem then as now.
More than that. They picked open source vendors that didn't (a) vanish in a puff of smoke, (b) get bought out by a company that slowly killed the open source version, or (c) who produced products that they were capable of supporting without the vendor (or capable of faking support for).
In general I agree with you. In practice, the more practical approach may be to focus on making more money & not fussing too much w/ vendor costs & whatever strategy you choose to use. It's easy to pay a big vendor bill when there's a bigger pile of cash from sales.
Don't expect a vendor to always stay competitively priced, especially once they realize a) their old model is failing, and b) everybody on their old model is quite stuck.