Managing connection strings and endpoints
Recently a colleague of mine shared his ideas on how to minimize an impact of an endpoint change for an external service. I thought that this was an interesting approach.
The actual problem is that in the microservices world, multiple projects may share the same external dependencies and if they are updated, one has to touch the configs across all these systems. My colleague's solution was quite simple and pretty much solved the problem - instead of providing the endpoints in the config file you could get by with a single line that exposes a gateway endpoint that would, in turn, fetch the rest of the dependencies from a service registry. The gateway could even hit the actual endpoint for you so that the only things you ended up caring about were the resource names and content retrieval. It also adds a possibility of implementing a centralized monitoring and reporting node, which increases visibility and provides an insight into the resource utilization. Moreover, it could also cache frequent requests to save the time. The drawback, however, is that you would have to live with a single point of failure and if, touch wood, the gateway or registry goes down, all the dependent systems would go down too.
To tackle that issue, an alternative is using, in our case, a Nuget library with these dependencies listed. If there is an endpoint update, the library could be modified and all the consumers would be required to update it. All the non-Nuget platforms, though, would not benefit from it so if your environment is fairly diverse, multiple package managers should be supported.
There is also a challenge of maintaining the infrastructure and convincing people to use it, but this is a different story for another time =) .
The actual problem is that in the microservices world, multiple projects may share the same external dependencies and if they are updated, one has to touch the configs across all these systems. My colleague's solution was quite simple and pretty much solved the problem - instead of providing the endpoints in the config file you could get by with a single line that exposes a gateway endpoint that would, in turn, fetch the rest of the dependencies from a service registry. The gateway could even hit the actual endpoint for you so that the only things you ended up caring about were the resource names and content retrieval. It also adds a possibility of implementing a centralized monitoring and reporting node, which increases visibility and provides an insight into the resource utilization. Moreover, it could also cache frequent requests to save the time. The drawback, however, is that you would have to live with a single point of failure and if, touch wood, the gateway or registry goes down, all the dependent systems would go down too.
To tackle that issue, an alternative is using, in our case, a Nuget library with these dependencies listed. If there is an endpoint update, the library could be modified and all the consumers would be required to update it. All the non-Nuget platforms, though, would not benefit from it so if your environment is fairly diverse, multiple package managers should be supported.
There is also a challenge of maintaining the infrastructure and convincing people to use it, but this is a different story for another time =) .
Comments
Post a Comment