A closer look at how Drupal adopts the 4 MACH principles

If we take a step back and look at the modular architecture of Drupal we see that indeed yes Drupal core does a lot of things and could be deemed monolithic. However, Drupal's core is getting smaller and smaller, moving more and more core modules to contrib modules. In Drupal 11 this trend will even accelerate.

While core still does a lot, it is this interdependency of data, users, and content that allows building the more ambitious multi-languages, countries, markets, channels, roles, sites... with multiple integrations for multiple personas experiences. On the other hand, there are enough examples of DIY microservice hell, where customers need to hire people to maintain all these microservices, do release management, DevOps, and maintain knowledge of all the separate services. A lot of risks are introduced for the sake of speed. That's not acceptable for every organization. Monoliths are often called a big ball of mud, microservice can easily become a big distributed ball of mud.

Having a standard in Drupal on how modules interact with core creates stability and allows the 1M strong Drupal community to maintain the 45k module ecosystem of functionality. So a bit of packaging and creating valuable dependencies out of the box has a lot of value. As a customer, having the possibility to move your project to another integrator gives you lots of freedom too. For developers, knowing there are standards the framework brings, allows them to easily take over projects, so less need for heroes saving the day. This re-usability is the foundation of contribution. It's also the foundation of industrialisation in an agency, being able to implement all projects the same way allows for maximum maintainability.

Drupal moving to automatic updates is a good thing. Maintaining Drupal has never been easier either. Yes, there is a certain maintenance cost to Drupal and there is a level of complexity and dependency present. On the other hand, this is needed to build ambitious digital experiences and give all that no-code/low-code power to the site builder while maintaining developer freedom.

Finally Drupal is based on Symfony which gives you the possibility to develop custom parts in the application by overriding existing code. This increases flexibility where needed.

I believe Drupal is striking a great balance between microservice and monolith. Core brings value in the sense that a lot of choices have been made through 20 years of evolution. Being microservice or not is not the question. It's how you balance and create value with it, that's the question.

Drupal is not cloud-native but companies like acquia.com, pantheon.io, platform.sh, and dropsolid.io help you to run Drupal in the cloud. Drupal runs events like the Olympics which means it's pretty scalable. Here too, is cloud-native a selling point? No, it's how you derive value from the cloud. Use the cloud where needed. Drupal being open means you can also run Drupal on your own premise if you want to guarantee data sovereignty. Companies like amazee.io and dropsolid.io help you do this.

Run the parts of your stack in the cloud or use cloud services where it makes sense. The cloud can also lock you in and make your costs spiral out of control. Keeping a sense of openness and ability to move your stack keeps a healthy pressure on cloud suppliers and service providers to keep costs under control.

Here too, to cloud or not to cloud is not the question. Use it where it creates value for you while maintaining your sovereignty.