Where in the World Is Your SAP Commerce Cloud Instance?
9 min read
With more and more companies looking to have a global footprint, an important step is to identify where to host your SAP Commerce Cloud instances. It is not always as simple as hosting and serving up your site from a single instance. With the growth of public cloud infrastructure, there are now easier ways to scale. Easier to scale, however, doesn't necessarily mean you should.
Table of Contents
The figures below show four typical instance strategies used on projects. They represent the most commonly used strategies that we see in projects. Variants of these strategies, however, can apply as well. You can also mix and match these strategies. For example, you may have a single global B2C instance but have multiple local B2B instances. Many different options exist. Therefore, an experienced architect is required to design and validate the right instance strategy.
Single Local Instance
The single local instance is by far the most used and proven model. This model can be used both for single-site as well as multi-site. We recommended this strategy for customers who use hardware and software efficiently and can organize both implementation and operations centrally.
Using a multi-site on a single instance is more challenging than running all sites in different instances. Most customers, however, will accept the additional complexity in a single instance to avoid the complexity of having many instances and the associated costs.
Multiple Local Instances
In order to serve different markets, some projects separate out SAP Commerce Cloud over multiple (local) instances. Organizational and functional differences between the markets (B2C versus B2B) drive this, not latency or scalability.
Single Global Instance
Global customers with geographically distributed markets should aim for a single global instance as long as they can coordinate and operate the project centrally.
There are several benefits to using a single global instance such as costs and simplicity. Improving performance is achievable with the use of a Content Delivery Network (distributes static resources).
Multiple Regional Instances
For customers who need to separate out different touch points over geographical locations, we recommend using multiple regional instances. There is often a combination of latency, high-traffic and organizational challenges to launching different touch points in parallel.
The factors to consider for the creation of the instance strategy are listed below:
Total Cost of Ownership
The TCO (Total Cost of Ownership) is an important influencer for the instance strategy. If you're not using SAP Commerce Cloud, the cost for a data center, with all the hardware and software licenses and the effort to set up and maintain the environment, will have a substantial increase for every additional instance. Some projects prefer different instances in order to deliver the project on time. This is especially true when an existing deployed solution requires a change that is not in the interest of the specific project. It is recommended to be fully transparent on the pros and cons of such decisions as multiple instances come at a high price.
|A single instance operates at a single geographical location which results in latency for requests from other geographical regions. The latency, between the location of the request and the response, influences the amount of time it takes to deliver a request for a page resource. Latency depends largely on how far away the user is from the server and the number of resources a web page contains compounds it. Customers who target markets across the world might want to consider multiple instances in different geographical regions. To help eliminate the need for multiple instances, use a Content Delivery Network (CDN) and/or optimize the frontend implementation (concatenate and minify resources, client caching).|
|If you're not on SAP Commerce Cloud, you will need to handle the scalability of your systems. The maximum number of application nodes in an SAP Commerce cluster is not set, but there is a limit. Customers who target high volumes that cannot be served by a single cluster should consider multiple instances. Customers who face the maximum cluster size are typically global customers who should consider multiple instances from the start. This is because of other factors described in this section (latency, flexibility, time-to-market).|
|Master Data Management||The different instances need to synchronize data from one instance to another when sharing data and using multiple instances. A central team, typically, enriches the product data. If you're managing your own set of SAP Commerce clusters, you will be responsible for setting up the ability to keep your data in sync across multiple instances. Having multiple instances and sharing some of the data between instances increases the complexity. Also, synchronizing data through the instances will take considerable time.|
|Organization||Customers who are not centrally organized will face challenges with a single instance. A single instance requires close collaboration between all parties involved; every code release requires alignment and parallel testing. Customers, coming from companies that have been acquired over the past decades, might especially face this challenge. The differences in cultures, time zones, and the requirements of the subdivisions, might affect the probability of having one instance.|
|Time to Market||Time to market considerably slows if different businesses need to roll out in parallel on a single instance. If you're looking at setting up a single global instance your local subsidiaries might have a strong business case to set up a standalone instance and not wait, as it requires a lot of time to consolidate all the requirements into a single global implementation. This could even put funding and support for the global program at risk.|
|Flexibility||Customers, who offer different touch points for different markets, might consider multiple instances. Technically, sites on a single instance would work. They introduce, however, higher risks and more challenges.|
|Multiple Backends||Customers with various backends could consider aligning the SAP Commerce instances with the different backends. The ERP backends might have contradicting or overlapping data and processes which can be complicated to manage. Understanding the differences might be a large project on its own.|
|Data Storage Regulations||
Customers, who need to comply with data protection regulations for specific regions or countries, might select more carefully the location of their instance or decide to use multiple instances in different countries.
Private Cloud Deployments
Although the SAP Commerce Cloud in the Public Cloud solution allows for all of the scenarios discussed in the article, there are still some customers that have a license for SAP Commerce Core and are responsible for hosting and maintaining the solution themselves. They may want to host their SAP Commerce Core instance on their own private cloud. Technically, there is nothing that would prevent this. You would be responsible, however, for creating and maintaining the tooling to support your private cloud, as well as all aspects of monitoring the system and ensuring all supporting libraries stay up to date. This may give you more flexibility as to which cloud providers to work with to achieve your business needs. Nevertheless, it could come with an increased TCO or a delay in your time to market. If you're managing your own SAP Commerce Core solution you will have to deal with a lot of the decisions to support many of these instance strategies. With SAP Commerce Cloud in the Public Cloud many of the concerns for the instance strategy scenarios are already included as part of the subscription, so it's just a matter of choosing which strategy best meets your needs.
This is only an option if you are running SAP Commerce on-premise. It is not a feature that is available for SAP Commerce Cloud in the Public Cloud or SAP Commerce Cloud on SAP Infrastructure.
If you are running a single instance with the same codebase, but want to separate your business data and footprint, multi-tenancy might be an option for you to consider. In most cases, the additional complications of ensuring all aspects of your solution can support multi-tenancy (integrations, performance, when to take the database down if it affects multiple sites) result in customers choosing to not use multi-tenancy. We include it here as an option to consider if none of the above strategies work for you.
Choosing an instance strategy for your SAP Commerce Cloud solution is a decision that needs to be made in every project. With SAP Commerce Cloud, it is possible to change your strategy later on. You should, however, recognize that not all changes are simplistic. If you're changing from a single global instance to multiple regional instances, this will have a big organizational impact. The best strategy to use will be based on your nonfunctional requirements.