Comment by omeze | Hacker News Reader

Comment by omeze | Hacker News Reader

The truth is that people who are fine operating and managing their own ElasticSearch/Postgres/Spark whatever cluster are not the people who will be buying the SaaS offering. Theres no point trying to convert those people, theyll convert themselves once they get tired of constantly upgrading and maintaining a non-differentiated piece of their business, or they’ll just be happy users who bring your tech stack to their next gig, where the buy vs self-host choice gets revisited.

The main problem is that many teams think they’re “that guy (or girl)” who can manage a complicated piece of infra as a small team and will be saving money. If you spend 10% of your time doing devops work, you spend 10% less time on your actual product (you might as well be binging netflix). A majority of these teams convert (IME) to a hosted offering once the right price and SLAs and DevExp are there. The only part of your sales pitch that matters to these teams is “this isnt worth your time to self host when we have a great offering thats cheaper and faster to get setup”. If you have a logo from a big co that has the talent to self host but are buying your product, then your work is done.

A few problems with your comment -

1. 10% of your time doing devops work isn't necessarily a waste - if 10% of that time is cheaper than enterprise offerings, then this is probably worth the resources, unless you are very short on talent.

2. You have an assumption laden in this comment that SaaS products eliminate the need for spending time on "devops work." It can greatly reduce that time, but IME even administrating a SaaS product can come with a ton work - look at EKS, a "managed" kubernetes cluster, but often requires a lot of kubernetes know-how to properly configure and maintain.

> 1. 10% of your time doing devops work isn't necessarily a waste - if 10% of that time is cheaper than enterprise offerings, then this is probably worth the resources, unless you are very short on talent.

That's not the right calculation for revenue-generating products (IME). The right calculation is: if your product got this 10% instead of you doing DevOps work, is the additional long-term revenue higher than the cost of the enterprise offering?

What is the X% of your product you're willing to outsource? What % of margin are you willing to give up for that capability? Because the hope/dream of every parasitic SaaS is to grow with their customers...

Having taken part in many build-vs-buy decisions, there are no easy answers. The overriding factors in most decision relate to the specifics of the business. Some very common reason for buy decisions:

- You don't actually know if this feature will be important long term

- You have many urgent needs, the opportunity cost of waiting for "build" to finish is too high

- Your company is, for various reasons, unable to attract and retain the kind of talent who could maintain a system of this complexity (I realize this sounds like "we're not willing to pay market reates", I promise it's more complicated than that)

Let’s be honest, dev ops can be more than 10% when there’s no consistent way to tie in every open source project into an environment.

SSO helps, but it can still be work to roll out.

Both your counterpoints are true, I didnt want to sprinkle the word “marginal cost” everywhere (marginal devops cost of buy vs self host). And ofc I agree, not all saas offerings are the same, EKS is fairly meh as far as setup and time savings.

3. Managed solutions usually aren’t as configurable.

E.g. plugins

Proper zero-hassle managed software is Heroku. All it takes is money, and it's refreshing to realize how much your ops really cost.

If you do 90% dev and 10% ops, and we call that 'devops'... are you devdevops?

I am really puzzled by the terminology.

Every discussion around subscribing to a SaaS vs. operating it is always reduced to costs on HN. There is another, more critical aspect to why we (and many others) operate their own infrastructure, run their own servers, operate their own Elasticsearch clusters: Keeping ownership of customer data for business continuity and compliance purposes.

You can enforce your own SLAs, manage your own downtime, avoid versions changing under your feet, avoid UI changes to critical apps... It is a cost, but it's also a necessary cost to provide the experience you want to deliver to your clients.

Good explanation.

There will be companies who prefer to self host and those who don’t, and having an option of paid support or cloud hosted can go a long way especially when the open source project can set itself up as a first class plugin in the Microsoft cloud.

Many of not most companies are already on Microsoft and it ensures a good amount of support for open source so they don’t have to separate features into different tiers.

One of the more interesting open source setups was a product that was licensed both as open spruce and commercial, and the customer (often government or education) would have a policy of commercial only or open source only and they could support it both ways.

Are we completely ignoring the technical impact of using a SaaS that is likely in a whole other data centre to everything else?

It is very easy to destroy response latency by pinging loads of messages around when they should be colocated in one place.

This is one of the reasons AWS services are so sticky compared to everyone else.

It's not in a different data center; it's in us-east-1.

Do you mean that us-east-1 is a single data center? OTOH any DCs that comprise that region should be close enough together, and on ridiculously fast links.

No, I mean if every lazy SaaS provider and every lazy customer is in us-east-1 then there won't be any latency problems.

Aren't there businesses for which self-hosting save far more money?

Infra is often a financial decision as much as technical.

(reminds me of basecamp exiting the cloud but I know nothing more than that)

Yes. After factoring in labor, our $XXmm company saves low-mid six figures per year by self-hosting the majority of our infra.

Truthfully I think you'll find with a thorough review of most SaaS SLAs that they are more expensive than the toil they say they replace. Otherwise how would the company make money? It's still engineers doing X work. There really aren't that many opportunities for economies of scale with enterprise SaaS when you have SLAs and data sovereignty unless you're cutting corners.

>> It's still engineers doing X work. There really aren't that many opportunities for economies of scale with enterprise SaaS when you have SLAs and data sovereignty unless you're cutting corners.

Not really, SaaS built specialized automaton to reduce the engineering effort so that they can scale better. Therefore, if the users need to spend 1 hour/day on their infra, the SaaS can spend the same amount time to manage infra for 100s customer.

In some extreme cases, the software run by the SaaS is completely different to what the regular users use. For example, Confluence Cloud Kafka service does NOT actually run Kafka underneath, but a proprietary system called Kora that speak Kafka protocol.

Yes. There are plenty of examples of going down the abstraction stack and saving money among other things.

I believe the question is really high level and strategic and there’s no one size fits all.

Saving money can be one consideration.

Not having the amount of expertise or hours on hand to support it can be another. Shadow labour costs can add up pretty quick and some orgs like offsetting that to the vendor to not overload their people.

Another consideration is how much the tech aligns with your core business. Just because you need it doesn’t mean you should build or run a ticketing system.

Too often there is a lot of SharePoint whiplash and problem “solutions” that grew out of control.

Large orgs don’t always behave rationally and pragmatically when there is self preservation or politics at play instead of being effective at your work.

Yeah. For a lot of SaaS companies, their entire profit margin is about state management (in Kafka, elastic, HDFS, whatever). There's a huge incentive to squeeze that part of the stack for cost efficiency.

Doing your own, requires you to gain knowledge in that area and in my view expanding your knowledge base is really important. It's not all about immediate possible financial gain. Obviously there's a line somewhere

Reply on news.ycombinator.com