What is the added value of Service Discovery in SOA for this project?

Question

We are retrofitting an architecture on a fragmented landscape of about 9 software products. These products are all related to a social/community platform. These software products, consisting of webapps, webservices and smartphone apps, were developed by students with no adherence to any architecture. The apps themselves were developed with a certain architecture, but no system-wide architectures have been considered or adhered to. It is therefore my group's responsibility to glue everything together so these software products can communicate together.

I've been thinking of a service-oriented architecture because I like the idea of being able to plug in services and because a lot of the software products themselves can be called services in their own respect. However, the subject that really bugs me is the service discovery I see in every SOA text. I don't understand why I would need it when:

1. The information and service needs of every software product are clearly defined. They know which other products they need and what information they want.
2. There is no external/3rd-party service catalogue and there are no plans to use one.

To put it bluntly, why can't I hardcode needed services within the respective software products? Or even just make small database of servers and use a broker to orchestrate API calls and whatnot? Of course the issue of scalability comes to mind: "What if a new service is added? Are you going to edit all the source code?" No, just the ones that need the new service. "What if all products need the new service?" Well, then we add it in a small development effort.

Transparency might also be affected: "What if we want to know the full service description of a service, and the calls we can make against its API?" We just look at the documentation then.

I'm having trouble with understanding the necessity in this context. I'm also nervous that I can't coin it as a true SOA if there is no such thing as service discovery or descriptions. Can someone explain the potential of service discovery in this project?

Answer 1

If all of your software projects are internal to your organization and the interface boundaries are well-designed and fully documented, then you may not need Service Discovery at all.

But if you publish a public API that other organizations depend on for the proper functioning of their software, then Service Discovery might become more important. A big part of Service-Oriented Architecture is allowing companies to collaborate in a data-oriented way, and Service Discovery helps them do that.

The term "Service-Oriented Architecture" is associated with certain "programming in the large" things like message queues and service buses. If you don't need any of these things, then I would question whether a full-blown SOA architecture is even suitable for your needs. You can have the benefits of loose coupling and modularity without deploying an entire SOA architecture, perhaps by taking advantage of microservices.