Should I be moving to a microservices based architecture?

Question

I am working on a monolith system. All of it's code is in one repository (Web API and background workers). System is written in Nodejs and MongoDB (Mongoose) is used as a data store. My goal is to set a new path how project should evolve. At first I was wondering if I could move towards microservices based architecture.

Monolith architecture creates some problems:

• If my background workers needs to scale. I have to deploy all the project to the server despite only using a small fraction of it.
• All system must be redeployed when code changes. What if payment processor calls webhook while system is being redeployed?

Using microsevices advantages are quite obvious:

• Smaller code base for individual microservice. Easier to reason about it.
• Ability to select programming tools best for particular use case.
• Easier to scale.

Looking at the current code I noticed that Mongoose ODM (Object Document Mapper) models are used across all the project to create, query and update models in database. As a principle of a good programming all such interactions with database should be abstracted. Business logic should not leak into other system layers. I could do that by introducing REPOSITORY pattern (Domain Driven Design). While code is still being shared across web api and it's background workers it is not a hard task to do.

If i decide to extract repositories into standalone microservices than all bunch of problems arise:

• Some sort of query language must be introduced to accommodate complex search queries.
• Interface must provide a way to iterate over search results (cursor based navigation) without returning all database documents over network.

Since project is in it's early stage and I am the only developer, going to microservices based architecture seems like an overkill. Maybe there are other approaches I should consider?

Extracting business logic and interaction with database into separate repository and sharing among services to avoid complex communication protocols between services?

Answer 1

Based on my experience with working in Microservices for last few years, it seems like an overkill in current scenario but pays off in long-term.

Based on the information stated above, my thoughts are:

• Code Structure - Microservices Architecture (MSA) applying in above context means not separating DAO, Business Logic etc. rather is more on the designing system as per business functions. For example, if it is an eCommerce application, then you can shipping, cart, search as separate services, which can further be divided into smaller services. Read it more about domain-driven design here.
• Deployment Unit - Keeping microservices apps as an independent deployment unit is a key principle. Hence, keep a vertical slice of the application and package them as Docker Image with Application Code, App Server (if any), Database and OS (Linux etc.)

• Communication - With MSA, communication between services become a key and hence general practice is to remain with the message-oriented approach for communication (read about the reactive system and reactive programming for more insight).

• PaaS Solution - There are multiple PaaS solutions available, which you can apply so that you don't need to worry about all the other aspects like container management, container orchestration, auto-scaling, configuration management, log management and monitoring etc. See following PaaS solutions:

• https://www.nanoscale.io/ by TIBCO

• https://fabric8.io/ - by RedHat

• https://openshift.io - by RedHat

• Cloud Vendor Platforms - AWS, Azure & Google Cloud all of them have specific support for Microservices App from the deployment perspective, which we can use as an alternative solution if you don't want to deploy PaaS solution in your organization.

Hope these pointers will have in understanding the overall landscape so that you can structure your architecture for future need.