This chapter is from the book
This chapter is from the book
This chapter is from the book
The Microsoft Dynamics CRM 2016 Online Experience
The average user of CRM Online would be hard pressed to know the difference between a CRM Online and CRM On-Premises installation; after all, the feature parity is very close, however in most cases, new features are available earlier with CRM Online than with CRM On-Premises.
Update Schedule
Microsoft provides two basic types of updates to the CRM platform: feature releases and update rollups (URs). Early in the development of CRM Online, the team at Microsoft targeted the release of a UR every eight weeks and a major release (what could be called a major feature release) twice per year. The early URs were arguably very stable and were automatically deployed to the CRM Online environment. Then, as the releases became increasingly complex and negative impacts grew, Microsoft rethought its schedule and began to put out releases for CRM Online and CRM On-Premises concurrently.
Late in the 2011 life cycle and based on feedback from On-Premises customers, Microsoft moved away from the concurrent release schedule. Going forward, Microsoft would still target UR releases every eight weeks, but now it would only include fixes and not new features. For CRM Online customers, there would be twice-per-year new feature releases, which were automatically deployed to the customer environment and, depending on the size, could include an optional opt-in to help with deployment timing. On-Premises gets new feature releases once per year, putting the CRM Online users in a position to receive new features twice as often.
This new approach has greatly improved the stability of releases and given organizations a chance to evaluate and decide which features to adopt. The different release schedules impact an organization’s ability to move between Online and On-Premises environments, and timing and other considerations are important. Figure 4.2 visually lays out the planned release cycle for URs.
)
Figure 4.2 Microsoft CRM release schedule.
Microsoft Data Centers
Microsoft has made a serious investment in its online and cloud services, such as CRM, Office 365, and Windows Azure, as well as top websites such as Microsoft.com, MSN.com, and Bing.com. CRM Online leverages the infrastructure Microsoft has in place for these services and benefits from the investments and attention in the Microsoft organization. Microsoft depends on a centralized team called Global Foundation Services (GFS) to operate its data centers worldwide.
Global Data Centers
Microsoft offers a global data center footprint with facilities located throughout the world that are managed and operated directly by Microsoft (see Figure 4.3).
)
Figure 4.3 Microsoft global data centers worldwide.
Regional Data Redundancy
Within a region, Microsoft replicates customer data in real time between at least two data centers. This provides for failover on planned (for example, maintenance) and unplanned bases. This redundant architecture eliminates a single point of failure. Figure 4.4 shows an example of data replication.
)
Figure 4.4 Example of U.S. data replication.
In addition to the real-time replication of data, Microsoft also performs near-real-time replication at the data center at the other side of the region for resiliency and disaster recovery.
Data Center Redundancy
The Microsoft Dynamics CRM Online data centers are built using “scale group” infrastructure to provide a high level of redundancy and scalability. The data center is built around the concept of pods, which are groupings of multiple server racks. Each scale group is a logical grouping of servers that share responsibility for workflow, sandbox, and other asynchronous activities. Each scale group consists of six database servers—three local and three remote. Each customer’s database (instance) is stored independent of other customers. Each customer can have one or more instances (for example, production and development instances), and each is referred to as a tenant.
Using this architecture, each scale group can support a large number of instances. If one instance starts consuming a large number of resources, it is automatically moved to another scale group that has more capacity. Figure 4.5 shows the scale group architecture.
)
Figure 4.5 Example of scale group architecture.