The name Commercetools will not immediately ring a bell with everyone. The commerce platform supplier is active in a market where all kinds of big IT names also sell software. Salesforce has a Commerce Cloud, SAP has a Commerce Cloud, Oracle has a Commerce Cloud, and Adobe has a Commerce Cloud, to give just a few examples. Because of the fierce competition, a smaller player like Commercetools has to show its muscle. According to the company, it does this with four pillars on which the platform is built: microservices, API-first, cloud-native and headless. In other words, MACH.
Commercetools can best be described as a platform that offers organizations separate building blocks with which they can build all kinds of different commerce solutions. Therefore, certain parts of the platform will lend themselves to the optimization of an online shop, while Commercetools can also be used, for example, for a shop in video games where players can buy items. Commercetools wants to support as many existing and future scenarios as possible. Due to the emergence of various disruptive technologies, such as the Internet of Things (IoT), the shopping experience of people could, in theory, continue to change.
In order to get a better understanding of how this works, we recently talked to Steven Fockema and Roman Zenner. They respectively work as Head of Sales Western Europe and Industry Analyst at Commercetools.
Microservices: the first part of the MACH approach
With the MACH architecture, Commercetools has found an approach to designing their platform. Microservices are an important part of the architecture. With microservices it is possible to build a modular application. This is because the application consists of small services that together form a whole. Each microservice is designed for a specific feature so that the service exactly does what it has to do for the customer. The microservices are connected to each other by means of Application Programming Interfaces (APIs), so that they can talk to each other. The microservices architecture is often said to form the basis of modern applications.
Thus, microservices generally offer benefits that are appreciated by developers. However, there are also standard challenges that companies face when they want to use microservices. The Commercetools platform has taken this into account by arranging these matters. For example, when implementing a microservices architecture, organizations should normally build an infrastructure to monitor all the different microservices, so that they have an overview of what is happening. After all, any problems with a microservice have to be solved. With Commercetools, a company has a platform in its hands with which it can do this.
For the Commercetools platform, a microservices architecture has the advantage that developers can build targeted commercial services. This is done with the help of the platform’s building blocks. An application that a developer builds with this, for example, is a shopping cart. The shopping cart has to take into account all kinds of factors, something that individual processes do. These include communicating with the payment system and the product management software, but also assessing whether the products in a shopping cart can be delivered. Developers can combine the Commercetools microservices with self-built microservices, which ultimately makes it possible to adapt the operation of the application to the wishes of the organization. With microservices, special features can be built directly into the shopping cart.
API-first: the second part of the MACH approach
APIs are needed to ensure that microservices also work properly. The difference between these two technologies is sometimes unclear. APIs are a kind of contract, in which it is determined which data must be supplied and what the expected outcome of the function is. This makes it possible to link different microservices, but also applications, to each other. API’s are therefore important for connecting all kinds of solutions, e.g. for connecting large IT systems. This is useful, for example, for a connection between Commercetools and an ERP system from SAP.
The Commercetools platform has hundreds of APIs available to developers. Therefore, the company is also talking about an API-first approach. Users of the Commercetools software can use the APIs to integrate the desired functionalities for their commerce system. The functionalities could be added to any endpoint with the APIs. Think of a CMS or specific functionality for a commerce function on a smartwatch.
Cloud-native: the third part of the MACH approach
With the third part of the MACH architecture, cloud-native, Commercetools point to the fact that its platform is fully hosted in the cloud. Commercetools was founded when the cloud came into being, which means that the platform is actually built in the cloud from the ground up. This was unusual a little over ten years ago, but nowadays it is a desired working method for most organizations.
For applications built with the Commercetools platform, this automatically means that they are hosted in the cloud. The built applications are, by definition, cloud applications. This has an effect on the described microservices architecture and APIs of commercial tools. Many IT vendors now also offer cloud-based versions of their systems. If you want to connect such a system with Commercetools technology, then cloud APIs will talk to each other. This cloud-to-cloud connection is easy to achieve when compared to connecting traditional IT systems. When connecting to on-premise software, developers are much more dependent on the openness of the software.
In addition, the scalability of the cloud is also an advantage cited by Commercetools. In traditional on-premise environments, upscaling often meant buying a new server. Commerce applications could then run into problems, for example when an online shop has to process extra traffic during the holidays. The cloud can then make extra resources available to handle this traffic without problems.
Headless: the fourth part of the MACH approach
Finally, the Commercetools platform has a fourth pillar: headless. This means that the commerce experience is tailored to each individual endpoint. Such an endpoint, also referred to by Commercetools as a frontend, can be a smartphone. However, you can also think of an IoT device or a chatbot.
In order to achieve headless, the frontend and backend are disconnected from each other. If the backend and frontend had merged, the implementation of a change, according to Commercetools, would result in delays in the systems. With a headless approach, microservices can be tinkered with in the backend, without this immediately having major consequences for the front end. Updates can also be implemented in the microservices. All processes take place in the background; the implementation of changes does not result in downtime. The addition of new commerce experiences must also be tightened up by headless, for example when a company wants to introduce a new voice functionality.
Pillars good basis to build on
With a focus on microservices, API-first, cloud-native and headless, Commercetools has created a solid platform for us. The company doesn’t have as big a footprint as the established names, but it has found an interesting approach. We are therefore curious what Commercetools has in store for us.
16 hours ago
