What you need to know
- Microsoft recently released its 2022 Work Trend Index (WTI).
- As illustrated in the WTI, Microsoft is fully cognisant of the importance of hybrid work and adjusting its services for remote environments.
- In a recent Teams-related post, Microsoft outlined its Microsoft 365 Reliability Principles, letting users know what to expect from the company and its products.
Microsoft Teams and the larger MS365 ecosystem are being fine-tuned for the hybrid work world, and the company behind the products has outlined the specific principles guiding its vision.
First and foremost, Microsoft wants Teams to be as failure-free as possible. That's why it has an organized, ten-step approach to its principles, which are divided into two categories.
Microsoft Cloud Principle:
- Design for resiliency
- Granular fault isolation
- Safe change management
Architecture Engineering Principles:
- Active-active-architecture
- No single points of failure
- Observability
- Partitioning for blast radius reduction
- Fault tolerance through replication and redundancy
- Automated deployment pipeline across gated rings worldwide
- Security development lifecycle
While some of those may sound self-explanatory, others contain technical jargon the average reader may not recognize. Here are the broad strokes of the aforementioned principles.
Everything's designed from a standpoint of endurance and the ability to withstand obstacles and unforeseen circumstances. Furthermore, problems need to be isolated so there's zero downtime in Teams functionality, and any updates or changes implemented to Teams need to be unobtrusive to the service in their implementation. These are the cloud principles.
The architecture engineering principles describe Teams design as having multiple "operationally independent heterogenous paths" in play so even if one fails, others are ready to keep service going. Observability includes making sure that Microsoft has the metrics it needs to ensure reliable performance.
Partitioning for blast radius reduction has the following description, directly from Microsoft: "The basic idea is that when we deploy a change, configuration, or code, we gradually deploy and validate our changes with a small set of users and then expand to a higher ring once metrics meet their targets, feedback has been gathered, and gates have been passed." In short, if anything goes wrong, it'll affect the minimum amount of people thanks to this approach.
Fault tolerance involves data being replicated across Microsoft's datacenters so that if one fails, another is ready to fill in the gap. The automated deployment pipeline takes the blast radius reduction philosophy and builds on it to ensure that only changes safe enough for wide deployment are instituted. And as for the security development lifecycle, that's Microsoft's way of ensuring the company is doing its homework on all the metrics it collects, utilizing its bug bounty program, and otherwise acting on its resources to ensure the safest environment possible for Team and Microsoft 365 users.
