Is your organization ready for microservice architecture?
Many enterprise e-commerce platforms are based on complex monolith software developed by large teams that are constantly struggling to keep up with the needs of the business. For companies dealing with a large share of mobile traffic, the increasingly competitive market can put them under pressure. As a way to manage in this new digital landscape, other organizations have switched to a microservice architecture, allowing them to deliver software rapidly, frequently and reliably.
Is your organization ready for such a big architecture change?
What is Microservice architecture?
Microservice architecture is an organization that structures your application as a collection of services that are:
- Easier to maintain and test
- Loosely coupled
- Independently deployable
- Built around business capabilities
- Maintained by a small team
How will microservice impact your organization?
Let's assume that you have a monolithic eCommerce platform that does everything from showing a product catalog, allowing a multi-step checkout process and managing the fulfillment of products and payment processes. But right now you can handle only desktop clients and you want to introduce a new touchpoint such as a chatbot.
In such a case, you will need to build new capabilities that probably are not part of the original platform. In this situation, you could start preparing an architecture in which the chatbot will use a dedicated set of APIs (Application Programming Interfaces) that can be developed independently and maintained by a new team. It can also be starting point from which to break up your out-dated platform and create a future-proof architecture that will deliver capabilities more beneficial to your business, such as faster time to market.
However, this process will also require you to shake-up your business team and set up technical cadres that will be able to develop, test and deploy independent services. Essentially, leveraging microservice is crucial when you have teams so large that they need to be divided into smaller parts.
This division could result in a huge re-organization for your current setup and will require you to have smaller agile teams that have possess the same or similar skillsets. This type of radical change can be difficult for smaller businesses.
Modern eCommerce business requires a fast decision-making approach coupled with the flexibility to quickly change the online experience.
Adding new features should be possible in quick deployment cycles that can be counted in days not months. The most important questions to ask when you decide to create a new service is:
Could I take this new service and place it in another architecture without making changes to it and fully use all of its capabilities?
If you don’t ask such a question, you can end up with what is called a "distributed monolith". This would result in replacing your old software platform with a set of services that theoretically are working separately but are unable to perform independently.
Organizations need to break up their monolithic processes, however, this doesn’t have to involve radical change. A dedicated migration path can offer smaller business a path of evolution not revolution.
Deliver new services into the existing experience using Headless Commerce
Headless Commerce assumes a complete separation of the front-end layer, where the customer experience takes place, from the back-end commerce functionality and business logic, such as the shopping cart, product catalogue, promotions, payments, checkout, etc. This separation allows teams to work and change each service independently, allowing them to create new experiences without interrupting or destroying the existing ones.
Phase 0 - existing solution
Phase 1 - introduce new dedicated checkout
Phase 2 - continuation of service decoupling
The first part of migration to a new architecture could be to add a new checkout process as a separate service and leave it only for a dedicated touchpoint (for example a chatbot). In this step you will start creating the foundation to move more touch points to the new architecture.
You will be required to expose a temporary Legacy API that will be an access point to your monolithic business functions, such as exposing a current product catalogue or querying user data.
Following up, you can plan to introduce new services and gradually move the rest of your business logic to the new headless commerce API.