We have existing Azure Subscription and resource groups for the applications.
I was going through Cloud Adoption Framework and came across Landing Zone to setup "Enterprise " best practices using automation (Infrastructure as code).
My question how we can use the "Landing Zones" to transform existing Azure infrastructure ?
There's roughly two approaches you can follow
set up a landing zone in a separate part of your AAD Tenant's resource hierarchy (i.e. a separate management group) and then move existing workloads over into it
incrementally build landing zone capabilities around the infrastructure you already have deployed
The first approach is more appealing when you have little experience with building key cloud governance functions implemented by landing zones (e.g. resource policies, tagging policies, audit logging). The risk here is that moving existing workloads under the new Management Group could break workloads and deployments. You can use e.g. terraform-azurerm-caf-enterprise-scale for this approach.
The second approach will allow you to iterate in smaller steps around your existing infrastructure and design a landing zone that best fits the workload. You can roll your own IaC automation to build management group hierarchy, configure policy etc. around your existing infrastructure using terraform, ARM, or whatever IaC tool your team is comfortable with. There are also frameworks like Landing Zone Construction Kit if you like a more structured approach instead of assembling your tools from scratch.
My experience with many teams is that end to end landing zone examples (like Azure's enterprise scale examples) are a great starting point for exploring what landing zones can do and learn how to build those capabilities, but in practice you have to customize the landing zones for your specific workload and application team needs anyway.
It is way more complex than just “use” landing zones.
But maybe in your case you just need to use Blueprints to create a resource consistency deployment for your new subscription.
You need to understand how/when/why to use Landing Zones to understand why I said is too complex in you case (which kind of network topology are you using? How this new landing zone will fit to your architecture? Etc…)
Refer to (https://learn.microsoft.com/en-us/azure/governance/blueprints/samples/caf-migrate-landing-zone/) to see how this Template implements Landing zone.
You can import state with the rover container. Or manually import the state into the statefile. The latter options is pretty messy and should be avoided if possible.
https://github.com/aztfmod/rover
Related
Currently, I am working on establishing enterprise-scale landing zones for Cloud Adoption Framework in Azure.
As part of the activity, I need to define the naming standards across resource groups, environments, physical location, products/types, applications, clients.
I understand that this is more a personal/organizational decision, but I'd like some examples before I can begin working on it. Do you have any suggestions?
If you are deploying a hybrid environment I could imagine that you might have some organizational requirement to follow.
If it is cloud-only, then this is a good starting point: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming
The article has a good list of examples
Maybe equally if not more important is imho the tagging scheme: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-tagging
I've been reading through the Microsoft Cloud Adoption Framework for some time now. In our company, we have a similar implementation (hub-spoke), but a lot less modular like it is depicted in the docs. We don't have an identity or management subscription for example.
When looking at our own hub-spoke architecture, we basically only have 2 spokes: non-prod and prod in which we deploy all applications (VMs) inside one big VNet (one per spoke). Since we have hundreds of VMs ranging from very small tools on a single VM up to large complex setups with dozens of VMs, we would eventually also have many landing zones (and therefor VNets) I suppose? Our hub contains central shared services like the firewall, domain controllers etc.
Important to know is that we don't do any in-house application development or let other departments like marketing deploy Azure resources themselves. We basically setup Azure infrastructure into the spokes from within our central IT infrastructure department and give external partners access to deploy their applications into it.
What I'm particularly curious about is when you would decide to create a new landing zone in this architecture? Would you have a landing zone for each application? One for each department to enable self-service? Is our approach a good idea?
Very interested to learn how other companies are implementing this architecture.
The big part of enterprise scale landing zone is probably the modules you mentioned that are missing in your implementation.(Or any start small type of land zone)
Enroll in EA so you have an account to manage multiple subscriptions
Have the proper resource organization in place(management groups and
subscriptions).This ensures that you can deploy policies and RBAC
etc at the proper level.
Landing Zone sits on much high level than the applications(resource groups). There is no need for more than 1 Landing Zone. You maybe need to extended it, by either creating new Spoke, and/or in some case new subscription.
I have an Azure subscription and there are a number of services available.
If I configure VM, web apps, application. etc.,
there are few high-end resources which are very expensive.
In order to avoid unwanted billing,
I want to create a policy that allows only a few services and lower configuration resources.
Is there an Azure policy that can do that?
If I configure VM, web apps, application.. etc there are few high-end
resources which prices are high. In order to avoid unwanted billing, I
want to create policy there allow only a few services and lower
configuration resources
Do take a look at Azure Policy. In short, Azure Policies enables Cloud Governance and by defining proper policies, you can restrict creation of certain kinds of resources, disallow certain SKUs for resources and more.
However, as a good practice, you should have only few people in your organization who have the capability to provision resources and there should be a formal procedure for provisioning resources. One of my friend burned $180,000 in Azure in just 3 months because every developer in his team has the capability to create resources in the company's Azure Subscription. The developers in the team created resources as they pleased without thinking about pricing implication.
I have multiple services running on Service Fabric. I would like to add Application Insight for logging. I'm just wondering whether I have to add an Application Insight resource for each microservice or only one is common for all. What is the best practice?
There is no such thing a the best practice for this. It really depends. Some considerations:
Pricing: depending on the level (basic or enterprise) you will get an amount of data for free / included in the base price. See the docs. So in some cases, depending on the amount of traffic you can reduce costs by having a dedicated AI resource per service. AI resources for services that send data below the threshold of the AI pricing plan are then (almost) free.
Querying: if you split up services per AI resource getting an overview of the whole system is difficult since at the moment you cannot create queries spanning multiple AI resources.
Responsibility: If you have multiple teams working on multiple services it might be an option to have an AI resource per team so they have a good insight in only the parts they are responsible for.
If you do decide to use a shared AI resource there are options like custom telemetry initializers to include custom data that further identify which ASF application or service is sending the data if it is not included by default.
See also Add Application Insight to a existing Azure Service Fabric cluster for more info about how to integrate AI.
Now, when it comes to bring data together you do have some additional options that may or may not need additional services or configuration. For example:
PowerBi: You can visualize data of AI resources using dashboards, see https://learn.microsoft.com/en-us/azure/application-insights/app-insights-export-power-bi
OMS: Operation Management Suite, See https://blogs.technet.microsoft.com/msoms/2016/09/26/application-insights-connector-in-oms/. As Jesse mentions you can link multiple AI Resources
Custom dashboards: Using the rest api you can create your own solution that displays data for one or more AI resources.
I want to host an Orleans project on Azure, but don't want to use the (classic) Cloud Services model (I want an ARM template project). The web app sample uses the old web / worker model - what is best option? There is a Service Fabric sample - is that the best route? The nearest equivalent to the web/worker model is VM Scale Sets - is that a well tested option?
IMO, app service is closet to web role.
Worker role however, depending on the point of view
From system architecture point of view, I think Scale Set is the closet. You get an identical set of VMs running your application. However you lost all management features. How your cluster handle application configurations, work loads on each node, service interruptions from server failure or deployments are pretty much DIY. Also you need to provision the VM with dependencies for your application.
From operations point of view, I think Service Fabric is the closest. It handles problems above but then you are dealing with design/implementation changes and learning curve from the added fabric layer in the architecture. Could be small, could be big depending on the complexity of your project. Besides, service fabric is still relatively new and nothing is for sure. Best case you follow the sample change a few lines of code and it works like a charm. Worst case you may want to complete refactor orleans solution into service fabric solution.
App service would be the easiest among the three. If it doesn't meet your requirement, I personally would try Service Fabric. Same reason why people are moving to cloud and you would opt for ARM solution.