Azure企业级着陆区架构的实际实现是什么



我已经阅读Microsoft云采用框架一段时间了。在我们公司,我们有一个类似的实现(轮辐式(,但不像文档中描述的那样是模块化的。例如,我们没有身份或管理订阅。

当查看我们自己的轮辐架构时,我们基本上只有两个轮辐:非prod和prod,在这两个轮辐中,我们将所有应用程序(VM(部署在一个大的VNet中(每个轮辐一个(。由于我们有数百个虚拟机,从单个虚拟机上的非常小的工具到具有数十个虚拟机的大型复杂设置,我想我们最终也会有许多着陆区(以及VNet(?我们的集线器包含中央共享服务,如防火墙、域控制器等。

重要的是,我们不进行任何内部应用程序开发,也不让营销等其他部门自己部署Azure资源。我们基本上从我们的中央IT基础设施部门将Azure基础设施设置到轮辐中,并允许外部合作伙伴将其应用程序部署到其中。

我特别好奇的是,你什么时候会决定在这个建筑中创建一个新的着陆区?你会为每个申请设置一个着陆区吗?每个部门一个以启用自助服务?我们的方法是个好主意吗?

非常有兴趣了解其他公司是如何实现此体系结构的。

企业规模着陆区的大部分可能是您提到的在实现中丢失的模块。(或任何启动小型陆地区域(

  1. 注册EA,这样您就有了一个帐户来管理多个订阅

  2. 建立适当的资源组织(管理小组和订阅(。这确保您可以部署策略和RBAC等处于适当的水平。

着陆区的级别远高于应用程序(资源组(。不需要超过1个着陆区。您可能需要通过创建新的Spoke和/或在某些情况下创建新的订阅来扩展它。

最新更新