I like microservices – I have used them on some big projects. But should Magento move to a microservice architecture?
Summary: I think Magento should become microservice capable, but not mandate them. I like how a recent tweet put it “Microservices have yielded simpler components – but more complicated systems”.
Before diving in, what is a microservice? In a nutshell microservices are small, granular services, maintainable by independent teams, that communicate using lightweight protocols (such as REST or JSON RPC). They are an evolution from Service Oriented Architectures (SOA) which generally have services communicating over a message bus. One illustrative strategy for Magento would be to have one web server for the presentation code, with separate servers running the cart code, the catalog code, and order management. There would no longer be one code base with all functionality included – it would be broken up into several programs to run independently.
Christian Münch posted a recent tweet pointing to a short summary of microservice business benefits. (You should read that post before continuing here as I refer to it frequently.) I generally agree with the thrust behind the article. However, what is slightly obscured, is that microservices are primarily useful when you have multiple teams working on the code base. Let’s run through some of the benefits listed.
Some more points from the referenced article. The first were a list of points around speed of delivery and business change.
The points around safety are also interesting:
So am I against microservices? Not at all. They are a great solution for scale and large teams. Am I trying to debunk the article? No, I get and understand the points and there is a merit of truth in them. But it’s wrong to think that microservices are the only solution. I can build you a microservice architecture that is less efficient, harder to test, less reliable, etc. Personally, the argument for microservices is primarily about the number of teams working on the project and the coordination required between them. They need smarter services to monitor and run them, but the coordination benefits can be real.
So what about Magento?
I don’t think Magento should mandate being broken into multiple microservices running separately. For smaller sites there is no benefit, only additional complexity (more moving parts to manage, more complex deployments, etc).
I do think Magento should be more modular, with better defined walls and doors to control the flow between modules. Service contracts (gee, I wonder where “service” came from in that name) are a part of this movement. But events and plugins are a part of the story as well. Maybe the current modules are not the right granularity for such walls; time will tell. For Magento, a part of the effort is evolution rather than revolution.
And once there are better lines drawn between sections of the code base, then the work being done in Magento around inbound calls onto services, and outbound calls to service interfaces (in progress) will make it easier to turn sections of the Magento code base into separate services, if that is what a particular project would benefit from. To achieve that however we need to get the well-defined APIs in place, make sure they are not too “chatty”, and make sure no calls occur between modules (and extensions) that bypass the APIs. Then those who want microservices can do so. This is an ongoing progression, but not the #1 priority as there are other activities with greater benefits to a broader spectrum of the Magento community.
If you like this post, you might also want to read my recent post on Headless Magento based on feedback from DevExchange at Imagine 2017. Headless Magento (direct API access) is very much aligned with microservices. It’s like not splitting the code base into separate processes, but making the different stages available directly so you can tap in where you need.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.