Registries for monoliths

Publish date:

Regardless of microservices or monoliths, APIs are crucial today.

Last year, I wrote an article for the Oracle Technology Network about the relationship between an API gateway and a microservice registry (the article can be found here). While the capability the article describes in terms of bringing a microservice registry and API platform has not yet arrived, it is our understanding that such integration is on the roadmap (the usual Oracle disclaimers obviously apply). I would imagine that such a feature will become available as Oracle’s cloud native offerings (such as Kubernetes Cloud – here) gain traction. But don’t assume that it will only work for the cloud native service. If Oracle’s gateway deployment strategy is anything to go by, any such feature will also be very platform agnostic. While Oracle has not yet delivered this capability, building your own custom capability using the API platform’s SDK is possible without too much difficulty.

This is fabulous if you’re fortunate to be working on a new IT landscape that is adopting all the technologies we associate with microservice solutions, but a great many organizations don’t have that luxury.  Assuming that, regardless of microservices or monoliths, APIs are crucial today, does it make sense in a non-microservice environment to use a registry in a more monolith environment and therefore also consider bringing both the API and registry capabilities together?

If we step back and look at microservices as a set of patterns and an architectural style rather than tools and technologies, we can more easily focus on the challenges a registry can help address. Referring to the summary definition from Martin Fowler’s et al. book “Patterns of Enterprise Architecture” (here), the entry makes reference to the ability to locate an object. If you search further, you’ll read about the abstraction and decoupling.  By abstracting, we can address things such as scaling through distribution and optimizing the scaling by tuning different parts of the deployment to meet different needs. For example, if a solution follows a classic three-tier architecture, the top tier is in a J2EE-based solution just WAR files containing content and calls to the mid-tier. The mid-tier may well need to use Coherence and have its data backed off to the database. In this model, you could use a registry to find you mid-tier, which may reside on WebLogic, for example. But, because of its simplicity, your front tier could be hosted using Apache Tomcat and fronted by load balancers.  The net result is that with WLS just supporting the more complex mid-tier and using Coherence, we’ve driven up the return on WLS investment because we’re focusing workload on its best value. The registry, in this case, could be realized by DNS, but it wouldn’t be as flexible or reactive as using a proper registry such as Etcd, Zookeeper, etc.

The goal to distribute layers in order to gain scale and resilience is far from new. J2EE provided local and remote interfaces for beans. With SOA came the UDDI (Universal Description, Discovery, and Integration) standards.  Going back a bit further, CORBA (Common Object Request Broker Architecture) had the concept of Trader Services (here).

As you can see, the arguments for a registry exist. Because endpoints are exposed through published APIs, the case for linking the two components must also be valid. For this reason, if an API layer is used to decouple different components of a solution, the registry can be stitched in when more dynamic routing is needed because the policies and API routing should remain unaffected.

Of course, there will always be use cases where performance is so critical that every possible extraneous fraction of a second must be shaved off. In such cases, using an API layer with a registry will simply not help. Some might argue that such an approach will just slow down the solution unnecessarily, but how does it stack up against ensuring decoupling and the ability to migrate to a purer realization of microservices?  When it comes to the perennial question of how coarse or fine-grained the separated pieces should be, I suggest asking two questions:

  • Do I spend more or look like I might spend more time passing through the API and registry than I do performing business logic? If so, the solution is probably too fine-grained.
  • Do I use the API and registry tier so little that the cost of deploying and maintaining these pieces doesn’t seem justified? If so, the chances are you’re too coarse-grained.

Of course, there will be occasions when these questions will point you the wrong way, but these should be edge cases.

To conclude, yes there are cases where the principles described in the original article are equally true for non-microservices environments, but the greatest benefit will be obtained in a microservice approach.

The author will be at Oracle Code London in May 2018. You can connect with him at the event or connect with him online.

Related Posts


A new approach for financial services

Elias Ghanem
Date icon January 5, 2021

In the ecosystem model, financial services will be embedded in customer journeys. While banks...


How to build an API economy for your enterprise

Ravikanth Ganta
Date icon December 7, 2020

Creating API economies at scale is a complex activity that requires careful planning, shifts...


Hitting home Runs: How to shift to B2D in the financial sector

Vincent Fokke
Date icon August 28, 2020

With open banking and the API economy driving the financial services industry today, banks...