4 ms·

It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Then there are the potential conf

by NBJack 3y ago

It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my personal favorite: weird customer deployment scenarios that break your library functionality. Bonus points if you are developing in a language without strong typing, or need to integrate with a dependency manager. Plus, if there was anything about your service that leveraged unique algorithmic improvements or some other proprietary tech, it is now at the mercy of anyone with a decompiler and sufficient time. I suspect the author may change their mind if exposed to scaled up solutions and technologies.

mooreds 3y ago
I thought the author addressed that point: "But this assumes that slow-to-upgrade users can have negative effects on everyone else. If one user can't have a negative impact on other users, then you don't care if some users are slow to upgrade; they're only hurting themselves." There's still the support issue, I agree. If a customer paid you money and they are on version n-10, they still expect support. > Plus, if there was anything about your service that leveraged unique algorithmic improvements or some other proprietary tech, it is now at the mercy of anyone with a decompiler and sufficient time. This is a valid point. My answer would be: it's all tradeoffs, but if your secret sauce is so valuable that it would be worth decompiling and can't be protected with decent pricing, license terms and lawyers, run a service. There are plenty of technologies that are not worth decompiling for your average business customers.
- LtWorf 3y ago
  If your updates don't break every single time, your customers will be more likely to do them.
- jampekka 3y ago
  In my experience the more they try to hide the sauce the worse it is. Quite logical though if the secret is that your secret sauce is bland and off-flavor copy of a canned soup. Which it usually is.
gjadi 3y ago
> It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. How is that different with services? I don't develop services, but I can imagine that before breaking the services, you have to poll with your biggest customers and you don't break until they are ready to move to the new version. The alternative I can imagine is to keep providing the old services with a grace period (e.g. /v1 will be available until dec next year). What am I missing?
- sokoloff 3y ago
  Many changes are believed to be non-breaking and so you can be running only one version in prod. (Most of the changes believed to be non-breaking are non-breaking.) With a library, you end up with many different minor or point versions running without control over it.
  - gjadi 3y ago
    Ok so the benefits here are transparent upgrade. Thanks.
  - genman 3y ago
    Emphasis on "are believed". This actually puts clients into risk of having breaking changes out of their control.
- materielle 3y ago
  The idea is to link a thin client library into the user’s code. Then the thick client is controlled server side by the devs. If you design the thin and thick client intelligently, you can make a lot of changes to the system by merely modifying the thick client (which you control), without needing to update the thin client. Problems tends to come in a few flavors, namely that this increases complexity and that some changes will always require modifying the thin client. The biggest pitfall, though, is that you have to actually put thought into the thin client design. “Thin” is an emergent property of a well thought out client. You can’t just “touch thin_client.java” and think because you named it “thin” that it’s inherently decoupled from the service. You have to actually put thought into it. Your example is exactly right. The service can support either v1 or v2 depending on the version of the thin client. The main other technique is to have the thin client communicate in a relatively abstract and generic manner. For instead a “write()” endpoint that accepts an “options” dictionary. “write()” is so generic that it probably won’t have to change, and changes in behavior can be modified by shoving stuff into dict, perhaps with a “version” field to instruct the server how to interpret the call. When you add a new feature, you can bump the thin client to v2 and shove new options in the dict. Then the server can support v1 and v2. But also, you can modify the server to handle v1 differently. E.g the absence of a “disable_new_feature” key automatically opts v1 callers into the new feature. I think the details are are really coupled into what you are engineering and what you want to roll out. There’s no magic bullet, and this increases the complexity of your code. Good engineering in my opinion is deciding when these approaches are worth it and how they should be implemented.
noah91734 3y ago
> It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Given how frequently needless breaking changes are made, or features are removed and paywalled, I would consider this a feature rather than a bug. Sometimes I have higher priorities than working to support someone else's breaking changes. Two years ago, I was using an official library for interfacing with a video chat service, and they decided to break the underlying API without updating their library, so I had to rewrite the library myself.
kuchenbecker 3y ago
Write a library, deploy it as a service if necessary.
crabbone 3y ago
This is a completely broken model. You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do. If you are trying to update before they want to, you are doing them a disservice. This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are either forced to update to gain useless features and the headache resulted from various inconsistencies and defects coming from the last update, or they are unable to get the product at all (because the provider cancels support or wouldn't sell older versions etc.) In other words, you with straight face describe some really shady practice and you don't even realize how bad it sounds.
- stefan_ 3y ago
  Unless they have a specific problem or missing feature, customers want to update never.
- actionfromafar 3y ago
  It can be that, but it doesn't have to be. It depends on the business model and it's quite orthogonal to library vs service.
- mrmanner 3y ago
  > This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are either forced to update to gain useless features and the headache resulted from various inconsistencies and defects coming from the last update, or they are unable to get the product at all (because the provider cancels support or wouldn't sell older versions etc.) Selling more is how service providers are able to sell their generic service at a lower price than the cost you would incur by building it in-house. In other words, being forced to upgrade to accommodate features that other users want is the price you pay for sharing the development cost with those other users. That's not shady.
- NBJack 3y ago
  You assume I wanted to make the update in the first place. I invite you to review roll outs of security updates. These are rarely about pushing new features, and may have nothing to do with my own code at all. It might just be a version bump to my dependencies config (if a dep manager with shared libraries is involved), or just a refresh of my flatpak equivalent. But, either way, shit breaks in weird and wonderful ways, and there is little I can do but wave my arms frantically at customers.
fsloth 3y ago
Yes you need to have n versions you support in parallel in the wild. One per released incompatible binary API (so in semver 1.x, 2.x etc). We support about 30 libraries with 5 ppl spread around a fortune 1000 org here and there. It’s quite tenable, we are just super strict regarding ticket policy and release notes, so we always know what’s released where. Just have a system. Stick to it. Keep things organized. Works like a charm. If someone wants a service out of those someone just packages them to docker and puts them to backemd somewhere. We can focus on pure business logic, someone else maintains services etc. Really nice setup.

by NBJack 3y ago

mooreds 3y ago

I thought the author addressed that point: "But this assumes that slow-to-upgrade users can have negative effects on everyone else. If one user can't have a negative impact on other users, then you don't care if some users are slow to upgrade; they're only hurting themselves." There's still the support issue, I agree. If a customer paid you money and they are on version n-10, they still expect support. > Plus, if there was anything about your service that leveraged unique algorithmic improvements or some other proprietary tech, it is now at the mercy of anyone with a decompiler and sufficient time. This is a valid point. My answer would be: it's all tradeoffs, but if your secret sauce is so valuable that it would be worth decompiling and can't be protected with decent pricing, license terms and lawyers, run a service. There are plenty of technologies that are not worth decompiling for your average business customers.

LtWorf 3y ago
If your updates don't break every single time, your customers will be more likely to do them.
jampekka 3y ago
In my experience the more they try to hide the sauce the worse it is. Quite logical though if the secret is that your secret sauce is bland and off-flavor copy of a canned soup. Which it usually is.

gjadi 3y ago

> It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. How is that different with services? I don't develop services, but I can imagine that before breaking the services, you have to poll with your biggest customers and you don't break until they are ready to move to the new version. The alternative I can imagine is to keep providing the old services with a grace period (e.g. /v1 will be available until dec next year). What am I missing?

sokoloff 3y ago
Many changes are believed to be non-breaking and so you can be running only one version in prod. (Most of the changes believed to be non-breaking are non-breaking.) With a library, you end up with many different minor or point versions running without control over it.
- gjadi 3y ago
  Ok so the benefits here are transparent upgrade. Thanks.
- genman 3y ago
  Emphasis on "are believed". This actually puts clients into risk of having breaking changes out of their control.
materielle 3y ago
The idea is to link a thin client library into the user’s code. Then the thick client is controlled server side by the devs. If you design the thin and thick client intelligently, you can make a lot of changes to the system by merely modifying the thick client (which you control), without needing to update the thin client. Problems tends to come in a few flavors, namely that this increases complexity and that some changes will always require modifying the thin client. The biggest pitfall, though, is that you have to actually put thought into the thin client design. “Thin” is an emergent property of a well thought out client. You can’t just “touch thin_client.java” and think because you named it “thin” that it’s inherently decoupled from the service. You have to actually put thought into it. Your example is exactly right. The service can support either v1 or v2 depending on the version of the thin client. The main other technique is to have the thin client communicate in a relatively abstract and generic manner. For instead a “write()” endpoint that accepts an “options” dictionary. “write()” is so generic that it probably won’t have to change, and changes in behavior can be modified by shoving stuff into dict, perhaps with a “version” field to instruct the server how to interpret the call. When you add a new feature, you can bump the thin client to v2 and shove new options in the dict. Then the server can support v1 and v2. But also, you can modify the server to handle v1 differently. E.g the absence of a “disable_new_feature” key automatically opts v1 callers into the new feature. I think the details are are really coupled into what you are engineering and what you want to roll out. There’s no magic bullet, and this increases the complexity of your code. Good engineering in my opinion is deciding when these approaches are worth it and how they should be implemented.

noah91734 3y ago

> It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Given how frequently needless breaking changes are made, or features are removed and paywalled, I would consider this a feature rather than a bug. Sometimes I have higher priorities than working to support someone else's breaking changes. Two years ago, I was using an official library for interfacing with a video chat service, and they decided to break the underlying API without updating their library, so I had to rewrite the library myself.

kuchenbecker 3y ago

Write a library, deploy it as a service if necessary.

crabbone 3y ago

This is a completely broken model. You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do. If you are trying to update before they want to, you are doing them a disservice. This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are either forced to update to gain useless features and the headache resulted from various inconsistencies and defects coming from the last update, or they are unable to get the product at all (because the provider cancels support or wouldn't sell older versions etc.) In other words, you with straight face describe some really shady practice and you don't even realize how bad it sounds.

stefan_ 3y ago
Unless they have a specific problem or missing feature, customers want to update never.
actionfromafar 3y ago
It can be that, but it doesn't have to be. It depends on the business model and it's quite orthogonal to library vs service.
mrmanner 3y ago
> This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are either forced to update to gain useless features and the headache resulted from various inconsistencies and defects coming from the last update, or they are unable to get the product at all (because the provider cancels support or wouldn't sell older versions etc.) Selling more is how service providers are able to sell their generic service at a lower price than the cost you would incur by building it in-house. In other words, being forced to upgrade to accommodate features that other users want is the price you pay for sharing the development cost with those other users. That's not shady.
NBJack 3y ago
You assume I wanted to make the update in the first place. I invite you to review roll outs of security updates. These are rarely about pushing new features, and may have nothing to do with my own code at all. It might just be a version bump to my dependencies config (if a dep manager with shared libraries is involved), or just a refresh of my flatpak equivalent. But, either way, shit breaks in weird and wonderful ways, and there is little I can do but wave my arms frantically at customers.

fsloth 3y ago

Yes you need to have n versions you support in parallel in the wild. One per released incompatible binary API (so in semver 1.x, 2.x etc). We support about 30 libraries with 5 ppl spread around a fortune 1000 org here and there. It’s quite tenable, we are just super strict regarding ticket policy and release notes, so we always know what’s released where. Just have a system. Stick to it. Keep things organized. Works like a charm. If someone wants a service out of those someone just packages them to docker and puts them to backemd somewhere. We can focus on pure business logic, someone else maintains services etc. Really nice setup.