6 ms·

"Third: Package it nicely. Ideally, your customer should be able to download a zip with an executable and some config files from a well designed enterprise page

"Third: Package it nicely. Ideally, your customer should be able to download a zip with an executable and some config files from a well designed enterprise page - or get a URL to a Docker Repo. When your on-premise version starts for the first time, it should set itself up as autonomously as possible: Check if it has the required access and permissions, connect to the database to set up tables, have sensible log output etc." LOL that paragraph hides all of it. On prem means that someone is administering your application that does not understand it. Which means YOU are administering it but via slacking with your customers infra engineers rather than through your own control plane. The article is right that there are customers who require this and if you want them you'll have to figure this out, but it is a huge pain in the ass and should be avoided if at all possible.

chatmasta 3y ago
Over 40% of the Web is deployed this way. Wordpress installation is basically "upload some files, complete installation GUI, and then get started." There's no reason other products couldn't do this as well, even those with a complicated stack that requires provisioning cloud resources (or equivalently, SSH'ing into servers on the local network or calling private cloud API endpoints). If you can deploy a commit from a pipeline, then you can make a self-hosted bootstrappable installer for your users. The installer could be a tiny shim running on the user's laptop that's responsible for bootstrapping the rest of the infrastructure and then deleting itself after redirecting the user to the cluster admin panel. The trick is to make it smooth, so even non-technical users can provision and eventually administer a secure, self-updating cluster as easily as they can keep their iPhone up to date. Walk them through the process of getting AWS credentials. Heck, scrape and script the login flows if that makes it smoother (it's their computer running the code so who cares?). Ask the user the minimal questions needed to fill the config. Once all that's in place, trigger your deployment scripts on the cluster, to pull images from a container registry or whatever. Wait for it to be up and running. When the cluster's up, redirect them to its admin panel that's more sophisticated and controlled by you. Let them check for updates, install plugins, run common operations (like "restart," etc). Then just don't ship broken code, make sure your scaling policies work (or at least that they work well enough to avoid phone calls from customers that don't make you any money). And boom you've got a nice product. I'm not saying it's easy. But if you already have automated deployments (you do have automated deployments, right?), then it's not that many extra steps. Productizing it is hard but can be done.
wolframhempel 3y ago
I really disagree. On-Premise software is frequently bought by large customers with significant resources - including a competent ops team. Yes, there may be some initial handholding, but once things are up and running, there is little support necessary. Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same.
- bitschubser_ 3y ago
  This highly depends on the industry… I worked on projects for large F500 companies who had neither ops nor where willing to spend resources… as I mentioned in another thread, on prem can be a world of pain… but it can also be a lot of fun if you have customers like you mentioned
- koolba 3y ago
  > Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same. Nope. You should look at how an app that uses all of those is published. That’s what on-premise software truly is. A combination of dependencies and your companies secret sauce. Your own app code is just one cog in that engine.
- toomuchtodo 3y ago
  > On-Premise software is frequently bought by large customers with significant resources - including a competent ops team. These are orthogonal. Resourcing is no guarantee of ops competency, or a culture where ops is enabled to deliver, hence the concept of shadow IT. On-prem software is bought by orgs with low risk appetite or other compliance objectives that skew procurement towards running on prem. I have seen exceptional ops teams on a shoestring ramen budget, and I have seen dumpster fire ops teams in companies with thousands of workers and billions of dollars a year in revenue who could not get you a single virtual machine in less than 90 days even if preventing the end of the world depended on it.
michaelt 3y ago
Let's not exaggerate here, the software industry managed to deliver software for on-premise use for several decades.
- freeone3000 3y ago
  They used things like standardized packaging mechanisms, matrix testing across supported profiles, dedicated staging environments, and sensible logging schemes. These are expensive and time-consuming! Product velocity is greatly increased when less time is spent on such engineering cruft.
  - sgarland 3y ago
    > Product velocity is greatly increased when less time is spent on such engineering cruft. This attitude is why I get paged. Perhaps we shouldn’t be encouraging lightning-fast growth above all else.
    - ocdtrekkie 3y ago
      This attitude is why the IT field is never going away. Businesses need adults and professionals ensuring reliable infrastructure, not "product velocity".
  - amichal 3y ago
    AND a several orders of magnitude larger investment in tech writers, and manual "How can my customer break this software" testing. When I worked in shrink-wrapped software back in dark ages the documentation writing team and a very extensive manual QA department where each the same size as the development department. Think people trying for DAYS to find out why out of 100s of thousands of active users, a few dozen reported being able to launch 2 instances of the main window when that should not be allowed. (Fix: Race condition in the "double click" handling code with a window of a few milliseconds)
  - coldbrewed 3y ago
    > standardized packaging mechanisms, matrix testing across supported profiles While this is somewhat true, it's not unreasonable to keep the matrix very small to start with and gradually expand it. People think that matrix testing is some insurmountable task when it mainly comes down to some reasonable, thoughtful engineering. If for some reason you've got some part of the matrix that's particularly expensive (looking at you AIX) then charge a heavy premium for that platform. > dedicated staging environments Even if you're a SaaS company you should have dedicated staging environments. Without this you're using your customers as QA, and that's just rude. > sensible logging schemes Please have sensible logging schemes. Your on-call/ops folks deserve to be happy too. Having lived on both sides of the on-prem / SaaS flow, the things that make an on-prem offering successful also make the SaaS offering easier to develop, maintain, and troubleshoot. On-prem can be more expensive but it also means bigger deals, more predictable income, and higher margins. Not every company can fully adopt the mechanisms to generate an on-prem offering but the purported costs of an on-prem offering frequently come down to "ship higher quality software" rather than "shipping somewhat sketchy code at a breakneck pace."
j45 3y ago
On prem can mean self manageable to a small or large degree. You can also sell a managed on-prem setup where you set it up and maintain it in the client environment. It’s not a huge pain in the ass as long as the software is reasonably designed to be multi-tenancy as well as multi server. For serverless architectures creating an internal service provider to route to your serverless (or theirs). A lot of non prem can be made easier by ring azure friendly which in turn has some ways to get on prem easier.
steveBK123 3y ago
The industry used to be able to ship shrink wrapped software that a non-technical person could install on their home computer, without 24/7 instant messenger support to get working. I think B2B software should be able to create manageable installations for technically competent IT professionals.. If your install has that long of a manual task list, your cloud SaaS infra is probably junk too.
- tobyjsullivan 3y ago
  You’re thinking of a time when only “computer geeks” could install and run the software of their choice. When every office had fleets of IT admins to install the pre-approved applications people needed for their day-to-day. Back then, learning how to manage your own PC and install software was tantamount to earning an IT certificate. Doing so for a few years in high school would be enough to qualify you for a career in IT. So I politely disagree. The industry was never able to ship software that a non-technical person could install. Especially not B2B, but barely B2C as well.
  - Terretta 3y ago
    > You’re thinking of a time when only “computer geeks” could install and run the software of their choice. Perhaps not thinking of a "time when", perhaps thinking of an OS that required an IT certificate. Because even early Macintosh System Software (classic Mac OS before OS X) was bewildering to Windows users, since any user could "drag" a program from a floppy disk onto their hard disk, leave it anywhere, and it worked. Arguably, OS X introduced the Applications folder in 2001 partly to give people a place to drag things to and feel more comfortable that's where they could find their "Program Files" (but mostly so multi-user system users would get to add and re-use apps in a common clear place they "should" be). But you still didn't need an IT admin.
  - MichaelZuo 3y ago
    Windows 7 Enterprise? Mac OS X Server? The vast vast majority of SaaS products talked about on HN are probably not even 1/10th as complex.
coldbrewed 3y ago
> On prem means that someone is administering your application that does not understand it. Which means YOU are administering it but via slacking with your customers infra engineers rather than through your own control plane. I got a first-hand view into how this model falls apart - and it wasn't the fault of the customer's infra engineers; it was entirely our fault and we walked away from piles of money because we couldn't deal with the issue. Here's my rather salty take on the issue. The killer issue with SaaS software that attempts to migrate to on-prem offerings is that SaaS companies tend to build up cultures that are locked into the "move fast and break things" model. Simply creating an on-prem offering from a SaaS product does not generate the cultural shift needed to successfully ship on-prem software. If it's extremely easy to ship then the development cycle can be fast and sloppy. You can ship buggy software, bypass meaningful testing, lean on your ops team/on call rotation to limp the software along, skip documentation and use humans to glue the thing together. SaaS is popular because of the accelerated iteration cycle because shipping a bug is much less difficult. Things fall apart extremely fast when moving from a SaaS offering to an on-prem offering because _all of the developers are still conditioned for the fast iteration cycle_. Developers are still going to be targeting SaaS first because they can interact with it, debug it, and evaluate telemetry from that running system. They won't be developing in the model where they're truly freezing features, polishing implementations, and shaking bugs out of the system. This ultimately means that regular releases are more of snapshots of main rather than something that can be shipped to a customer and run unattended. In addition, having an ops team or on-call rotation for a SaaS offering means that troubleshooting/operational guides can be largely informal or loosely written runbooks. For an on-call/ops person, if given the option between scratching together a loose note or using Slack for documentation, or taking the time to write well polished documentation that can be consumed by outsiders, operational velocity is going to drive people to follow the easier, less labor intensive. The end result of this is that on-prem offerings are not going to have a lot of critical operational documentation. I was on the team responsible for building, shipping, and supporting an on-prem version of our software; it was one of the most grindingly miserable work experiences I've had to date. In addition to dealing with the on-prem version my team was also on the on-call rotation and I can say from first hand experience that the SaaS model was only held together with a great deal of firefighting; shipping an on-prem version exposed every single weakness we had on the SaaS version in painful detail. The project ultimately failed; millions of dollars of deals were left on the table and my entire team was laid off because the company was not capable of shipping a reliable, documented project that could be operated without constant babysitting. The product itself had a great number of incredible features and if people slowed down and focused on improved quality rather than sheer velocity then we'd be drowning in enterprise contracts. > Which means YOU are administering it but via slacking with your customers infra engineers rather than through your own control plane. If your product requires that you're remotely administering your software because your customers can't operate it successfully, then please invest in documentation, validation and testing, and troubleshooting. Your customers will need it as much as your on-call rotation.
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.
jochem9 3y ago
Sounds like a great business model if you're able to pull off the reduction in support load the article also mentions.

chatmasta 3y ago

Over 40% of the Web is deployed this way. Wordpress installation is basically "upload some files, complete installation GUI, and then get started." There's no reason other products couldn't do this as well, even those with a complicated stack that requires provisioning cloud resources (or equivalently, SSH'ing into servers on the local network or calling private cloud API endpoints). If you can deploy a commit from a pipeline, then you can make a self-hosted bootstrappable installer for your users. The installer could be a tiny shim running on the user's laptop that's responsible for bootstrapping the rest of the infrastructure and then deleting itself after redirecting the user to the cluster admin panel. The trick is to make it smooth, so even non-technical users can provision and eventually administer a secure, self-updating cluster as easily as they can keep their iPhone up to date. Walk them through the process of getting AWS credentials. Heck, scrape and script the login flows if that makes it smoother (it's their computer running the code so who cares?). Ask the user the minimal questions needed to fill the config. Once all that's in place, trigger your deployment scripts on the cluster, to pull images from a container registry or whatever. Wait for it to be up and running. When the cluster's up, redirect them to its admin panel that's more sophisticated and controlled by you. Let them check for updates, install plugins, run common operations (like "restart," etc). Then just don't ship broken code, make sure your scaling policies work (or at least that they work well enough to avoid phone calls from customers that don't make you any money). And boom you've got a nice product. I'm not saying it's easy. But if you already have automated deployments (you do have automated deployments, right?), then it's not that many extra steps. Productizing it is hard but can be done.

wolframhempel 3y ago

I really disagree. On-Premise software is frequently bought by large customers with significant resources - including a competent ops team. Yes, there may be some initial handholding, but once things are up and running, there is little support necessary. Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same.

bitschubser_ 3y ago
This highly depends on the industry… I worked on projects for large F500 companies who had neither ops nor where willing to spend resources… as I mentioned in another thread, on prem can be a world of pain… but it can also be a lot of fun if you have customers like you mentioned
koolba 3y ago
> Basically, if you want to build an on-premise offering, look at the way Nginx, Postgres, Redis and similar projects are packaged and do the same. Nope. You should look at how an app that uses all of those is published. That’s what on-premise software truly is. A combination of dependencies and your companies secret sauce. Your own app code is just one cog in that engine.
toomuchtodo 3y ago
> On-Premise software is frequently bought by large customers with significant resources - including a competent ops team. These are orthogonal. Resourcing is no guarantee of ops competency, or a culture where ops is enabled to deliver, hence the concept of shadow IT. On-prem software is bought by orgs with low risk appetite or other compliance objectives that skew procurement towards running on prem. I have seen exceptional ops teams on a shoestring ramen budget, and I have seen dumpster fire ops teams in companies with thousands of workers and billions of dollars a year in revenue who could not get you a single virtual machine in less than 90 days even if preventing the end of the world depended on it.

michaelt 3y ago

Let's not exaggerate here, the software industry managed to deliver software for on-premise use for several decades.

freeone3000 3y ago
They used things like standardized packaging mechanisms, matrix testing across supported profiles, dedicated staging environments, and sensible logging schemes. These are expensive and time-consuming! Product velocity is greatly increased when less time is spent on such engineering cruft.
- sgarland 3y ago
  > Product velocity is greatly increased when less time is spent on such engineering cruft. This attitude is why I get paged. Perhaps we shouldn’t be encouraging lightning-fast growth above all else.
  - ocdtrekkie 3y ago
    This attitude is why the IT field is never going away. Businesses need adults and professionals ensuring reliable infrastructure, not "product velocity".
- amichal 3y ago
  AND a several orders of magnitude larger investment in tech writers, and manual "How can my customer break this software" testing. When I worked in shrink-wrapped software back in dark ages the documentation writing team and a very extensive manual QA department where each the same size as the development department. Think people trying for DAYS to find out why out of 100s of thousands of active users, a few dozen reported being able to launch 2 instances of the main window when that should not be allowed. (Fix: Race condition in the "double click" handling code with a window of a few milliseconds)
- coldbrewed 3y ago
  > standardized packaging mechanisms, matrix testing across supported profiles While this is somewhat true, it's not unreasonable to keep the matrix very small to start with and gradually expand it. People think that matrix testing is some insurmountable task when it mainly comes down to some reasonable, thoughtful engineering. If for some reason you've got some part of the matrix that's particularly expensive (looking at you AIX) then charge a heavy premium for that platform. > dedicated staging environments Even if you're a SaaS company you should have dedicated staging environments. Without this you're using your customers as QA, and that's just rude. > sensible logging schemes Please have sensible logging schemes. Your on-call/ops folks deserve to be happy too. Having lived on both sides of the on-prem / SaaS flow, the things that make an on-prem offering successful also make the SaaS offering easier to develop, maintain, and troubleshoot. On-prem can be more expensive but it also means bigger deals, more predictable income, and higher margins. Not every company can fully adopt the mechanisms to generate an on-prem offering but the purported costs of an on-prem offering frequently come down to "ship higher quality software" rather than "shipping somewhat sketchy code at a breakneck pace."

j45 3y ago

On prem can mean self manageable to a small or large degree. You can also sell a managed on-prem setup where you set it up and maintain it in the client environment. It’s not a huge pain in the ass as long as the software is reasonably designed to be multi-tenancy as well as multi server. For serverless architectures creating an internal service provider to route to your serverless (or theirs). A lot of non prem can be made easier by ring azure friendly which in turn has some ways to get on prem easier.

steveBK123 3y ago

The industry used to be able to ship shrink wrapped software that a non-technical person could install on their home computer, without 24/7 instant messenger support to get working. I think B2B software should be able to create manageable installations for technically competent IT professionals.. If your install has that long of a manual task list, your cloud SaaS infra is probably junk too.

tobyjsullivan 3y ago
You’re thinking of a time when only “computer geeks” could install and run the software of their choice. When every office had fleets of IT admins to install the pre-approved applications people needed for their day-to-day. Back then, learning how to manage your own PC and install software was tantamount to earning an IT certificate. Doing so for a few years in high school would be enough to qualify you for a career in IT. So I politely disagree. The industry was never able to ship software that a non-technical person could install. Especially not B2B, but barely B2C as well.
- Terretta 3y ago
  > You’re thinking of a time when only “computer geeks” could install and run the software of their choice. Perhaps not thinking of a "time when", perhaps thinking of an OS that required an IT certificate. Because even early Macintosh System Software (classic Mac OS before OS X) was bewildering to Windows users, since any user could "drag" a program from a floppy disk onto their hard disk, leave it anywhere, and it worked. Arguably, OS X introduced the Applications folder in 2001 partly to give people a place to drag things to and feel more comfortable that's where they could find their "Program Files" (but mostly so multi-user system users would get to add and re-use apps in a common clear place they "should" be). But you still didn't need an IT admin.
- MichaelZuo 3y ago
  Windows 7 Enterprise? Mac OS X Server? The vast vast majority of SaaS products talked about on HN are probably not even 1/10th as complex.

coldbrewed 3y ago

> On prem means that someone is administering your application that does not understand it. Which means YOU are administering it but via slacking with your customers infra engineers rather than through your own control plane. I got a first-hand view into how this model falls apart - and it wasn't the fault of the customer's infra engineers; it was entirely our fault and we walked away from piles of money because we couldn't deal with the issue. Here's my rather salty take on the issue. The killer issue with SaaS software that attempts to migrate to on-prem offerings is that SaaS companies tend to build up cultures that are locked into the "move fast and break things" model. Simply creating an on-prem offering from a SaaS product does not generate the cultural shift needed to successfully ship on-prem software. If it's extremely easy to ship then the development cycle can be fast and sloppy. You can ship buggy software, bypass meaningful testing, lean on your ops team/on call rotation to limp the software along, skip documentation and use humans to glue the thing together. SaaS is popular because of the accelerated iteration cycle because shipping a bug is much less difficult. Things fall apart extremely fast when moving from a SaaS offering to an on-prem offering because _all of the developers are still conditioned for the fast iteration cycle_. Developers are still going to be targeting SaaS first because they can interact with it, debug it, and evaluate telemetry from that running system. They won't be developing in the model where they're truly freezing features, polishing implementations, and shaking bugs out of the system. This ultimately means that regular releases are more of snapshots of main rather than something that can be shipped to a customer and run unattended. In addition, having an ops team or on-call rotation for a SaaS offering means that troubleshooting/operational guides can be largely informal or loosely written runbooks. For an on-call/ops person, if given the option between scratching together a loose note or using Slack for documentation, or taking the time to write well polished documentation that can be consumed by outsiders, operational velocity is going to drive people to follow the easier, less labor intensive. The end result of this is that on-prem offerings are not going to have a lot of critical operational documentation. I was on the team responsible for building, shipping, and supporting an on-prem version of our software; it was one of the most grindingly miserable work experiences I've had to date. In addition to dealing with the on-prem version my team was also on the on-call rotation and I can say from first hand experience that the SaaS model was only held together with a great deal of firefighting; shipping an on-prem version exposed every single weakness we had on the SaaS version in painful detail. The project ultimately failed; millions of dollars of deals were left on the table and my entire team was laid off because the company was not capable of shipping a reliable, documented project that could be operated without constant babysitting. The product itself had a great number of incredible features and if people slowed down and focused on improved quality rather than sheer velocity then we'd be drowning in enterprise contracts. > Which means YOU are administering it but via slacking with your customers infra engineers rather than through your own control plane. If your product requires that you're remotely administering your software because your customers can't operate it successfully, then please invest in documentation, validation and testing, and troubleshooting. Your customers will need it as much as your on-call rotation.

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.

jochem9 3y ago

Sounds like a great business model if you're able to pull off the reduction in support load the article also mentions.