Amazing! I need to learn more about how to democratize the platform, but this video was an excellent start. Studying for the AZ-305 has me wondering if I have just been going rogue with some migrations. Love the content and can't wait to check out the rest of your stuff!
Thanks for the videos guys. I've just shared this with my client as they're at a critical juncture with their journey. Hopefully, this will help them design a subscription model which is aligned with the organisation's operating model and industry regulations.
Very informative video on subscriptions. Just one thing when you say 'overlapping ip assignments within an address space...' could you clarify what you mean by 'ip assignments'. I understand we can't have overlapping ip address with a subnet so was wondering what you meant by overlapping ip assignments?
@Jack Tracey why would Cloud Networking Team would object to different subscriptions? What about Secure Hub-spoke landing zone with different subscription? Any idea Great Knowledge Base Info. Please keep coming with videos with your advisory about what to use not use as well.
Funny you should ask, as we're currrently working on recording some epsiodes for the Azure Enablement Show which will include demos using our Bicep and Terraform implementations. I'll try to remember to post links here once they go live!
Whilst yes there will be an increase in costs due to vNet peering, it will be very small in relation to the rest of the workload ($0.01 per GB in same region - azure.microsoft.com/pricing/details/virtual-network/). And this does not outweigh the benefits of democratization and reducing the blast radius 👍
in cases where you have 100s apps needing to talk with one another as well as platform services this cost can easily skyrocket. And especially if you choose to root everything through the hub net like suggested here if I understood correctly.
Yes that is correct, subscriptions are meant to be created first before deploying ALZ. You can see a nice diagram here learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/#landing-zone-journey
Ivory tower discussion.. All the points mentioned are pro multiple subscription and nothing to the contrary. We are a 50 person organization with an IT team of 5 people. Why should we create a management group hierarchy and multiple subscriptions and increase the complexity from the get go ?
Hey Duraid, thanks for the feedback. I think the point of ALZ is to set you up for long-term success and growth. We know that migrating resources out of single subscription environments can be painful, depending on the services you have within it. Also having a single subscription approach can cause: - Running into Resources/Quota limits faster and when you do, you dont have a scalable way to handle this. - Apps can be impacted by noisy neighbours, using quota they may need etc. - Complex RBAC assignments - hard to give higher level of control to app/workload teams in shared single subscription model - Larger blast radius should a single subscription become compromised Management groups help you enable, operate and govern and multi-subscription environment at scale. Hope that helps
@@MicrosoftCAE Thanks for the response. The advantages were mentioned in the video. Thanks for re-iterating them. Non of the trade-offs were mentioned however which an unbalanced design decision. So now we build skyscrapers for everybody even if they need a couple of rooms just in case you need them in the future?
@@duraidh7299 I think CAE's response was valid, and I'll ask. How does having multiple subscriptions increase complexity? If anything, it allows you to reduce complexity as your company's cloud adoption goes. As architects, we should design environments that scale well. As outlined in the video, a single subscription can run into very painful scalability issues. A multi-subscription environment on the other hand might avoid those. If the complexity is not large (and there is no additional cost involved), why not create the more scalable solution? One final question that I'll ask that probably could have summarized my entire response. What about multiple subscriptions do you find more complex than a single subscription? The requirement for additional VNet Peering perhaps?
Amazing! I need to learn more about how to democratize the platform, but this video was an excellent start. Studying for the AZ-305 has me wondering if I have just been going rogue with some migrations.
Love the content and can't wait to check out the rest of your stuff!
Thanks for the videos guys. I've just shared this with my client as they're at a critical juncture with their journey. Hopefully, this will help them design a subscription model which is aligned with the organisation's operating model and industry regulations.
Awesome vid, great content and key areas covered in 15 mins. Good work.
Very informative video on subscriptions. Just one thing when you say 'overlapping ip assignments within an address space...' could you clarify what you mean by 'ip assignments'. I understand we can't have overlapping ip address with a subnet so was wondering what you meant by overlapping ip assignments?
Good informative stuff.. let us have next deep dive sessions
it is great content. Learned a lot.
@Jack Tracey why would Cloud Networking Team would object to different subscriptions?
What about Secure Hub-spoke landing zone with different subscription? Any idea
Great Knowledge Base Info. Please keep coming with videos with your advisory about what to use not use as well.
Do we need to provision subscription before we start Azure Landing zone accelerator?
good stuff gents
Thanks for the video.
Would be great to make a end to end "demo" of a say Contoso cloud deployment using IaC after this one.
Funny you should ask, as we're currrently working on recording some epsiodes for the Azure Enablement Show which will include demos using our Bicep and Terraform implementations. I'll try to remember to post links here once they go live!
what about extra network peering cost?
Whilst yes there will be an increase in costs due to vNet peering, it will be very small in relation to the rest of the workload ($0.01 per GB in same region - azure.microsoft.com/pricing/details/virtual-network/). And this does not outweigh the benefits of democratization and reducing the blast radius 👍
in cases where you have 100s apps needing to talk with one another as well as platform services this cost can easily skyrocket. And especially if you choose to root everything through the hub net like suggested here if I understood correctly.
Are we supposed to create all required subscription first? is this applicable for terraform as well?
Yes that is correct, subscriptions are meant to be created first before deploying ALZ. You can see a nice diagram here learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/#landing-zone-journey
Good idea for content
more Subscriptions = longer it takes to view combined cost analysis. We can't view costs are MGMT group scope, only Sub scope.
As someone that worked very little in azure with infrastructure, this was very hard to follow.
Ivory tower discussion.. All the points mentioned are pro multiple subscription and nothing to the contrary. We are a 50 person organization with an IT team of 5 people. Why should we create a management group hierarchy and multiple subscriptions and increase the complexity from the get go ?
Hey Duraid, thanks for the feedback. I think the point of ALZ is to set you up for long-term success and growth. We know that migrating resources out of single subscription environments can be painful, depending on the services you have within it.
Also having a single subscription approach can cause:
- Running into Resources/Quota limits faster and when you do, you dont have a scalable way to handle this.
- Apps can be impacted by noisy neighbours, using quota they may need etc.
- Complex RBAC assignments - hard to give higher level of control to app/workload teams in shared single subscription model
- Larger blast radius should a single subscription become compromised
Management groups help you enable, operate and govern and multi-subscription environment at scale.
Hope that helps
@@MicrosoftCAE Thanks for the response. The advantages were mentioned in the video. Thanks for re-iterating them. Non of the trade-offs were mentioned however which an unbalanced design decision. So now we build skyscrapers for everybody even if they need a couple of rooms just in case you need them in the future?
@@duraidh7299 I think CAE's response was valid, and I'll ask. How does having multiple subscriptions increase complexity? If anything, it allows you to reduce complexity as your company's cloud adoption goes.
As architects, we should design environments that scale well. As outlined in the video, a single subscription can run into very painful scalability issues. A multi-subscription environment on the other hand might avoid those. If the complexity is not large (and there is no additional cost involved), why not create the more scalable solution?
One final question that I'll ask that probably could have summarized my entire response. What about multiple subscriptions do you find more complex than a single subscription? The requirement for additional VNet Peering perhaps?
@@tharagz08Complexity