Microsoft Azure cloud supports three roles Web, Worker and VM with different capabilities to be utilized by application developers.
If I understand correctly when we use Web or Worker role, Azure acts more like PaaS while using VM role puts Azure in IaaS role.
Web, Worker roles has the advantage of OS/Platform being managed by the Fabric Controller (updates to OS etc), where with VM we have to manage those ourselves.
My question is, if we implement a private cloud using solutions provided by Microsoft, Can we still create Web/Worker roles on our private cloud, or is it limited to VM roles?
Cloud Services, which you're describing, are comprised of Web / Worker / VM roles, with Web and Worker OS's maintained by Microsoft and VM Role maintained by you (with multiple instances all based off the baseline image you upload). In all three cases, any type of new image creation is like starting fresh: changes made to the OS while running are not permanently persisted. VM Role does not put Windows Azure into IaaS mode, as the fabric is still using a single baseline image to manage role instances. IaaS, with Virtual Machines, is a bit different, with the Virtual Machines constructable in the cloud (vs. VM Role that requires them to be built locally and then uploaded). Further, any change to a Virtual Machine is persistent. When scaling to multiple instances, you'd need to make VHD copies from your master image, and then each instance would be living on its own (e.g. a change to one Virtual Machine will not show up in the other Virtual Machines).
Having said all that: You have access to Cloud Services (web/worker/vm role) only in Windows Azure today; there's no way to run these locally.
Recently we announced the availability of Windows Azure services for Windows Server. You'll see that there is a subset of Windows Azure features runnable on Windows Server:
Web Sites
Virtual Machines
Service Management Portal and API
The answer is not yet. WebRole and WorkerRole PAAS are relying on Azure Fabric Controller and that thing does not yet run on premise outside of Microsoft's control, as far as I know.
Yea as far as I'm aware you can, I haven't tried it myself, you need to create a VNET and then create your Cloud Services within your VNET, Michael Washam has a good post detailing it: Connecting Web or Worker Roles to a Simple Virtual Network in Windows Azure
Related
I'm trying to migrate a number of solutions into Azure.
The solutions consist of multiple projects but the projects come down to three basic types:
ASP.NET MVC/WebForms Application
ASP.NET WebApi Application
.Net Windows Services (We have a large number of these)
Each of these projects utilize a RabbitMQ cluster that we run.
At the moment these are all running on our windows servers in our data center.
We do not want to just pick up and start running Virtual Machines in the cloud, we want to move to utilize the PaaS offerings as managing and maintaining the servers is not something we want to do.
However I am confused on what Microsoft's recommended process is when it comes to migrating a Windows Service to Azure PaaS. There is talk about Worker roles, Web Roles, Logic Apps and Web Jobs.
It initially looked like worker roles would be the thing to go towards so I implemented a very simple worker role that talks to a RabbitMQ cluster on my local machine and it worked fine.
I then setup 2 virtual machines in a virtual network in Azure (Resource Manager) and now I find that worker roles can only connect to a virtual network created via the classic portal (WTF).
So my question is:
What is the recommended approach to having windows services in Azure, remembering that we want to utilize PaaS offerings rather than IaaS wherever possible.
The documentation seams to be all over the place, some places are talking about the classic portal some are talking about the new portal.
I cannot believe that I'm the first person to ever want to have an ASP.NET WebApp be able to talk to a virtual machine on a Azure Virtual Network and also have some kind of windows service also talk to the same virtual machine.
The answer is, as always, "It depends".
The full answer can be very long, but in 2 words:
You can take new Azure portal as "Azure2.0". Among other changes, Azure completely changed the way its resources are created and managed
As far as Web / Worker roles (cloud services) are belongs to "old" model, you have limitations you described.
WebJobs and Logic Apps can be great, as well as Azure Functions - but each of them is limiting your code / solution to its restrictions.
I'd consider to check out Azure Service Fabric - it should allow you to more effectively deploy and reuse compute resources of your migrated 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.
When you create an Azure VM, it has to be placed into a Cloud Service (either new or existing).
Is that the exact same logical structure as an Azure Cloud Service that's created when deploying Web and Worker roles via Visual Studio?
Can I deploy Roles from VS into a Cloud Service created via VM creation? I can deploy a VM into a Cloud Service created via VS deployment? If either of those are true, how does that "free-standing" VM relate to the Role VMs? Is it just floating inside the Cloud Service independently from the Role VMs?
Thanks in advance!
This really should be on ServerFault, and the question will likely be closed, but...
Treat "cloud service" as a wrapper around either a collection of web and worker role instances or a collection of Virtual Machines, behind a single xyz.cloudapp.net namespace. Both are equivalent to the outside world (that is, accessing a service+endpoint via xyz.cloudapp.net:port). But managed differently.
Virtual Machines cannot be mixed with web/worker role instances in the same cloud service.
I just created a windows 2012 datacenter VM in azure, however I notice in management portal that Azure also created a cloud service with same name. Is this normal?I don't want to be double charged..
This is normal. You are not charged for Cloud Services. You're only charged for actual VM's deployed in them. Cloud Service is just a record in a database and a concept that is used to group Azure resources together
Can i use the Autoscaling Application Block for balancing/scaling the Azure VM role instances?
If this is possible, do i need to include Autoscaling Application Block in the service model definition which is for the virtual machine role?
Thanks a lot.
Yes, you should be able to target VM roles as Wasabi goes through the standard Windows Azure Management API. See the Design of Wasabi section for more info.
WASABi uses standard Diagnostics and Management API which are fully supported by the VM Role. However, if you're not able to get WASABi to work with your VM Role, you can try AzureWatch, a third-party SaaS monitoring & auto-scaling service
No WASABI is not supported for VM Role. It is primarily designed and tested with Web/Worker Roles only. The fact is that if you understood WASABI and plan to use WASABI in VM Role, you might be better of using Web/Worker role instead of using VM Role.
Visit link below for more info:
http://blogs.msdn.com/b/agile/archive/2011/08/23/autoscaling-windows-azure-applications.aspx