12 ms·

So You Wanna Go On-Prem

256 points by friendzis 10y ago

seibelj 10y ago
yes Yes YES! One thousand times yes! I previously worked at a SaaS mobile device management company (apperian) that took the on-prem plunge to score big enterprise / government contracts. The ops / support team quadrupled and there were so many headaches. This article nailed it.
- x0x0 10y ago
  Oh god yes. Just wait until you're attempting to support a distributed ML system through some fucking idiot sysadmin (well, "sysadmin") who god only knows how he still has a job, but HE CANNOT RELIABLY USE SSH. Because of their security requirements (ie no internets for you, including package servers), getting updated packages onto their 4 year old redhat installs were a nightmare. And they wanted to run very high cpu requirement distributed solvers inside 4gb single processor vms. The fun was just endless.
apitts 10y ago
For those who haven't come across it before and have already dockerized there is a nice solution for some of these issues from replicated (http://www.replicated.com http://www.replicated.com).
- gkoberger 10y ago
  We use Replicated, and it was insanely easy to set up. We had an on-prem version ready to go in a few days. Definitely recommended!
  - grantlmiller 10y ago
    We do what we can to ease the pain of going on-prem for modern SaaS companies :)
paloaltokid 10y ago
Having done On-Prem in a past life, this article nails it on the head. It's a difficult problem to solve and the support costs are very real. You need a team (or teams) dedicated to OP if you're going to do it right. It can be lucrative and a huge differentiator for your product, but it is far from easy.
- abraae 10y ago
  Great article, rings very true. I'd say if you're in the early adopter phase and you desperately need big enterprise traction then do the deal with the devil and go on-premise. Otherwise run a mile. Worth noting is that sometimes a sales technique is to agree to on-premise (since your competitors probably won't) and then look for opportunities to remove it from the deal further down the line - the customer may even come to the conclusion themselves that its not a good idea.
pnathan 10y ago
One thing I would call out: don't do CI to these people. Eat the pain and cut honest-to-goodness versions. Ideally, cut them on the quarter, so that your customers can comfortably expect a New Version to be available at a specific time. I used to be on the other side of this desk, so.... trust me. It makes it easier when we can all refer to a specific version. You can throw us specific patches or whatever. From the developer standpoint, you're not delivering a continuously delivered system, you're delivering a "server app" of a specific version.
- wmf 10y ago
  From experience, on-prem customers won't accept continuous updates anyway. They have multi-month change freezes.
  - voltagex_ 10y ago
    Sometimes more - if your product is used in an internal app that has a 6+ month release cycle, they'll be updated in sync (if they're updated at all)
- gregmac 10y ago
  > don't do CI to these people. Eat the pain and cut honest-to-goodness versions. You say this as if these are opposing things. If you're not doing CI, you're not delivering software properly. On-prem or SaaS is irrelevant. Making release 'versions' is slightly different than continuous deployment (maybe that's what you meant?). There are many ways to do it, I'm a fan of having a 'release/1.2.3' branch (and having the CI system/build scripts automatically pick that version number up and embed it in the source and all output files), but some people use tags to do the same thing. QA team can take the release builds for testing, and dev can merge in bug fixes (either specifically from a gitflow bugfix branch or by integrating in the master branch, depending on your workflow and what other work has happened since the branch was created). Once you have a final GA build, you pin/save it, and give it your customers. Your CI system should absolutely be building the final package you give to your customers (whether it's a zip/tarball, .dpkg/.rpm or setup.exe). If someone has to do something to "get it ready" for customers after the CI build is done, you're not using CI properly.
avitzurel 10y ago
Every time someone tells you "You can buy a server for 2000$ why pay Amazon 4500$?" show him/her this article. I've done on prem in the past, it's a real pain and I still remember it as a horrible experience. That being said, I think it's pretty easy to combine. One of the things we had in the earlier days is hosting the CI and other build/compile servers @ the office and all the rest was in the cloud. Even if you have some customer requiring something hosted on prem you can still host ALL OTHER clients on the cloud and this client on prem etc... Good post.
- sciurus 10y ago
  Most of the points in this post. apply to hosting installs for your customer in "the cloud" too.
twakefield 10y ago
This is a great post. We've been talking to a lot of people about going "on-prem". This post is right on in that the deployment is the relatively easy part. The ongoing operations is where you will get killed. Luckily, for those that are thinking about doing this, for the end customers "on-prem" many times means single-tenant, private cloud (usually AWS) which makes things slightly easier (as the op mentions). The vendors that do it right make their multi-tenant cloud app and "on-prem" environments as similar as possible. So that means containerizing and using an orchestration layer like Kubernetes or Mesos everywhere (multi-tenant and single-tenant). Then you need to make sure you have a secure and scalable way to access all environments for upgrades, patches, support. We open sourced an SSH framework specifically for this purpose[1]. Bottom line: no special snowflakes. Edit: for more info feel free to reach out: http://gravitational.com/vendors.html http://gravitational.com/vendors.html [1]: http://gravitational.com/teleport/ http://gravitational.com/teleport/
- rdtsc 10y ago
  > for the end customers "on-prem" means single-tenant, private cloud (usually AWS) Nope. On prem means in their own private data center. Also possibly airgapped from the outside.
  - twakefield 10y ago
    Yes, that is true. I meant it more that a new class of "on-prem" is being created.
  - azernik 10y ago
    Depends on the customer. Often, the motivations that push them to demand on-prem can be fulfilled just as well by a less-demanding single-tenant SaaS solution; you just have to convince the customer's IT department that such a thing exists. Sure, there are some (mostly in defense, finance, and a few other security-sensitive fields) where physical on-prem is non-negotiable, but in my experience customer demands for on-prem are far more likely to be driven by outdated and/or overly-conservative IT practices than by real need.
pbnjay 10y ago
This is my life right now. Fighting customers for on-site installs. This hits too close to home...
old-gregg 10y ago
Ahh... my favorite subject! Can't resist :) SaaS companies are leaving a lot of money on the table by insisting to "making the world a better place" from their US-East AWS region ;-) The world, especially the enterprisey world of lucrative contracts, is much larger than that. Gravitational [1] specializes in taking complex multi-server SaaS stacks into private cloud environments and providing ongoing management for them. [1] http://gravitational.com http://gravitational.com Full disclaimer: I work there.
- hdmoore 10y ago
  In a similar vein, BitNami makes money licensing full-stack open source components with an integrated installer. I used it/them for a few years and while I wasn't smitten, it got the job done until something better came along. If you want a one-click installer for your mvc + db app, it might be worth looking at.
rdtsc 10y ago
> If they suck so much, why do them? > Money. Yap. > when you move to any sort of on-prem model, your operational and support problems are multiplied. No kidding. Multiplied by orders of magnitude. Difference between looking up a query in Splunk vs directing someone possibly less technical to ssh in try to read logs to you via phone and figure out the problem from that. Or even worse, having to urgently put people on the plane to fly them onsite to solve the problem. And often when they return they can't bring any logs with them.
agibsonccc 10y ago
Doing on prem is hard but worth it. The sales cycles look different than SAAS but I don't see it going anywhere for a long time. The key to this is a field team and a good support infrastructure. Operationalizing it is half of it which is (echoing another poster here) the key to making it economical. Our on prem stuff targets hadoop/spark clusters though so typically there's already ops folks in place who understand how our stuff works. This obviously won't be true for all scenarios though..
johnbellone 10y ago
As an operations person who has dealt with deployment of different "on-prem" software in the enterprise please keep in mind that smaller organizations have different needs then the larger enterprise. For a smaller organization a VMware disk image (commonly referred as an appliance) works quite well. But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use our own managed infrastructure (e.g. MySQL, Redis, RabbitMQ). If you're targeting the larger enterprise you can expect to have a somewhat more technical IT person to deal with, and if its a technical organization people who are keen on scaling the application/infrastructure independently.
- 0xEFF 10y ago
  > But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use our own managed infrastructure (e.g. MySQL, Redis, RabbitMQ). Puppet professional services consultant here. I work with lots of "enterprise" teams on "ops stuff" on-premise. Between 2010 and 2016, I observed a change in teams interested in trying to scale individual components. Back in 2010/2011 teams did expect to scale out and manage individual components of the stack. Today, nearly every team I work with is like, "Oh you ship your own postgresql server in the product? Awesome, I'd much rather use that (and make it your problem)." Same is true for pretty much every component in the stack. I don't know exactly why this is the case, but I have two suspicions. First, every Ops team I work with is has too much on their plate. Way too much. They're having trouble finding people to hire. They're happy to offload a potential maintenance issue, particularly if they're paying for the software. Second, this might be a reflection of crossing the chasm to the mainstream market sometime between 2011 and now, so the teams themselves might be inherently different. What surprises me is that it doesn't really matter what industry the customer is in today. Government, technology, retail, insurance, finance, whatever... No team is interested in taking these maintenance issues on unless they _have_ to. Making a product they don't need to tune and scale component-by-component is a highly valued feature. Both for SaaS and On-prem products. I think this "feature" is the common root of all the things cited as issues in the article. Making this stuff easy to operate is _hard_, hard enough for SaaS and _much harder_ when on-premise.
ryanackley 10y ago
This topic is mildly amusing because I remember when all (or most) software was sold as "on-prem". Then everything moved to SaaS...and now everything is moving back to on-prem! I used to work for Atlassian which made most of its money at the time I left in 2013 from on-prem software. It was low-touch, high-volume sales to people downloading and installing software on their own servers. They still sell a ton of it too. If your stack is a hodge podge of web servers, shell scripts, and cron services, I think better advice would be based on how to make your application more packageable before moving to that model.
- NegativeLatency 10y ago
  Or you could copy tableau and shove it all into a vm
  - brazzledazzle 10y ago
    That's how Github Enterprise is distributed for on-prem. Virtual appliance.
    - cstejerean 10y ago
      Which made GitHub enterprise a nightmare to operate compared to Atlassian's products.
      - majewsky 10y ago
        Can you elaborate? (Dev here with not very much ops experience.)
- koolba 10y ago
  > I used to work for Atlassian which made most of its money at the time I left in 2013 from on-prem software. It was low-touch, high-volume sales to people downloading and installing software on their own servers. They still sell a ton of it too. IIRC most of their apps are Java based so the JVM ends up being their VM to normalize the installations. That would definitely simplify things and you see it even today with on-prem apps running in containers to normalize things (ex: that's apparently how NPM runs). > If your stack is a hodge podge of web servers, shell scripts, and cron services, I think better advice would be based on how to make your application more packageable before moving to that model. Live by the cloud, die by the cloud!
telecuda 10y ago
Synology DiskStations are an affordable option (<$1000) for on-prem data storage accessible to your web application. They run a standard LAMP stack out of the box (basic database and file storage) and have redundant/RAID storage. A few tips from experience: if you can get them to put it on a dedicated IP, even better; use Synology firewall to limit access to your servers IPs, or VPN (do not leave on public net, because ransomware); set to auto-update the OS (because the customer never will!); still have another backup (even a USB-attached 1TB solid state drive, but ideally another physical location); disable all unused services (to limit potential exploits); if customer allows, give them a user and you a user - enable logging and now you can demonstrate if/when you had to access their box for maintenance (feel good factor)
- koolba 10y ago
  > Synology DiskStations are an affordable option (<$1000) for on-prem data storage accessible to your web application. They run a standard LAMP stack out of the box (basic database and file storage) and have redundant/RAID storage. You're joking right? What enterprise would install a consumer NAS in their data center to use for "data storage accessible to your web application"? [1]: http://www.amazon.com/Synology-DiskStation-Diskless-Attached-DS1513/dp/B00CM9K7E6 http://www.amazon.com/Synology-DiskStation-Diskless-Attached...
  - telecuda 10y ago
    Can you explain? Sure, they're marketed to consumers because their audience is largely there, but if configured securely (to only talk to your infrastructure etc) offer a very affordable option to store data behind a customer's walls. "In their data center" implies you're thinking large enterprises. Small businesses/industries may have requirements to keep data on-prem but without enterprise budgets. (Your link returns 404 for me)
    - koolba 10y ago
      > Can you explain? Sure, they're marketed to consumers because their audience is largely there, but if configured securely (to only talk to your infrastructure etc) offer a very affordable option to store data behind a customer's walls. Couple of separate points. First off forget "affordable". The customer that's paying for an on site version of something has a very different definition of "affordable" than whatever you're considering. Something that costs $500 literally rounds to zero. Second, nobody, and I mean NOBODY, is going to let you plug your own box onto their network to watch some other box that you've deployed on their network. In fact, you're not going to have your app on your own box there either. The vast majority of customers will want to deploy your software on whatever version of RHEL they have a licenses for (or CentOS if they're "modern"). At best you'll deploy your app in a VM that (hopefulyy) plays nice with whatever VM kit they're using. Third, that consumer NAS won't fit in a rack. Is it just going to be plugged in to a wall socket with a cross over cable connecting to your "app box"? > (Your link returns 404 for me) Sorry about that. I chopped off the rest of the gunk at the end of the URL and ended up taking too much off.
capkutay 10y ago
I wonder if there's an inverse 'So you wanna go SaaS' for on-prem only companies...
- cgarrigue 10y ago
  Going to SaaS can be quite an issue depending on the reliability of the company developing the software. One of the company I'm dealing with as a reseller had the bad habit of delivering releases with semi-critical issues and even regression bugs, consequently with my colleagues we decided to act as a buffer, doing a pass of QA ourselves, and depending on the results making the versions available or not to our customers. Sometimes it took one year before getting an good enough release. Quite annoying to do this ourselves, but at least our customers are satisfied with the quality. Now a year ago the partner decided to deliver a SaaS version, which made completely sense commercially. Then the SaaS became public a month ago and we keep encountering critical issues, like features not working, translation files older than the last on-prem release, or even impossibility to log in because somebody installed a patch and never checked anything after (and never told us about it either). But this time we cannot buffer anything, so they are basically shooting themselves in the foot.
brudgers 10y ago
Jeff Meyerson's recent interview with Julien Lemoin discusses the reasons Algolia has not created an on premises version. [spoiler: it is contrary to the strategic focus on performance, the same reason Algolia runs on metal it owns.] http://softwareengineeringdaily.com/2016/04/17/search-service-julien-lemoine-2/ http://softwareengineeringdaily.com/2016/04/17/search-servic...
apaprocki 10y ago
As a consumer of a number of on-prem installs, I'd just like to add something positive in what will probably be a lot of negativity regarding selling your product on-prem. The on-prem situation is evolving just as the SaaS/cloud world is evolving as well. Selling an on-prem product can be very lucrative if done correctly, and that can mean intentionally not selling to customers who don't have their act together. As more sophisticated customers install "private clouds" with OpenStack and the like, you can potentially have a SaaS on-prem use the OpenStack API natively and have a much better sales/maintenance story rather than boxing up a static VM and trying to get it or the customer to scale horizontally using static VM images and lots of configuration tweaking. I do agree that monitoring/logging can be problematic, but sometimes there can be somewhat standard OSS offerings that can be plugged in if the customer already has a managed monitoring platform running keeping tabs on lots of other things. The more adaptable (literally adaptable -- adapters to various solutions) your software is due to good design, the easier it will be for you -- or even the customer -- to adapt it into their stack.
- tajen 10y ago
  We went the other way, and it was far easier. Actually, our product is an Atlassian add-on, and Atlassian itself went from OnPremise to Cloud. It was, however, a long migration for both Atlassian and the add-on vendors. It was necessary because the market wants to try products withut installing them. Now Atlassian is able to make cloud-level changes to their software: They can use CD, live analytics, mutualized authentication for all tenants, etc. However, their API for cloud addons is, and will be forever, completely different from the API for onpremise addons. It's a major difficulty for the ecosystem. Many vendors extract a .jar that they reuse in both onpremise and cloud addons, but the cloud runtime that connects this .jar to the cloud API is at least as big as the jar itself (because we don't benefit from the host's services such as user management, storage or logging). OnPromise, which we started with, was however easier for us than Cloud. The customers, even enterprise ones (we have about 28 of them) are in charge of Ops, it cuts off half the work for us. And OnPromise is 3x more revenue for us per year, with the downside that it's a one-off, non-recurrent sale by default.
meowface 10y ago
As an employee at an enterprise that often asks SaaS companies for on-prem solutions... this is very on point. That said, we do pay a lot.
davidmr 10y ago
This is a subject near and dear to my heart, albeit from the "enterprise" side of the table, not the scrappy startup side. I've spent a non-trivial amount of effort trying to convince software companies to spin an on-premise version of their software. Sometimes with success, and sometimes not. I understand that it's quite attractive to rely on AWS or GCE abstractions to the point where it would be nearly impossible to break it apart for installation on my boxes, but it seems like it's leaving quite a lot of money on the table. There are perfectly valid reasons to require on-premise applications: in-house interpretation of regulatory requirements, protection of intellectual property, etc. Of course, I have a right to ask and they have a right to say no, but I wish more companies would consider making an on-premise solution. (Slack, I'm looking in your direction. Please come take the money I'm currently giving to Atlassian.)
- tomjen3 10y ago
  Given how much code is on github, I no longer think protection of intellectual property is a valid excuse. It may be a requirement from your boss.
  - mseebach 10y ago
    That's not really how thinking about security works. "But everybody else is doing it" wasn't a valid argument in school, still isn't. As a thought experiment, (ignoring the fact that it's not an appropriate store for such things, and only thinking about security towards third parties) how would you feel about a company storing your PII/medical records/credit card number in a private repo on GitHub? That's how your boss thinks about the company's intellectual property.
    - tomjen3 10y ago
      Why would I feel any different if they stored it on Amazon cloud, github or on their own systems?
  - davidmr 10y ago
    I'm sorry, but I have absolutely no idea what you're trying to say. Would you mind providing an alternate phrasing for your comment?
hdmoore 10y ago
I honestly thought this was satire for the first half of the article. When did working on SaaS products exempt people from understanding how to deliver software? Should we just remove the first [S] from SaaS? I see this attitude a ton in conversations with startups. A founder describes their whiz-bang thing, a question comes up about how this works in larger environments, usually followed by a mumbled reply about virtual appliances. Virtual appliances (and to some extent, docker containers) are not the solution, for so many reason, I might run out of space in the comment field listing them. The short version: OS updates, security updates, networking issues, customer-side diagnostics, size, and support for the customer's specific virtualization platform. Docker is great if your customers all use docker and you have the update process sorted out, but that is probably a small fraction of your total market. In other words, build actual installable software that runs on some set of supported operating systems. Make a DEB, an RPM, maybe an MSI. Build an installer. Have a nifty splash screen. Add desktop links. Don't lose revenue because you can't be bothered to figure out omnibus, nullsoft, or bitrock. If you are building software, keep in mind that customer environments are insane and should be treated as hostile. Every bit of your software and packaging needs to be paranoid, defensive, and respond well to failures. When something goes wrong, customers are not your QA team (you have one, right?). Don't make them run a thousand commands for you. Build actual diagnostic features into the product. Some organizations (hint: they have lots of money), don't let your icky code talk to the internet. Offline activation, offline updates, and offline diagnostics are super important to counting these folks as customers.
- blazespin 10y ago
  The problem with maintaining the install is that it really slows down your deployment of feature and evolving the ecosystem. It's not just a matter of extra know how. SaaS is more than just ease of use, it's a very very rapid and competive delivery of new features day in day out. Companies are adopting SaaS not just because they don't want to maintain the infrastructure / install software. They're adopting SaaS because they want the latest and greatest so they can compete better against their colleagues that don't have the latest and greatest.
  - dingaling 10y ago
vchamakkala 10y ago
Just use replicated. http://replicated.com http://replicated.com. Easiest way to on-premify your SaaS app.
deleted 10y ago
[deleted]
borski 10y ago
CoreOS actually makes this significantly better with their Cloud Config capabilities. With CoreOS and Docker, we've successfully deployed this at a number of companies. With that said, there has been plenty of support to be handled, and we need to get better at doing multi-node deploys, but we're learning. :)
- icebraining 10y ago
  Well, you're quite lucky to be allowed to use CoreOS. In our case, only a minority of customers didn't want to dictate the distro to be used. In one extreme case, we had to install on SLES 10 (in 2014), without root or sudo, and then hand over the machines, since we weren't allowed direct access to the production system. And maintenance involved sitting with one of their sysadmins and telling him what to do :)
walkingolof 10y ago
Going on-prem also means building a different system, it has to be more streamlined, self contained and serviceable. The quality of this is tested once the customer wants to upgrade his system from version X to version Y.
_delirium 10y ago
Depends on your customers, but a decent amount of the stuff complained about here is stuff you may need to do in your SaaS anyway even if it's not deployed on-prem. The article mentions that in the SaaS version you update daily and don't maintain 6-month-old versions, but that's often not really realistic. If customers depend on stable functionality and versions, the fact that you control the hosted install doesn't mean you can just break things whenever you want. Yes, you can more easily do careful, planned updates since you control the whole environment. And you can run off of one integrated code-base. But you often need to conceptually support "6-month-old versions" in the sense of having announced and planned upgrade and migration paths, supporting parallel versions of APIs, etc. Many of the problems are at least similar, though not identical. Now if you can use a Facebook-style "move fast and break things" approach with no care for versioning or legacy support, you can bypass all of those. But if you were in a market where you had potential on-premises customers in the first place, how often is that true?
ww520 10y ago
On-premise install can be marred with problems. I have a case where the customer's IT refused to grant access to their network. The PM on the business side had to start Webex, shared his desktop, and allowed outside access to do the install via his desktop. Talk about punching a huge hole through their firewall.
- TickleSteve 10y ago
  ...and he would probably have been disciplined for it or at least had a stern talking to from IT. This is a very common situation and in fact is the major reason behind them wanting on-premise solutions. You don't want your SaaS talking to the big wide world. If you're thinking you should be able to do on-premise installations remotely... its already gone over your head!
jasonkester 10y ago
Strange that the author mentions two ways of doing this (managed here vs. managed there), and spends the rest of the article saying how those are not in any way fun, but never mentions the obvious third option: As Is. I sell a self-hosted source-included license of Twiddla, as a single breakout of the current codebase, with the understanding that no further updates will be provided once we're all satisfied that you're up and running correctly. You can do whatever you like with the code, and I'm happy to sell you additional consulting time to help with what you're doing. But you're essentially on your own. It pretty much dispenses with every concern in the article.
- majewsky 10y ago
  How do you deal with updates? Do you just sell them a newer version, like with MS Office major upgrades in the past?
  - jasonkester 10y ago
    No updates. Hence the "As Is." They're buying the version of the website as it exists at the point of time when they buy it. The assumption being that it works for them now, it should continue working for them in the future, regardless of what direction the .com goes.
    - reitanqild 10y ago
      What about vulnerabilities then? Or is it supposed that the customer use it behind a firewall / VPN solution?
      - jasonkester 10y ago
        In this case, we're talking about software built on the Microsoft stack, so most of that is Windows Update's job (patching servers manually isn't really something that needs to happen in this world). As to vulnerabilities in the handful of 3rd party libraries that we use? In the 10 years that Twiddla has been around, we've had exactly zero cases where we had to patch something from our end for security reasons. I guess there's something to be said about avoiding the tall skinny (and wobbly) tower of 3rd party dependencies that seems to be the norm these days in web app development.
pesenti 10y ago
Has any anybody here considered leveraging the on prem offerings of cloud providers, e.g., Azure on prem (http://www.geekwire.com/2015/microsoft-brings-azure-on-premises-with-new-services/ http://www.geekwire.com/2015/microsoft-brings-azure-on-premi...) or Bluemix local (http://www.ibm.com/cloud-computing/bluemix/local/ http://www.ibm.com/cloud-computing/bluemix/local/)?
fideloper 10y ago
After years working at a company that has a 10 year old on-prem and had a saas app as well, here is my POV on this: On premise vs saas is a trade off in the type of customer support. With on-prem, you do have support complicated by customers have unique infrastructure, and varying degrees of knowledge and post within their organization. Some people are adept, some are not. Some support keeps you screen sharing for hours, some do not. In general for on-prem, support is done via your customer support app, professionally, as you're usually dealing with an IT department. On the other hand, SaaS customer support volune/time is a measure of how often you break stuff for ALL (some, of you're lucky) of you're customers at the same time). Often an issue is experienced by many rather than a single person. "Always" (ish) it's your fault instead of being an issue of a customers configuration or infrastructure. Often Twitter becomes the public stomping ground for complaints, as you get end-users going to Twitter rather than an issue bumped up from an end user took their IT before reaching you. In considering of you want to support on-prem, a key point is to keep your software simple. For example, optionally (and easily) logging to files instead of <third party here> to reduce requirements on external systems (elastic search). Making the app as simple and easy to run as possible is pretty important. Definitely very strongly consider if you need to rely on that saas app for your App to run.
- lloeki 10y ago
  > In considering of you want to support on-prem, a key point is to keep your software simple. For example, optionally (and easily) logging to files instead of <third party here> to reduce requirements on external systems (elastic search). We have extensive experience doing this over here, and this is key. Keep things even simpler than you think they could ever be, because "simple" times gazillions produces terrific economies of scale. During interviews I'm often asked if I have experience on a product "at scale", by which interviewers often suppose it can only mean some typically tiered load balancers/front-end code/backend code/data persistence and you spin up new dynos/AWS of what is really (taken as a whole) a single cohesive application to face demand, and ultimately get dismissive when I tell them I'm not working on a 1Mreq/min product... but there's a whole other orthogonal dimension to "scale" which most products have firmly locked to 1, and believe me, everything suddenly follows a square law when your code and architecture can have an impact on each dimension, especially the one that involves humans that don't have the level of intimacy with neither your product, team, or methods.
jamiesonbecker 10y ago
We[1] drive the bulk of our revenue with on-prem. Many companies prefer to keep their SSH key management in house, and we actually count on that. However, we've invested a LOT of time into making our distributable a simple daemon. It's very easy to manage and install. We offer two on-prem versions: one is Pro which provides the basics (starts at around $3,500), and one is Enterprise which costs a lot more and supports external Redis, multiple app servers, web servers, LDAP integration, etc. Sales between the two are split approximately 30/70 in terms of revenue. In other words, we make a lot more on the Enterprise versions, but we sell less of them and the support costs are definitely higher. Just my 2c - but for us, on-prem has been a huge win and has taken us to profitability. In truth, however, we've probably focused too much on on-prem and not given enough focus to SaaS/cloud. For a startup that's just starting to hit profitability, we've actually been very happy with focusing on on-premise over SaaS, in contrast to the article, but our product was (re)designed with both scenarios in mind from the very beginning. We actually re-wrote the entire product before offering an on-prem version. In other words, just as described in the article: making technology changes like SQL to something else 'on the fly' might be hard but not impossible with SaaS... but with on-premises, it's almost impossible to work through hundreds of on-prem installations of some previously chosen tech, and the need for data migration, installs of new supporting packages, etc. I used to work as a tech consultant for a big company and one of our huge clients decided to upgrade all of their on-site journaling systems (running a PII-300!) from Windows to Linux. Remotely. Through an ISDN. Yes, this is possible if you have multiple drives available in the box with careful syslinux. Yes, it's also pretty insane. (We had about 95% success across around 10,000 stores worldwide.) Changing horses in the middle of the race is something to avoid where possible. It's easy to see that you're probably going to be stuck with your early technology choices if you go on-premise, unless you really build fantastic, auto-data-migration tooling that never fails, so make wise decisions and stick with SaaS until you're certain that you are sticking with your tech choices. (We don't differentiate between "on-prem" in your datacenter versus your VPC or (your) cloud. To us, you're installing/managing/running it and we're not, so, to us, that's on-prem. Other providers probably define this differently.) 1. https://userify.com https://userify.com (sudo and SSH public key management.)
k__ 10y ago
Things I learned after 10 years of dealing with enterprise customers. 1. They want on premise. 2. They want key account people to talk to. You don't need multi tenancy. You often get your own server to run on AND a local ops guy. It's a bit like an exclusive cloud. Yes, the deployments are a bit harder, since you often can't simply drop in a new version over the internet. This is why you need more ops to handle this all. But if I wanted to sell to enterprises I wouldn't got into the cloud in the first few years after starting the company. If the system works fine, it's a no-brainer to deploy it in the cloud and you already have all the ops people to maintain this...

256 points by friendzis 10y ago

yes Yes YES! One thousand times yes! I previously worked at a SaaS mobile device management company (apperian) that took the on-prem plunge to score big enterprise / government contracts. The ops / support team quadrupled and there were so many headaches. This article nailed it.

x0x0 10y ago
Oh god yes. Just wait until you're attempting to support a distributed ML system through some fucking idiot sysadmin (well, "sysadmin") who god only knows how he still has a job, but HE CANNOT RELIABLY USE SSH. Because of their security requirements (ie no internets for you, including package servers), getting updated packages onto their 4 year old redhat installs were a nightmare. And they wanted to run very high cpu requirement distributed solvers inside 4gb single processor vms. The fun was just endless.

apitts 10y ago

For those who haven't come across it before and have already dockerized there is a nice solution for some of these issues from replicated (http://www.replicated.com http://www.replicated.com).

gkoberger 10y ago
We use Replicated, and it was insanely easy to set up. We had an on-prem version ready to go in a few days. Definitely recommended!
- grantlmiller 10y ago
  We do what we can to ease the pain of going on-prem for modern SaaS companies :)

paloaltokid 10y ago

Having done On-Prem in a past life, this article nails it on the head. It's a difficult problem to solve and the support costs are very real. You need a team (or teams) dedicated to OP if you're going to do it right. It can be lucrative and a huge differentiator for your product, but it is far from easy.

abraae 10y ago
Great article, rings very true. I'd say if you're in the early adopter phase and you desperately need big enterprise traction then do the deal with the devil and go on-premise. Otherwise run a mile. Worth noting is that sometimes a sales technique is to agree to on-premise (since your competitors probably won't) and then look for opportunities to remove it from the deal further down the line - the customer may even come to the conclusion themselves that its not a good idea.

pnathan 10y ago

One thing I would call out: don't do CI to these people. Eat the pain and cut honest-to-goodness versions. Ideally, cut them on the quarter, so that your customers can comfortably expect a New Version to be available at a specific time. I used to be on the other side of this desk, so.... trust me. It makes it easier when we can all refer to a specific version. You can throw us specific patches or whatever. From the developer standpoint, you're not delivering a continuously delivered system, you're delivering a "server app" of a specific version.

wmf 10y ago
From experience, on-prem customers won't accept continuous updates anyway. They have multi-month change freezes.
- voltagex_ 10y ago
  Sometimes more - if your product is used in an internal app that has a 6+ month release cycle, they'll be updated in sync (if they're updated at all)
gregmac 10y ago
> don't do CI to these people. Eat the pain and cut honest-to-goodness versions. You say this as if these are opposing things. If you're not doing CI, you're not delivering software properly. On-prem or SaaS is irrelevant. Making release 'versions' is slightly different than continuous deployment (maybe that's what you meant?). There are many ways to do it, I'm a fan of having a 'release/1.2.3' branch (and having the CI system/build scripts automatically pick that version number up and embed it in the source and all output files), but some people use tags to do the same thing. QA team can take the release builds for testing, and dev can merge in bug fixes (either specifically from a gitflow bugfix branch or by integrating in the master branch, depending on your workflow and what other work has happened since the branch was created). Once you have a final GA build, you pin/save it, and give it your customers. Your CI system should absolutely be building the final package you give to your customers (whether it's a zip/tarball, .dpkg/.rpm or setup.exe). If someone has to do something to "get it ready" for customers after the CI build is done, you're not using CI properly.

avitzurel 10y ago

Every time someone tells you "You can buy a server for 2000$ why pay Amazon 4500$?" show him/her this article. I've done on prem in the past, it's a real pain and I still remember it as a horrible experience. That being said, I think it's pretty easy to combine. One of the things we had in the earlier days is hosting the CI and other build/compile servers @ the office and all the rest was in the cloud. Even if you have some customer requiring something hosted on prem you can still host ALL OTHER clients on the cloud and this client on prem etc... Good post.

sciurus 10y ago
Most of the points in this post. apply to hosting installs for your customer in "the cloud" too.

twakefield 10y ago

This is a great post. We've been talking to a lot of people about going "on-prem". This post is right on in that the deployment is the relatively easy part. The ongoing operations is where you will get killed. Luckily, for those that are thinking about doing this, for the end customers "on-prem" many times means single-tenant, private cloud (usually AWS) which makes things slightly easier (as the op mentions). The vendors that do it right make their multi-tenant cloud app and "on-prem" environments as similar as possible. So that means containerizing and using an orchestration layer like Kubernetes or Mesos everywhere (multi-tenant and single-tenant). Then you need to make sure you have a secure and scalable way to access all environments for upgrades, patches, support. We open sourced an SSH framework specifically for this purpose[1]. Bottom line: no special snowflakes. Edit: for more info feel free to reach out: http://gravitational.com/vendors.html http://gravitational.com/vendors.html [1]: http://gravitational.com/teleport/ http://gravitational.com/teleport/

rdtsc 10y ago
> for the end customers "on-prem" means single-tenant, private cloud (usually AWS) Nope. On prem means in their own private data center. Also possibly airgapped from the outside.
- twakefield 10y ago
  Yes, that is true. I meant it more that a new class of "on-prem" is being created.
- azernik 10y ago
  Depends on the customer. Often, the motivations that push them to demand on-prem can be fulfilled just as well by a less-demanding single-tenant SaaS solution; you just have to convince the customer's IT department that such a thing exists. Sure, there are some (mostly in defense, finance, and a few other security-sensitive fields) where physical on-prem is non-negotiable, but in my experience customer demands for on-prem are far more likely to be driven by outdated and/or overly-conservative IT practices than by real need.

pbnjay 10y ago

This is my life right now. Fighting customers for on-site installs. This hits too close to home...

old-gregg 10y ago

Ahh... my favorite subject! Can't resist :) SaaS companies are leaving a lot of money on the table by insisting to "making the world a better place" from their US-East AWS region ;-) The world, especially the enterprisey world of lucrative contracts, is much larger than that. Gravitational [1] specializes in taking complex multi-server SaaS stacks into private cloud environments and providing ongoing management for them. [1] http://gravitational.com http://gravitational.com Full disclaimer: I work there.

hdmoore 10y ago
In a similar vein, BitNami makes money licensing full-stack open source components with an integrated installer. I used it/them for a few years and while I wasn't smitten, it got the job done until something better came along. If you want a one-click installer for your mvc + db app, it might be worth looking at.

rdtsc 10y ago

> If they suck so much, why do them? > Money. Yap. > when you move to any sort of on-prem model, your operational and support problems are multiplied. No kidding. Multiplied by orders of magnitude. Difference between looking up a query in Splunk vs directing someone possibly less technical to ssh in try to read logs to you via phone and figure out the problem from that. Or even worse, having to urgently put people on the plane to fly them onsite to solve the problem. And often when they return they can't bring any logs with them.

agibsonccc 10y ago

Doing on prem is hard but worth it. The sales cycles look different than SAAS but I don't see it going anywhere for a long time. The key to this is a field team and a good support infrastructure. Operationalizing it is half of it which is (echoing another poster here) the key to making it economical. Our on prem stuff targets hadoop/spark clusters though so typically there's already ops folks in place who understand how our stuff works. This obviously won't be true for all scenarios though..

johnbellone 10y ago

As an operations person who has dealt with deployment of different "on-prem" software in the enterprise please keep in mind that smaller organizations have different needs then the larger enterprise. For a smaller organization a VMware disk image (commonly referred as an appliance) works quite well. But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use our own managed infrastructure (e.g. MySQL, Redis, RabbitMQ). If you're targeting the larger enterprise you can expect to have a somewhat more technical IT person to deal with, and if its a technical organization people who are keen on scaling the application/infrastructure independently.

0xEFF 10y ago
> But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use our own managed infrastructure (e.g. MySQL, Redis, RabbitMQ). Puppet professional services consultant here. I work with lots of "enterprise" teams on "ops stuff" on-premise. Between 2010 and 2016, I observed a change in teams interested in trying to scale individual components. Back in 2010/2011 teams did expect to scale out and manage individual components of the stack. Today, nearly every team I work with is like, "Oh you ship your own postgresql server in the product? Awesome, I'd much rather use that (and make it your problem)." Same is true for pretty much every component in the stack. I don't know exactly why this is the case, but I have two suspicions. First, every Ops team I work with is has too much on their plate. Way too much. They're having trouble finding people to hire. They're happy to offload a potential maintenance issue, particularly if they're paying for the software. Second, this might be a reflection of crossing the chasm to the mainstream market sometime between 2011 and now, so the teams themselves might be inherently different. What surprises me is that it doesn't really matter what industry the customer is in today. Government, technology, retail, insurance, finance, whatever... No team is interested in taking these maintenance issues on unless they _have_ to. Making a product they don't need to tune and scale component-by-component is a highly valued feature. Both for SaaS and On-prem products. I think this "feature" is the common root of all the things cited as issues in the article. Making this stuff easy to operate is _hard_, hard enough for SaaS and _much harder_ when on-premise.

ryanackley 10y ago

This topic is mildly amusing because I remember when all (or most) software was sold as "on-prem". Then everything moved to SaaS...and now everything is moving back to on-prem! I used to work for Atlassian which made most of its money at the time I left in 2013 from on-prem software. It was low-touch, high-volume sales to people downloading and installing software on their own servers. They still sell a ton of it too. If your stack is a hodge podge of web servers, shell scripts, and cron services, I think better advice would be based on how to make your application more packageable before moving to that model.

NegativeLatency 10y ago
Or you could copy tableau and shove it all into a vm
- brazzledazzle 10y ago
  That's how Github Enterprise is distributed for on-prem. Virtual appliance.
  - cstejerean 10y ago
    Which made GitHub enterprise a nightmare to operate compared to Atlassian's products.
    - majewsky 10y ago
      Can you elaborate? (Dev here with not very much ops experience.)
koolba 10y ago
> I used to work for Atlassian which made most of its money at the time I left in 2013 from on-prem software. It was low-touch, high-volume sales to people downloading and installing software on their own servers. They still sell a ton of it too. IIRC most of their apps are Java based so the JVM ends up being their VM to normalize the installations. That would definitely simplify things and you see it even today with on-prem apps running in containers to normalize things (ex: that's apparently how NPM runs). > If your stack is a hodge podge of web servers, shell scripts, and cron services, I think better advice would be based on how to make your application more packageable before moving to that model. Live by the cloud, die by the cloud!

telecuda 10y ago

Synology DiskStations are an affordable option (<$1000) for on-prem data storage accessible to your web application. They run a standard LAMP stack out of the box (basic database and file storage) and have redundant/RAID storage. A few tips from experience: if you can get them to put it on a dedicated IP, even better; use Synology firewall to limit access to your servers IPs, or VPN (do not leave on public net, because ransomware); set to auto-update the OS (because the customer never will!); still have another backup (even a USB-attached 1TB solid state drive, but ideally another physical location); disable all unused services (to limit potential exploits); if customer allows, give them a user and you a user - enable logging and now you can demonstrate if/when you had to access their box for maintenance (feel good factor)

koolba 10y ago
> Synology DiskStations are an affordable option (<$1000) for on-prem data storage accessible to your web application. They run a standard LAMP stack out of the box (basic database and file storage) and have redundant/RAID storage. You're joking right? What enterprise would install a consumer NAS in their data center to use for "data storage accessible to your web application"? [1]: http://www.amazon.com/Synology-DiskStation-Diskless-Attached-DS1513/dp/B00CM9K7E6 http://www.amazon.com/Synology-DiskStation-Diskless-Attached...
- telecuda 10y ago
  Can you explain? Sure, they're marketed to consumers because their audience is largely there, but if configured securely (to only talk to your infrastructure etc) offer a very affordable option to store data behind a customer's walls. "In their data center" implies you're thinking large enterprises. Small businesses/industries may have requirements to keep data on-prem but without enterprise budgets. (Your link returns 404 for me)
  - koolba 10y ago
    > Can you explain? Sure, they're marketed to consumers because their audience is largely there, but if configured securely (to only talk to your infrastructure etc) offer a very affordable option to store data behind a customer's walls. Couple of separate points. First off forget "affordable". The customer that's paying for an on site version of something has a very different definition of "affordable" than whatever you're considering. Something that costs $500 literally rounds to zero. Second, nobody, and I mean NOBODY, is going to let you plug your own box onto their network to watch some other box that you've deployed on their network. In fact, you're not going to have your app on your own box there either. The vast majority of customers will want to deploy your software on whatever version of RHEL they have a licenses for (or CentOS if they're "modern"). At best you'll deploy your app in a VM that (hopefulyy) plays nice with whatever VM kit they're using. Third, that consumer NAS won't fit in a rack. Is it just going to be plugged in to a wall socket with a cross over cable connecting to your "app box"? > (Your link returns 404 for me) Sorry about that. I chopped off the rest of the gunk at the end of the URL and ended up taking too much off.

capkutay 10y ago

I wonder if there's an inverse 'So you wanna go SaaS' for on-prem only companies...

cgarrigue 10y ago
Going to SaaS can be quite an issue depending on the reliability of the company developing the software. One of the company I'm dealing with as a reseller had the bad habit of delivering releases with semi-critical issues and even regression bugs, consequently with my colleagues we decided to act as a buffer, doing a pass of QA ourselves, and depending on the results making the versions available or not to our customers. Sometimes it took one year before getting an good enough release. Quite annoying to do this ourselves, but at least our customers are satisfied with the quality. Now a year ago the partner decided to deliver a SaaS version, which made completely sense commercially. Then the SaaS became public a month ago and we keep encountering critical issues, like features not working, translation files older than the last on-prem release, or even impossibility to log in because somebody installed a patch and never checked anything after (and never told us about it either). But this time we cannot buffer anything, so they are basically shooting themselves in the foot.

brudgers 10y ago

Jeff Meyerson's recent interview with Julien Lemoin discusses the reasons Algolia has not created an on premises version. [spoiler: it is contrary to the strategic focus on performance, the same reason Algolia runs on metal it owns.] http://softwareengineeringdaily.com/2016/04/17/search-service-julien-lemoine-2/ http://softwareengineeringdaily.com/2016/04/17/search-servic...

apaprocki 10y ago

As a consumer of a number of on-prem installs, I'd just like to add something positive in what will probably be a lot of negativity regarding selling your product on-prem. The on-prem situation is evolving just as the SaaS/cloud world is evolving as well. Selling an on-prem product can be very lucrative if done correctly, and that can mean intentionally not selling to customers who don't have their act together. As more sophisticated customers install "private clouds" with OpenStack and the like, you can potentially have a SaaS on-prem use the OpenStack API natively and have a much better sales/maintenance story rather than boxing up a static VM and trying to get it or the customer to scale horizontally using static VM images and lots of configuration tweaking. I do agree that monitoring/logging can be problematic, but sometimes there can be somewhat standard OSS offerings that can be plugged in if the customer already has a managed monitoring platform running keeping tabs on lots of other things. The more adaptable (literally adaptable -- adapters to various solutions) your software is due to good design, the easier it will be for you -- or even the customer -- to adapt it into their stack.

tajen 10y ago
We went the other way, and it was far easier. Actually, our product is an Atlassian add-on, and Atlassian itself went from OnPremise to Cloud. It was, however, a long migration for both Atlassian and the add-on vendors. It was necessary because the market wants to try products withut installing them. Now Atlassian is able to make cloud-level changes to their software: They can use CD, live analytics, mutualized authentication for all tenants, etc. However, their API for cloud addons is, and will be forever, completely different from the API for onpremise addons. It's a major difficulty for the ecosystem. Many vendors extract a .jar that they reuse in both onpremise and cloud addons, but the cloud runtime that connects this .jar to the cloud API is at least as big as the jar itself (because we don't benefit from the host's services such as user management, storage or logging). OnPromise, which we started with, was however easier for us than Cloud. The customers, even enterprise ones (we have about 28 of them) are in charge of Ops, it cuts off half the work for us. And OnPromise is 3x more revenue for us per year, with the downside that it's a one-off, non-recurrent sale by default.

meowface 10y ago

As an employee at an enterprise that often asks SaaS companies for on-prem solutions... this is very on point. That said, we do pay a lot.

davidmr 10y ago

This is a subject near and dear to my heart, albeit from the "enterprise" side of the table, not the scrappy startup side. I've spent a non-trivial amount of effort trying to convince software companies to spin an on-premise version of their software. Sometimes with success, and sometimes not. I understand that it's quite attractive to rely on AWS or GCE abstractions to the point where it would be nearly impossible to break it apart for installation on my boxes, but it seems like it's leaving quite a lot of money on the table. There are perfectly valid reasons to require on-premise applications: in-house interpretation of regulatory requirements, protection of intellectual property, etc. Of course, I have a right to ask and they have a right to say no, but I wish more companies would consider making an on-premise solution. (Slack, I'm looking in your direction. Please come take the money I'm currently giving to Atlassian.)

tomjen3 10y ago
Given how much code is on github, I no longer think protection of intellectual property is a valid excuse. It may be a requirement from your boss.
- mseebach 10y ago
  That's not really how thinking about security works. "But everybody else is doing it" wasn't a valid argument in school, still isn't. As a thought experiment, (ignoring the fact that it's not an appropriate store for such things, and only thinking about security towards third parties) how would you feel about a company storing your PII/medical records/credit card number in a private repo on GitHub? That's how your boss thinks about the company's intellectual property.
  - tomjen3 10y ago
    Why would I feel any different if they stored it on Amazon cloud, github or on their own systems?
- davidmr 10y ago
  I'm sorry, but I have absolutely no idea what you're trying to say. Would you mind providing an alternate phrasing for your comment?

hdmoore 10y ago

I honestly thought this was satire for the first half of the article. When did working on SaaS products exempt people from understanding how to deliver software? Should we just remove the first [S] from SaaS? I see this attitude a ton in conversations with startups. A founder describes their whiz-bang thing, a question comes up about how this works in larger environments, usually followed by a mumbled reply about virtual appliances. Virtual appliances (and to some extent, docker containers) are not the solution, for so many reason, I might run out of space in the comment field listing them. The short version: OS updates, security updates, networking issues, customer-side diagnostics, size, and support for the customer's specific virtualization platform. Docker is great if your customers all use docker and you have the update process sorted out, but that is probably a small fraction of your total market. In other words, build actual installable software that runs on some set of supported operating systems. Make a DEB, an RPM, maybe an MSI. Build an installer. Have a nifty splash screen. Add desktop links. Don't lose revenue because you can't be bothered to figure out omnibus, nullsoft, or bitrock. If you are building software, keep in mind that customer environments are insane and should be treated as hostile. Every bit of your software and packaging needs to be paranoid, defensive, and respond well to failures. When something goes wrong, customers are not your QA team (you have one, right?). Don't make them run a thousand commands for you. Build actual diagnostic features into the product. Some organizations (hint: they have lots of money), don't let your icky code talk to the internet. Offline activation, offline updates, and offline diagnostics are super important to counting these folks as customers.

blazespin 10y ago
The problem with maintaining the install is that it really slows down your deployment of feature and evolving the ecosystem. It's not just a matter of extra know how. SaaS is more than just ease of use, it's a very very rapid and competive delivery of new features day in day out. Companies are adopting SaaS not just because they don't want to maintain the infrastructure / install software. They're adopting SaaS because they want the latest and greatest so they can compete better against their colleagues that don't have the latest and greatest.
- dingaling 10y ago

vchamakkala 10y ago

Just use replicated. http://replicated.com http://replicated.com. Easiest way to on-premify your SaaS app.

deleted 10y ago

[deleted]

borski 10y ago

CoreOS actually makes this significantly better with their Cloud Config capabilities. With CoreOS and Docker, we've successfully deployed this at a number of companies. With that said, there has been plenty of support to be handled, and we need to get better at doing multi-node deploys, but we're learning. :)

icebraining 10y ago
Well, you're quite lucky to be allowed to use CoreOS. In our case, only a minority of customers didn't want to dictate the distro to be used. In one extreme case, we had to install on SLES 10 (in 2014), without root or sudo, and then hand over the machines, since we weren't allowed direct access to the production system. And maintenance involved sitting with one of their sysadmins and telling him what to do :)

walkingolof 10y ago

Going on-prem also means building a different system, it has to be more streamlined, self contained and serviceable. The quality of this is tested once the customer wants to upgrade his system from version X to version Y.

_delirium 10y ago

Depends on your customers, but a decent amount of the stuff complained about here is stuff you may need to do in your SaaS anyway even if it's not deployed on-prem. The article mentions that in the SaaS version you update daily and don't maintain 6-month-old versions, but that's often not really realistic. If customers depend on stable functionality and versions, the fact that you control the hosted install doesn't mean you can just break things whenever you want. Yes, you can more easily do careful, planned updates since you control the whole environment. And you can run off of one integrated code-base. But you often need to conceptually support "6-month-old versions" in the sense of having announced and planned upgrade and migration paths, supporting parallel versions of APIs, etc. Many of the problems are at least similar, though not identical. Now if you can use a Facebook-style "move fast and break things" approach with no care for versioning or legacy support, you can bypass all of those. But if you were in a market where you had potential on-premises customers in the first place, how often is that true?

ww520 10y ago

On-premise install can be marred with problems. I have a case where the customer's IT refused to grant access to their network. The PM on the business side had to start Webex, shared his desktop, and allowed outside access to do the install via his desktop. Talk about punching a huge hole through their firewall.

TickleSteve 10y ago
...and he would probably have been disciplined for it or at least had a stern talking to from IT. This is a very common situation and in fact is the major reason behind them wanting on-premise solutions. You don't want your SaaS talking to the big wide world. If you're thinking you should be able to do on-premise installations remotely... its already gone over your head!

jasonkester 10y ago

Strange that the author mentions two ways of doing this (managed here vs. managed there), and spends the rest of the article saying how those are not in any way fun, but never mentions the obvious third option: As Is. I sell a self-hosted source-included license of Twiddla, as a single breakout of the current codebase, with the understanding that no further updates will be provided once we're all satisfied that you're up and running correctly. You can do whatever you like with the code, and I'm happy to sell you additional consulting time to help with what you're doing. But you're essentially on your own. It pretty much dispenses with every concern in the article.

majewsky 10y ago
How do you deal with updates? Do you just sell them a newer version, like with MS Office major upgrades in the past?
- jasonkester 10y ago
  No updates. Hence the "As Is." They're buying the version of the website as it exists at the point of time when they buy it. The assumption being that it works for them now, it should continue working for them in the future, regardless of what direction the .com goes.
  - reitanqild 10y ago
    What about vulnerabilities then? Or is it supposed that the customer use it behind a firewall / VPN solution?
    - jasonkester 10y ago
      In this case, we're talking about software built on the Microsoft stack, so most of that is Windows Update's job (patching servers manually isn't really something that needs to happen in this world). As to vulnerabilities in the handful of 3rd party libraries that we use? In the 10 years that Twiddla has been around, we've had exactly zero cases where we had to patch something from our end for security reasons. I guess there's something to be said about avoiding the tall skinny (and wobbly) tower of 3rd party dependencies that seems to be the norm these days in web app development.

pesenti 10y ago

Has any anybody here considered leveraging the on prem offerings of cloud providers, e.g., Azure on prem (http://www.geekwire.com/2015/microsoft-brings-azure-on-premises-with-new-services/ http://www.geekwire.com/2015/microsoft-brings-azure-on-premi...) or Bluemix local (http://www.ibm.com/cloud-computing/bluemix/local/ http://www.ibm.com/cloud-computing/bluemix/local/)?

fideloper 10y ago

After years working at a company that has a 10 year old on-prem and had a saas app as well, here is my POV on this: On premise vs saas is a trade off in the type of customer support. With on-prem, you do have support complicated by customers have unique infrastructure, and varying degrees of knowledge and post within their organization. Some people are adept, some are not. Some support keeps you screen sharing for hours, some do not. In general for on-prem, support is done via your customer support app, professionally, as you're usually dealing with an IT department. On the other hand, SaaS customer support volune/time is a measure of how often you break stuff for ALL (some, of you're lucky) of you're customers at the same time). Often an issue is experienced by many rather than a single person. "Always" (ish) it's your fault instead of being an issue of a customers configuration or infrastructure. Often Twitter becomes the public stomping ground for complaints, as you get end-users going to Twitter rather than an issue bumped up from an end user took their IT before reaching you. In considering of you want to support on-prem, a key point is to keep your software simple. For example, optionally (and easily) logging to files instead of <third party here> to reduce requirements on external systems (elastic search). Making the app as simple and easy to run as possible is pretty important. Definitely very strongly consider if you need to rely on that saas app for your App to run.

lloeki 10y ago
> In considering of you want to support on-prem, a key point is to keep your software simple. For example, optionally (and easily) logging to files instead of <third party here> to reduce requirements on external systems (elastic search). We have extensive experience doing this over here, and this is key. Keep things even simpler than you think they could ever be, because "simple" times gazillions produces terrific economies of scale. During interviews I'm often asked if I have experience on a product "at scale", by which interviewers often suppose it can only mean some typically tiered load balancers/front-end code/backend code/data persistence and you spin up new dynos/AWS of what is really (taken as a whole) a single cohesive application to face demand, and ultimately get dismissive when I tell them I'm not working on a 1Mreq/min product... but there's a whole other orthogonal dimension to "scale" which most products have firmly locked to 1, and believe me, everything suddenly follows a square law when your code and architecture can have an impact on each dimension, especially the one that involves humans that don't have the level of intimacy with neither your product, team, or methods.

jamiesonbecker 10y ago

We[1] drive the bulk of our revenue with on-prem. Many companies prefer to keep their SSH key management in house, and we actually count on that. However, we've invested a LOT of time into making our distributable a simple daemon. It's very easy to manage and install. We offer two on-prem versions: one is Pro which provides the basics (starts at around $3,500), and one is Enterprise which costs a lot more and supports external Redis, multiple app servers, web servers, LDAP integration, etc. Sales between the two are split approximately 30/70 in terms of revenue. In other words, we make a lot more on the Enterprise versions, but we sell less of them and the support costs are definitely higher. Just my 2c - but for us, on-prem has been a huge win and has taken us to profitability. In truth, however, we've probably focused too much on on-prem and not given enough focus to SaaS/cloud. For a startup that's just starting to hit profitability, we've actually been very happy with focusing on on-premise over SaaS, in contrast to the article, but our product was (re)designed with both scenarios in mind from the very beginning. We actually re-wrote the entire product before offering an on-prem version. In other words, just as described in the article: making technology changes like SQL to something else 'on the fly' might be hard but not impossible with SaaS... but with on-premises, it's almost impossible to work through hundreds of on-prem installations of some previously chosen tech, and the need for data migration, installs of new supporting packages, etc. I used to work as a tech consultant for a big company and one of our huge clients decided to upgrade all of their on-site journaling systems (running a PII-300!) from Windows to Linux. Remotely. Through an ISDN. Yes, this is possible if you have multiple drives available in the box with careful syslinux. Yes, it's also pretty insane. (We had about 95% success across around 10,000 stores worldwide.) Changing horses in the middle of the race is something to avoid where possible. It's easy to see that you're probably going to be stuck with your early technology choices if you go on-premise, unless you really build fantastic, auto-data-migration tooling that never fails, so make wise decisions and stick with SaaS until you're certain that you are sticking with your tech choices. (We don't differentiate between "on-prem" in your datacenter versus your VPC or (your) cloud. To us, you're installing/managing/running it and we're not, so, to us, that's on-prem. Other providers probably define this differently.) 1. https://userify.com https://userify.com (sudo and SSH public key management.)

k__ 10y ago

Things I learned after 10 years of dealing with enterprise customers. 1. They want on premise. 2. They want key account people to talk to. You don't need multi tenancy. You often get your own server to run on AND a local ops guy. It's a bit like an exclusive cloud. Yes, the deployments are a bit harder, since you often can't simply drop in a new version over the internet. This is why you need more ops to handle this all. But if I wanted to sell to enterprises I wouldn't got into the cloud in the first few years after starting the company. If the system works fine, it's a no-brainer to deploy it in the cloud and you already have all the ops people to maintain this...