Should Magento Go Microservices?

[akent99]

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.

• You can deploy parts of the code base separately. The main benefit here is around coordination. One team can ship without waiting for other teams. There is, however, additional complexity here too – you need forward and backwards compatibility between the independent services because you do not atomically deploy changes across all services.
• The article mentioned “[the] approach is ideal for big systems… Big is not referring to the size of our system, rather it is referring to the capability of scaling”. I understand the point, but it does depend on the application. For example, microservices allow you to scale one part of the code base (one microservice) faster, independent to other parts of the code base. Why is this better than horizontally scaling the same code base? Isolation. With separate services, you can limit the impact of overloading one service from others. For example, Magento EE allows you to split the checkout database tables from the catalog database tables, so you can protect checkout performance from bots hitting product pages (and protect browsing from the write intensive checkout process). Is Magento EE microservice based? No, but it achieved the same goal.
• “Microservices are small in size.” A common metric is “two pizza teams” – you should not need more people than can be fed by two pizzas on the team looking after a microservice. You can have smaller teams, but don’t go crazy small (without reason).

Some more points from the referenced article. The first were a list of points around speed of delivery and business change.

• Agility (through frequent deployments) for organizations is relevant if you have multiple teams, but its not exclusive to microservices. You can deploy Magento more frequently if you have the right deployment pipeline in place.
• Composability is not microservice specific – you can do it with a well-structured code base and strict coding rules and barriers.
• Comprehensibility is the same as composability. Good software architecture can achieve this without microservices.
• Independent deployability is a multi-team coordination issue, which can be made more complex by too many microservices, as there is a version dependency graph that you have to get right in your roll outs.
• Organizational alignment of services to teams, which implies that you have multiple teams; this I agree with.
• Polyglotism of different tools for different parts of the system is a valid concern, but can also lead to business exposure as you may end up with a small number of Scala developers for a particular service – losing staff is more impactful, especially if you need specialist skills to replace them with.

The points around safety are also interesting:

• Efficiency is not a question of microservices – it is almost the opposite given they they introduce additional network hops. A microservice is not automatically more efficient than libraries of code linked into a single code base.
• Independent manageability is true if that part of the service can go down but the site as a whole keeps running. But it’s usually a question of scale. If you are doing offline processing of user events, then that can be deferred.
• Replaceability leading to less technical debt can occur, but you can fix technical debt in a monolithic code base as well.
• Strong resilience and higher availability can occur due to isolation of services (if someone hits one part of the user experience hard, having other parts of the system on different servers reduces that risk).
• Better runtime scalability is more about isolation – you can scale multiple copies of one program more easily when it is a decided number of servers.
• Testability is certainly possible for one library of code – microservices make testing operational performance of one section of code easier, but you can test without microservices.

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.