2

We are about to embark on a large programme of work to migrate a small number of hugely monolithic 3 tier frameworks into a SOA/Microservice architecture. However there is one thing that I haven't really managed to nail down, version management (note the use of the word management, not control)

One of the core principles of this programme is that each component is absolutely independent, and therefore is designed, developed, built, versioned, deployed, operated, monitored and deprecated independently of all other Consumers and Services. This is the right principle and therefore means that the future holds 15+ clients and 50+ services. In operation we need to quickly and very reliably know all the dependencies. In a world where a service may have 3 or 4 versions of its API in production and a consumer may use 20+ services the dependency tree very quickly becomes large and complex.

So my question is how do you guys manage this? How do you maintain your "enterprise version matrix" (if that is even the correct terminology)?

MrEyes
  • 13,059
  • 10
  • 48
  • 68
  • Possible duplicate of [Product Versioning Microservices](http://stackoverflow.com/questions/33202053/product-versioning-microservices) – theDmi Oct 25 '16 at 07:53
  • I would use the likes of Nuget for dependency management and packaging for deployment (to add to the link above) – Sean Farmar Oct 26 '16 at 13:13

0 Answers0