If one has multiple environments(dev/qa/prod) in different subscriptions, there might be some restrictions with Azure DevOPs pipelines. I think currently Azure DevOps cannot span multiple subscription.
Considering this, will it be a good design to say have multiple synapse workspaces(one for each environment - dev/qa/prod) for each project in the same subscription but different resource groups?
There is always more than one way to do things but I do not think one subscription is always the right answer. It brings a bit of risk that someone could accidentally 'deploy to prod', and although this could happen in any situation, having only one subscription makes this more likely. The environments should of course be properly ring-fenced with permissions, resource groups, resource locks, clearly defined release pipelines with gateways etc which will help reduce that risk.
Multiple subscriptions, or at least a dedicated prod subscription housing a single prod environment and a non-prod subscription housing dev, test, QA (and other environments) is another option. This should reduce the risk of a single subscription but introduces additional complexity.
One way to think about it then, and what is best for your organisation is to think about a grid or matrix, with axes for Risk, DevOps maturity and Complexity versus number of Azure subscriptions you have. Ask a series of questions to help decide your position on this chart. A simple example and some sample questions:
Regarding "easy life", DevOps engineers and architects do not think like this and you shouldn't either.
You should have a single Subscription and within that subscription you can have multiple resource groups like Dev/Prod/QA. Deploy and manage your resources for different environment under a corresponding resource group for easy and hustle free experience.
Check the below diagram for your reference.
For better understanding, refer Microsoft official document.
Related
As an MSP, we manage multiple customer subscriptions through Azure Lighthouse.
Historically we've used a single Automation Account per subscription to contain solutions such as runbooks related to the Start/Stop v1 solution, Automation-based Update Management, Inventory, and Change Tracking. This Automation Account is also linked to a single Log Analytics workspace per subscription.
We've since deployed Start/Stop v2, which uses LogicApps and Azure Functions. We now have a requirement to, as part of stopping and starting some VMs, stop and start some services on the machines itself. I plan on doing this through (PowerShell) Azure Automation Runbooks, which would only stop a VM if the runbook has successfully stopped a service on it.
My question relates to whether a single monolithic Automation Account is the way to go, or whether there are any considerations to be taken if we were to implement multiple Automation Accounts.
(I've noticed Best practice to deploy Azure Automation Account Runbooks, but that's over a year ago. Things might have changed in the mean time)
The best practice related question which you have mentioned still holds good i.e., 2 major attributes to consider are pricing and logical resource allocation. One other attribute to keep in mind while deciding whether to go with single or multiple automation accounts is the limits i.e., if you go with single automation account then does the traffic in your environment or the activities that your automation account does reach the limits mentioned here? If yes, then go for multiple automation accounts approach.
I have created a policy which will enable Azure Hybrid Benefit for Windows Servers, Client & SQL. We have multiple subscriptions created based on prod and sandbox. What i'm looking for is, If the subscription is belongs to prod then it should do audit and for others it should do Append. So i think it should have kind of if else condition or where condition, but as i checked i don't see any reference article or any possibble solutions to achieve the same. Can someone guide me how to acheive the same. Thanks in advance!
Regards,
Logan
I would consider setting up an Azure Management Group hierarchy with the first level below the Root MG broken out into Prod and Sandbox. From there, you can scope different Azure Policies (one for Audit, the other for Append) depending on the Management Group the subscription falls under.
I see that in Azure Devops the billing account is set per organization. So, I can do a cost analysis per organization. Is it possible to do the same thing on a project level with labels and etc? I have checked but I couldn't find any labeling for the projects.
I want to see what is the exact cost of each project based on users, pipelines, parallel jobs costs.
I could not find any billing per project as your question states.
As an alternative or workaround ( I'm not saying this is an ideal solution) you could separate your projects in organizations in order to be able to bill them separately.
Just in case here is the link about billing per organization and here is the link for Billing overview for Azure DevOps in case it may give you some more insights.
Is it possible to do the same thing on a project level with labels and etc?
For this issue , I am afraid this is currently not possible in azure devops . Until now, billing only exists in organization level.
You could add your request for this feature on our UserVoice site , which is our main forum for product suggestions.After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it. Thank you for helping us build a better Azure DevOps.
In addition, for detailed information about billing, you can refer to this document.
I'm looking into transitioning all our company systems to MS Azure from our current on-premises setup. We have multiple affiliates operating using their versions of the same system (i.e. a custom built application that is fundamentally the same but is tailor fit to specific business cases/industries.
Is it possible for our mother company to register for MS Azure, and the affiliates exist as separate organizations on that plan? or is each organization required to have its own Azure subscription?
Many Thanks,
Jevb
I saw many different implementations of Azure for companies. Mostly based on per-separate-subscription model, sometimes I saw working with 1 subscription and then splitting teams to Resource Groups, I think it is all up to the company, budgets and goals.
I would recommend to read first these, maybe this will give you some hints how to start and migrate :)
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/reference/azure-scaffold
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/subscriptions/
https://learn.microsoft.com/en-us/azure/governance/management-groups/overview
You can have one tenant for your whole company, and individual subscriptions for each business case. The way that Azure does billing it is nice to split your industries into separate subscriptions until you have a solid tagging strategy in place.
I would highly suggest looking into management groups within Azure as you start to implement policy and RBAC for your individual subscriptions so that you can adhere to security best practices and avoid repeating yourself.
https://learn.microsoft.com/en-us/microsoft-365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings?view=o365-worldwide
https://learn.microsoft.com/en-us/azure/governance/management-groups/overview
We are a software company so we setup solutions for the other companies. I guess we are not unique in this regards :) so I would like to know if we should create a new subscription each time or just a resource group.
Requirements:
We should be able to bill each customer/project separably
They should be able to take control of their resources easily and move to another company
Managing them should not be a headache
What we have tried
We've tried adding a subscription for each customer. This way, we could just change the admin profile and they could completely move away from us.
The billing is also OK, since we receive a different email for each subscription, but managing them is becoming a real headache.
What I guess could work
From what I read, I guess we could work with resource groups instead of subscriptions and handle the billing part with tags (haven't tried it yet. can we?) but then I'm afraid of not being able to move it to another subscription when they've asked us.
Is it even possible? How easy is that? Does it envolve contacting support?
Has anyone tried it?
I would advise against billing using resource groups and tags. The reports are a real mess and 100% unusable. Also, its a lot of extra work for nothing (seriously, do you care if you have 1 subscription or 10?) and adds no real benefit.
Also, you can move resources across subscriptions of different tenants. Best way of handling this is doing a subscription move. That way you dont have to do anything else. They just link your subscription to another tenant and you are good.
I'm talking from a perspective of administering dozens of subscriptions, and believe me, if you move away from subscriptions to resource groups (as a billing\security boundary) you will get completely devastated by the increased complexity of what you are doing.
In my experience working with organisations that provide similar hosting services to customers, I'd say resource groups is the way to go to avoid too much segregation. It's easier for you to keep control of the resources as well as keeping the cost low if you decide to use shared compute resources such as Application Gateway, DDOS protection, etc.
Bear in mind that depending on what level of permission you're giving to your clients, they might have access to information from other clients, so it's important to come up with a good security and governance plan for the Azure environment and strictly limit what they can access.
Moving things from one subscription to another is easy as long as you're using resources within the supported move list. Check the list below:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-move-resources
You don't have to open a ticket with Microsoft to move these resources and the move can be easily done through the portal interface as long as you select all the resources and it's dependencies and you have access to both subscriptions. If your client decides to move their stuff to their own Azure subscription, they will have to give you permission on that. If the resource you're trying to move is not in the supported list, not even Microsoft can move that.
From a billing perspective, I'd say separating by RG and using tags is the way to go as that can be easily filtered in your exported Azure consumption usage report.