you should never actually remove an api without a deprecation process.
basically a message format is part of your api.
actually in a microservice world your interfaces/api should be as stable as possible.
if something gets changed, it needs to go trough a deprecation, that means not removing it until a certain amount of time.
private apis exist for a reason. going through the deprecation cycle repeatedly sounds like a waste of time if you control all sides of the system. which is to say, not every interface needs to be a service boundary. you do need to keep versioned apis, but there is a cost to doing so.
Re:Give Me Back My Monolith
by organsnyder on Wednesday March 13, 2019 @10:22PM
(#19386024)
IMHO, part of a successful microservices program is treating your "private" APIs like your public ones, with SLAs, deprecation protocols, etc. Otherwise, you end up with tight coupling to the point that you should just go with a monolith.
Re:Give Me Back My Monolith
by galangalalgol on Thursday March 14, 2019 @11:03AM
(#19389830)
When you are still figuring out the problem space and message formats are being created removed extended and reverted several times a sprint, and you have already gone live with third parties depending on stable interfaces so that you cannot make the changes you need in a timely fashion, the warm arms of a purpose built monolith look particularly attractive.
Re:Give Me Back My Monolith
by organsnyder on Thursday March 14, 2019 @11:38AM
(#19390199)
Indeed. At that early stage of development, a monolith (or at least monolith-style practices, such as tight coupling between API providers and consumers) is definitely simpler and more efficient. But it wouldn't hurt to take steps from the beginning to make it easier to break the monolith apart when/if it becomes pragmatic to do so.
> private apis exist for a reason. going through the deprecation cycle repeatedly sounds like a waste of time if you control all sides of the system. which is to say, not every interface needs to be a service boundary.
The whole point of a microservice is to create a service boundary. If you have a private interface where both sides are maintained by the same team, both sides should be in the same service.
All interfaces are service boundaries. The only difference is whether you controll all clients and servers or not. Either way, API versioning is a must and trivial to implement, and there is really no excuse to avoid it. All it takes is a single integration problem caused by versioning problemd to waste more time than it takes to implememt API versioning.
The accept header could fix this easily if no third parties are involved and if it's a rest like API protocol
Re:Give Me Back My Monolith
by dragonwriter on Thursday March 14, 2019 @12:03AM
(#19386441)
The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions, which is a dev process issue, not a technical issue.
Feature flags, just enable it.
When all applications are adjusted, the accept-headers request a protobuff format in return.
=> Propagated everywhere except when a js ajax calls happens to the api-gateway.
> The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions
That assertion is not true. Media type API versioning is a well established technique.
A "service" is not defined principally by a code repository or communications-channel boundary (though it should have the latter and may have the former), but by a coupling boundary.
OTOH, maintaining a coupling boundary can have non-obvious pitfalls; e.g., supported message format versions can become a source of coupling--if you roll back a service to the version that can't send message format v3, but a consumer of the messages requires v3 and no longer supports consuming v2, then you have a problem.