7 ms·

"If you're not careful with dependencies and coupling, you can get into situations where you can't upgrade a service without touching n other services; and you

by UK-AL 10y ago

"If you're not careful with dependencies and coupling, you can get into situations where you can't upgrade a service without touching n other services; and you have to be sure to deploy them in order. " Why aren't you versioning your api?

jose_zap 10y ago
How does versioning an API solve the problem of having to deploy interdependent services in the right order? For a change involving two services that need changing, Service A calling Service B, you still need to deploy B before A.
- UK-AL 10y ago
  Because you obviously need to add that feature to service b before anyone can use it. This goes for anything in software, libraries, products, APIs etc. Ideally that feature should be developed indepedently by the team looking after that service. It could however be a feature request by another team. Once the feature is ready, you deploy it and then advertise this feature is now available. If it's a breaking change, you version it so it doesn't effect existing services. Then the team for service a can now start integrating that feature into their service. You don't need complicated orchestrated deployments. The time from service/team b advertising that the feature is available, to service a acutally consuming it may be weeks. You just treat the microservices as separate products exposing a API, which operate on different timelines. Other teams may request features, but the team maintaining the service determine the how and the timeline. Obviously higher priority items get developed first.
- lostapathy 10y ago
  When the API is versioned (and you keep both versions online), you can deploy the update to service B long ahead of when service A needs deployed
djsumdog 10y ago
We do version API. Everything is done by content type. You can ask for a "vnd.something.something.json+v1" "+v2" etc...you still want to update everything on the older version so you don't want to maintain that crap forever. Then there's the splunk searches you have to run to make sure all your consumers are onto the new version .. and that "What the hell is that IP and why is it using v1? Why does this API key not have a name on it?!"

by UK-AL 10y ago

jose_zap 10y ago

How does versioning an API solve the problem of having to deploy interdependent services in the right order? For a change involving two services that need changing, Service A calling Service B, you still need to deploy B before A.

UK-AL 10y ago
Because you obviously need to add that feature to service b before anyone can use it. This goes for anything in software, libraries, products, APIs etc. Ideally that feature should be developed indepedently by the team looking after that service. It could however be a feature request by another team. Once the feature is ready, you deploy it and then advertise this feature is now available. If it's a breaking change, you version it so it doesn't effect existing services. Then the team for service a can now start integrating that feature into their service. You don't need complicated orchestrated deployments. The time from service/team b advertising that the feature is available, to service a acutally consuming it may be weeks. You just treat the microservices as separate products exposing a API, which operate on different timelines. Other teams may request features, but the team maintaining the service determine the how and the timeline. Obviously higher priority items get developed first.
lostapathy 10y ago
When the API is versioned (and you keep both versions online), you can deploy the update to service B long ahead of when service A needs deployed

djsumdog 10y ago

We do version API. Everything is done by content type. You can ask for a "vnd.something.something.json+v1" "+v2" etc...you still want to update everything on the older version so you don't want to maintain that crap forever. Then there's the splunk searches you have to run to make sure all your consumers are onto the new version .. and that "What the hell is that IP and why is it using v1? Why does this API key not have a name on it?!"