As customer expectations, business models, and technology standards change at rapid pace, too many businesses are stuck using “black-box” software that simply can’t react quickly enough to stay competitive.
Many enterprises looking to escape the software monolith are turning to a MACH approach to development, embracing Microservices, APIs, Cloud-Native, and Headless technologies to build a modern enterprise architecture.
In a recent webinar, Heiko Mock, Advisor to the MACH Alliance, joined Kelly Goetsch, CPO of commercetools and President and Co-founder of the MACH Alliance, to discuss the core principles of MACH, the benefits of this approach, and advice for developers who are making the move from monolith to MACH.
Check out the replay below for the full story, or read underneath for a quick look at some of the topics covered by Heiko and Kelly in their conversation about using MACH principles to build open tech ecosystems in the enterprise.
“Microservices are a very specific style of development where you have small, vertical teams building single purpose applications, exposing the functionality through APIs.” defined Kelly, “It’s very granular, very modular, and very scoped in terms of business functionality.”
Each microservice can be developed, written, and scaled independently, using a modern programming language that is selected to best suit the type of services and its business function. This granularity provides a high degree of flexibility in coordinating microservices with specific hardware and creates an enterprise architecture that can adapt quickly to change.
Granularity of Services
“A lot of the purists out there say that a microservice should be so small that it could be rebuilt over the course of a single weekend. I think that’s kind of ridiculous, to be honest with you.“ said Kelly, explaining that with pieces that small an enterprise would face an impractical amount of communication overhead.
“I think it makes sense to have slightly larger teams that look after a collection of APIs, and that’s how we do it at commercetools.” said Kelly, “We have a team that looks after the order, checkout, and shopping cart APIs backed by microservices. We have a team that looks after the product catalogue, and we have one that looks after search. We break up the platform that way, and I think that’s a better way because of the amount of data.”
Team Structure for Modern Development
Even with a more consolidated level of granularity, microservices require a new way of thinking and communicating among development teams. Both speakers were keen to mention Conway’s Law, a theory proposed by the computer programmer Melvin Conway that any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.
For companies moving to microservices, transforming how teams communicate is a crucial early step. “To put it simply, there’s no way for you to succeed unless you change your development team such that individual teams of developers are responsible for each microservices.” says Heiko, “Accountability has to be clear, and someone has to own the overall design. Otherwise, you end with itty bitty services that are redundant, inconsistent, and ultimately of poor quality.”
The Composable Enterprise
“Composable Commerce is something that Gartner came up with. I do like the term, as it’s a bit more business user friendly.” Kelly said, explaining that the term refers to the ability to compose a commerce experience through different APIs. While composable and microservices are often linked, they aren’t mutually exclusive. “Composable is more about how you consume the APIs, where microservices is more about how you produce the APIs.”
“You see some publications online, even tech publications, that confuse APIs with microservices and kind of use the two interchangeably, but they do have a very distinct meaning.” said Kelly, “The relationship is that microservice is the code, it’s the application, but the API is how it exposes that data and that functionality publicly.”
API maturity will vary across different companies (Kelly pointed to the Richardson Maturity Model to help explain this), but the general advised approach is to start by first building the API and then implementing the microservice code behind it.
While there is no specific blueprint for APIs, Heiko discussed the benefits of leveraging a model language such as RAML or OpenAPI. This makes it easier to describe and provide all the information necessary for RESTful APIs. Says Heiko, “If you use any one of these standards, the whole ecosystems open up for you.”
“At commercetools we see about 75% of our customers using GraphQL today, so we really see it picking up widely.” said Kelly about the rising popularity of the API query language originated by Facebook developers. Instead of calling REST APIs, which are prone to over-fetching and under-fetching, GraphQL sits on top of APIs as a query layer.
“You can retrieve exactly, precisely what is requested.” Kelly explained, “It allows you to select a product and then, for that product, retrieve its content from a content management system, retrieve its price from its price API, retrieve the inventory level from the inventory API.”
“It is mostly useful in scenarios where we have rapidly changing entities and it’s a huge task to change the whole flow.” said Heiko, describing a common situation where the UI has difficulty receiving data because of a model definition mismatch between the service layer and the UI layer. “GraphQL is a perfect fit here and almost a blessing for developers. You can easily get around the issue and get the data to the front-end.”
In the same way that you would go to Gmail or AWS, when you sign up for the service of a Cloud-Native enterprise application you are gaining access to the service, not an individual instance.
“As a vendor, you are provisioning one instance of your application, and you’re doing that at scale, but that instance of the application can service a request from any of your customers.” explains Kelly, “If the system needs more capacity the vendor can go and add that capacity. But they do it at scale, they do it across all their customers.”
Along with autoscaled provisioning, a major benefit of Cloud-Native Multi-tenant SaaS (software-as-a-service) applications is that enterprises no longer shoulder the burden of software upgrades.
“The whole process of upgrading software on a regular basis is really difficult. You spend all your time performing these upgrades and not actually innovating.” said Kelly, “Where with MACH Alliance vendors, we as vendors are pushing the updates to you. That’s good from a support standpoint, because now everyone is on the same version of that software. It’s good from a maintenance standpoint, because the vendors don’t have to release and maintain all of those old versions of software. It’s good from an availability standpoint, because all of the environments are exactly the same.”
“This is the new world that we’re in, it’s all Multi-tenant SaaS, and everything is updated by the vendor, and scaled and managed automatically. You’re buying a service, you’re not buying a hosted environment.”
Cloud Native vs Cloud Hosted
As SaaS software and Cloud adoption become more popular in both the business and consumer space, more companies are including Cloud capabilities in their marketing. However, being “In the Cloud” and being “Native to the Cloud” can have very different definitions, and organizations should be skeptical about previously Single-tenant, on-premise platforms that now claim to be Cloud Hosted.
“In some cases it’s actually a monolithic environment just now hosted on a server. Each environment is still built and scaled independently, so actually it’s the same as an on-premise environment.” explains Heiko. “You can’t easily convert a Single-tenant application into a Multi-tenant SaaS. It’s a complete project that would have to be developed from scratch.”
Headless solutions, such as a CMS or a shop system, are designed to provide content (article, products, images, prices, etc) fully through APIs. As a result, these solutions are front-end agnostic and can render content across any touchpoint.
“An API is the back-end facing out. I use a microservice to pose a request to a back-end environment and I get a response within the formation I need.” Heiko explained, “In contrast to that, Headless means we’re talking about the front-end. So how the front-end consumes the data.”
API-first vs API-added
As the amount of touchpoints we interact with rises, legacy enterprise platforms are adding APIs to their products in an attempt to glue on some type of omnichannel support to compete with the natively Headless solutions that are designed for omnichannel from the ground up.
“A lot of the old enterprise applications out there started with having a specific front-end included as part of the platform and then dynamically rendering the HTML on the server side. The code was written for that model specifically, and what they’ve done now is slapped APIs on top of their legacy application” discussed Kelly, “API-first means that you first model your APIs, and then you write the code to actually implement the APIs behind the scenes. So it’s a different model, and it changes the way of thinking.”
Lead with Headless to Avoid Big Bang Implementation
When moving from a monolithic architecture to a MACH approach, many companies start by adopting a headless approach early on so they are able to quickly improve the client-facing experience while modernizing the back-end over time.
“The key is to avoid the big bang” says Heiko, “The best approach is to start separating the front-end to a headless structure. This also means creating your own microservices, which then will be called from the front-end and communicate via a middle layer, or API gateway, with the back-end. That’s the first big step you have to do.”
“The world, as we’ve seen in years past but especially this year, is changing very quickly,” said Kelly. “Customer touchpoints change all the time, business models change all the time, geopolitics and public health needs change. If we look back at when lockdowns started, the week after lockdown Best Buy came out with contactless, curbside pickup. That’s remarkable, and shows their ability to innovate very quickly using a MACH compliant architecture.”
The ability to evolve is paramount, and companies stuck on legacy platforms with long lead times can’t keep up. Said Kelly, “If you’re releasing a production once a year, you’re as good as dead out there. You really need to innovate, and innovation comes from iteration all the time.”
Companies across industries are faced with the imperative to transform their architecture to stay competitive, and a MACH approach gives companies the speed and flexibility to not only adapt today but to evolve easily in the future.
For companies currently on the fence if they should start their transformation, or wait to see if their current solution can hold out another year, Kelly suggests, “It’s better to do it now rather than keep postponing it. It has to be done, and MACH is the way to do that. It’s the imperative these days, it’s the standard.
For the full conversation between Heiko Mock and Kelly Goestch, check out the replay.
MACH: Business Technology for 2020 and Beyond
”66% of developers find that maintaining and “paying for” technical debt (aka the money, flexibility, and opportunity lost to a bad technical investment) associated with outdated technology is bad for their productivity at work." State of the Developer report 2109, Devada