Cloudtidings.com

When comes to Application Modernisation, we can’t argue that Containers are leading the way.  With Containers you can wrap up an application into its own isolated box meaning that app will have no knowledge of any other applications or processes that exist outside of its box.

With Containers, you can wrap up a monolithic application or create a more modern approach: a microservice-based architecture, in which the application is built on a collection of services that can be developed, tested, deployed, and versioned independently, which is perfect for mission-critical application scenarios.

Monolithic deployment versus the microservices approach. Image Source: Microsoft Docs (https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservices-architecture)

If you own the app source code and are on a optimisation path, I would recommend the microservices approach, which allows agile changes and rapid iteration allowing you to change specific areas of complex, large, and scalable applications. But if do not have the source code or breaking the application code in to small pieces it is not feasible, you still can look at Containers as away to modernize the app. Either way, you also need to consider: Automation, Management, High-Availability, Networking, Scalability, Upgrades and Monitoring requirements.

Automating and Managing Containers:

The task of automating and managing a large number of containers and how they interact is known as orchestration. Azure offers two container orchestrators: Azure Container Service (AKS) and Service Fabric.

Azure Container Service (AKS) makes it simple to create, configure, and manage a cluster of virtual machines that are preconfigured to run containerized applications. This enables you to maintaining application portability through Kubernetes and the Docker image format.

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers. Service Fabric addresses the significant challenges in developing and managing cloud native applications.  Service Fabric reresents the next-generation platform for building and managing these enterprise-class, tier-1, cloud-scale applications running in containers.

Modernize existing .NET applications with Azure cloud and Windows Containers Guide/eBook

Microsoft released a guide to help learn how you could move your existing .NET Framework server-applications directly to the cloud by modernizing specific areas, without re-architecting or recoding entire applications. You can download this eBook in multiple formats, too:

.PDF format: https://aka.ms/liftandshiftwithcontainersebook
.MOBI (Kindle) format: https://aka.ms/liftandshiftwithcontainersebookmobi
.EPUB (eReader) format: https://aka.ms/liftandshiftwithcontainersebookepub

For more detailed Information on Containers and Microservices, check out :

• https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/
• https://blogs.msdn.microsoft.com/dotnet/2017/08/02/microservices-and-docker-containers-architecture-patterns-and-development-guidance/
• https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservices-architecture
• https://blogs.msdn.microsoft.com/dotnet/2017/11/01/modernize-existing-net-apps-with-windows-containers-and-azure/

Image Source: Harsh Vardhan Verma

Wondering how you could use Microsoft OMS to have a single view of the jobs’ status across multiple VMM instances?

Well, you can now deploy an open-source solution that can be included in your OMS workspace called Virtual Machine Manager Analytics . This solution brings in the job data of your on-premises VMM instances to the log analytics in OMS. VMM admins can then use this versatile platform to construct queries for searching the relevant data and creating data visualizations.

The Virtual Machine Manager Analytics solution comes with some built-in reports with preconfigured data visualizations so you can easily get started with frequently used queries, such as:

• Distribution of failed jobs across VMM instances to easily scope down the broken instances.
• Distribution of failures over time to find sudden spikes, and to help with correlating the cause and failures.
• Distribution of failed jobs and errors to help with identifying the most error-prone jobs and the cause.
• Distribution of the job runtime across different runs to identify the sluggish and error-prone jobs.

Additionally, the VMM jobs data in OMS Log Analytics can be correlated with the data from other OMS solutions for better debugging and auto resolution with Azure automation Runbooks

Image Source: Francesco Molfese

Microsoft MVPs Dave and Cristal Kawula developed an eBook when you’ll find useful information about what not to do when Installing and Configuring Hyper-V .

This eBook focuses on the 6 most important Hyper-V configuration mistakes made today and how to avoid them. You’ll learn about:

• Common Deployment Mistakes
• NUMA best practices that won’t affect performance
• Proper use of Anti-Virus with Hyper-V
• Proper use of Checkpoints

You can download the ebook here.

The eBook Authors: Dave Kawula – MVP and Cristal Kawula – MVP

For many years I have been using Hyper-V in my laptop, which is specially useful considering a run many demos and from time to time I speak at conferences that requires you or to have 2 or 3 computers or to run virtualisation in your laptop.

But, to run some demos I needed network in my Virtual Machines, particularly internet connection,  and in most cases that was not easy to accomplish. The trick I used to have: a Internal Virtual Switch assigned to all VM’s and a second External Virtual Switch assigned to a VM acting as a router, running Windows Routing and Remote Access Service, which as you would understand was undermining my demos, by consuming vital resources (memory, cpu…) that I could otherwise assign to VM’s that was actually the demo VM’s.

Other common way to have internet on the Virtual Machines were by creating Connection Sharing (ICS) to connect on a shared Connection.

Anyway, that is now past, as since Microsoft released Creators Update for Windows 10, you can now create a Hyper-V Virtual Switch with NAT support which enables VM’s to be isolated behind a single IP address assigned to the host. This means that you don’t need to setup an ICS or create a VM to act as a route anymore. Also as Sarah Cooley, Hyper-V PM, pointed out in her post, NAT networking is vital to both Docker and Visual Studio’s UWP device emulators and there are two significant improvements to NAT brought by Windows 10 Creators update :

1. You can now use for multiple NAT networks (internal prefixes) on a single host.
2. You can build and test applications with industry-standard tooling directly from the container host using an overlay network driver (provided by the Virtual Filtering Platform (VFP) Hyper-V switch extension) as well as having direct access to the container using the Host IP and exposed port.

BTW, the process is done by using PowerShell. There is no UI for that. In fact, when you create a NAT Virtual Switch, it will appears as Internal Switch in the Hyper-V UI

To create the NAT Virtual Switch:

1. Open the PowerShell console with Admin rights and create an Internal Virtual Switch. In the example below, I am naming the Virtual Switch “vNAT”. You can choose the name you want.

   New-VMSwitch -SwitchName “vNAT” -SwitchType Internal

    

   

2. After creating the Virtual Switch, you need to configure the NAT gateway. This IP address must be from a new range, which will be defined in the next step. Notice the name of the Interface Alias, which is composed by the prefix “VEthernet ” plus the name of the Virtual Switch created in the previous step enclosed in brackets. I am assigning the IP address 10.1.3.1 as a NAT Gateway IP and using 24 as prefix length (255.255.255.0) which would cater for 254 VM’s.
    New-NetIPAddress -IPAddress 10.1.3.1  –PrefixLength 24  –InterfaceAlias “vEthernet (vNAT)”
   

   You can otherwise utilise the InterfaceIndex instead of InterfaceAlias. For that, you need to find the interface index (ifindex) of the virtual switch previously created by typing

   Get-NetAdapter.
   
   In my case, the interface index is 68.

   
   Then executing the following:
   New-NetIPAddress -IPAddress 10.1.3.1  –PrefixLength 24  –InterfaceIndex 68
   

   You can check if the IP addresses for the NAT default Gateway were assigned by typing:
   Get-NetIPAddress -InterfaceAlias “vEthernet (vNAT)”

3. The next step is to define the NAT network name and its IP address range, that the VM’s with the assigned Virtual Switch will run on. Make sure the IP address created in the previous step is on the range of this network.
   
   New-NetNAT -Name “NATNetwork” -InternalIPInterfaceAddressPrefix 10.1.3.0/24

   

4.  The next step is to assign the NAT Virtual Switch to the VM’s to use the NAT virtual switch. You can do that by using PowerShell or the UI.

1. The final step is to assign an IP address to the VM’s. You will need to manually configure the network settings for the VM, as the built-in NAT switch doesn’t include a DHCP server for automatic IP address assignment. Assign the default gateway IP address of the private network to the internal VM switch Management Host vNIC.

Note: When the endpoint is attached to a container, the Host Network Service (HNS) allocates and uses the Host Compute Service (HCS) to assign the IP address, gateway IP, and DNS info to the container directly.

Note: If you require automatic IP address assignment to your VM’s, it can be easily accomplished by adding a DHCP server role to one of the VM’s. In my case, I added the DHCP role to the Domain Controller VM.

Important: To access the VM’s from the external network, you will need to create NAT rules, translating an external TCP/UDP port on the external interface to the NAT Virtual Switch port.

#The following command, maps the Hyper-V host port 80 to port 81 on VM 10.1.3.2
Add-NetNatStaticMapping -NatName “NATnetwork” -Protocol TCP -ExternalIPAddress 0.0.0.0  -InternalIPAddress 10.1.3.2 -InternalPort 81 -ExternalPort 80

If you need to remove the NAT (clean up):

Get-NetNat | Remove-NetNat
Removes existing container networks, vSwitch,  NetNat