Continuously monitor and troubleshoot fabric-related issues.<\/li>\n<\/ul>\nIn many ways, our IT organization will function like a managed service provider or Azure service broker. The Microsoft Azure product group recognizes that a necessary gap exists between corporate application engineering and Azure services. We refer to this addressable gap as the corporate context. The corporate context<\/em> consists of the specific company\u2019s policies, standards, identity scenarios, and network connectivity scenarios. It\u2019s the role of the service broker or fabric administrator to apply the corporate context to the fabric to enable loosely moderated consumption by application engineering teams.<\/p>\nUsing IaC and Microsoft Azure DevOps<\/h3>\n
Within the IaC and Microsoft Azure DevOps area, we\u2019re building a more agile and flexible process for developing and deploying critical pieces of the cloud-centric architecture. Self-service and automation are paramount, driving the goal of empowering our engineers to quickly create and configure their solutions in an unencumbered manner.<\/p>\n
IaC<\/h4>\n
Infrastructure as Code (IaC) is the process of managing and provisioning cloud infrastructure and its configuration through definition files that machines can process\u2014rather than through the configuration of physical hardware or the use of interactive configuration tools. IaC is about using scripts and templates to build or configure a connected landing place for applications and business data.<\/p>\n
IaC doesn\u2019t involve building user-interactive portals or creating tickets for others to run automation. IaC instead involves supplying standardized, robust APIs to application engineering teams to integrate into their deployment automation. Beyond supplying APIs, the infrastructure team supplies standard, curated configuration templates and software images for application engineering teams to consume.<\/p>\n
Within the Microsoft Azure Resource Manager framework, Azure contains recognized IaC that allows engineering teams to rapidly provision the underlying hosting platform for their applications.<\/p>\n
Microsoft Azure DevOps<\/h4>\n
We need to continue the push from fully centralized operations to a Microsoft Azure DevOps model. Specific efforts from infrastructure teams in partnership with business units need to continue and improve in the following ways:<\/p>\n
\n- Continuing to decentralize operations that involve governance and auditing, while the centralized team remains responsible for the security and compliance posture<\/li>\n
- Investing in management groups and Microsoft Azure Policy to supply guardrails for Microsoft Azure DevOps environments<\/li>\n
- Decentralizing services, including those for patching, configuring, monitoring, backup, and managing alerts and events<\/li>\n
- Gaining clarity on who’s responsible for responding to incidents by using the proper tools and processes for Microsoft Azure DevOps<\/li>\n
- Improving automation by investing in tools such as Chef, creating a runbook library strategy, and specifying how teams should use Microsoft Azure Automation<\/li>\n
- Ensuring that Microsoft Azure DevOps processes can properly deal with accessibility and privacy<\/li>\n<\/ul>\n
Using identity management and governance<\/h3>\n
Identity management and governance supply the guardrails that help protect our cloud-centric architecture. Identity is the new perimeter in modern networking and architecture, so it deserves high-priority consideration within the architecture to help ensure the security of our environment. Governance is also critical in the modern architecture, helping to guide and safeguard a largely self-service environment.<\/p>\n
Identity management<\/h4>\n
We need to simplify provisioning, entitlements, and access management. We also need to streamline account provisioning and management, helping ensure that all access is auditable and linked to an approved business justification. Finally, we need to ensure that all credentials will expire or be revoked when no longer required while maintaining the principle of least privilege for administrators and users. Our two primary efforts in identity management are:<\/p>\n
\n- Eliminating passwords through Microsoft Azure Multi-Factor Authentication. We want to remove the use of passwords in favor of strong authentication mechanisms.<\/li>\n
- Helping protect administrators. We want to help ensure that all users with elevated privileges use those privileges in compliance with our access control standard.<\/li>\n<\/ul>\n
Governance<\/h4>\n
Cloud-focused architectures still require proper guardrails and governance for two reasons: to help protect corporate data and assets from internal and external threats and to help ensure that the data and assets adhere to corporate and compliance standards. Much of our current governance is manual in nature, and some is our own intellectual property created to fill product gaps in Microsoft Azure. As Azure continues to add features, we need to embrace those native features that will help ensure we\u2019re properly governing the cloud:<\/p>\n
\n- Microsoft Azure Policy will take a forefront position in supplying the right guardrails to help ensure that application teams can operate day to day within subscriptions that will keep the data in those subscriptions safer and more secure.<\/li>\n
- With Microsoft Azure Blueprints, we want to create appropriate sets of controls for bundling policies, networking, role-based access control, runbooks, and templates info full workspace packages that complement the Microsoft Azure DevOps environments we\u2019re pushing teams to use for their day-to-day operations.<\/li>\n
- We need to invest efforts into the lifecycle workflow around governing subscriptions, exception management, and scaling to the enterprise via management groups.<\/li>\n<\/ul>\n
Using modern apps and data solutions<\/h3>\n
The way we treat our apps and data has changed in cloud-centric architecture. With more user-design models becoming available, engineers no longer function as the only developers in our organization. Users are taking advantage of platforms and tools that offer no-code or low-code development methods to create business solutions. Through all of this and within our more traditionally developed apps, we need to drive consistent development and data usage and protection methods.<\/p>\n
Modern apps<\/h4>\n
As more teams use Containers and Microsoft Azure Service Fabric, the infrastructure and security teams need to invest in creating the right guardrails for these new paradigms. This means that even more than previously, we need to track the Microsoft Azure subscription, make the correct policies and templates available, and then apply those policies and templates\u2014to help ensure that the more-transitory resources belonging to modern solutions immediately use the correct controls. Our priorities are as follows:<\/p>\n
\n- We need to supply design patterns and templates to help ensure that teams build resources according to a standard. Automatic configuration should occur during deployment, and desired state should be automatically enforced on a continual basis.<\/li>\n
- Developers need to create containers by using default images containing the correct settings and policies.<\/li>\n
- For microservices, teams need to build Service Fabric clusters that use standardized settings and policies right from creation time.<\/li>\n
- We need to assess the connectivity that modern apps require. We want users to primarily access these modern systems only via the internet, but private virtual networks might also have some use in data-focused, segmented environments. The hybrid model will benefit some teams and certain types of data.<\/li>\n<\/ul>\n
Modern data solutions<\/h4>\n
Managing our most-critical data assets will continue to be a top priority going forward. With more modern architectures, an increased ability to separate the compute and storage resources will exist, so managing the storage data will become a critical priority:<\/p>\n
\n- We need to continue examining solutions based on VMs and Microsoft SQL Server and transition them to more modern architectures.<\/li>\n
- We need to accelerate data deduplication by moving commonly used data sources into Microsoft Azure Data Lake Storage.<\/li>\n
- Our Microsoft Azure DevOps teams need to manage cloud storage in a security-enhanced and efficient manner. This includes having centralized standards for using encryption at rest whenever possible and helping ensure that all solutions use the proper business continuity and disaster recovery options.<\/li>\n
- We need to ensure that we classify, label, and protect all Microsoft data.<\/li>\n<\/ul>\n
Using modern networks<\/h3>\n
Our investment in the modern networks area involves all aspects of our networking environment. That is, we\u2019re investing in modern deployment and configuration practices to create and support a networking environment that supplies a solid foundation upon which the cloud-centric architecture rests. This includes adopting an internet first network model, increasing support for Software-Defined Networking, making more efficient use of Microsoft ExpressRoute connections, creating more intentional network segmentation, migrating to Internet Protocol version 6 (IPv6), and increasing Network Function Virtualization (NFV).<\/p>\n
Internet first<\/h4>\n
All clients have been moving to an internet first model over time\u2014first, by enrolling mobile devices with Microsoft Intune and, eventually, by connecting branch offices and some corporate offices primarily through the internet instead of through traditional on-premises network connectivity. Clients traversing a virtual private network (VPN) or similar solution for access to corporate applications won\u2019t offer the best model going forward. To become an internet first organization, we\u2019re focusing on the following:<\/p>\n
\n- We need to make line-of-business applications accessible from the internet by either providing a hybrid connection to the application\u2019s presentation layer, making the presentation layer entirely internet facing, or making the full application internet based versus traditionally on-premises network based.<\/li>\n
- Infrastructure teams need to help secure the solutions in a standardized manner and always use verified intended access.<\/li>\n
- Infrastructure teams need a way to correctly and efficiently handle edge traffic. They need to know how to accurately audit, respond to, and report that traffic.<\/li>\n
- We need to find ways to supply hybrid access for data anchors that stay in a more-restricted zone, which won\u2019t be the on-premises network.<\/li>\n
- We need to invest in resiliency and security for these internet-facing solutions to help prevent unwanted impacts.<\/li>\n<\/ul>\n
With most clients moving to an internet first model over the next few years, we in MSD need to examine where line-of-business applications place services going forward. With most clients moving outside the on-premises network boundary, it makes the most sense for the applications they use day to day to have a presence on the internet versus continuing to require a special network connection back to an on-premises network-based solution. To improve services placement, we\u2019re examining the following:<\/p>\n
\n- Making user-facing services and the presentation layer externally reachable.<\/li>\n
- Placing data or the backend in an administrator channel or private zone if appropriate to help safeguard access.<\/li>\n
- Resolving impact to clients and applications, such as when they send data to an on-premises printer.<\/li>\n<\/ul>\n
Software-Defined Networking and ExpressRoute<\/h4>\n
Within MSD, the Zero Trust and internet first efforts will encourage teams to examine their on-premises, network-bound solutions by using ExpressRoute. Additionally, the Microsoft Azure ExpressRoute service will continue to grow, because a plethora of product teams are just starting to move their lab and build solutions to Azure. Over time, we want teams to examine hosting their solutions outside the traditional corporate network more and more\u2014that is, in a fully internet-based posture, in an appropriate Software-Defined Networking environment, and with defense-in-depth security controls applied.<\/p>\n
To further embrace Software-Defined Networking and ExpressRoute, we\u2019re focusing as follows:<\/p>\n
\n- Teams should modernize their solutions as their first choice versus migrating them directly to Microsoft Azure IaaS services. This needs to become a strategic goal across the organization.<\/li>\n
- For our MSD applications, we need to prioritize deployment governance over ExpressRoute usage. This will encourage the transition to modern applications that assume an internet posture versus continued dependence on the on-premises network.<\/li>\n
- Even with a pure internet first design, these modern solutions should use Software-Defined Networking and the security features of Azure that supply controlled access to solutions.<\/li>\n
- We\u2019ll simplify our current ExpressRoute architecture, which uses significant physical resources. We\u2019ll redesign the architecture to use more of the Software-Defined Networking components of Azure. The goals are to reduce costs, increase the deployment speed, make the service easier to consume, and make the service even less reliant on on-premises hardware.<\/li>\n
- We need to engineer differentiated zonal-stratification offerings for production and mission-critical solutions versus those for research and development.<\/li>\n
- We need to revisit the hybrid design options and revise them based on both new features and proper governance within all zones.<\/li>\n<\/ul>\n
Network segmentation<\/h4>\n
For us in MSD, network segmentation is one of the largest components of the cloud-centric architecture. The corporate extranet network and the security zones that define it have existed for decades. In the modern cloud-environment era, we need to revise network segmentation by:<\/p>\n