CODEWITHSUNDEEP
restdockercloudmicroservices
SerchRac
SerchRac

Reputation: 181

Architecture of microservices from a business approach or technical?

Our team is trying to decouple a monolithic spring mvc administrative application (create, update, delete) and we want to adopt an architecture based on microservices.

After a bit of research, it seems the best is create microservices according to the problem that a specific part of the software solves, for example, Managing Clients.

The problem comes when we read some definitions, like the following from Wikipedia:

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

Based on that definition, my application is not monolithic, because it is perfectly separated in layers, but it is not found in a micro-services architecture either, which is confusing to me since in the web everything is about Monolithic vs. Microservices.

enter image description here

So, should the microservices architecture be designed based on the business problem it solves?

Should the microservices architecture be designed based on to the way in which the application is organized in layers?

Thanks.

Upvotes: 1

Views: 610

Answers (2)

Marcin Natanek
Marcin Natanek

Reputation: 576

From my experience, the most obvious advantage of a microservice is the ability to scale horizontally. User analysis takes to long? Just add 10 more workers. Done. Remove then. No need to add more RAM/CPU/whatever to your already costly server that runs your monolith.

Do not plan ahead an try to separate ClientManager microservice - this should be just a class.

You are thinking about migrating to microservices for a reason. Something is using up too much resources. Find the most problematic process that slows everything down, and create microservice for it. It can be for example report generation, user creation, data agregation. Start with planning the API. It will state clearly, what are responsibilities it will have and how much resources it will use. When you know what it should do, name it properly.

Agile software methodologies are your greatest friend in this process. Take the processes one by one. Experiment, iterate and evaluate. With time, it will be obvious how the microservices should do.

There is also a hot topic on how to organize code with microservices - I lean towards a monorepo - a single repository with all the code.

  • Pros: One pull request for many services, easy utils sharing, common dependencies, common deployment procedure and easier automation.
  • Cons: You can easily break the API contract and do too much work within one microservice (meaning, it can take other services responsiblity.)

Upvotes: 0

Timir
Timir

Reputation: 1425

I like to view each microservice as self contained smaller monoliths. When you're forcing yourself to split up your legacy application to, um, smaller monoliths, you'll find:

  1. 60% of your code is scaffolding and will need to be repeated across multiple services.

  2. It's easier to split things (and maintain them that way) if you've established a what-goes-where rule upfront.

The most common approach is to split the application by functionality area. So to answer your question, I'd agree more with the image at the top-right, assuming you intended to show multiple containers there.

And about #1 above, there's often a whole bunch of scaffolding modules that you can avoid writing by hand after all.

Upvotes: 1

Related Questions