undefined | Better HN

0 pointskgeist4y ago0 comments

>The golden rule is to never break API backwards compatibility. If you must, create a new version of the API and leave the old version functional

It also helps with zero-downtime deployments:

1) spawn a new instance of the service with the new API, side by side with the old one

2) now incoming traffic (which still expects the old API) is routed to the new instance with the new API, and it's OK, because it's backward-compatible

3) shut down the old instance

4) eventually some time later all clients are switched to the new API, we can delete the old code

0 comments

noogle4y ago

How can accumulation of versions be prevented? Now the same team has to maintain two products, and the underlying mechanism is still limited by the older version.

Anecdotally, a robust backward-compatibility has been seen as a hinderance to e.g. Java's progress (so much that a newer language, Kotlin, was created to break free from that burden).

ARandumGuy4y ago

There isn't really a solution to version bloat aside from good processes and general diligence. There's no easy way to handle that sort of thing, unfortunately.

However, I do think it can be easier to deal with for internal services then for something like Java. When the number of users is in the dozens rather then the millions, it's a lot easier to make sure everyone gets moved over to the new version.

noogle4y ago

That's what makes the whole idea of microservices seems weird to me. If a functionality has merit on its own (e.g. an authentication service), then it will naturally fall outside of the main application. If a service is tightly coupled to other parts of the app, then microservices seems like intentionally hindering yourself: the coupling remains (as evident by the need for backward compatibility), but now we it's harder to keep everything aligned due to the extra separation (e.g. different code bases, multiple databases, no static validation of remote interfaces etc.).

The point of organizations and products is to work as a tightly coordinated machine. The decoupling that microservices create seems opposite to that goal.

Happy to hear different perspectives.

1 more reply

trinovantes4y ago

One way is to rewrite version N endpoints to use version N+1 endpoints. You just need to ensure clients can handle null/empty data so that when some requested data is depreciated, you don't break old apps. The increased latency from N conversion calls also encourage the oldest clients to migrate without breaking backwards comparability.

kgeistOP4y ago

Well we usually coordinate between the teams. I.e. we don't force other teams to make changes as soon as possible (they have their own plans) but we agree to add relevant changes to their backlog, so that it was fixable in a 1-2 month window.

thebean114y ago

You need to talk to the other teams. Usually the change isn’t so drastic, I often made the change myself in the other teams service and sent them a review.

j / k navigate · click thread line to collapse

0 pointskgeist4y ago0 comments

>The golden rule is to never break API backwards compatibility. If you must, create a new version of the API and leave the old version functional

It also helps with zero-downtime deployments:

1) spawn a new instance of the service with the new API, side by side with the old one

2) now incoming traffic (which still expects the old API) is routed to the new instance with the new API, and it's OK, because it's backward-compatible

3) shut down the old instance

4) eventually some time later all clients are switched to the new API, we can delete the old code

0 comments

noogle4y ago

How can accumulation of versions be prevented? Now the same team has to maintain two products, and the underlying mechanism is still limited by the older version.

Anecdotally, a robust backward-compatibility has been seen as a hinderance to e.g. Java's progress (so much that a newer language, Kotlin, was created to break free from that burden).

ARandumGuy4y ago

There isn't really a solution to version bloat aside from good processes and general diligence. There's no easy way to handle that sort of thing, unfortunately.

noogle4y ago

The point of organizations and products is to work as a tightly coordinated machine. The decoupling that microservices create seems opposite to that goal.

Happy to hear different perspectives.

1 more reply

trinovantes4y ago

kgeistOP4y ago

thebean114y ago

You need to talk to the other teams. Usually the change isn’t so drastic, I often made the change myself in the other teams service and sent them a review.

j / k navigate · click thread line to collapse