If you have visited before on the pages of this blog, you may have seen this article : “Azure VNET to VNET VPN, across regions and data centers: not so complicated”. At that point, I wrote about how to put in place a connection between multiple Azure Virtual Networks, in particular a VNET-to-VNET-to-VNET relationship. All based on PowerShell scripting and classic deployment in Azure.
Today is the time to write again about this subject, but this time under a new cover related to several aspects: ARM (Azure Resource Manager) deployment, usage of the new Azure Portal, and application of new networking concepts in Azure, like VNET Peering.
This is a two-part series of articles on these aspects. The series is related to the publication of a dedicated MS Experiences Online recording. In the recording we speak about these concepts, so I will focus here mainly on detailing and documenting the forenamed recording.
The first article includes the business case, the networking concepts and topologies and their applicability in Azure, and the technical solution we propose for the given use case.
We propose to make communicating multiple environments (or resources) between each-other, in a IaaS (networking) context. That may be within the same Azure data center or region, or across regions. For this, we are required to put in place network connectivity between these environments.
To put it even more concrete, we chose to facilitate the deployment of a SQL Server AlwaysOn Cluster (available with SQL Server 2012 editions and later ones), cluster to be deployed as follows:
- 1 primary replica in Dublin (North Europe region)
- 1 secondary replica in Dublin
- 1 secondary replica in Amsterdam (West Europe region)
The solution will be focused on the network connectivity aspects, and not on the network security ones.
Azure Technical Concepts and Services
The following concepts will be used in the next lines, so we need to reference first the corresponding definitions in the Azure documentation:
- VNET – Virtual Network, Subnet [https://docs.microsoft.com/fr-fr/azure/virtual-network/]
- Public IP [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-ip-addresses-overview-arm]
- Network Interface Card [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-network-interface-overview]
- VPN Gateway [https://docs.microsoft.com/fr-fr/azure/vpn-gateway/]
- ExpressRoute [https://docs.microsoft.com/fr-fr/azure/expressroute/]
- VNET Peering [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-peering-overview]
- Network Security Group [https://docs.microsoft.com/fr-fr/azure/Virtual-Network/virtual-networks-overview]
- Virtual Appliances [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-networks-overview]
- User Defined Routes [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-networks-udr-overview]
Most of these are already known and used from some time. I will insist on one concept only: the VNET Peering. As stated in the documentation, it practically allows you to join 2 VNETs located in the same region, by passing directly through the local backbone without needing a VPN gateway. This is very practical, as the VMs across the 2 VNETs will communicate with each-other on a bandwidth limited by the VMs’ network cards only.
Let’s take a look at the networking structure of the original environment as we assumed it in our scenario.
The first VNET, named “net1dublin”, based in Dublin DC (North Europe): a classical VNET configuration, with a 10.0.1.0/24 range and composed from a single subnet named “default” having 10.0.1.0/25 range.
There is a single virtual machine deployed in this subnet, named “vm1net1”, having attached one network card with the IP address 10.0.1.4. As remark, the access to the VM is controlled via the Network Security Group “nsg1net1”.
Similarly, we have a second VNET in Dublin, “net2dublin”, range 10.0.2.0/24, containing the VM “vm2net2” with the IP address 10.0.2.4.
Finally, the third VNET, deployed in Amsterdam DC (West Europe), is named “net3amsterdam”, has an IP range of 10.0.3.0/24 and contains the VM “vm3net3” having the IP address 10.0.3.4.
In our scenario – a SQL Server AlwaysOn cluster – we would have:
- “vm2net2” : primary replica (“master”) in Dublin
- “vm1net1” : a synchronous secondary replica in the same region
-“ vm3net3” : an asynchronous secondary replica in Amsterdam.
Networking Architectures and Topologies
1. Simple hybrid topology
First of all, will remind the simple topologies, starting with the “classical” hybrid Azure-VNET-to-On-premises-Network:
This “point-to-point” topology es at the base of all coming ones. The connection is made either over public internet (IPSec Site-to-Site VPN Azure, via an VPN Gateway in Azure and a network gateway device on-premises), or over private infrastructure (Azure ExpressRoute + typical MPLS infrastructure put in place for you by the provider of your choice and availability). You can have – if you need, for example, in a HA / DR architecture – both S2S VPN and ExpressRoute working at once.
2. Simple cloud-only topology
Now we’ll apply the same concepts for S2S VPN, but this time between 2 VNETs (in the same region or across regions):
So the solution is quite similar, but you will simply pass through the Microsoft backbone infrastructure. Note that you can make profit of your hybrid ExpressRoute circuit – if any – to put in connection Azure VNETs also. In that case, the S2S VPN Gateways will be replaced by ExpressRoute ones.
Under the same simple cloud-only topology, you may have this time a VNET Peering put in place (if the VNETs are in the same region):
Note that you can connect either ARM-to-ARM VNETs or ARM-to-Classic VNETs. This is a perfect solution for Azure “legacy” infrastructure” (a bit strange to speak about “legacy” in Azure ) deployed on classic networks, in order to avoid their migration to ARM if not absolutely necessary, while still let them communicate with all the new [ARM] deployments.
3. Complex topologies: Hub & Spoke
When the requirements become more complicated, we will use adapted connectivity patterns to cover them. Here is the “Hub & Spoke” topology.
Cases are when there is a central system which needs to communicate with “satellite” systems. In the case of an SQL Server AlwaysOn cluster with multiple replicas for higher availability and throughput, the VNET of the master replica will be “surrounded” by the VNETs corresponding of secondary replicas.
In this case, we will configure simple bidirectional communications between the master VNET end the satellite VNETs. Any of the direct connectivity options described before (IPSec VPN, ExpressRoute if the case, or Peering) can be used here.
Note that the Hub & Spoke topology doesn’t imply connectivity transitivity : the left VNET won’t (necessarily) communicate with the right one.
4. Complex topologies: Daisy Chain
This can be achieved in Azure via User Defined Routes functionality. But you will find another solution out a bit later in the article.
If the Daisy Chain topology has the advantage of getting profit of a connection already established (e.g. center with right) for the usage of another VNET (left one), you may have surely seen its inconvenient also: if the VNET on the center (or its gateway) loses its connectivity, it will also affect the connectivity between the lateral VNETs.
5. Complex topologies: (Full) Mesh
The Full Mesh let you master with precision the direct connectivity between various VNETs, without having dependencies on intermediate VNETs or their gateways :
On the other side, definitely there is much more work to getting it done; also, the complexity increases exponentially with each new VNET you want to add to the topology.
You may remark, by the way, that the picture reflects a Mesh which is not “full” actually; it’s up to you to decide if you want the left VNET communicate with the right VNET.
How do you implement a topology like this in Azure? The VPN gateways let you create this type of connectivity, but you can put it in place very quickly with multiple VNET peerings.
Technical Solution for the Given Scenario
Let’s depict the technical solution we propose for our business case:
So, recall that we have a primary replica in VNET2, and we need a secondary replica in VNET1 and another one in VNET3.
The solution is composed of 3 main segments:
1. VNET Peering between VNET2 and VNET1 (both VNETs being in the same region)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3 (Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1. This connection transitivity will be configured in the VNET Peering settings directly.
You will find the implementation of this solution in the next (and last) article of this series: http://blog.lecampusazure.net/2016/11/azure-multi-vnet-topologies-in-arm-era.html.
This article is the second (and the last) one of the series dedicated to Azure Multi-VNET Topologies in ARM implementation. You may find the first article here: http://blog.lecampusazure.net/2016/11/azure-multi-vnet-topologies-in-arm-era-1.html .
We will continue with the implementation of the technical solution as it was defined in the first article.
Technical Solution for the Given Scenario
The diagram for the technical solution we proposed is below:
The solution is composed of 3 main segments:
1. VNET peering between VNET2 and VNET1 (both VNETs being in the same datacenter)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3 (Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1, configured in the VNET Peering settings directly.
a. VNET Peering configuration
The first part of our implementation consists in putting in place the NET Peering configuration between VNET1 and VNET2.
For this, in the “net1dublin” Settings, section Peerings, we will add a new peering, by giving it a name, selecting the corresponding VNET (“vnet2dublin” in our case):
Then you will see the peering listed in the Peerings list:
See that the Peering status is “Initiated” at this stage.
Similarly, let’s add a peering in the other way – “net2dublin” to “net1dublin”:
Here it is, listed in “net2dublin” ‘s Peerings list:
Quickly, both Peerings pass in the Connected state. You can see it if go back in “net1dublin” ’s Peerings list:
And that’s all for the VNET Peerings part
Testing the VNET Peering
At this point, you can already test the connectivity between the two virtual machines deployed across the networks. Download the proposed RDP file for the first VM (click “Connect” in the VM blade), connect via RDP to the VM, “vm1net” (private IP identified as 10.0.1.4), and then ping the second one, “vm2net2” (private address 10.0.2.4):
In the same way, test the connectivity from vm2net2 to vm1net1:
You may remark the very fast response time between the two VMs (and the underlying networks).
b. VNET-to-VNET VPN configuration
Now let’s add the VNET-to-VNET VPN configuration. We will start by creating a first VPN Gateway, “gw1net1”, for “net1dublin”. From the Azure portal, add a new Virtual Network Gateway as follows:
Note the main steps during this configuration:
- selection of the gateway type: VPN
- selection of the VPN type: route-based (known also as “dynamic” gateway)
- selection of the SKU (which will give you the expected performance level)
- selection of the VNET
- configuration of the IP address range for the gateway instances (which will create behind a dedicated subnet in our VNET)
- configuration of the Public IP Address (newly created, by default, or select an existing one).
The result (after 30-45 min, the gateway provisioning is quite long) will look as follows:
The same steps will be followed for the second VPN Gateway, “gw3net3”:
And here is the result for this configuration:
After creating the gateways, we will create the connections between the gateways. We need to create 2 VNET-to-VNET connections, that is one connection from the first gateway to the second, and another way around.
From the gateway “gw1net1” Settings, Connections, add a new Connection “conn-net1-net3”:
Configure it as follows:
- type: VNet-to-VNet
- second gateway: “gw3net3”
- shared PSK key (a string to your choice).
Here is the result:
The connection is created, but the status either “Unknown” or “Not connected” at this stage:
The connection with its details:
Proceed in the same way to create a connection “conn-net3-net1”, from “gw3net3” to “gw1net1”. After a few seconds (52, to be precise ), we have the result :
At this stage, you will see the 2 connections in both “gw1net1” and “gw3net3” settings.
After a few minutes of attempts, you will see the 2 connections passing in “Connected” status:
Testing the VPN connection
If you connect remotely to “vm3net3”, from there you will be able to ping the VM “vm1net1”:
Note the ~25ms response time between the 2 datacenters at a few hundreds kilometers distance, which is a very good performance indeed.
c. Connection Transitivity
There is one last piece missing from the assembly : connectivity between “vnet2dublin” and “vnet3amsterdam”.
Due to the awesome implementation of the Peering feature, this will be solved by 2 clicks configuration only:
1. In the “net1dublin” settings, “net1-net2-peer” peering, under Configuration, check “Allow gateway transit” checkbox:
2. In the “net2dublin” settings, “net2-net1-peer”, under Configuration, check “Use remote gateways” checkbox:
And that’s it. Really!
Testing the connection transitivity
As you may expect, the ping from “vm2net2” to “vm3net3” will start working:
And the same thing in the other way:
We have seen together the essential networking concepts and architectures to be able to implement simple or complex topologies in the Cloud, depending on our needs.
You have seen demonstrated the implementation of a relatively complex VNET-to-VNET-to-VNET topology, within the same Azure region and across regions.
With the switch to the Azure Resource Manager (ARM) deployment model in Azure, the previously existing functionalities in classic model were ported and published in the new Azure portal, but also simplified enormously. The new features like VNET Peering are equally configurable in a simple manner and are integrated seamlessly, permitting the connection transitivity via adjacent VPN gateways, or more advanced scenarios like IP forwarding for the usage of VPN appliances.
Scripting and Automation
As the ARM deployment model is based on ARM templates, you can have the complete solution implemented as ARM template which can be used in automation scenarios.
Here is for conformity a screenshot showing the resource group of the demo implementation:
For automating the deployment, you can either develop the ARM template in your preferred tooling (like Visual Studio or VS Code), or export it directly from the portal (from the resource group level).
Please note that as of today not all the resources are exportable as is from the portal; some of them are not yet available. However, you can still go to Resource Explorer (http://resources.azure.com) and extract the template elements from there.
The “MS Experiences Online” corresponding video (in French, named: “Architecture et topologie Azure multi-VNet”) is available on https://experiences.microsoft.fr/.
A “From-Zero-to-Hero” white-paper on this subject (in French also) is available on Cellenza’s blog.
A demo ARM template of this technical solution is available on GitHub: https://github.com/LeCampusAzure/demo-assets.
After Cloud Expo Europe, I will head to Belgium on December 3rd, 2016, for one of the famous conferences in the region, CloudBrew:
There, I will speak about “Azure Networking - innovative features and Multi-VNET topologies” :
“Are you looking to deploy a more complex structure of resources in Azure, all secured and segregated by precise boundaries while closely communicating with each other? Following the arrival of the advanced IaaS networking features in Azure (network security groups, routing, multi-NIC,…) and their maturation in the last months, here is the moment for you to find a modern architectural vision of networking in Azure, with focus on multi-VNET / VPN topologies, and based on ARM deployment model”
If it sounds interesting to you, link to http://cloudbrew.be/ and check the organizers’ web site.
On November 29th and 30th, at the Exhibition Center Porte de Versailles Paris, will take place the conference Cloud Expo Europe & Data Centre World 2016.
Within this conference I have the honor to be speaker in a session dedicated to Cloud governance and identity : “Gouvernance unifiée et sécurisation de vos ressources Cloud avec Azure Active Directory”. This session will be held on November 30th at 15h, on Hall 6, and will include Q&A on the subject.
If you are interested by these problematics as well as by Microsoft Azure services and Cloud architectures, or if you want to simply meet me, you will be welcomed.
Here is for reference a link to the session, on the organizers’ web site.
ContextIn most demos and tutorials about Azure (and not just that) you will find a variety of resources provisioned in "fast / light" mode, that is to say without being super strict on concepts such as naming artifacts. "WebApp1", "MyVM", "MyRG" are names commonly found in demonstrations or even the "Proof-of-Concepts" (which are supposed to be much more than basic demos).
No particular concern at this point, we're supposed to be focused on the principles and concepts of the demo involved. But what about what about naming Azure artifacts when moving to a real project or an application to put into production? How do we ensure that the names we choose will be well in tune with the architectural complex context, environment, safety, operation of this application, project or system?
Naming in IT projectsFirst, the notion of strict naming is not specific to Azure; each IT project should follow a set of naming rules, rules that will help to properly structure the project, easily find the terms we already knew before, or even be able to identify resources exposed in lists not always structured. Naming rules are present in each programming language, in each infrastructure provisioning.
That said, there are concepts specific to the cloud (even specific to Azure) which will complement the already existing concepts. We must first catalog the list of naming aspects that is applicable for our organization, our project and our cloud.
Key principles:Today, who said cloud, said agile mind. The cloud itself (and the public cloud in particular) is agile by his speed provisioning, scaling elasticity, and especially its fast pace of updates and new features. To respect this spirit, rules must accept flexibility. One should not be blocked to deploy a prototyping environment because, for example, the project name has not been clearly defined, or the type of artifact or resource is fresh in the cloud; however, even in this case, we should be able to easily understand afterwards in what context the resource was provisioned (if only for environment deprovisioning to avoid Azure consumption). This article will not try, so, to impose a set of rules as universal, but rather guide you how to define your own set of rules and then apply. That said, we still try to exemplify concretely (and for those who will see the example very close to their cases, apply directly the model in its state). Finally, the last "disclaimer", the dynamic spirit of the Azure will make possible that certain rules or constraints no longer apply (or are different) at the time of reading. In this case, a feedback from you will be very useful for the update of the article.
What’s a name of an Azure resource?Let’s start from the base: the name of a resource Azure represents a string which allows unique identification of the Azure resource.
The very general vision of this definition stops here:
- The name itself can be a simple "code" unique, or may correspond to a "namespace" (ex. Azure Service Bus), an "account name" (ex. Azure Storage), a "hostname" (ex. Azure VM) or other specific significance to the type of resource
- Unique identification, where? Names can have a context (scope) global public (eg. Based on an Azure subdomain, like the Azure Service Bus namespaces, Azure Storage accounts etc.), local to the subscription (eg. Azure VNET) or local to the parent resource (ex. the names of files or blobs in Azure Blob Storage container)
- To further complicate the task, some types of resources have naming rules different for different types within the same type (difficult to understand? example: the Azure VMs have stronger constraints - maximum 15 characters - for VMs based on Windows, than on Linux. Historical issue, of course, coming from on-premises infrastructure, but that is reflected in the cloud naming).
- The characters allowed in names also vary; but we can identify some sets of applicable characters - like below (but not limited to):
- Alphanumeric (numbers and letters)
- Alphanumeric plus underscore and dash
- Alphanumeric plus underscore, dash and dot
- Any character allowed in a URI
- Any character
- Case sensitive names (ex. blob names in Azure Storage container)
- Case insensitive names (eg. resource groups)
- Mandatory lowercase names (eg. the Azure Storage accounts)
Hence once again the importance of this naming structuring task. It is not unusual that you start with the rules that you consider sufficient (for the types of resources you deal with at that time) and which fall blocking for the naming of the very new resource you need in your project).
Naming constraints for Azure resourcesTo give you a more accurate and centralized reference for these constraints, here they are (compiled from the Azure documentation and following the requirements outlined in the resources creation process):
|Resource or artifact||Context (Scope)||Min len||Max len||Case||Valid character set|
|Resource Group||Global||1||64||Insensitive||Alphanumeric, underscore and hyphen|
|Availability Set||Resource Group||1||80||Insensitive||Alphanumeric, underscore and hyphen|
|Virtual Machine (Windows)||Resource Group||1||15||Insensitive||Alphanumeric, underscore and hyphen|
|Virtual Machine (Linux)||Resource Group||1||64||Insensitive||Alphanumeric, underscore and hyphen|
|Storage account||Global||3||24||Lower cap||Alphanumeric|
|Azure Storage Container||Storage account||3||63||Lower cap||Alphanumeric and hyphen|
|Azure Storage Blob||Container||1||1024||Sensitive||URL characters|
|Azure Storage Queue||Storage account||3||63||Lower cap||Alphanumeric and hyphen|
|Azure Storage Table||Storage account||3||63||Insensitive||Alphanumeric|
|Azure Storage File||Storage account||3||63||Lower cap||Alphanumeric|
|Virtual Network (VNet)||Resource Group||2||64||Insensitive||Alphanumeric, underscore, hyphen and point|
|Network Subnet||Parent VNet||2||64||Insensitive||Alphanumeric, underscore, hyphen and point|
|Network Interface||Resource Group||1||80||Insensitive||Alphanumeric, underscore, hyphen and point|
|Network Security Group||Resource Group||1||80||Insensitive||Alphanumeric, underscore, hyphen and point|
|Network Security Group Rule||Resource Group||1||80||Insensitive||Alphanumeric, underscore, hyphen and point|
|Route table||Resource Group||1||80||Insensitive||Alphanumeric, underscore, hyphen and point|
|ExpressRoute Circuit||Resource Group||1||80||Insensitive||Alphanumeric, underscore, hyphen and point|
|Public IP Address||Resource Group||1||80||Insensitive||Alphanumeric, underscore, hyphen and point|
|Load Balancer||Resource Group||1||80||Insensitive||Alphanumeric, underscore, hyphen and point|
|Load Balanced Rules Config||Load Balancer||1||80||Insensitive||Alphanumeric, underscore, hyphen and point|
|App Service Plan||Subscription||2||40||Insensitive||Alphanumeric|
|Web App||Global||2||60||Insensitive||Alphanumeric and hyphen|
|Function||Global||2||60||Insensitive||Alphanumeric and hyphen|
|Mobile App||Global||2||60||Insensitive||Alphanumeric and hyphen|
|Logic App||Global||2||60||Insensitive||Alphanumeric and hyphen|
|API App||Global||2||60||Insensitive||Alphanumeric and hyphen|
|App Service Environment||Global||2||60||Insensitive||Alphanumeric and hyphen|
|App Service Certificate||Global||3||15||Insensitive||Alphanumeric|
|Notification Hub||Subscription||1||260||Insensitive||Alphanumeric, underscore, hyphen and point|
|Notification Hub Namespace||Global||2||50||Insensitive||Alphanumeric and hyphen|
|SQL Database||Subscription||1||28||Insensitive||Alphanumeric, underscore and hyphen|
|SQL Server||Global||1||63||Lower cap||Alphanumeric and hyphen|
|SQL Data Warehouse Database||Subscription||1||28||Insensitive||Alphanumeric, underscore and hyphen|
|Document DB||Global||3||50||Lower cap||Alphanumeric and hyphen|
|Redis Cache||Global||1||63||Insensitive||Alphanumeric and hyphen|
|Search Service||Global||2||60||Lower cap||Alphanumeric and hyphen|
|Power BI Workspace Collection||Subscription||3||64||Insensitive||Alphanumeric and hyphen|
|Cognitive Services Account||Subscription||2||64||Insensitive||Alphanumeric, underscore and hyphen|
|HDInsight Cluster||Global||1||59||Insensitive||Alphanumeric and hyphen|
|Machine Learning Workspace||Subscription||3||24||Insensitive||Alphanumeric and hyphen|
|Data Factory||Subscription||3||64||Insensitive||Alphanumeric and hyphen|
|Event Hub||Subscription||1||50||Insensitive||Alphanumeric, underscore and hyphen|
|Service Bus Namespace||Global||6||50||Insensitive||Alphanumeric and hyphen|
|Service Bus Queue||Subscription||1||50||Insensitive||Alphanumeric, underscore and hyphen|
|Service Bus Topic||Subscription||1||50||Insensitive||Alphanumeric, underscore and hyphen|
|Stream Analytics Job||Subscription||3||63||Insensitive||Alphanumeric and hyphen|
|IoT Hub||Subscription||3||50||Insensitive||Alphanumeric and hyphen|
|Traffic Manager||Global||1||63||Insensitive||URL characters|
|Media Service Account||Global||3||24||Lower cap||Alphanumeric|
|CDN Profile||Global||1||?||Insensitive||Alphanumeric and hyphen|
|Azure AD Domain||Global||1||27||Insensitive||Alphanumeric|
|Azure AD||Subscription||1||256||Insensitive||Any character|
|Team Services Account||Global||1||50||Insensitive||Alphanumeric and hyphen|
|Team Project||Account||1||65||Insensitive||Alphanumeric and hyphen|
|DevTest Labs||Subscription||1||27||Insensitive||Alphanumeric, underscore, hyphen and parenthesis|
|Application Insights||Subscription||1||255||Insensitive||Any except 3 characters|
|Automation Account||Subscription||6||50||Insensitive||Alphanumeric and hyphen|
|Recovery Services Vault||Subscription||2||50||Insensitive||Alphanumeric and hyphen|
|Scheduler Job||Subscription||1||260||Insensitive||Alphanumeric, underscore and hyphen|
|Scheduler Job Collection||Subscription||1||100||Insensitive||Alphanumeric, underscore and hyphen|
|Cloud Service||Global||1||63||Insensitive||Alphanumeric and hyphen|
|Batch Account||Global||3||24||Lower cap||Alphanumeric|
|BizTalk Service||Global||6||20||Lower cap||Alphanumeric|
|Mobile Engagement Collection||Global||2||50||Insensitive||Alphanumeric and hyphen|
|Mobile Engagement App Resource||Global||1||50||Insensitive||Alphanumeric, underscore and hyphen|
|Mobile Engagement Application||Subscription||1||?||Insensitive||Any character|
|Key Vault||Global||?||?||Insensitive||Alphanumeric and hyphen|
|Operations Mgmt Suite Namespace||Global||4||24||Insensitive||Alphanumeric and hyphen|
Follow-upThis first article about the naming of Azure resources and artifacts will be followed soon by other items, which will include details of the aspects or particles included in the names, reference charts of particles, composition rules and the good practices. Note: you will find the French version of this article at: http://blog.cellenza.com/cloud-2/azure/partie-1-nommage-ressources-azure/.
That’s all. Have a good deployment!
• Vous pouvez participer à cet événement virtuel, il suffit de cliquer 'Save the Date': http://connect2015.visualstudio.com/
• Vous pouvez suivre l'événement à travers vos canaux de médias sociaux, Twitter en utilisant le hashtag #connect2015
• Vous pouvez également suivre directement ci-dessous l'évènement:
Plus besoin de détailler qu'est-ce que WPC, sauf éventuellement l'acronyme lui même : Microsoft Worldwide Partner Conference - 2015 (Orlando, FL).
J'ai l'honneur d'y représenter la France et mon entreprise, Econocom, en tant que speaker partenaire dans la session: CA04 : Accelerating Growth in Corporate Accounts . Session très intéressante focalisée sur le rôle du programme P-SELLER dans le partenariat Microsoft. Je vous invite d'y participer si vous êtes à WPC, je parlerai de mon expérience dans le programme, mais aussi des modalités et astuces de gagner en tant que partenaire dans le business Azure. Je vous attends !
Samedi prochain, 25 avril 2015, comme chaque année dans cette période, il y aura Global Azure Bootcamp, événement ayant rassemblé à travers le monde et le même jour 7432 personnes, 154 Speakers, 96 villes, 194 sessions techniques et 74 MVP.
En France, l'évènement se tiendra à la fois à Paris et Lyon. Pour Paris - où vous pourrez me rencontrer - vous trouverez les informations logistiques ici.
QUEL PROGRAMME ?
Des sessions techniques sur Azure se tiendront toute la journée.
Des environnements de laboratoires Microsoft Azure seront mis en place ad-hoc. Les experts seront à vos côtés pour vous apporter le support nécessaire à votre initiation dans le Cloud ou, au contraire, pour donner vie à vos expériences techniques les plus folles sur la plateforme Azure.
Agenda du jour :
Voici la session que je présenterai ensemble mon collègue Maxime Launay:
Automati(sati)on de votre application Azure. Passage sur les solutions d'automatisation des processus Azure. Moment pour discuter, bien sûr, d'Azure Automation, mais aussi PowerShell DSC. D'autres surprises à venir.
Venez nombreux !