3 ms·

> 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. My

by 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.

devdas 10y 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.
- 0xEFF 10y ago
  > If there are people who know PostgreSQL already and they have the tooling for it, then they want to reuse that stack. I haven't ran into these people in all of my experience on-site with paying customers. I'm not saying you're wrong, just that either I've gotten very lucky with my sample, or they do exist, but they don't really matter from a product perspective. For example, I have run into a few Ops teams who interface with separate teams who have DB admin roles. Universally, the Ops team prefers the included DB "feature" because it allows them to avoid the overhead of dealing with the database. It's unfortunate the "overhead" in this case is collaborating with the DB admin team, but it's the reality I see on the ground. > If PuppetDB was to support multiple backends, then you would find that every organisation would want to run on their own stack. I'm not sure that's true. I'm sure it's not true for _every_ organization. However, assuming it is true, I think it's a good example of why supporting multiple backends for PuppetDB would be a poor product decision. It wouldn't provide much value to Puppet the company or to their customers and it would increase the cost of support and maintenance tremendously for both parties. The same applies to any on-premise software product. This is probably why pluggable backend data layers as a feature are so rare in on-premise commercial software products. Why bother?

by 0xEFF 10y ago

devdas 10y 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.

0xEFF 10y ago
> If there are people who know PostgreSQL already and they have the tooling for it, then they want to reuse that stack. I haven't ran into these people in all of my experience on-site with paying customers. I'm not saying you're wrong, just that either I've gotten very lucky with my sample, or they do exist, but they don't really matter from a product perspective. For example, I have run into a few Ops teams who interface with separate teams who have DB admin roles. Universally, the Ops team prefers the included DB "feature" because it allows them to avoid the overhead of dealing with the database. It's unfortunate the "overhead" in this case is collaborating with the DB admin team, but it's the reality I see on the ground. > If PuppetDB was to support multiple backends, then you would find that every organisation would want to run on their own stack. I'm not sure that's true. I'm sure it's not true for _every_ organization. However, assuming it is true, I think it's a good example of why supporting multiple backends for PuppetDB would be a poor product decision. It wouldn't provide much value to Puppet the company or to their customers and it would increase the cost of support and maintenance tremendously for both parties. The same applies to any on-premise software product. This is probably why pluggable backend data layers as a feature are so rare in on-premise commercial software products. Why bother?