I am trying to setup the Infrastructure on Azure using the CAF. However, I have a requirement to deploy multiple instance of the Infrastructure specific to the Application(s), say Azure Synapse & it's related components in Dev, Stage, Prod.
I am calling everything from the Root to Connectivity as Azure Landing Zone and Application specific deployment as Azure Vending machine as it deploys multiple instance. Is this fine?
What is the difference between Azure Landing Zone and Azure Vending machine?
The term landing zone is a bit overloaded depending on the context it's mentioned in. Based on the official definition Microsoft uses the terms
Azure Landing Zone (sometimes with an appended "Architecture", which I think clarifies it a lot) describes the entire set up of your Azure Tenant, e.g. your management groups, subscriptions etc. Think of it as "this is where the organization lands".
Platform Landing Zone to describe the subscriptions providing central functions like an Azure vWAN Hub managing on-prem connectivity for your entire org. Think of it as "this is where shared platform services land".
Application Landing Zone to describe the subscriptions where individual applications land. In a lift & shift setting this may be one big subscription hosting multiple apps in resource group, but for something more cloud-native you'd have a subscription for each. Think of it as "this is where an individual application team lands".
The Vending Machine's job is to provision new application landing zones. I find it useful to cut down the specific jargon a bit and think of it more in terms of capabilities, i.e. a vending machine gives you the capability to provision new environments for application teams in a multi-tenant Azure landing zone – so you can call the capability tenant provisioning. The vending machine is just an automated implementation for this type of task as a self-service workflow.
It is almost the same, and yet it is not.
Landing Zones are your subscriptions where your workloads reside. A small environment you could call it. It includes multiple resources and is used in a larger scale to generate the Azure Landing Zone architecture.
Vending Machines are basically fully-working landing zone provisioning. A process for how you will deploy new landing zones via IaC (e.g. Terraform) that will support workload requirements. It is not just the subscription, but also the resources like VNet, Storage accounts, etc.
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/
Related
I can see in Azure portal there is a nice UI to scale instances automatically.
Is there a way to change an app plan automatically?
For example, I may want to move from P1V2 to S1 during out of business hours, then scale back up again in the morning.
If there is no way to do it via the portal, I'm open to using APIs to change the app plans via a schedule functions or logic app if anyone can provide an example.
Any other suggestions are also welcome.
Thanks.
Is there a way to change an app plan automatically?
Not like there is a way to do so horizontally by using auto-scale. You can, however, accomplish this using Azure Automation.
Azure Automation delivers a cloud-based automation, operating system updates, and configuration service that supports consistent management across your Azure and non-Azure environments. It includes process automation, configuration management, update management, shared capabilities, and heterogeneous features.
Your scenario is explicitly mentioned under Common scenarios.
Azure resource lifecycle management - for IaaS and PaaS services.
Resource provisioning and deprovisioning.
Add correct tags, locks, NSGs, UDRs per business rules.
Resource group creation, deletion & update.
Start container group.
Register DNS record.
Encrypt Virtual machines.
Configure disk (disk snapshot, delete old snapshots).
Subscription management.
Start-stop resources to save cost.
Dev/test automation scenarios - Start and stop resources, scale resources, etc.
To set the App Service Plan, use Set-AzAppServicePlan from the Az.Websites module.
In AWS we can define a Serverless App within a VPC. Need not be the case but is considered obviously a good practise.
Can the same be done for an AZURE App Service? I.e. can an AZURE App Service be defined as part of a VNET?
There are a couple of segments to answer your question. Here goes ...
VNet integration
Yes, you can Integrate your app with an Azure virtual network.
With Azure Virtual Network (VNets), you can place many of your Azure resources in a non-internet-routable network. The VNet Integration feature enables your apps to access resources in or through a VNet. VNet Integration doesn't enable your apps to be accessed privately.
Azure App Service has two variations:
The multitenant systems that support the full range of pricing plans except Isolated.
The App Service Environment, which deploys into your VNet and supports Isolated pricing plan apps.
If you're looking for restricting access to the App Services, the article linked in silent's comment is a good read. Especially the Access restrictions chapter.
Access restrictions let you filter inbound requests. The filtering action takes place on the front-end roles that are upstream from the worker roles where your apps are running. Because the front-end roles are upstream from the workers, you can think of access restrictions as network-level protection for your apps.
Infrastructure as Code
The blueprint (or 'cloud template') you're talking about in the comments feels like you need Infrastructure as Code to build/maintain resources for customers that all have the same structure. And while Azure has a service that's called Azure Blueprints, I think that would be overkill for the requirements you're giving.
Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization's standards, patterns, and requirements. Azure Blueprints makes it possible for development teams to rapidly build and stand up new environments with trust they're building within organizational compliance with a set of built-in components, such as networking, to speed up development and delivery.
I think you could implement what you're looking for by creating a (parameterizable) Bicep file to enable you to create/update the resources in a repeatable way as needed.
Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. We believe Bicep offers the best authoring experience for your infrastructure-as-code solutions in Azure.
Noticed Virtual Network and Virtual Network(Classic) in Azure, Wondering what is the difference between them and when to choose what ?
Azure has two different deployment models for creating and working with resources: Resource Manager and classic.
How you create, configure, and manage your Azure resources is different between these two models. In classic mode, each resource provisioned in Azure is a single management unit. You manage all of the resources individually. The classic mode does not allow grouping of resources, which makes managing Azure resources difficult.
Azure resource management mode adds the concept of the resource group, which is a container for resources that share a common lifecycle. In ARM mode, you can deploy, manage, and monitor all the services for your solution as a group, rather than handling these services individually. Also, you can apply tags to resources to logically organize all the resources in your subscription.
When you interact with Classic mode resources from a command line such as Azure PowerShell, you are using Azure Service Management API calls (ASM). ASM is a traditional way of accessing Azure resources. In the Resource Manager mode, you are using Azure Resource Manager Rest API. When a user sends a request from any of the Azure tools, APIs, or SDKs, Resource Manager receives the request. It authenticates and authorizes the request. Resource Manager sends the request to the Azure service, which takes the requested action. See Azure Resource Manager overview.
The Virtual Network(Classic) is used for the classic models. Virtual Network in Azure is created for Resource Manager models. Currently, Microsoft recommends that you use Resource Manager for all new resources. Mostly, the Virtual Network(Classic) is used when you are creating a VNet for cloud services as far as I can tell. For Resource Manager resources, you just need to create Virtual Network in Azure portal.
There are three scenarios to be aware of:
Cloud Services does not support Resource Manager deployment model.
Virtual machines, storage accounts, and virtual networks support both Resource Manager and classic deployment models.
All other Azure services support Resource Manager
Here is a blog about Azure Classic vs Azure Resource Manager
So which one should I use?
Since both modes are viable options at this point, it is necessary to
pay careful attention to the features that each offer and your
specific requirements. ARM cannot simply be assumed to be the best fit
as it simply may not meet all of your or your customer’s needs.
Team,
I have a complete running cloud service application upgraded to latest Azure SDK version and unfortunately need to dump this into a CSP subscription. But I came to know that Azure CSP supports only the Azure Resource Manager model, the cloud service is a classic deployment model. So we cannot create a cloud service within a CSP subscription.
Is there any other alternative within Azure CSP to using "cloud service" so that we can migrate with minimal changes. Please help
Firstly, here are some good reads on Microsoft Docs to help comparing the options available and make decisions based on your requirements:
(I mean requirements like Hosting features, Service Limits, 3rd party software installation and RDP access is required or not, Network isolation to a separate VNET is required or not, Cost considerations, minimum SLA, Regions available, instant deployment and auto-scaling, state management etc.):
Azure App Service, Virtual Machines, Service Fabric, and Cloud Services comparison
Decision tree for Azure compute services (This one covers a big spectrum.. simple virtual machines, Batch, Functions, Containers, AKS, ServiceFabric)
Criteria for choosing an Azure Compute Service
Also know that when looking for alternatives, it's not uncommon to make use of multiple compute or other Azure service options by breaking up an older solution into parts at the time of such migration (for e.g. A serverless compute option like Azure Function + Service Fabric + something else if needed).
Generally speaking (and without knowing much about your application from your question currently), Azure App Service and Service Fabric could be considerations IMHO when migrating from an existing Cloud Service, but this is exactly where detailed requirements help you in decision making.
On a side note, here is a list of Azure Services available in CSP - Available Azure services in Azure CSP
In Azure there are 2 options available to create virtual machines.
A. normal VM
B. Classic VM
Does anybody know what is the difference between both option? When do we use one over other?
Short answer to your question is Normal VM or Virtual Machines is the new way of deploying your Virtual Machines whereas Classic VM or Virtual Machines (Classic) is the old way of deploying them. Azure is pushing towards the new way of deploying resources so the recommendation would be to use it instead of old way. However please keep in mind that there're some features which are available in the old way that have not been ported on to the new way so you just have to compare the features offered and only if something that you need is not available in new way, you use the old way.
Now comes the long answer :)
Essentially there's a REST API using which you interact with Azure Infrastructure.
When Azure started out, this API was called Service Management API (SMAPI) which served its purpose quite well at that time (and to some extent today). However as Azure grew, so does the requirements of users and that's where SMAPI was found limiting. A good example is access control. In SMAPI, there was access control but it was more like all-or-none kind of access control. It lacked the granularity asked by users.
Instead of patching SMAPI to meet user's requirement, Azure team decided to rewrite the entire API which was much simpler, more robust and feature rich. This API is called Azure Resource Manager API (ARM). ARM has many features that are not there in SMAPI (my personal favorite is Role-based access control - RBAC).
If you have noticed that there are two Azure portals today - https://manage.windowsazure.com (old) and https://portal.azure.com (new). Old portal supports SMAPI whereas new portal supports ARM. In order to surface resources created via old portal into new portal (so that you can have a unified experience), Azure team ended up creating a resource provider for old stuff and their names will always end with (Classic) so you will see Virtual Machines (Classic), Storage Accounts (Classic) etc. So the resources you create in old portal can be seen in the new portal (provided the new portal supports them) but any resources you create in the new portal using ARM are not shown in the old portal.
The Azure Virtual Machine (classic) is based on the old Azure Service Management Model (ASM). Which revolved around the concept of a cloud service. Everything was contained inside a cloud service, and that was the gateway to the internet. While it is still used (extensively) Azure is now moving over to the Azure Resource Management Model (ARM).
ARM uses the concept of declarative templates to configure an entire solution (rather than individual components) So you can create an entire Sharepoint stack, rather than just a singular machine.
ARM also has a much more logical approach to networking. Instead of having a monolithic VM in an obscure cloud service. You have a VM, that you attach a network card to. You can then put the Network card into a VNet and attach a public IP (if you need one)
Unless you have a compelling reason to use ASM (classic) You should create your solution using ARM. As this is the MS recommendation going forward (todo find a link to that) It also means that you can create templates for your deployments, so you can have a repeatable solution.
On the negative, the old portal manage.windowsazure.com can not manage anything that is deployed using ARM, and there are still parts of ASM that haven't been migrated over to ARM yet. For instance you cannot configure Azure VM backup, since Azure backup is ASM and it can't 'see' ARM VMs
It very largely depends on your circumstances though, what it is you are planning for, the method you are going to deploy with. If you are just looking to stand a machine up to do a single task, it makes very little difference. If you are looking to deploy into an environment that will have some concepts of DevOps going forward, then ARM is the way to go.
The one big differences is for resource management. For that new version is called Azure Resource Manager VM (ARM VM).
ARM VM is better in terms of;
Classic VM must be tied with Cloud Service, and Cloud Service consumes resource limitation and not-so-flexible network configuration.
ARM VM is managed under Azure Resource Manager (ARM) which can be organized with/without other Azure services. ARM is like a folder of Azure services, and it gives you more fine-grained resource management.
Classic VM can be migrated to ARM VM version, but you have to afford service downtime. To migrate from classic VM, read the official article: Considerations for Virtual Machines.
Azure provides two deploy models now: Azure Resource Manager(Normal) and Azure Service Management(Classic) and some important considerations you should care when working Virtual Machines.
Virtual machines deployed with the classic deployment model cannot be included in a virtual network deployed with Resource Manager.
Virtual machines deployed with the Resource Manager deployment model must be included in a virtual network.
Virtual machines deployed with the classic deployment model don't have to be included in a virtual network.