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
Related
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
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.
After going through several similar questions I am still not entirely sure about the pros and cons of the two approaches; hence this question.
Based on my understanding it is possible to have
Multiple roles (Web and/or Worker) in a single Cloud service.
Alternatively we can have these roles separated in their own Cloud
service (our current approach).
What are the benefits of either approach over the other and particular use cases where either one should be preferred/avoided.
Also how do they compare to each other when it comes to scalability and availability?
When do I choose which? My understanding at the moment is both offer the same except maybe the pricing.
if you did not see that Azure Multitenancy Guidance, i highly recommend to take a look, because they wrote it using Cloud Services as an example and the link above discusses some of the architecture decisions you are asking of.
IMO, it is difficult to say that first approach is better then the second somehow, it depends on what is the scenario in your project.
I would say that one of the important things are the limits of one Cloud Service. If you have the project that has instances that should be unique for the customer, then it can be more difficult to isolate your users if the solution is in the same CS, etc. A lot of decisions - mostly depends on the project specifics.
One difference between the two approaches is in deployment. Cloud services are deployed with all their web roles and worker roles together. If you need to have separate deployment schedules for some of your roles, separating them into different cloud services will allow you to do that.
As for pricing, I don't think there is a difference as cloud services are billed on a "per (role) instance" basis and this does not change between the two options you described.
I am a newbie to web development
I would like to host my site in azure.
There are so many subscriptions plans.
So which subscription is reasonably good and give me price details of that?
Thanks in advance
Windows Azure has few types of hosting. For a website you might want to look at the following -
Web Sites - You can host right away without modification of your existing project.
Cloud Services - I used this, but it requires changes such as Caching.
Here is the calculator based on your need.
FYI: Rule of thumb is you need a least two instances in Production to minimize the downtime.
If you are a newbie , I would strongly suggest using azure websites for now, and you can always move to a custom solution using webroles/caching Etc later if you feel it doesn't cater all your needs..
Azure websites pricing can be obtained from here :
https://azure.microsoft.com/en-us/pricing/details/web-sites/
Again on what parameters would you choose the right package, you are the best judge for that since you know what traffic are you expecting and how much memory etc you need
I am designing the architecture for an Azure application, and I have a few questions on how to proceed. I am familiar with the basics of Azure, but have never built and deployed an Azure application before. I have extensive experience with conventional non-cloud, web-hosted applications, though.
My application will be the usual database-centric business system with a web user interface. We want to start very small and grow it slowly as we gain user base. I am planning to use an SQL Azure database for relational storage as well as blob storage for documents and the like. These will be accessed by a Data Access Layer, which in turn will be operated by a Business Layer. The web user interface will be built using ASP.NET and will rest on the Business Layer.
All this is very traditional, but I wonder how well it fits with Azure. I have some specific and inter-related questions:
I see the Data Layer and Business Layer as part of an Application Tier that can be deployed on a worker role, whereas the web user interface can be deployed as a Front-End Tier on a web role. Is separating the business and presentation logic like this a wise decision on Azure?
Having said the above, having two separate roles wouldn't make sense while the user base is very small, so I would rather deploy everything together on a single web role until we get bigger. What do I need to do to make sure that these two tiers can be easily reconfigured to work as either one or two roles with any recoding?
The communication between the web user interface and the Business Layer must be fast; I am concerned that it won't be very fast especially when these two are deployed as separate tiers on different web/worker roles. What is the best communications mechanism in Azure that I should use? I have considered queue storage, service bus and virtual network, but I am not sure how to make a decision here.
I have been reading some best practices posts and documents online, but they seem to address advanced issues. I would rather like to have answers to these quite basic concerns in the form of pointers to best practices articles or the like. Thank you.