I’ve been looking into cloud resources (specifically Azure) and looking at a lot of online tutorials.
One thing I’ve come across is copying resources. Am I right in thinking that I can move or copy resources between other cloud providers and on premise servers by use of Azure migrate, but not from Azure to Azure subscriptions? I have a couple of vms in a work supplied subscription that I’d like to copy to my personal subscription (purely for learning purposes, my company has no problem with this, not stealing any secrets haha) but I can’t figure out a way to do this.
Does any one know how I can achieve this? One is a windows vm and two Ubuntu vms but that shouldn’t make a difference I don’t think.
Looked at Azure migrate but doesn’t seem to copy from azure to azure
Related
I'm coming from Google Cloud Platform, and have been used to creating service agents, essentially user accounts to grant permissions/access that I specify to non human actors, so they can view/modify resources/attributes. I have been exploring Azure all evening and can't quite find something similar to that. Can anyone suggest Azure services or keywords I should do some reading on so I figure out how to implement similar identity and access in Azure?
You'll want to start off by looking at Azure Active Directory Service Principals and Application Registrations. These are the rough equivalent to Service Accounts. You'll also want to research Managed Service Identities, which are a way to simplify the use of Applications and Service Principals. You can start with this page and keep linking from there.
This medium article can give you a good comparison circa 2020.
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
My company has a direction to create web app to be published and sold on Azure Marketplace.
After reading up on the topic on https://azure.microsoft.com/en-us/marketplace/programs/certified/, I am confused that what is actually the right way to achieve what we want to do above.
Do we need to create a VM as a container for our webapp so that it can be sold on Market Place? In this method, are subscribers creating their own VM service from the image we publish? I wonder how are updates/fixes being pushed out to every subscriber.
I then came across AppSource. In this way, are we creating/hosting the app in our azure app service, and users are authorized into the app through AAD (it looks like we have to use AAD authentication?)? Are we able to segregate user data by say, organizations?
I really appreciate if someone can shed some light on this.
For point 1, you could look at this question: Publishing a web application on Azure
i think what you are looking for is the "solution template". it took me a while to get it, but if you look at the docs there is a comparison between "Virtual machine" and "Solution template".
From the docs:
VM example:
As an Azure publisher, you've created and validated a VM with an innovative database service. Other Azure subscribers want to procure and deploy this VM into their cloud service environments.
Solution template example
As an Azure publisher, you've bundled a set of services from across Azure that make it quick to deploy cloud services with load balancing, enhanced security, and high availability. Other Azure subscribers can save time by procuring the solution template that meets their objective. They don't have to manually locate, procure, deploy, and configure the same or similar Azure services.
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.
I'm currently stuck with designing my Azure environments.
What i would like to have is multiple Azure subscriptions that work togheter in a private network with Active directory on the different subscriptions that are synced.
Imagine the following scenario:
I've got two developers, who each have an own Azure Subscription (free with msdn) on which they develop their software.
When they finished the code, they will do a checkin to a visualstudio online and a build server on a second azure subscription will build the code.
When everything is ok, the code will be deployed on a VM in a third subscription.
All this would need to work with synced active directory's and in a private network.
This means that if their is a website created in the thrid subscription, it would only be accesible from a VM in subscription 1 or 2
So as resume:
1 subscription for the developer to developer code (visual studio, AD, sql, ...)
1 subscription for building the code of the developer
1 subscription for collect all the code and test the software (AD, SQL, website, ...)
Only subscription 1 should be able to access VM's, websites, ... in subscription 2 or 3.
Could any of you advise how I should set up the Virtual network, VPN, ...? Or maybe is just not possible?
Thanks in advance!!
Today's Virtual Network feature does not let you span data center regions, subscriptions, etc. as far as I know, sorry!
I'm sure people are looking at what it would take to support this sort of scenario someday.
I'd recommend to look at Azure VNet-to-VNet VPN gateway. It works fine through different regions and Azure subscriptions.