5min

De naam commercetools zal niet direct bij iedereen een belletje doen rinkelen. De commerceplatformleverancier is namelijk actief op een markt waar allerlei grote IT-namen ook software verkopen. Salesforce heeft een Commerce Cloud, SAP heeft een Commerce Cloud, Oracle heeft een Commerce Cloud en Adobe heeft een Commerce Cloud, om maar eens wat voorbeelden aan te halen. Door de stevige concurrentie moet een kleinere speler als commercetools zijn spierballen laten zien. Naar eigen zeggen doet het dit met vier pilaren waarop het platform gebouwd is: microservices, API-first, cloud-native en headless. Oftewel MACH.

Commercetools laat zich het best omschrijven als een platform dat organisaties losse bouwstenen biedt waarmee ze allerlei verschillende commerce-oplossingen kunnen bouwen. Bepaalde onderdelen van het platform zullen zich dus lenen voor het optimaliseren van een webshop, terwijl commercetools ook gebruikt kan worden voor bijvoorbeeld een shop in videogames waar spelers items kunnen kopen. Commercetools wil zoveel mogelijk bestaande en toekomstige scenario’s ondersteunen. Door de opkomst van verschillende disruptieve technologieën, zoals het Internet of Things (IoT), zou de shopervaring van mensen in theorie immers kunnen blijven veranderen.

Om eens wat meer zicht te krijgen op hoe dit precies werkt, gingen we recent in gesprek met Steven Fockema en Roman Zenner. Zij zijn respectievelijk werkzaam als Head of Sales Western Europe en Industry Analyst bij commercetools.

Microservices: het eerste onderdeel van de MACH-aanpak

Commercetools heeft met de MACH-architectuur dus een aanpak gevonden voor het vormgeven van zijn platform. Binnen de architectuur zijn microservices een belangrijk onderdeel. Met microservices is het mogelijk om een modulaire applicatie te bouwen. Dit doordat de applicatie bestaat uit kleine services die samen een geheel vormen. Elke microservice is ontworpen voor een specifieke feature, waardoor de service precies doet wat het moet doen voor de klant. De microservices worden met elkaar verbonden door middel van Application Programming Interfaces (API’s), zodat ze met elkaar kunnen praten. Over de microservices-architectuur wordt vaak gezegd dat ze de basis vormen van moderne applicaties.

Microservices bieden over het algemeen dus voordelen die in de smaak vallen bij ontwikkelaars. Er zijn echter ook standaard uitdagingen waar bedrijven tegenaan lopen wanneer ze microservices in willen zetten. Het commercetools-platform heeft hier rekening mee gehouden door dit soort zaken te regelen. Zo zouden organisaties bij het implementeren van een microservices-architectuur normaliter een infrastructuur moeten opbouwen om alle verschillende microservices te monitoren, zodat ze zicht hebben op wat er gebeurt. Eventuele problemen van een microservice moeten immers opgelost worden. Met commercetools heeft een bedrijf een platform in handen waarmee dit kan.

Voor het commercetools-platform levert een microservices-architectuur het voordeel op dat ontwikkelaars gerichte commerce-diensten kunnen bouwen. Dit met behulp van de bouwstenen van het platform. Een applicatie die een ontwikkelaar hier bijvoorbeeld mee bouwt is een winkelwagentje. Het winkelwagentje moet met allerlei factoren rekening houden, iets wat afzonderlijke processen doen. Hierbij kun je denken aan het communiceren met het betaalsysteem en de product management-software, maar ook aan het beoordelen of de producten in een winkelwagentje wel geleverd kunnen worden. Ontwikkelaars kunnen de commercetools-microservices combineren met zelfgebouwde microservices, waardoor het uiteindelijk mogelijk is de werking van de applicatie aan te passen aan de wens van de organisatie. Met microservices zijn speciale features direct in het winkelwagentje in te bouwen.

API-first: het tweede onderdeel van de MACH-aanpak

Om er voor te zorgen dat microservices ook goed werken, zijn API’s nodig. Over het verschil tussen deze twee technologieën heerst overigens wel eens wat onduidelijkheid. API’s zijn een soort contract, waarin bepaald wordt welke gegevens aangeleverd dienen te worden en wat de verwachte uitkomst van de functie is. Dit maakt het mogelijk om verschillende microservices, maar ook applicaties, aan elkaar te koppelen. Daarmee zijn API’s belangrijk voor het verbinden van allerlei oplossingen, bijvoorbeeld voor het verbinden van grote IT-systemen. Dit is bijvoorbeeld handig voor een connectie tussen commercetools en een ERP-systeem van SAP.

Het commercetools-platform heeft honderden API’s beschikbaar voor ontwikkelaars. Het bedrijf spreekt daardoor ook wel over een API-first benadering. Gebruikers van de commercetools-software kunnen de API’s inzetten voor het integreren van de gewenste functionaliteiten voor hun commerce-systeem. De functionaliteiten zouden met de API’s op iedere endpoint toegevoegd kunnen worden. Denk hierbij aan een CMS of specifieke functionaliteit voor een commerce-functie op een smartwatch.

Cloud-native: het derde onderdeel van de MACH-aanpak

Met het derde onderdeel van de MACH-architectuur, cloud-native, wijst commercetools op het feit dat zijn platform volledig gehost wordt in de cloud. Commercetools is opgericht tijdens het ontstaan van de cloud, waardoor het platform eigenlijk vanaf de grond af aan opgebouwd is in de cloud. Dat was iets meer dan tien jaar geleden ongebruikelijk, maar inmiddels voor de meeste organisaties een gewenste werkwijze.

Voor applicaties die gebouwd zijn met het commercetools-platform betekent dit automatisch dat ze gehost worden in de cloud. De gebouwde applicaties zijn per definitie cloudapplicaties. Dit heeft effect op de omschreven microservices-architectuur en API’s van commercetools. Veel IT-leveranciers bieden inmiddels ook cloud-gebaseerde versies van hun systemen aan. Wil je zo’n systeem verbinden met commercetools-technologie, dan zullen cloud API’s met elkaar praten. Deze cloud-to-cloudconnectie is eenvoudig te realiseren wanneer je het vergelijkt met het verbinden van traditionele IT-systemen. Bij een connectie met on premise-software zijn ontwikkelaars namelijk veel meer afhankelijk van de openheid van de software.

Daarnaast is de schaalbaarheid van de cloud ook een voordeel dat commercetools aanhaalt. In traditionele on premise-omgevingen betekende opschalen vaak dat er een nieuwe server aangekocht moest worden. Commerce-toepassingen zouden dan tegen problemen aan kunnen lopen, bijvoorbeeld wanneer een webshop tijdens de feestdagen extra verkeer moet verwerken. De cloud kan dan extra resources beschikbaar stellen om dit verkeer zonder problemen af te handelen.

Headless: het vierde onderdeel van de MACH-aanpak

Tot slot heeft het commercetools-platform met headless nog een vierde pilaar. Hiermee wordt bedoeld dat de commerce-ervaring op maat gemaakt is voor ieder afzonderlijk endpoint. Zo’n endpoint, door commercetools ook wel aangeduid als frontend, kan een smartphone zijn. Je kan hierbij echter ook denken aan een IoT-device of een chatbot.

Om headless te realiseren zijn de frontend en de backend van elkaar losgekoppeld. Als de backend en frontend wel samengesmolten zouden zijn, dan levert het doorvoeren van een verandering volgens commercetools vertragingen in de systemen op. Bij een headless-benadering kan er in de backend aan microservices gesleuteld worden, zonder dat dat direct hele grote consequenties heeft voor de frontend. Er kunnen ook updates doorgevoerd worden in de microservices. Alle processen vinden op de achtergrond plaats, het doorvoeren van veranderingen heeft geen downtime tot gevolg. Het toevoegen van nieuwe commerce-ervaringen moet door headless eveneens strakker verlopen, bijvoorbeeld wanneer een bedrijf een nieuwe voice-functionaliteit wil introduceren.

Pijlers goede basis om verder op te borduren

Met de focus op microservices, API-first, cloud-native en headless heeft commercetools wat on betreft een solide platform neergezet. Het bedrijf heeft weliswaar niet zo’n grote voetafdruk als de gevestigde namen, maar heeft wel een interessante benadering gevonden. We zijn dan ook benieuwd wat commercetools nog verder in petto heeft.