Nat  Grady

Nat Grady

1615547460

Modular Monolith vs Upfront Microservices

This article discusses the differences and similarities between Modular Monolith and Upfront microservices for microservice architecture.

Finding (micro)service boundaries is a challenge and become relatively easy as we learn more about the business domain. So, we wanted to try a modular monolith (modules within the microservice) approach.

As the module matures and we see it becoming the first-class microservice, we can take it out of the modular monolith very easily and with fewer efforts as the module is developed as a first-class concept with loose coupling with other modules.

This worked quite well in spring webflux and kotlin microservices as well as Scala Play microservices.

With modular monoliths, it is easier and cheaper to add and remove modules. This helps greatly to come up with correct boundaries for microservices as we go along delivering projects.

You can apply  Domain Driven Design patterns (tactical patterns) within each module. Each module can be thought of as a bounded context in Domain-Driven Design terms.

Each module should have its own DB migrations, and modules should not access other modules’ database tables directly.

One module should access other modules through controllers only (making in-process call instead of HTTP call). Keeping interaction at the controller level avoids one module depending on the domain layer of another module as Controller would return view models.

When we take out the module and make it a microservice, we will move in process API calls from one module to another and then to HTTP calls to move database tables for that module to the new microservice. Note that each module has its own set of database tables when the module is first created. We wanted to choose an approach so that we can have different modules or services in one place but not as a one monolith service, and so that we can easily extract them out if needed.

#microservice architecture #software engineering #modular monolith #microservices

What is GEEK

Buddha Community

Modular Monolith vs Upfront Microservices
Nat  Grady

Nat Grady

1615547460

Modular Monolith vs Upfront Microservices

This article discusses the differences and similarities between Modular Monolith and Upfront microservices for microservice architecture.

Finding (micro)service boundaries is a challenge and become relatively easy as we learn more about the business domain. So, we wanted to try a modular monolith (modules within the microservice) approach.

As the module matures and we see it becoming the first-class microservice, we can take it out of the modular monolith very easily and with fewer efforts as the module is developed as a first-class concept with loose coupling with other modules.

This worked quite well in spring webflux and kotlin microservices as well as Scala Play microservices.

With modular monoliths, it is easier and cheaper to add and remove modules. This helps greatly to come up with correct boundaries for microservices as we go along delivering projects.

You can apply  Domain Driven Design patterns (tactical patterns) within each module. Each module can be thought of as a bounded context in Domain-Driven Design terms.

Each module should have its own DB migrations, and modules should not access other modules’ database tables directly.

One module should access other modules through controllers only (making in-process call instead of HTTP call). Keeping interaction at the controller level avoids one module depending on the domain layer of another module as Controller would return view models.

When we take out the module and make it a microservice, we will move in process API calls from one module to another and then to HTTP calls to move database tables for that module to the new microservice. Note that each module has its own set of database tables when the module is first created. We wanted to choose an approach so that we can have different modules or services in one place but not as a one monolith service, and so that we can easily extract them out if needed.

#microservice architecture #software engineering #modular monolith #microservices

Autumn  Blick

Autumn Blick

1595342460

Microservices and Data Management - DZone Microservices

Introduction

For pure frontend developers who doesn’t have much exposure to backend or middleware technology, microservices are a vague thing. They might have high-level introduction. So, let us have some deep understanding of what microservices are, and how it is different from monolithic application data management.

Monolithic and Microservice

In a monolithic application, all the stakeholders like all the business logic, routing features, middle-wares and Database access code get used to implement all the functionalities of the application. It is basically a single unit application. It has a lot of challenges in terms of scalability and agility. On the other side, in a microservice, all the business logic, routing features, middle-wares, and database access code get used to implement a single functionality of the application. We break down the functionalities to the core level and then connect to related services. So, the functionalities are actually dependent on related services only and does not get affected if there is an issue with other services. This helps to make the application agile, flexible, and highly scalable.

Monolithic architecture

Microservices Architecture

Why Microservices

Independent DB for the Services

The very first important thing associated with microservices is that each functionality requires its own database and never connects to the database of other services. In a monolithic service, since you have a single database. if something goes wrong with it then the whole application gets crashed. But in microservice, since we have an independent database for each service, in case of any problem with any particular database, it certainly does not affect other services and your application does not crash as a whole.

No Dependency on Schema

We have many services in our application and each service requires its own database. Hence, each database has its own schema or structure. But, if any service is connected to other service and shares the data and during development, the source database changes its schema and does not update the dependent services, then the service will not function correctly and may crash. So, there should be no dependency on databases.

Performance

Depending on the nature of service, we choose the appropriate type of DB. Some services are more efficient in specific database. So, creating a single database for all the services in the application might affect performance. In Microservice, since we have individual DB for each of the service, it is quite flexible, independent, and functions efficiently.

Data Management

Unlike the monolithic approach, in microservice, each functionality or service connects to its own database and never gets connected to other database. So, the big question arises of how we communicate between two services. It is quite generic in an application that we require to get some information based on the combination of many service outputs. But as a thumb rule, services dont communicate. Then what is the solution to this issue? Let us see, how data communicates between the services.

#data management #monolith vs microservice #microservices benefits #microservices communication #microservices archiecture

Autumn  Blick

Autumn Blick

1595338835

Microservices and Data Management - DZone Microservices

Introduction

For pure frontend developers who doesn’t have much exposure to backend or middleware technology, microservices are a vague thing. They might have high-level introduction. So, let us have some deep understanding of what microservices are, and how it is different from monolithic application data management.

Monolithic and Microservice

In a monolithic application, all the stakeholders like all the business logic, routing features, middle-wares and Database access code get used to implement all the functionalities of the application. It is basically a single unit application. It has a lot of challenges in terms of scalability and agility. On the other side, in a microservice, all the business logic, routing features, middle-wares, and database access code get used to implement a single functionality of the application. We break down the functionalities to the core level and then connect to related services. So, the functionalities are actually dependent on related services only and does not get affected if there is an issue with other services. This helps to make the application agile, flexible, and highly scalable.

Monolithic architecture

Microservices Architecture

Why Microservices

Independent DB for the Services

The very first important thing associated with microservices is that each functionality requires its own database and never connects to the database of other services. In a monolithic service, since you have a single database. if something goes wrong with it then the whole application gets crashed. But in microservice, since we have an independent database for each service, in case of any problem with any particular database, it certainly does not affect other services and your application does not crash as a whole.

No Dependency on Schema

We have many services in our application and each service requires its own database. Hence, each database has its own schema or structure. But, if any service is connected to other service and shares the data and during development, the source database changes its schema and does not update the dependent services, then the service will not function correctly and may crash. So, there should be no dependency on databases.

Performance

Depending on the nature of service, we choose the appropriate type of DB. Some services are more efficient in specific database. So, creating a single database for all the services in the application might affect performance. In Microservice, since we have individual DB for each of the service, it is quite flexible, independent, and functions efficiently.

Data Management

Unlike the monolithic approach, in microservice, each functionality or service connects to its own database and never gets connected to other database. So, the big question arises of how we communicate between two services. It is quite generic in an application that we require to get some information based on the combination of many service outputs. But as a thumb rule, services dont communicate. Then what is the solution to this issue? Let us see, how data communicates between the services.

#data management #monolith vs microservice #microservices benefits #microservices communication #microservices archiecture

Autumn  Blick

Autumn Blick

1595335187

Microservices and Data Management - DZone Microservices

Introduction

For pure frontend developers who doesn’t have much exposure to backend or middleware technology, microservices are a vague thing. They might have high-level introduction. So, let us have some deep understanding of what microservices are, and how it is different from monolithic application data management.

Monolithic and Microservice

In a monolithic application, all the stakeholders like all the business logic, routing features, middle-wares and Database access code get used to implement all the functionalities of the application. It is basically a single unit application. It has a lot of challenges in terms of scalability and agility. On the other side, in a microservice, all the business logic, routing features, middle-wares, and database access code get used to implement a single functionality of the application. We break down the functionalities to the core level and then connect to related services. So, the functionalities are actually dependent on related services only and does not get affected if there is an issue with other services. This helps to make the application agile, flexible, and highly scalable.

Monolithic architecture

Microservices Architecture

Why Microservices

Independent DB for the Services

The very first important thing associated with microservices is that each functionality requires its own database and never connects to the database of other services. In a monolithic service, since you have a single database. if something goes wrong with it then the whole application gets crashed. But in microservice, since we have an independent database for each service, in case of any problem with any particular database, it certainly does not affect other services and your application does not crash as a whole.

No Dependency on Schema

We have many services in our application and each service requires its own database. Hence, each database has its own schema or structure. But, if any service is connected to other service and shares the data and during development, the source database changes its schema and does not update the dependent services, then the service will not function correctly and may crash. So, there should be no dependency on databases.

Performance

Depending on the nature of service, we choose the appropriate type of DB. Some services are more efficient in specific database. So, creating a single database for all the services in the application might affect performance. In Microservice, since we have individual DB for each of the service, it is quite flexible, independent, and functions efficiently.

Data Management

Unlike the monolithic approach, in microservice, each functionality or service connects to its own database and never gets connected to other database. So, the big question arises of how we communicate between two services. It is quite generic in an application that we require to get some information based on the combination of many service outputs. But as a thumb rule, services dont communicate. Then what is the solution to this issue? Let us see, how data communicates between the services.

#data management #monolith vs microservice #microservices benefits #microservices communication #microservices archiecture

Why Transition From Monolith to Microservices?

**Microservices architecture **is a way of creating applications through loosely coupling services. Every service represents a system component that can be created and maintained separately, executing an independent business goal.

Microservices are basically small services that work independently as part of a more complex system. They are easy to manage, portable, and created in order to accomplish the business objectives of the application. They can be developed with the use of different programming languages, like Node.js, PHP, Python, Java, etc.

#knowledge #microservices #monolith architecture #monolith vs. microservices