Authors: David Uccelli, Worldwide Principal Solution Architect, Digital Commerce, AWS and Cody Shive, Global Partner Solutions Architect, AWS
There’s a lot of buzz around composable transformation today. In this blog Amazon Web Services (AWS) will explain some important concepts that will help you navigate the waters of Microservices-based, API-first, Cloud-native and Headless components—known as MACH.
But, where do we start with MACH, and why should we care? If you’re new to it, MACH endeavours to help you to build a solution specific to your business needs by selecting best-of-breed components and combining or 'composing' them into a custom platform. Many have likened it to building something out of Lego bricks or building a car by picking components such as the engine, steering rack, and body. However, this car makes it easier to swap or upgrade components and even try components before you buy or rent them.
The MACH Alliance has a list of 80+ members who have been certified to all follow the same values. There are three types of members in the alliance. Most are Independent Software Vendors (ISVs) who provide large components such as the engine and wheels in our car analogy. Then there are the System Integrators (SIs) who provide the blueprint and expertise to put the car together. Finally, there are the Enablers, which are defined as “supporting functional areas of a MACH architecture, including monitoring, data storage, container management, tracing and orchestration.” In our analogy, an Enabler would provide components such as the nuts and bolts, speedometer, brake handle and windscreen as well as the metal sheeting or plastic you need to make your own components.
As you embrace the MACH philosophy, we have some “tips” that will hopefully help. To get started, let’s compare and contrast a monolith with a microservice:
- A monolith is a tightly coupled single tiered application in which the user interface and data are combined into a single program. It is self-contained, and independent from other applications. It can have modules, but they have to all be deployed at once.
- A microservice is a tightly scoped, strongly encapsulated, loosely coupled, and independently deployed application service. Several microservices usually work together to form a platform. The most important feature is that components can be independently deployed. In other words, you can make a change to the microservice, or deploy a new version of it into the production environment without having to change any other parts of the system.
Common reasons for decomposing monoliths into microservices
There are many benefits offered by moving from a monolithic application to microservices. Below are the most commonly quoted benefits:
- Faster time to market Teams can implement changes independently, resulting in new capabilities being rolled out much faster.
- Truly omnichannel Microservices encapsulate business rules; and as such, user interfaces are independently developed, accessing the microservices via APIs. This concept is also known as headless.
- Reduced software complexity and specialized knowledge The scope and functionality of a single microservice is limited, resulting in easier maintenance and updates. Testing and deployment are incremental, rather than with a monolith which is often drawn out and subject to heavy regression testing, especially if it has been heavily customized.
Tip #1: We’ve been there, we know
About twenty years ago, Amazon.com made the decision to move away from monolithic applications, simply because they wouldn’t scale. At that time, Amazon had one monolithic application and one Oracle database. It took 11 hours to update. They recognized if they continued in that vein, they would not achieve the agility necessary for the burgeoning ecommerce market. So, in a bold move, Amazon.com embraced what was new for the time, the concept of “service-oriented architecture” to achieve its first generation microservices. As a result, DevOps was born at Amazon.com with the mantra, “You build it, you run it” ringing through the halls. In a nutshell, here’s how it was done:
Amazon.com enforced an API-only communication mentality
Amazon.com further enforced MACH principles through what it now calls the API Mandate. The only way that teams were allowed to communicate with each other was through the use of APIs – no exceptions. This mandate came in 2002 from Jeff Bezos, and it remains true to this day. Among other tenets, Bezos spelled out that you shouldn’t share databases as this would bypass the business logic in the microservice and restrict working independently. If you have shared a database what happens if you want to delete a column? Do you have to check if another service is using that column?
Amazon.com re-imagined the concept of the release cycle
One of the key impacts of adopting DevOps and independently deployable microservices is a dramatic change in the release cycle. Instead of 11 hours of down time to launch, at Amazon.com they now have over 60 million deployments a year. This enables huge improvements from an innovation, experimentation and from a time-to-market perspective.
Amazon.com started with the end in mind
The Amazon working backwards method is a product development approach that starts with the team imagining the product is ready to ship. Knowing what success looks like (from the customer’s point-of-view) gave Amazon.com a north star to aim for. Knowing that a migration from monolith to MACH can be broken into manageable phases, they started breaking down the code into discrete operational components. And, they didn’t expect to migrate everything at once; instead, Amazon.com took a phased approach to make an orderly transition employing a Strangler pattern. In a future blog, we will look more closely at patterns you can use.
Tip #2: Make Sure Microservices are Right for You
Monolith does not equate to legacy
Many people think there is only one type of monolith, and we often think legacy equates to monolith. In reality there is a continuum of monoliths, and they can be highly modular and even have multiple databases, enabling several of the advantages of microservices such as independent teams working on modules.
In a recent article called Monoliths are not dinosaurs, Werner Vogels, Amazon’s CTO emphasizes “there is no one-size-fits-all” and you should design your architecture to fit your situation and objectives.
Do you need to customize?
If you have a pretty standard use case then a tried and tested monolithic platform may be the best choice. Monoliths often come with “starter stores” that have been developed and refined over many years to accelerate the deployment of popular use cases.
However, many companies want unique features that can only be built through customization. With more and more customization, problems start adding up for a monolith as the single block of code becomes more difficult to deploy. This results in larger scoped deployments and the need for release coordination, which can greatly slow innovation. It can even result in being stuck on an old version of the monolith that is no longer supported.
How important is a business-friendly management UI and experience orchestration to you?
As a result of being tightly coupled, most monoliths have extremely useful management user interfaces (UI) that are designed to be used by the business. Monoliths can also do things that are currently quite difficult for microservices-based platforms or require larger development teams. For example, in WebSphere Commerce, Oracle Commerce and others, you can easily preview a consumer experience in next summer’s sales, including any personalization, loyalty, catalogue changes and offers. Recreating that type of experience orchestration and management UI in a microservices world is not impossible, but it is pretty difficult as it involves orchestrating many different vendors’ microservices using a single UI. For some retailers it is worth developing themselves using services like Amazon EventBridge and AWS Step Functions for their particular use cases. There are also services offered by AWS Partners for “experience orchestration” with pre-built connectors for many common MACH components.
Tip #3: Help is Out There
Getting started with the process of refactoring a monolithic application into microservices can be daunting. What should you address first? How do you convince management of the benefits? What’s everybody else doing?
Leverage a Systems Integrator as your partner
In the past it was common for a company to pick a monolithic vendor using a long RFP process, then ask the vendor which Systems Integrator (SI) would be suitable. Picking an SI was an afterthought.
An important tip, that everyone who has started the MACH journey knows, is that the SI should now be your most important decision and can help pick vendors with you. After all, one of the reasons you are moving to MACH is the ease with which you can upgrade or swap out a vendor if it does not work out. It is a lot more difficult to swap out your SI.
Many SIs are MACH Alliance members, and you can find much larger lists on similarly curated marketplaces such as AWS’s Marketplace. In a future blog we will explain how to safely widen your net beyond the 80+ MACH members.
Once you have narrowed down your list of candidates, an alternative approach to a long RFP process is to pick one or more simple proof of concepts and develop them with one or more potential SI partners. See how they work with your team and how they help you identify the capabilities you need first. How good are they at either suggesting the best Commercial Off The Shelf (COTS) services on the market to evaluate or helping you build your own services?
Pick a partner that has experience with similarly-sized companies, and look for an SI that does not use one template to fit all customers. Ask yourself “do you trust them to handover a fully optimized solution that has been thoroughly documented, so any future partners or in-house teams can take over the solution?”
Ensure You Have a Champion
It’s important to have a champion who can provide the mandate for completing the migration. Seek out an executive sponsor, and help them understand the benefits of MACH. As mentioned earlier, at AWS we use the working backwards mechanism to help us provide a clear understanding and purpose for an initiative. A key artefact of working backwards is a document called a Press Release/Frequently Asked Questions, or PR/FAQ for short. That mechanism, or one like it, is an excellent way to explain to executive management your purpose and method for migrating a monolithic application to microservices. It also can be used to help that sponsor understand the relative costs and benefits of the migration.
Understand your goals, your capabilities, and your weaknesses
Together with your chosen SI, clearly define your goals for the project, and identify the capabilities necessary to launch and maintain the future state. Remember that every company has different priorities. For example, your company may be known for an amazing online experience but rated poorly for customer support. Make sure everyone is aware of your priorities, and the capabilities you want to improve.
A good method to quickly separate the wheat from the chaff is to prioritize what is necessary to achieve a Minimum Viable Product (MVP). For example, you will probably need a search capability for the launch of your new digital commerce site, but will you need it to be personalized at the start or will some other feature have a higher return on investment?
Involve the business at every stage
Set up product teams to implement, refine and manage each service. Make sure the business stakeholders who will actually use the product are fully involved from design to testing and training others on the solution. Getting buy-in by involving business users in every step of the implementation and ongoing maintenance and enhancement of the solution sounds simple, but it will bring incredible rewards in the future.
Tip #4: Keep Innovating Through Experimentation
When asked about the objectives of a MACH transformation, the likely answer is going to revolve around innovation and keeping up with changes in the market. What many companies forget is innovation and product market fit is achieved through experimentation.
One of the most popular quotes from Bezos is:
“To invent you have to experiment, and if you know in advance that it's going to work, it's not an experiment”
A less well known, but equally important quote is:
“What you really want to do company wide is maximize the number of experiments you can do per given unit of time. Since the outcomes of all these things are uncertain, if you can figure out how to conduct an experiment, you can make more bets. So, the key, really, is reducing the cost of the experiments.”
Amazon has a dedicated group that allows teams to constantly experiment with the user interface on the website and mobile app. Amazon has put a lot of energy into trying to figure out how to be very low cost with experiments so they can run a much larger number of them.
However, a lot of companies don’t make full use of the fact MACH architectures can handle a vast number of changes needed for experimentation. Skillshare experimented with their in-house recommendation system vs. Amazon Personalize in 2020 after a boom in customers due to the pandemic. It found that using Amazon Personalize resulted in a 63% increase in click through compared with the in-house developed solution.
The secret is to set up a team that purely enables cheap experimentation. Keep an eye on the market and keep listening to your customers by running experiments.
Ready For MACH?
While these tips may seem simple to achieve to those who have not started a monolith to MACH transformation, they are all very powerful and have been recounted by retailers, brands, vendors, SIs and technology enablers who have been through the process.
In a future blog we will be revealing more tips, including different migration patterns and using MACH Enabler services with MACH Vendors to create a unified experience for customers. As part of this we will touch on serverless and event driven architecture. We will also look at how to widen your net beyond the 80+ MACH members, while making sure you follow MACH principles.
Authors:
David Uccelli is the Worldwide Principal Solutions Architect for Digital Commerce at AWS and works in the CPG and Retail team. David started in eCommerce over 20 years ago, working with IBM customers to build online solutions. Since then, he has worked with a huge number of large retailers and CPGs, including working directly for Walmart, Sainsbury’s, John Lewis, Heineken, Canon and PVH. David has also worked for several large consultancies and was a founder of a startup that was sold to Sainsbury’s. Having worked on large monolithic platforms in the past he now specialises in composable architectures for all channels and works closely with many MACH Alliance members.
Cody Shive is the Global Partner Solutions Architect for Grocery, Drug, and Convenience at AWS, where he works with both cloud and physical store retail partners. Cody has over 20 years in Retail as an independent consultant, a technical lead for IBM/Toshiba Global Commerce Solutions, and as a Retail Transformation architect for NCR. Cody specializes in deep data analytics and keeps himself involved in self-service solutions such as Self-Checkout and Dash Cart technologies. He is passionate about grocery, stemming from his very first job at Albertsons in Jacksonville, Florida. Cody is a graduate from the University of North Florida with a degree in Computer and Information Sciences and minor in Business Management.