Combining Continuous Deployment and a Microservice architecture brings new challenges to develop and operate your platform. A service discovery enables you to build a flexible system. Developers need to have an up to date view on the deployed services as well. A human readable registry with relevant information is needed.
I will outline what we solved with a Service Registry and what impact it had on our architecture. Furthermore I will show what we needed to give our developers to get an up to date view on the whole platform.
Target Audience: Architects, Developers
Prerequisites: Concept Microservices, Continuous Deployment
In the last couple of years Continuous Deployment paved the way for delivering customer features very fast to production. Still the code was deployed often on the very same machines every time. If there is a problem or you need to scale fast there are very likely manual steps to fix things. Combining this with a fast growing number of microservices and it can get out of hand very quickly. This is where a Service Discovery can be of a great benefit. It solves the problem with a minimal impact on the rest of the system.
With lot’s of microservices running, developers facing the problem of knowing what are the capabilities of all these services, who is responsible if they have a question, where can I find more information about it, who talks to my service if I need to make an incompatible change? Usually you find lot’s of outdated information about that in the company wiki. So everybody ends up at digging through the code and commit logs. What needed here is what Martin Fowler called a ‘Humane Registry’. Automated up to date information about the services in a readable format for humans.
In this talk I will outline how and what we solved with a Service Registry and what impact it had on our architecture. Furthermore I will show what we needed to give our developers and architects to get an up to date view on the whole platform.