CODEWITHSUNDEEP
design-patternsarchitecturemicroservices
Alok Kumar Singh
Alok Kumar Singh

Reputation: 2569

Ideas on breaking a monoliths admin dashboard?

A monolith is being broken into many microservices based on domain/business functionalities.

This monolith has an admin dashboard which is used to update the configurations and feature flags in the monolith. By configurations I mean domain level configurations which require frequent updates from admin console.

Problem is how do we move these admin controlled configurations out of monolith database.

Two school of thought:

  1. Centralized Configuration: We make a central configuration service to keep all the configuration and feature data. It has an API layer which integrates with existing admin UI. Admin UI calls these API to update data. Other microservices are eventually synced from here using events. Pros: easier management Cons: data outside service boundary, data still coupled like in monolith.

  2. We split the configuration to be maintained by each microservice, based on the configuration and where it should belong. And data from these microservices flows to the central service by events. Admin UI calls this central service. Pros: microservices own their configs Cons: difficult to maintain

Let me know how would you tackle this problem?

Upvotes: 1

Views: 479

Answers (2)

Matt Timmermans
Matt Timmermans

Reputation: 59303

In the best expression of the Single Responsibility Principle, each service would maintain its own configuration and provide for its own configurability through the admin dashboard.

"Providing for its own configurability" would be accomplished using inversion of control. Each service would register navigation information and callback endpoints with the dashboard service, probably at deployment time, and then the admin dashboard would call these entry points at run time to generate a dashboard with components aggregated from all those services.

The callback endpoints could provide schema+CRUD operations, allowing the dashboard to synthesize its own UI, or HTML widgets if the services need custom UI for their config.

Upvotes: 0

Gerd
Gerd

Reputation: 2813

You have already pointed out the pros and cons for each approach.

However, also keep in mind that the goal for microservices architectures is that you should be able to deliver and deploy the services independently of each other. Also, a development team should be able to implement a service independently of the other services.

So could a microservice eventually add or remove some config settings in the future? If this happens, you would have to change both that service and also the config service in scenario 1, but not in scenario 2.

If on the other hand the settings themselves never change and you only change their content during operation, you could decide to accept the coupling (even though this is not a pure microservice architecture any more).

BTW: Spring has a Spring Cloud Config Service for managing properties for distributed systems (other article here). This seems to be mainly for keeping configs for different environments (such as development, test, production), but might be interesting for you to check.

Upvotes: 0

Related Questions