Hacker News Reader

Comment by RickJWagner | Hacker News Reader

The author doesn't mention application updates, which can be important.

Shared application scenarios can bring headaches when different customers want different application behavior implemented in upgrades.

View on HN

Isn't that a different tangent? Does it matter, when the SaaS codebase is same for all tenants? If you are dealing with different codebase for different clients, then that is a flawed approach in that it is error prone and not scalable as tenants increase in number.

trying running a single SaaS codebase for enterprise clients. Maybe you can upgrade everyone with CI on a single commit, but no line of business solution wants that. We have to run a very strict and explicit upgrade cycle for our apps that allows them to test extensively before committing to newer versions.

Just because you're SaaS doesn't mean your clients are...

Care to share any details how your upgrade cycles work for enterprise clients in a SaaS?

It's not a 100% fail proof solution, but enforcing API versions in the the request helps. /latest/ is available in our preprod environment, but in production you can only call the API with an explicit version.

Even big software vendors whose products auto-update, e.g. Chrome, have to support differing versions to some degree - even if it's just to achieve A/B testing, phased upgrade rollouts, etc.

Being forced to flip the switch for all of your users at the same time can make that an awfully big and scary switch you're about to touch.

Traditional enterprise software suffers from this problem. SaaS doesn't really. Having to deal with different versions of a codebase for different customers was hellish and I don't want to do it again.

Telling the customer that "we are SaaS and we will distribute all updates on our schedule" is really convenient for the provider. However, is that really the best service to your clients?

What's best to your client is that you do not break the app or redesign the UI every other Wednesday. This has little relation with the upgrade schedule.

Depends on the industry / clients.

It's significantly better for us as a team to be able to focus on projects and improvements that benefit everyone. I've noticed the business starts to suffer when we focus on individual clients with narrow needs. Any one client only brings in 1/4000th of our revenue, so spending 1/4 of our development capacity on just something for them is a huge opportunity cost when we could be using it on something that benefits all our customers.

It was a different ballgame when I worked on on-prem software that cos millions and we only had 10 customers with a few customers sharing the same version.

IMO this is a great problem to raise, but is best solved by feature toggles and maintaining a single application codeline. Separate codelines are absolutely brutal to maintain.

Reply on news.ycombinator.com