[ALZ Core Team Proposal]: Retire Trey Research Implementation (Single Platform Subscription)

[jtracey93]

Today we in ALZ support both a:

• Multi platform subscription deployment (connectivity, identity, management) each in their own dedicated management group (recommended)
• Single platform subscription deployment (platform) in a single platform management group

We are looking to potentially retire the Single platform subscription deployment implementation for the following reasons:

1. Whilst supported, it is not the recommended ALZ architecture
2. The ALZ default recommended policies focus on the multi platform subscription model
3. It is hard and sometimes not possible for customers to migrate all resources out of a single subscription into multiple at a later stage and therefore if you chose the single platform option now but later want the multiple platform subscription option you will have additional work to do to complete this. And we want to ensure you are setup on the right path from day 0 👍
4. ALZ Bicep & ALZ Terraform only provide options for the multi platform subscription model out of the box
5. It is a maintenance and testing overhead we have in the ALZ team
6. We believe it not to be used that heavily anymore
   • We just added additional telemetry to the portal experience to confirm this in feat: Add additional, optional, telemetry for ALZ team to identify deployment styles of ALZ #1623

So we want you to help us decide by voting below. We will then use these poll results alongside telemetry results, that we will capture over the next 1-2 months and then we will make a decision.

Please also feel free to leave a comment below and we are happy to discuss

[mri786]

I agree with retiring the single platform deployment for the reasons you mentioned. However for dev/test purposes (and for engineers/architects) that would be interested in testing the ALZ and what it is about (or in some cases better understanding it), keeping the single platform subscription deployment as a "dev/test" option I believe would be of real value.
In our org we have over 3000 colleagues with a Visual studio developer account, this entitles them to £115 of azure credits a month but most importantly its a single subscription. The ability for them to use the single platform subscription deployment option as been very valuable (again in a dev/test & understanding capacity).

[MarcoJanse]

Some of our customers don't see the benefit of multiple platform-related subscription, although I agree it's the way forward. Some smaller Azure customers still prefer to have less subscriptions. Then again, if the option is gone, there won't be a discussion about this anymore 😆 But just as mentioned in previous comments, I also see the added benefit of having everything under a single subscription for dev/test environment.

My own lab environment has two Visual Studio Developer subscriptions (for which I use one for platform and the other one for a corp landing zone) - and I like the fact that I can link and test all policies under a single platform management group.

[jameswestall]

I would challenge the move away from having a documented single subscription option. Remove the implementation of single subscription if you must, but not the documentation itself.

The rationale behind this is as follows:

Single subscription is a viable deployment for many small businesses and corporates. Multi-Sub doesn't come with a huge overhead for competent cloud operators; however, smaller teams want something that "just works" and single-sub currently fits this gap. I've had the "Why do I need many subs" conversation more times than I can count, sometimes not even for a technical reason (e.g. the tech team knows requesting them from their CSP will be akin to pulling teeth)

To my knowledge (happy to be wrong), the Microsoft learn documentation links directly to this repository for reference architecture on single sub platform. Assuming you remove the documentation & implementation of single sub, partners and cloud providers who are implementing single sub for these SMB/C organisations will cease to have a Microsoft provided reference architecture.

Leaving the documentation in place allows partners and cloud providers to fill the gap, while removing the overhead for maintainers.

[Nitramsk11]

We have similar issues.. Lot of small customers thinks that Trey research is simple and cheap. But at the end it is not true... because management overhead at some point will be much larger. Also lot of customers got to the point when Trey research is overcomplicating their environment and we have to split it. And if they have EntraID Domain services deployed, then it is a little hell.

So from my point of view, Trey research is something what has sense in ages before Enterprise scale when there was one subscription and workloads were segregated based on RGs.

So marking it as Sandbox or Lab approach will make huge sense, because customers will not be pointing us to Trey approach.

But different customer different requirements :)

[jonathan-vella]

First things first - all customers need ALZ and all customers directly benefit from ALZ :-) The value add of ALZ is undeniable.
However smaller customers prefer to have a single subscription for platform resources since they have minimal need for segregation and for e.g., role separation.
Also, for CSP partners it is far much more easier & efficient to provision 2 subscriptions (1 for platform, 1 for corp) vs 4 (mgmt, ident, connectivity, corp).

[lukemurraynz]

I'm in the same camp, alot of orgs I talk to, want something that is scaled down, so trey research is my go to, to fill in the gap.

It's not to say, we couldn't do this, anyway without this guidance, but makes it easier reference having it under the Microsoft banner.

It's not so much the portal deployment experience, that I use, but the reference architecture images, and doco.

[tulpy]

The main problem with a single platform Landing Zone comes when you discuss compute workloads (mainly Domain Controllers and DNS Servers if they aren't using DNS resolver), routing and segregation becomes complex. This guy gets it and explains the challenges and reasons why you shouldnt do it https://aidanfinn.com/?p=23391

[mundayn]

I still split off the Connectivity, Management and Identity into separate VNETs & RGs within the one Platform subscription when following the Trey Research model.

You don't need the separate subscriptions to achieve this.

But 100% agree with no compute in the hub, a lot of people still follow the old recommendations with DNS in the hub, and as the blog points out it can cause a headache.

[macko76]

Very few customers even considered the Single Platform version and that was because the entire azure team was a 1-man show in a brownfield still, though chaotically managed. Heard later that another provider moved them to Multi-platform either way.

[TarekNabeel]

Although I prefer the multi management group for the platform and I always recommend, but not on small number of my deliveries with customers they find it more convenient for them to have an all-in-one platform management group. For that I vote not to remove it, if it doesn't help, it won't hurt ! :D.

[mundayn]

I'd like to echo the MSDN / Visual Studio item, as someone with access to the $200 free credit per month, having this portal accelerator for lab / demo / learning purposes is very useful.
If there is a way to continue using this with only one subscription, I would be happy.

Secondly, I work for an MSP, we have a lot of small clients that don't really need the 3 subscription platform hierarchy, it does not add any benefit to them. We usually (as @jonathan-vella said above) deploy 1 x Platform and 1 x Corp, and that will see them through the rest of their Azure journey (usually clients with 2-50 servers, and 0, 1 or 2 IT people).
If this was taken away it would not be the end of the world, as it would just force the small clients down the 4 subscription path.

[KyriacosAristodemou]

As a partner dealing with mainly SMB customer or small Enterprise customers by global standards Trey research is very usefull for us and allows us and our customers to benefit from ALZ Trey Research as it is easier to deploy and manage

[Springstone]

I understand the MSDN argument, but even the smallest customer should adopt subscription democratization. Subscriptions are free billing/security boundaries. Why would this help SMB?

[simone-bennett]

According to the Microsoft Cloud Adoption Framework, subscription democratization is recommended when there are separate teams managing applications or workloads, where subscriptions act as management boundaries for security and policy purposes. This makes sense when there are distinct teams for different workloads, but for small SMBs with a team of 2-3 managing everything end to end, who are you democratising it from?

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions

[MRendlessloop]

ALZ Trey is the ideal choice for SMBs over multi-subscription models. Its streamlined approach simplifies management and reduces costs, making it perfectly suited for smaller enterprises seeking efficiency and ease of use.

[LeighS]

We use the "single-sub" deployment pattern a lot. 100% want to keep it.

We are an MS Partner that deploys a lot of SMB/Startups. The desire is to have a "simplified" deployment without being overwhelmed with multiple subscriptions.

Also, there is a default limitation on Azure Subscriptions of 5 subscriptions for customers depending on their billing account type. Using 3 subs for platform resources means that we need to either create support requests or be limited to 2 landing zones. Having 4 subscriptions for landing zones is usually fine for SMB / startups but 2 isn't.

That last point is something that we see a lot when helping customers that are a part of the Founders Hub program.

[simone-bennett]

We work with lots of ISV's who have tiny teams and really only need one subscription for connectivity, identity and management. It is the same team of 2-3 who manages everything and there's no need to complicate things with networking etc.

We also work with start-ups and ISV's who are using ISV success, founders hub credits or who are on an MCA agreement and have a limit of five subscriptions. On the MCA you can log a ticket to increase the subscription limit but when I tried to do this recently, it took weeks of back and forth before we reached out using a back channel to eventually get the ticket escalated and the limit increased. Most customers would still be struggling to get the ticket actioned.

For these smaller footprints, the CAF aligned landing zones are still super important, especially when preparing for growth and assuring customers that they have a best practices aligned environment. But they don't need multiple subscriptions.

(The terraform modules and ALZ accelerator support single sub out of the box also. Props to the team because it's an excellent solution!)

[struz7]

Single sub is very palatable for smaller businesses who's cloud adoption strategy is rather minimal, also useful for not-for-profit organisations with Sponsorship subscriptions.

[richardf5]

I voted 'no' Honestly, I think removing the single Subscription model is a backwards step. I in fact only know of this survey because a member of the Terraform Accelerator team replied to my request to have the single Subscription model added!
Most of the organisations we deal with are mid-market / small-Enterprise.
They don't have large separate IT teams where the three Subscription model is concerned.
Consistently, our customers when given the choice, opt for the single subscription.

[jtracey93]

Thanks @richardf5 for voting.

Could you and maybe @struz7, @simone-bennett @LeighS @MRendlessloop @KyriacosAristodemou provide some further context and details as to why it is seen as more complex or costly or any other reason than not to align to multiple platform subscriptions by default?

As we know migrating out of a single sub later, if and when the customer hopefully grows is very painful exercise, so starting from a multi-platform sub model by default really helps teams avoid this pain at a later stage, and it doesnt cost them any more.

@LeighS good point on the sub creation limits, but my understanding is these are only for subscriptions that don't have any resources in them generating costs. As soon as the subs start generating costs they are freed from the pool of 5 and you can create additional subs. If this isn't the case, please raise a support ticket.

Finally to throw another question into the mix, these customers that use the single platform sub model, do they follow the subscription democratization principle in ALZ for application landing zones? or do all their apps end up in single large subscriptions with each other?

Thanks all 👍

[simone-bennett]

the sub creation limits are not easy to get around, I recently had to log a ticket for this is and it was incredibly painful. It was only reaching out through an MS back channel that eventually got it resolved. I would not want to subject customers to this :D

For other agreements - there's no option to add more subscriptions and increase the limit.

Re: these customers that use the single platform sub model, do they follow the subscription democratization principle in ALZ for application landing zones? or do all their apps end up in single large subscriptions with each other?

For the small start-ups or businesses we're working with, they're small and likely will stay small. We usually deploy a shared services subscription and then depending on the customer we would structure the others around

• Regions if they have data sovereignty requirements and host workloads in each region
• Environments
• Some other requirement that takes into account the possibility of growth and making sure it's future proofed.

[richardf5]

Hi @jtracey93.

I think the key issue here is that the Landing Zone concept came from the Enterprise end of the CAF. The other end (start small) was always pretty pointless for customers as they wanted a best practice implementation off the bat.

This meant that System Integrators etc. had to come up with their own middle-ground for customers who are mid-market/small-Enterprise or who didn't need subscription democratisation or they didn't have distributed single-discipline teams.

The world has changed a bit - companies now expect their cloud people to do cloud-networking as well as resource creation, operational management etc. which is unlike the days where you had a dedicated networking team per se.

Long story short, it's a difficult sell to many customers and feels (not having a go at anyone!) unnecessarily complex / over-engineered for non-Enterprise customers.

Finally to throw another question into the mix, these customers that use the single platform sub model, do they follow the subscription democratization principle in ALZ for application landing zones? or do all their apps end up in single large subscriptions with each other?

Answer is 'it depends'. Certainly, we try to split applications, environments (prod, non-prod) out. Part of the issue is the high costs for data transfer over Peerings (more so if it routes via the Azure Firewall). For customers who move large amounts of data between applications, the cost is prohibitive.

We do a lot of work with JDE on Azure - That's large enough to go into its own Subscription. It's generally preferred by most companies as they can lock down access for such a business-critical app.

Other companies only have half a dozen servers - partly down to their size but also the trend to move to SaaS platforms. Does it make sense for them to have three platform Subscriptions to service one Application landing zone?

Again. Thank you for all your hard work - we love what you've built here.

[richardf5]

I meant to touch upon your comment:

As we know migrating out of a single sub later, if and when the customer hopefully grows is very painful exercise, so starting from a multi-platform sub model by default really helps teams avoid this pain at a later stage, and it doesnt cost them anymore.

Some of the work we do is retrofitting environments that don't have platform landing zones. Companies who dived into Azure before the ELZ was fully fleshed out, those who started with Azure Classic etc.

As a rule, we create new Landing Zones as though they are greenfield complete with Management Groups, policies etc. Then it's just a case of swapping out networking connections to the new VNet Gateway (or SD-WAN), maybe migrating a couple of Domain Controllers etc. and moving other Subscriptions into the new Management Group structure and establishing new peerings.

It takes careful planning and testing, but I'm not sure I'd describe it as 'very painful'.

That said, I'm not dealing with the USA market, so you've probably encountered issues and pain that I haven't yet!!