• Github
  • https://github.com/m-wilczynski/Localwire.Graphinder
• Graphinder series articles
  • Graphinder – Project Introduction
  • Graphinder – I don’t need this covered…
  • Graphinder – Minimum Vertex Cover problem
  • Graphinder – Simulated Annealing algorithm
  • Graphinder – Code review yourself
  • Graphinder – Genetic Algorithm – Introduction
  • Graphinder – Genetic Algorithm – Selection
  • Graphinder – Genetic Algorithm – Crossover
  • Graphinder – Genetic Algorithm – Mutation
  • Graphinder – Genetic Algorithm – Wrap up
  • Graphinder – Monthly Progress Report – March
  • Graphinder – Async IEnumerable with Rx.Net and IObservable
  • Graphinder – Reporting progress with Rx.Net
  • Graphinder – TDD and starting from red
  • Graphinder – Domain models vs Persistence models
  • Graphinder – Queries and Commands vs Repository pattern
  • Graphinder – Encapsulating persistence layer
  • Graphinder – Solution changes and nuget hell
  • Graphinder – Monthly Progress Report – April
  • Graphinder – Application architecture
  • Graphinder – Resources planning on Azure
  • Graphinder – Quick summary and what next
  • Quick thoughts after Daj Sie Poznac 2016 finals

As promised in previous post about application architecture, I’d like to share few words on my (moment of hesitation here) journey with resource planning on Azure. We’ll play around with network configuration for our environment, define application and development endpoints and juggle with possible service plans to meet our needs.
Oh, I’d like to mention that I’m gonna show things in old (https://manage.windowsazure.com) Azure portal as not everything is possible in new one (shame, because I love the direction MSFT is push it). ☁️

Network planning on Azure

Since we want to run quite a few microservices around with possibly lowest overhead possible (authenticating between services left out too if possible), planning a virtual network for our environment would be a good place to start.
Let’s think of a simple network that would suit our needs:

Our points of interests here would be:

• Virtual machines – hosts for our applications; even if we’re running App Service on Azure, it’s still a virtual machine so I won’t differentiate here
• Endpoints – actual ports opened either internally in virtual network or outside, through VM public address
• VPN gateway – point of accessing virtual network and operating inside of it while connecting from outside

Creating virtual network

As I’ve had lot of trouble with configuring VPN gateway on new portal, I will show most of deployment on old portal located @ https://manage.windowsazure.com.
Let’s choose ‘Networks’ from left-hand menu, then create New from bottom menu and go with Custom Create.
Name the network, choose the region and on a next screen make sure to mark Configure a point-to-site VPN:

Few next screens will guide you with VPN configuration that is quite straightforward, so I won’t go through it.
In case you have trouble, Cheryl McGuire got this covered on MSFT article Configure a Point-to-Site VPN connection to a VNet using the classic portal.

Provisioning of network along with VPN gateway may take up to 1h (was my case), so you need to have patience. 😥

Creating virtual machines

Whether its Windows Server or Linux machine you’re aiming to deploy on Azure, it’s important to put it in a virtual network we’ve created.
Since its impossible to do this later on, make sure you did not skip this part. On a Create a virtual machine -> Virtual machine configuration part, there is a dropdown for selecting a region for your virtual machine:

It’s easy to miss that you need to actually choose previously created virtual network here, so that VM would belong to it.
On a same screen you will also have a possibility to define endpoints for your virtual machine. You can leave them as they are for now and define/change them later from either new or old Azure portal.

Example endpoints generated by Azure wizard:

Watching out the cost

When deploying your environment to Azure, you need to take into account costs of VM and VPN gateway, as they would hurt the most.
Both virtual machine and gateway will be charged for amount of time it is enabled, no matter if you’re using it or not.
As for virtual machines, you can actually stop them, so they become deallocated and you won’t be charged
As for VPN gateway, there is no such an option and you are forced to delete it if not in use.
You might want to use a public port for RDP access to your machines if that’s fine for you tough.