2 ms·
The problem with onprem is that you need your customer to be operationally competent, and that is not the core competency of most organizations (and in most cas
by happytiger 3y ago
The problem with onprem is that you need your customer to be operationally competent, and that is not the core competency of most organizations (and in most cases nor should it be).
SaaS is just specialization of a vendor in operational software delivery, freeing end-user organizations from having to maintain and support the competency in house, and properly supporting, securing, auditing, certifying, and updating software is hard and complex at scale — an expertise that is, as you say, a huge pain in the ass.
The main driver at scale (excluding Enterprise, security sensitive and real-time apps that really should be on prem) of the abandonment of this efficiency is excessive profit taking by SaaS vendors and the overall expense being extraordinarily more expensive that the in-house expertise, or the considerable misappreciation by end customers of how hard developing and supporting a competent dc/Noc operation can be by end user customers.
I’ve seen both.
SaaS vendors move to value added pricing and nose bleed out of contention frequently because the most profitable top-market customers are who the category market leaders build their valuations and VC pleasing returns on. So there is this massive pressure to push prices and disqualify less profitable customers, leading to surges in prices for market leading solutions as SaaS companies mature.
And then there is the “don’t stack the coffee machine on the network rack” crowd, which can get pretty sophisticated. I’ve seen some impressive network operations inside of non-descript office buildings even recently. But then everyone is confident until it’s time for SOC 2 certification and realize their IT staff doesn’t even know what they should be getting audited, or they get their first successful hacker infiltration event that gets the attention of the CEO and their emergency PR group realizes they have nobody to fire but their own VP, or somebody finds the unsecured Postgres database with nmap and hits up their journalist friend who writes an article about it… suddenly it’s back to AWS or vendor soup.
And beyond those two there is also an optics problem.
IME in a lot of big companies you sell an on-prem solution and install it only to have a management change 3 years later and their entire board pitch is about outsourcing to the cloud to gain efficiency and moving off “legacy” systems and you realize you screwed up because on-prem doesn’t have the right optics to the ocean of management consultants who see your category as an easy win… unless you’ve got hardcore integration with the mainframe in the basement that runs the bean counter machines that nobody wants to touch because integration is done with an rj-11 jack and serial port adapters from 1993 and only get their support from Susan or Steve who are half retired but keep the mainframe up because they are the last people in the county who have the expertise.
It’s hard to counter these trends with on-prem. Regime changes are killers even when the on-prem solution is justified or even a no brainer — it’s tough to pitch and support on-prem for a lot of use cases and hard to keep broad support.
I remember when supermicro would drop entire rack assemblies off preconfigured with software and burned in ready to go, and they couldn’t keep it going because the cloud and SaaS trend was just a deal killer. Maybe that’s changed, but I don’t see much evidence beyond organizations at scale looking to recapture the millions AWS takes in profits. Maybe companies like backblaze and Dropbox are exceptions but they are among the companies who should run dc ops because it’s core to their business — it’s what they do. That’s not true of most companies.
Just my 2c.