Yesterday, I had a thought. It didn't fit into a tweet so wrote a few paragraphs. I was very pleased with myself, finally getting round to writing again after a few months off. That was, until two different people who I respect highly, told me I was wrong. That part sucked.
Who Can Do This For Me?
Mike Amundsen stated in comments on the blog that what I was describing was simply the usage of a service, not the discovery of service. Mike has written about the process of service discovery as part of a series of articles in Infoq. Mike uses the term Service Discovery to describe the process of identifying who will be providing a particular service as part of an application.
If we were to consider a real example, consider the need to provide security services within an application. One part of that process is the role of an authentication manager. Some service needs to take credentials and provide an identity. There are a whole range of choices. An application developer could create their own service. They could use an open source product like IdentityServer, or a hosted service like Auth0 or Stormpath. Many different identity providers also provide service APIs for doing authentication. e.g. AzureAD, Facebook, Google, LinkedIn, Twitter, Github.
Currently there are minimal facilities for doing this "service discovery" in any kind of automated way. If we look into the past, some will remember UDDI as promising this kind of capability. More recently, apis.io was created as a search engine to facilitate the discovery process.
Where Is It Now?
John Sheehan also felt that I was misappropriating the Service Discovery term. From his perspective,
@@darrel_miller it's about separating the logical location from the physical so that the application layer doesn't need to think about it.
— John Sheehan (@@johnsheehan) September 3, 2015Being a past member of the Runscope team, I know how critical the microservices architecture is to their product. I also have a good idea of how much devops work they have done to enable the agility of their product. Being able to separate the logical identity of a service from the physical identity is hugely valuable when it comes building scalable, reliable and evolvable systems.
When building products that are composed of many different services it can challenging to to seamlessly support dev, test and production environments. The same goes for being able to roll back deployed services and fail-over services. Having systems in place that allow you to dynamically change physical addresses of machines for logical services is essential.
What Identifier Should I use?
Both Mike and John we correct. I was using the term Service Discovery to describe something different. But interestingly, so were they.
What I described was a distinct process that falls somewhere in-between their definitions. I was describing the use of a URL as a service identifier. Once an application has "discovered" which authentication service they are going to use, an identifier for that service needs to be communicated in some way to components of the application in order for them to interact with the service. This could be done as simply as adding a config entry for each application component. It could be centralized in some kind of registry service that other services use to discover the identifier, or as I was suggesting it could be delivered via hypermedia.
The idea is that a component that needs access to authorization capabilities only needs to know in advance the link relation type identifier used to advertise authorization services, it doesn't need to find out until runtime what the identifier for that service is. Having some kind of semantically significant type associated to the service identifier is a key concept for enabling this type of discovery.
I'm not going to deny that there is some smoke and mirrors going on here because interchangeable services from different identity providers is still fairly uncommon. However, standards like OAuth2 do provide a certain level of consistency. Just because something isn't possible today, doesn't mean it is not a good idea 
.
Naming is Hard
I believe all three scenarios are valid and could easily be described as "service discovery". That's not going to help though! For my own sanity, I decided to try and come up with distinct names for these different types of discovery.
- Provider Discovery is the process of finding a service that can provide the desired capabilities.
- Service Identification is the process of getting an identifier for a service that will provide a certain type of service.
- Service resolution is the process of taking a service identifier and locating a specific implementation of that service.
I have no illusions that these definitions are "right" or that they will gain any traction, but it will help me have conversations about a topic that I think is very important.
Image Credits: Seal https://flic.kr/p/r4mqqE