MACH: The future of IT architecture


A brief overview of the MACH movement, its main benefits and its likely future impact on CTOs 

Software engineering expectations have transformed over the past decade, thanks to the DevOps movement and the rise of cloud technologies and their now ubiquitous providers. The large-scale shift to remote work has made it even more important to reduce dependencies between engineers, which have always been the main reason for delays in software projects.

According to a new study, tech leaders see MACH (microservices-based, API-first, cloud-native SaaS and headless) as the “future of architecture”, with 80% planning to increase their investments in it over the next year and beyond. Let’s look at the benefits of the IT architecture principles of microservices, API-first, cloud-Native SaaS and headless:


Microservices architecture assumes that multiple smaller pieces of software can create the same value as one big monolithic piece of software. But the advantage of switching over to microservices is the decoupling of engineering work. Now, each engineer can focus on their own small piece of software instead of spending huge amounts of time trying to coordinate on a big software project. 

DoiT International is fully remote, so breaking our larger software projects into smaller pieces that can be assigned to teams with minimum coordination has obvious benefits and advantages. This is no easy task, but with the expectation of software value to be delivered faster than ever before, there is no other way.


API-first software architecture is almost mandatory when moving to microservices. Again, it allows small or even tiny teams of engineers to create pieces of software that can fit together fit to create a bigger whole by enabling their peers to consume the work in a decoupled consumption-like model. For non-software engineers, this can be explained using a hose analogy: A car engine has a hole where the fuel needs to go, and it doesn’t matter which kind of oil tank the car has as long as the tube between the oil tank and the engine diameter fits each one. That is a simple way to explain APIs: The oil tank is made by one factory, the engine by another, and the only coordination required is to document the diameter of the tube.

Cloud-native Software-as-a-Service

Cloud-native Software-as-a-Service (Saas) is another exceptionally important pillar in the new remote-only software engineering world. The move to remote engineering has forced companies to rethink “closed cage” data centers that could only be accessed from the office and instead allow software engineers to work from anywhere. Once this line was crossed, more and more companies that need to create software realized they no longer needed to maintain their own data centers and could rely instead on a cloud provider to maintain the physical infrastructure for them. 

In the same way, a factory doesn’t need to create its own electricity and can usually buy it from an electrical company. The accelerated move to the cloud enabled cloud providers to hire more people and create more services in a very short time. And, as more IT technologies now have an -as-a-service version in the cloud, engineers can experiment with technologies much faster and more cheaply than before. 

Previously, an engineer who wanted to test-run some new database had to get one person to buy the hardware, another to install the hardware in the data center and yet another to install the operating system and database on that hardware. Only after he received access instructions could he test out this new database. Today, this can all be done with the click of a button. The cloud has evolved from delivering infrastructure to delivering any technology at the click of a button, enabling ever greater flexibility to pick and choose the best tools to fit engineering requirements.


Headless fits extremely well with microservices and API-first. Many modern software offers are multiheaded because of API-first backends. While the more complicated business logic can run in the cloud, the data that it consumes or generates is available via APIs. This enables other decoupled teams of engineers to create experiences for the web, for mobile or for desktop separately from each other and with limited and minimal coordination across the frontend and backend teams. 

The abundance of cloud-native SaaS offers or “technologies-as-a-service” allows these frontend experiences to be supplemented by cloud-provider managed off-the-shelf technologies.

The future of MACH 

DoiT is a cloud-first and remote-only company. All our infrastructure is in the cloud, and our only physical infrastructure is the laptops our engineers use to leverage cloud technologies and create small pieces of software that fit into the big product of the company. 

Several years ago, when our product was much smaller, it relied heavily on cloud provider SaaS technologies to enable us to deliver huge value to our customers with a very small team of engineers in a very short time. As the company and our engineering expanded, it made sense to create additional services as small microservices that integrate into the larger product – instead of coupling everything together into one huge monolithic mess.

As we progress with engineering increasingly valuable experiences for our customers, it makes sense to double down on MACH and constantly remind engineers why it is so important for us as a business. Someone will always suggest moving a step or two back, by adopting yet another technology we must maintain ourselves, or by creating yet another service that has tight-coupling across the front and back with no APIs. These moves can only slow us down, so we would prefer to keep our releases small, frequent and valuable and avoid becoming bogged down by non-MACH ideas and concepts.

Our company is not a member of the MACH alliance right now, but we welcome the effort. Making these concepts more popular and accepted in the industry can only lead to a much better software experience for everyone.

Subscribe to updates, news and more.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related blogs