So You Wanna Go On-Prem

http://blog.lusis.org/blog/2016/05/15/so-you-wanna-go-onprem-do-ya/

by friendzis • 10 years ago

256 102 10 years ago

blog.lusis.org

seibelj• 10 years 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• 10 years 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• 10 years 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).

gkoberger• 10 years 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• 10 years ago

We do what we can to ease the pain of going on-prem for modern SaaS companies :)

paloaltokid• 10 years 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.

beachy• 10 years 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.

pnathan2• 10 years 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• 10 years ago

From experience, on-prem customers won't accept continuous updates anyway. They have multi-month change freezes.

voltagex_• 10 years 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• 10 years 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.

mr_tristan• 10 years ago

I think you mean "don't expect to do CD to these people".

CI is "developers check in code and everything is integrated daily".

CD adds "and then we push it out live if tests pass".

I've worked on software products that attempted CD, and it's not gotten a lot of great acceptance. Customers don't really want constant notifications about having to upgrade, except for very serious fixes. And I don't know many IT departments in big companies that are like, "sure, go ahead and auto-update".

CI, on the other hand, is wonderful. You don't have the mainline off in this broken state for weeks while you're adding features.

pnathan2• 10 years ago

Whoops, yes, you're right. Misnomer. >.>

TorKlingberg• 10 years ago

Stable versions is the correct way to do it, but it certainly has a cost. You have to support a version with bugs you fixed months ago. You will have to backport security patches and other critical fixes. If you have refactored the code since the stable release merging fixes back to the release branch is much more work. So people will resent the person who made extra work for them by refactoring. Soon everything has the wrong name and functions are 1000 lines long because nobody dares to refactor.

jasonlotito• 10 years ago

You have to support a version with bugs you fixed months ago.

Technically, you do this with any serious SaaS. You cannot just update your service without regarding to existing integrations, and guess what? Those companies are already integrated with you. Having to integrate again is an additional cost, and I promise you, at that moment, they will investigate other options. After all, they are already having to spend additional time/money to update.

avitzurel• 10 years 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• 10 years ago

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

twakefield2• 10 years 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

[1] http://gravitational.com/teleport/

rdtsc3• 10 years 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.

twakefield2• 10 years ago

Yes, that is true. I meant it more that a new class of "on-prem" is being created.

azernik3• 10 years 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.

jitl• 10 years ago

For us, "on-prem" means "in our private AWS cloud, with no dependencies on the Public Internet". For critical services for engineering, we want to know that your service is not going to stop working if Github or some CDN goes down or has latency problems. We want to know that you aren't going to toggle some feature switch on your service and expose us to some new bug. We want to know how much headroom your software has, so we know if it can scale with us.

I think this concept of "on-prem" being "in our private cloud, firewalled from the internet" is pretty well-understood among consumers of AWS or other IaaS products.

brazzledazzle4• 10 years ago

Teleport looks really cool–I can't wait to try it out. Thanks for releasing it.

pbnjay• 10 years ago

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

old-gregg• 10 years 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 Full disclaimer: I work there.

hdmoore2• 10 years 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.

rdtsc3• 10 years 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• 10 years 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..

johnbellone2• 10 years 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.

emanlin• 10 years 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.

devdas• 10 years ago

It depends on what the organisation has standardised on.

If there are people who know PostgreSQL already and they have the tooling for it, then they want to reuse that stack. If the organisation has standardised on MySQL/Oracle/SQL server/something else, then learning about and supporting PostgreSQL are additional headaches.

If PuppetDB was to support multiple backends, then you would find that every organisation would want to run on their own stack.

Ops has always been overloaded. That is the biggest reason why enterprise support contracts are a thing.

ryanackley2• 10 years 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• 10 years ago

Or you could copy tableau and shove it all into a vm

brazzledazzle4• 10 years ago

That's how Github Enterprise is distributed for on-prem. Virtual appliance.

koolba3• 10 years 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!

mseebach3• 10 years ago

No, "everything" is not moving back on-prem, just like "everything" never moved to the cloud.

But a great many things did move to the cloud, even more were conceived there, and practically all of them are going to stay there. You can successfully run a whole business of a very respectable size without managing even a single on-prem device, and that's great, and that's not going to change.

The push back to on-prem isn't a move, it's an expansion. Old/large/government orgs which for different good and bad but mostly immutable reasons can't let their data off-prem is getting interested. It's a new market, not a change in the old.

ryanackley2• 10 years ago

I agree it's not a dichotomy. However,it's also not a "new" market and it's not just dinosaur enterprises buying on-prem software.

draw_down• 10 years ago

No, this article is literally about why you should do everything in your power to never go "on-prem".

telecuda2• 10 years 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)

koolba3• 10 years 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...

telecuda2• 10 years 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)

capkutay• 10 years ago

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

cgarrigue• 10 years 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• 10 years 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-servic...

apaprocki• 10 years 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• 10 years 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• 10 years 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.

davidmr2• 10 years 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.)

tomjen32• 10 years 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.

mseebach3• 10 years 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.

davidmr2• 10 years 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?

kordless• 10 years ago

The problem is with licensing and trusted deployments. Having done the high level of the architecture for one possible solution, I can tell you we are about 3-4 years out before this is common practice.

hdmoore2• 10 years 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• 10 years 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• 10 years ago

so they can compete better against their colleagues that don't have the latest and greatest

But there's nothing exclusive about SaaS and often our rivals' logos are already on the SaaS vendor's pitch-deck

Buy for equivalence, build for advantage. SaaS provides out-of-the-box solutions for basic functionality like HR or payroll and allows a company to deploy its programmers where they can build an advantage over their competitors in the domain of business logic.

SaaS is the new MS Word; just buy whatever everyone uses and get on with using that to do the things that actually make money.

mattlutze• 10 years ago

Vendors have responded to this challenge for a while with Long-Term Support builds to complement the standard product cycle. Get a major set of features that your on-prem customers want, freeze the features, and keep 12, 18, 24 months between major feature updates.

Most companies of any complexity are going to be unable to integrate into their business processes all of your latest and greatest features as fast as the fictional SaaS dev team can release them (then revise, then revise again).

For most of these businesses (just read, most businesses), your software will be less of a time suck if it has a moderate release cycle with a predictable, well-advertised lead out to new changes, allowing IT departments to evangelize and pre-educate on the new capabilities.

vchamakkala• 10 years ago

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

borski• 10 years 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• 10 years 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 :)

_lbaq• 10 years 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• 10 years 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• 10 years 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• 10 years 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!

jasonkester3• 10 years 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.

majewsky2• 10 years ago

How do you deal with updates? Do you just sell them a newer version, like with MS Office major upgrades in the past?

jasonkester3• 10 years 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.

pesenti• 10 years 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-premi...) or Bluemix local (http://www.ibm.com/cloud-computing/bluemix/local/)?

fideloper• 10 years 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• 10 years 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• 10 years 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 (sudo and SSH public key management.)

k__• 10 years 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...

So You Wanna Go On-Prem

Related Stories