MACH – OPC

Modularization of Applications with Microservices means when you take a system and you break it up into smaller units of development. To understand how microservices are different to the way we used to develop code, we are going to talk about two concepts and that’s loose coupling and tight coupling.
A good example of a tightly coupled system is a mobile phone. If you want to charge the battery in a mobile phone, you have to plug the whole phone into a larger. If you wanted to replace the camera, if you wanted a better processor or a better screen, you’d actually have to replace the phone with a new phone with those components in it because they saw tightly coupled together.

And in some ways, this is very similar to software.
So previously, we would build applications from blocks of code and libraries, and to build an application, what you’d have to do is take the interfaces of each of these blocks, each of these libraries and glue them together with another layer of code.
If you wanted to make changes or add new features, you’d have to start pulling the blocks apart from the application and reinserting them and re-gluing them together.

This is because you start to create dependencies between the blocks because of the glue code.

In fact, the whole application starts to build dependencies across its entire architecture and this type of development, where you are fusing the blocks together creates tight coupling.
So with tightly coupled development it becomes slower and less agile.

Microservices repairs software components and libraries with services, which are independent and loosely coupled.
You can think of Lego bricks as very loosely coupled because you can assemble them into lots of different structures without creating any real dependencies on the bricks themselves, and microservices connect together using an API web service.

This gives you a common standard so you can connect them together to build a larger application.

Connecting components in this way creates very few dependencies, hence the components are loosely coupled.

Previously, when you architected applications and systems, data would be centralized into a large structured database. These large structured databases were designed to support all the data driven components in your system. This way of centralizing data also created tight coupling between the different data structures. One of the problems of that is some data structures. For instance, customer data may have very different views or requirements dependent on the context in which they’re used in the system. For example, the view for a customer looking at their personal data is very different to the view of a support operative looking at a customer record.
And if you have to make changes to a centralized data model to reflect these different views, you have to do a lot of testing to make sure you don’t break different parts of the system.

Often changes made in a centralized database can lead to risky, large scale migration processes, due to the widespread nature of those changes.

Microservices have a different approach: Microservices prefer to manage their own data.

This means you can design data structures specifically for that microservice without creating dependencies on other areas of the system. This has the advantage of allowing you to choose the best database for the job.
For instance, a high throughput content service may use a SQL database. Yet if you’re building something around social networking, perhaps a graph burst database may be better instead.
However, with this approach you do need to consider how to keep data consistent across all of these microservices.

Another important area that microservices improve is that of deployment. And at first you’d think that having lots and lots of small services would actually create a management overhead. However, the benefit of a microservice is that it’s very easy to automate its deployment and teams that develop microservices tend to use continuous integration and continuous development and automate as much as possible through infrastructure as code.

Be loosely coupled means that smaller changes and iterations can be made super quick, making microservice development much more agile.

The thing we really love about microservices is that they are business oriented.
When you design an application with microservices, Business-oriented Microservices you split it up in terms of its business capabilities. So each microservice actually takes hold of a business capability, such as an API for managing a basket. So splitting up the system in this way allows you to focus the development on adding business value.

It also means all that agility you get from using microservices is geared towards agility in the business itself.

• The most obvious one is the agility, which we just talked about.

• Another big benefit of microservices is that because they’re loosely coupled, you can get a lot of reuse across many different applications.

• And what developers love about developing microservices is it gives them the freedom to choose the technology they want to use.

• Microservices are independently scalable, which means you can scale the services that are getting the traffic. Means that your scaling is much more targeted than just scaling an entire application as you had to do with the monolith.

• The fact that microservices are independently releaseable, means you can be much more reactive to change.

• Building systems from microservices can make them much more fault tolerant as an outage from a small service has much less impact.

• Another big benefit of microservices is that you don’t have to build them all yourself. You can choose to buy business capability and then plug them into the rest of the architecture.

Code-first was how we used to build applications. It’s how we used to build applications in the beginning.
As the name suggests, you would start with the design and then the code of an application, and then consider the APIs at the end.

You would insert the APIs once you’d finish the core functionality in the application.
What you do is you build that core functionality out of modules of code that you glue together.
With code-first approaches, you tended to build monolithic applications that were really accessible through a UX and only had a minimal set of API coverage.

So code-first development can lead to lots of delays and lots of revisions as you start adding the interfaces and adding APIs and altering those APIs to really work with what the consumers need.

So to help explain this, let’s look at a really simple analogy:
Imagine you’re trying to build a highway that’s going to join up two cities, City A and City B.
Imagine that City A and City B are 1000 miles apart.
So in the code-first approach, you take a look at the map, you’d look to see where the obstacles are.

Where do you need a bridge?
Where do you need a tunnel?
Are there any obstacles you need to curve around?

You might look at something like the climate and see what materials you needed to use for the road. What’s the best tarmac to use, for instance.
We are not an experts in road construction, but imagine you’ve went through that process first.

You then get your teams together and then start building that road.
So now let’s imagine that road is now complete, and you release it into the general public, and everyone’s really excited of getting on this new highway.
What happens is a week later, you get inundated with news stories of people being stranded on the road, families being left without food and water 500 miles in the middle of this road.

And why is that?

It’s because you neglected to think about adding service stations.

And not only that, you get a political storm where Cities X, Y, and Z have not been connected to the road because you didn’t put that in the design.

You didn’t think that was necessary.

And the real reason why that happens is that you focused on building the core functionality of the road and not about the consumers of that road.
You haven’t thought of the road as a service. If you think about the highway as a service-first and then build the core functionality, you wouldn’t have had those problems.
And that’s what API-first tries to address.

What is API-first?
Let’s start with the standard definition of API-first.

API-first in development is where you consider your APIs as first class citizens.

And what you’re developing is developed with the angle of API consumption in mind. It means that all functionality is completely accessible through the API. There is complete API coverage. There’s not one piece of functionality that can’t be accessed through an API.

It also means there are no restrictions on using that API. There is no special SDK you you have to use so that you can get access to a particular piece of functionality.

So to try and help understand what that really means, we are going to answer three questions:

So why is API-first different to code-first?

As we outlined earlier, in code-first, you build your application, you build your core functionality and then you bolt on your APIs.
Whereas in API-first, you start by creating the APIs and after those APIs are created, you then start building the core functionality to support those APIs.

So what this means is that you start focusing on imagining your business in terms of consumable services, and you start thinking about the business problems you’re solving with your services.
This strategy helps you merge your business model with all the new exciting functionality and technology you’re building.

So, basically, the API-first approach thinks of the highway as a service, who is using it, and how it’s going to be used.

So what’s the difference between API-first and headless?

Headless technology is about creating a system that is completely independent from the implementation of its presentation and user experience using sets of APIs.

That sounds a lot like API-first, right?
But the real difference comes down to API coverage.

Delivering the user experience is only a fraction of the functionality of a system.
For instance, an e-commerce system is not just about delivering the experience but it’s also about delivering a brand’s business model. It’s about delivering business user processes and allowing you to connect to other systems in that ecosystem.

And that is why API coverage is so important.
Without great APIs, it’s impossible to integrate these systems together and give you the business user experience you need.
It’s entirely possible to have a headless system and it’s still not be API-first.

So what’s the difference between microservices and API-first?
We already know that microservices are essentially aware of building application APIs. It focuses on grouping APIs around functional demands.
It’s not necessarily about the API coverage. Therefore, again, you can have a system with a sets of microservices and it’s still not to be API-first.

API-first means you develop a system that delivers value to all the consumers of that system far more quickly and efficiently than just leaving your APIs as an afterthought.

The first dimension is about platform delivery, and this dimension describes how the software delivers its service. Does it deliver it as a multi-tenanted scalable service or does it deliver it as a managed service delivering instances?

The second dimension we are going to use is that of API coverage. As we are use the context of MACH Architecture, it’s important to understand how well it opens up the system using APIs. What’s really interesting is when you bring these two dimensions together, it forms four distinct quadrants and we’ve named these quadrants to help you understand what they really mean:

This is cloud enabled or a managed service with very little API coverage.
Towers are often created when you get those large monolithic on-premise systems being packaged wholesale and moved onto cloud instances.

Cloud Towers often have massive amounts of functions and features that they’ve developed over the years, but very few of them are available through APIs and web services.
Towers do take away the pain of managing your own infrastructure, but that does still come at a cost that you get with monoliths.
You still get protractive development time, softwares still require long complex and risky migrations.
Core changes require long release cycles, getting to high availability and resilience still requires a lot of investment, integration with other systems can be quite tricky because of the lack of APIs.

Towers might be very strong at delivering in one vertical channel, but they’re very weak when it comes to multichannel and omni-channel delivery.

These are multi-tenanted systems with a low API coverage.
Icebergs are little like Towers where they’re large monolithic systems that are very feature rich.
Unlike Towers, there’ll be architected to accommodate an entire customer base.
Where we’ve seen Icebergs arisen is from the older SaaS based platforms.

Those early cloud pioneers that’ve invested heavily in infrastructure and heavily in features, but that’s been at the expense of re-architecting their systems to really benefit from new cloud-based technologies and investing in increasing API development.

Icebergs will have large, scalable, distributed infrastructures, but the lack of API coverage comes at a cost.
Development still means that core changes require extensive development cycles.

The closed nature of Iceberg architectures means that developers can be quite difficult to find and quite expensive because often, they need to know proprietary languages or proprietary frameworks.
Although integrating with Icebergs can be quite challenging, what we’ve seen are large ecosystems developing on these Icebergs, partner start developing plugins and accelerators that work with these Icebergs and are delivered through marketplaces.

If multichannel is provided, it’s often limited, if delivered through small sets of APIs, delivering little tiny Iceberg peaks.

These are systems that are managed services but have a lot of API coverage.
Factories focus less on shared large distributed infrastructure and more on software architecture. They focus on delivering software as discrete components that are nicely wrapped in APIs.

This approach means that packages of that technology can be built on automated production lines that can churn out shrink, wrapped instances for each customer at super speed.

Factories often evolve from companies that have heavily invested in API development before moving to cloud or companies who take open source software and shrink-wrap them into managed services.

The API coverage of manufactured instances provides a great platform for developers for integration, but they still suffer from the downsides of managed services. The way that these packaged instances are deployed and managed may increase the costs of scaling, redundancy and resilience.
You won’t see the economies of scale you get with multi-tenanted platforms and upgrading to new versions on that production line may not be that simple and may require further development and further migration.

However, it’s significantly less than the cloud Towers.

Cloud Native is multi-tenanted with full API coverage often with an API first mindset, meaning that every platform interaction can be delivered through an API.

Cloud Native technologies have fully embraced the cloud at every level. They use large scale cloud infrastructures and processes to deliver multi-tenanted platforms. These technologies are designed to scale for all of their customer needs, not just the biggest customer, but all of their customers all at the same time.

With Cloud Native technologies, all customers get the same version of the platform. In fact, there’s only ever one version of the platform. There is a constant stream of new features and new functionalities all delivered through automated CI/CD processes, meaning that there is very little or zero downtime.

These systems are significantly faster to develop on and allow businesses to be nimble and agile and meet the demands of the future.

To understand why we need headless technology, let’s first look at some of the previous architectural patterns.

The way we used to design applications in the past, was that we used to separate them into tiers.
And you could actually visualize these tiers with something like a layered cake.

In the bottom tier, you would put your databases, your data repository.
In the middle tier, this would be where the business logic and the application logic would live
and the very top, you would have your presentation layer.

And this would be where you design and implement your user experience.
And this pattern was used in nearly every single monolithic system in the past, whether that was an ERP, a CMS,an e-commerce platform, a search engine, or even a recommendations engine, and the same pattern was used when you built a larger platform, based on these technologies.
In these systems each component was mapped into the layers using code to glue them together.

Components in one layer would have dependencies in components in other layers.
For instance, a page in the presentation layer, maybe generated by CMS, would have to be represented in the data layer.
And the business layer, would basically translate what a page is, and what it means, and how it could be used by the presentation layer.

Although, layers are really useful to help you understand the system at a logical level, in reality, those layers are fused together.

And ultimately, this is how we organize what we know today as the monolith.

One of the downsides of this approach is that, to implement the presentation layer, you’d have to use a specific set of technology.
And that technology was often prescribed by the technology in the layer below.

For instance, you may need to use ASP.NET with .NET architecture, because the layers are tightly coupled and the components are tightly coupled.

You often had to represent presentation elements within the database, so that the business layer could actually translate what those objects were to the presentation layer.
This makes it almost impossible to implement the presentation layer for different digital channels.

And this approach can lead to building monoliths for all your different digital channels that use different types of digital technology in the presentation layer.
Which as we know, leads to lots of duplication and lots of siloed content and data.

How does headless technology address this?

Well, first of all, we remove the presentation layer. In other words, we remove the head. This means that you do not need to implement any type of user experience. It means you do not need to implement an SDK or any other front end technology components for the technology to actually work.
To do this, headless systems replace the presentation layer with an API layer.

These APIs are web services, typically a REST service. In the future we may even see the technology of GraphQL, starting to replace REST interfaces.

As these APIs, or web services, there is not tight coupling between components or any dependencies on what the front end technology has to be. It can be an iOS native app, it could be an Android app. It could be web technology and using any of the new frameworks like React, or Vue, or even Svelte.
And it doesn’t have to stop there, you can implement voice interfaces, or interfaces into IoT devices.

Now there’s one subtle thing about real headless technology and it goes back to the layers discussion we had earlier. In the data layer for a headless system the data is only concerned with the business model or the application domain. It will not include any specific dependencies on how that needs to be presented, like we used to have to do in the old world.

And again, the business logic layer does not have any dependencies on what the presentation layer is. It’s this reason why headless technologies can not only be used for different devices, different front-end technologies, but they can also be used in lots of different digital channels, in different digital contexts.
For instance, they could be used in store for different in-store devices and different install applications, they could be used in customer support, or even a grill.

Headless technology is more than just removing the presentation layer. It’s about creating a system that is completely independent of how you have to implement the presentation and the user experience.
And this is why we see implementations of monoliths, that have been wrapped in an API, failing again, and again, and again, in a headless system and a MACH based architecture.

Digital channels are now the primary channels for businesses – it’s never been so important to deliver great experiences at every digital touchpoint, wherever your customer is.

That’s why headless technology is so important today.

Headless is critical to deliver consistent, omni-channel and multi-channel experiences.
Headless technology finally gives the opportunity for businesses to be more agile and more nimble, when it comes to creating content and creating digital experiences.

You can now create platform agnostic content, create it once, and deliver it everywhere. Deliver it into every single channel you have, by separating the layers, and pulling out the presentation layer away from the business logic, away from your content, and away from your data.

This means you can innovate far more quickly in the digital experience.
Headless technologies make it easier to experiment and innovate without large scale developments and large scale deployments of technology.