Firebear Studio published an interesting blog on Magento and Microservices. You might like to go read it first at Microservices In eCommerce And Magento | FireBear Blog. I thought I would give a quick possible way forward for Magento to see what others think. (There is no commitment to do any of this at this stage, but hopefully it is clear that this is in line with current directions for the platform.)

I fundamentally agree with the blog above. If I put my perspective on it, if you are at say ebay.com scale, techniques like microservices are important. It is hard to get large teams to coordinate on releases and it slows down progress. Microservices also allow you to scale one area that is running slow, and so get better hardware utilization (and better isolation to protect the performance of critical areas, like checkout). On the other hand, if you are small, the added complexity is not worth the pain (the negatives dominate).

I will however add, at another level microservices are not that different to one code base. Microservices must still have stable external APIs, even across releases. Both approaches need good discipline around deployments to make sure that changing one part of the overall system does not affect another part.

Microservices also allow you to pick different programming languages for different services. I must admit I find this a little less compelling – most organizations prefer a degree of uniformity across the platform. Microservices are however more important as your code base grows in terms of development speed for languages such as Java and C++ where you have a compile phase. If you have a monolithic code base, you need to get everything compiled and running locally. Microservices gives you more development flexibility – you only have to build and run a subset of the whole system during development. From my personal experiences, this is actually the main benefit.

So is it possible for one platform to both be microservice friendly and run as a single service for simplified smaller deployments? I believe “yes”. It may not be worth the effort, but yes it is technically possible.

How? It all comes down to the coupling between modules and the granularity of calls. One of the issues with microservices is the cost of doing a call between services. When the code is a single application, function calls are cheap. When they are microservices doing a REST call or similar, calls are expensive.

Enter Service Contracts. Magento 2 is moving towards getting more cross module calls using service contracts. If we can get more modules (or even groups of modules) communicating in this way, then the code can be split to replace the service contract service call with REST bindings (without change to the code). Thus code loaded into the same server does direct function calls; code loaded onto separate servers does REST calls. And without any change to the application logic.

Introducing service contracts does not solve all problems however. For example, if lots of little calls to a service contact are performed, the performance may not be satisfactory for a microservice architecture.

As well as the functional split between modules, the same logic applies for between layers. That is, if the presentation layer can talk to the business layer 100% using service contracts, then the presentation code can be run in a separate server to the backend code, again using REST or similar calls between the units of code. This could allow an organization to separate UI teams from business logic teams for example.

Is Magento going to split in this way? For now there are no concrete plans for this. Service contracts are useful in their own rights for more modular code. It is not yet clear the granularity of calls across the service contract boundaries and the overall impact on performance. There are also other challenges of event observers, plugins, and so on that assume code is all running together. So for now I am content (within the core product) to push forward on general code modularity and incremental improvement over up-coming releases.

Is it mandatory that Magento move to microservices? I don’t think so. The code base is not so large that there is a compelling reason to do this and impose that burden on developers. The code base is also pretty modular already, allowing developers to focus on subsets of the code. Back inside ebay.com microservices were clearly the way to go with thousands of developers.

But it is certainly interesting to see how people are thinking about pushing the curve. It would be great if the one code base could successfully support both models, without too many sacrifices.