Service registries: What are they and why do you need them?
By Lori MacVittie
Adoption of microservices, if you haven't been paying attention, is more than just idle talk from pundits these days. A 2015 Typesafe survey reported that "out of 3,060 overall users, 33 percent (or 1,020 people) identified their systems as microservices-based."
Given the rapid rise of this application architecture designed as much for speed of development as scalability, it's increasingly important to understand how those microservices are going to be deployed. Not just from the DevOps perspective of automation and orchestration of deployment processes, but of the critical operational processes of monitoring and scaling the services once in production.
While the soothsayer's warning regarding virtualization and its impact on scalability may have been somewhat hyperbolic, similar warnings regarding microservices should not be summarily dismissed. The highly localized nature of microservices does, in fact, lead to a significantly higher rate of change, which must be addressed by the systems put in place to monitor and scale them. They will need to scale independently and potentially be required to scale unpredictably – and often. Consider a data point from a November 2015 Structure presentation by Adrian Cockcroft that tells us the average container lives for zero to one minute. While microservices certainly do not require containers and containers are used to provision more than just microservices, the two are undeniably often paired, giving us a view on just how incredibly dynamic the environment will be in which microservices need to be managed.
The result is that many services may be dynamically appearing and disappearing at an alarming rate as demand waxes and wanes. One of the challenges that arises from this is how to direct the client – whether internal or external, e.g. a mobile app – to the right instance of the service at the right time. Multiple microservices are often composed using APIs to provide the various functionality needed for what would have been a monolithic application. One service for checkout, another for login, one for search, and so on. Each of these services can then scale as needed. More folks searching? More search services. More checkouts? More checkout services.
But launching additional services (increasing capacity) is only part of the operational process required to put those services into, well, service. Somehow, users (which include humans, things and apps) must be able to locate them. This is where service registries enter the picture.
Service registries serve the purpose of keeping track of all the microservice instances available in a scalability domain (pool) and, when asked (queried) will respond with the right service for the client based on what is available right now. In some ways, a service registry is a real-time DNS for microservice instances, with monitoring and additional metadata to ensure instance locations are distributed appropriately.
When a new microservice instance is provisioned, it is added to the service registry and is then available to clients. When that service is no longer available, it is removed from the registry. This removal may be triggered by a failure detected by monitoring or deliberately when the capacity is no longer needed.
That probably sounds suspiciously like a load balancer. Unsurprisingly, load balancers can fulfill the role of a service registry if they can operationally handle the constant updating of pools, which service registries typically accomplish with an API. Because service instances often live very short lives, the use of automation using APIs is almost a requirement, given that manual addition and removal at such high rates of change would likely not be feasible.
The responsibilities of a service registry keeps the current "list" (pool) of available microservice instances up to date, so that clients can locate and make use of the service, effectively addressing the challenges of scaling microservices.
In the rest of this series, we'll look at deployment patterns and security considerations for service registries.
Lori MacVittie is a subject matter expert on cloud computing, cloud and application security, and application delivery and is responsible for education and evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she authored articles on a variety of topics aimed at IT professionals. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.