How to get started with cloud-native architecture for commercetools

One of the ingredients of commercetools’ secret sauce is cloud-native SaaS architecture, which enables businesses to scale commerce capacity at speed during Black Friday-like traffic moments without having to provision hardware and software internally. Essentially, companies can outsource the heavy lifting of data center operations, so they can leverage auto-scaling, high availability, reliability and security offered by cloud computing providers. 

commercetools runs on leading hyperscale providers, Google Cloud Platform (GCP) and Amazon Web Services (AWS), ensuring access to their most resilient primitives: Multi-zone deployments, distributed storage, global networking and managed recovery services. This multi-cloud strategy prevents lock-in, allows us to meet regional compliance requirements, and offers choice and redundancy.

Multi-tenancy is also a vital component of our architecture and works in tandem with cloud nativity. In short, multi-tenancy allows multiple customers (or “tenants”) to share the same application or infrastructure while keeping their data and processes separate and secure. Overall, a multi-tenant system has much higher scalability limits than a single-tenant system. This approach ensures that all our customers in a region receive the same experience while immediately benefiting from performance improvements and fixes. 

Finally, a cloud-native architecture relies on independent APIs backed by microservices. Each microservice is deployed into the cloud, maintaining its own application layer, datastore and infrastructure, so expert teams can deploy updates through independent development and release cycles faster and more efficiently. 

Together, these elements are critical to the resiliency, flexibility and scalability of the commercetools Platform. Next, let’s dive a little deeper into commercetools’ underlying cloud infrastructure and how you can benefit from it.

We extend these provider capabilities with our own service mesh, zero-trust security model and observability layer. The result is a unified commerce platform that takes advantage of the reliability and scale of hyperscalers while incorporating platform-level controls for resiliency, security and performance.

Here’s an overview of how the various elements of the commercetools’ architecture work together:

Being “in the cloud” does not automatically mean resiliency. Legacy applications migrated into a single cloud zone remain vulnerable to outages. commercetools avoids this pitfall by being architected cloud-native from inception:

• All core services are stateless where possible, relying on distributed storage and event streams.

• Stateful components like databases and queues are replicated across AZs with built-in durability guarantees.

• Infrastructure is codified with Infrastructure as Code (IaC) using Terraform, ensuring reproducibility and rapid redeployment.

This design ensures that hardware failures, network disruptions or zone outages never result in service disruptions for customers.

As a customer, you can deploy services that integrate with commercetools in the cloud vendor of your choosing. 

Our cloud-native architecture distributes infrastructure across multiple geographic Regions, each composed of multiple Availability Zones: 

• Every service in our software stack is deployed across at least three Availability Zones per Region to ensure high availability and resilience.

• Availability Zones are independent failure domains with separate power, networking and physical infrastructure. However, they are strategically located within a Region to maintain low-latency connectivity (under 1 ms round-trip at the 95th percentile). This design enables fully active-active deployments within a Region.

By leveraging this architecture, the platform is inherently resilient to failures of application nodes and hardware. Infrastructure redundancy is built in, and underlying hardware maintenance is managed automatically by the cloud provider, minimizing operational risk and downtime.

This is how Availability Zones are utilized within a Region:

What happens when you sign up for commercetools:  

1. Set up your cloud service in a specific Region, leveraging three Availability Zones per Region for maximum resiliency. This cloud deployment approach protects against application node and hardware failures, as well as system outages due to automatic maintenance, as well as redundancies kept by the cloud provider. 

2. Provision of your multi-tenant project with a unique logical database in our shared MongoDB instances upon creation. The logical databases share the same infrastructure resources but are otherwise separate. To achieve this, each tenant project can be provisioned with a unique logical database that shares the same infrastructure resources but is otherwise logically separated from other projects. We then manage access to these logically separated projects via our API credentials. 

3. Provision of access to commercetools’ extensive library of APIs, GraphQL endpoints and our business tooling, Merchant Center. This “backend” cloud, as we call it, is entirely commercetools’ responsibility to maintain, update and upgrade for your benefit. 

As a user of commercetools solutions, you need your own cloud (e.g., virtual private cloud or VPC), which you can use for building/running your frontends (if your business brings its own frontends), managing extensions/customizations, custom microservices, consuming events and an API gateway. These elements are the customer’s responsibility to host and maintain.

Managing the backend and frontend clouds is where our cloud-agnostic strategy shines: For instance, it’s common to use AWS for the frontend and Google Cloud for the backend. The technical setup for your Region of choice is also flexible, allowing you to run your frontend cloud in Australia and your backend cloud in Germany. 

At the end of the day, when you sign up for commercetools, your business is consuming APIs, events and using our Merchant Center as a SaaS service, so these technical elements become almost invisible to your commercetools experience. 

To provide the best possible Service Level Agreement (SLA) and minimal latency, the Composable Commerce API is provided in the following Regions: North America (Google Cloud, Iowa), North America (AWS, Ohio), Europe (Google Cloud, Belgium), Europe (AWS, Frankfurt), and Australia (Google Cloud, Sydney).

These Regions are completely isolated from each other, and no data is transferred between them. User accounts created for one Region are not valid for other Regions. It’s important to know that selecting a Region does not prevent you from accessing data anywhere in the world; it’s simply where the data and services live and run.  

To get started, a sign-up is required for each Region. Learn here how to set up your Region(s) using our Merchant Center and the Merchant Center API Gateway.

Our cloud-native services eliminate the need for customers to manage the extensive scale and intricacies of infrastructure, hardware and security vulnerabilities associated with on-premises solutions. We alleviate the challenges and risks related to enterprise operations and security that are inherent in on-premises systems, facilities and software. 

With commercetools, powered by a cloud-native architecture under the hood, your business gains reliability, security and agility while reducing costs and complexity. 

Learn more about cloud-native architecture by downloading our paper Migrating your Commerce Platform to the Cloud and learn how your business can make the move to the cloud with ease and speed with commercetools.