7 ms·

The author doesn't mention application updates, which can be important. Shared application scenarios can bring headaches when different customers want differen

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.

sirkarthik 6y ago
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.
- nogabebop23 6y ago
  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...
  - HatchedLake721 6y ago
    Care to share any details how your upgrade cycles work for enterprise clients in a SaaS?
  - squeaky-clean 6y ago
    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.
- rkagerer 6y ago
  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.
yabai_yatsu 6y ago
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.
- pegas1 6y ago
  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?
  - user5994461 6y ago
    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.
  - yabai_yatsu 6y ago
    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.
bri3d 6y ago
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.

sirkarthik 6y ago

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.

nogabebop23 6y ago
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...
- HatchedLake721 6y ago
  Care to share any details how your upgrade cycles work for enterprise clients in a SaaS?
- squeaky-clean 6y ago
  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.
rkagerer 6y ago
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.

yabai_yatsu 6y ago

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.

pegas1 6y ago
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?
- user5994461 6y ago
  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.
- yabai_yatsu 6y ago
  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.

bri3d 6y ago

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.