Deployment considerations
Deployment capabilities can occur in various ways, whether it's a CSU setup in the cloud or a CSU setup that is hosted on-premises or in a data center that is run by the customer. The on-premises version of the solution is called Local Business Data (LBD), which is implemented when the solution uses the service fabric but it's maintained in the customer’s on-premises environment.
The tendency is always to reduce servicing while simultaneously maximizing uptime. When using a CSU setup in the cloud, you can expect that the approximate servicing times would be around 30 minutes. This time frame depends on the necessity of the servicing and on how much customization has been done.
In a standard on-premises CSU setup, you have the option of working in offline mode, which prevents any real downtime and allows for quicker service. However, if you work primarily with the on-premises setup, where you have a CSU hosted on-premises or you’re in a data center, you'll need to run the installers manually and validate that the data has been correctly synchronized. This approach applies to the LBD concept as well.
You also need to consider the fundamental concepts of network dependency, management of certificates, and the handling of your stage rollouts. All three of these concepts are dependent on the architecture on which your topology is based. The more you host on-premises, the more requirements exist across the customer’s IT infrastructure. The same premise applies to the hardware footprint and its availability.
When planning for high availability and business continuity, you need to consider that they'll be heavily dependent on concepts such as disaster recovery and the amount of network infrastructure and management you have. The more CSUs that are set up on-premises, the more you run Store Commerce for web versus the Store Commerce app with all their various features. This situation presents a pivoted availability depending on how much is managed by the Microsoft team in comparison to how much you and the customer are managing.
From a CSU perspective, on-premises and in-the-cloud component structures are the same. The cloud CSU has more scalability because it will be driven more as a web service as opposed to the on-premises version, where the customer and partner must know their own architecture and how it's going to scale. Another advantage of setting up cloud CSUs is the peak load possibilities, which, in the cloud, are close to non-existent due to the scalability of the platform.
Whenever you host the solution on-premises (especially in the LBD scenario, where it's completely managed by the customer), you'll increase efforts regarding how much you have to service, how much security you provide, and other aspects. However, you also potentially limit the communication latency and can potentially remove issues around security that is external of your infrastructure.
Every implementation concept has its advantages and disadvantages, and it's customer-dependent in that perspective.