Should I Microkernel or Microservice my legacy ERP?

Question

I have been working on an n-tier monolith application for a couple of years, and want to build a plan to transform this big ball of mud to a more maintainable system.

I came across Software Architecture Patterns by Mark Richards, where he explains different software architecture patterns, including Microkernel and Microservices.

What makes Microservices different than Microkernel? if we are considering an ERP system.

Can we consider Plugins in the MK model similar to Microservices? and the Core Module in my MK Model to be the glass-pane and authentication services?

My plan was to rip out modules sharing same domain from my legacy system and place it in self-contained units. given that the original system relies heavily on persistence on a RDBMS, and has most of the business logic processed through stored procedures.

Answer 1

There are certainly similarities between a plugin architecture and a service architecture. Both approaches can be used to modularize an application. But there are fundamental differences:

• With a plugin architecture, everything typically runs in the same process. And the kernel/host application orchestrates how and if the plugins can communicate. Typically a common data model is exposed by this kernel. Because they share data, all plugins must use a common runtime, e.g. JVM.

• A service architecture is distributed. Services can be deployed independently. Sometimes there is a common component such as a message bus but this is not necessary: the services can in principle talk to each other freely. There is no common component that orchestrates and organizes the data flow between these services, though there might be a service that functions as an interface to the external world. The messages between services have to use some kind of compatible format, but the data model within each service is not typically shared. Since services are separate processes (possibly on separate servers) they do not have to share a common runtime, and can use arbitrary technologies.

The main selling points of service architectures are independent deployability and independent technology choices, which potentially makes them more suitable when separate teams have to collaborate or when scalability is important. However, developing and deploying a distributed system also has a lot of inherent complexity, so they are not a good default choice.

If you are only looking for more modularity, then extracting plugins or libraries from your main project already provides most of that value. By staying within the same language you also reap some benefits, such as better type checking.