Azure Day Rome 2019 Reloaded - Strangle(r pattern) your legacy application running on AKS Windows Node

Strangle(r pattern) your legacy application
running on AKS Windows Node
Giuliano Griggio – Solution Architect, Application & Infrastructure Consulting
Giancarlo Lelli – Solution Architect, Application & Infrastructure Consulting
Avanade Italy
Application & Infrastructure Market Unit

SPEAKERS
Giuliano Griggio
Solution and Technology Architect - Group Manager
membro della Market Unit Italia - APPs & INFRA, sono principalmente
coinvolto nella fasi Pre-sale e Delivery e da oltre 15 anni opero a 360° su tutto
lo stack Applications and Infrastructure.
giuliano.griggio@avanade.com linkedin.com/in/giulianogriggio/
Giancarlo Lelli
Solution Architect – Sr. Consultant
Membro della Market Unit Italia - Application & Infrastructure.
Focus sulle soluzioni di Application Modernization e Modern Architectures
Microsoft MVP on Developer Technologies
giancarlo.lelli@avanade.com linkedin.com/in/giancarlolelli/

4©2019 Avanade Inc. All Rights Reserved. <Confidential>
Our people and expertise Globally
36,000
Skilled and diverse
professionals –
32% of whom
are women
18,500
Microsoft Certified
Professionals
10,000
Projects with
4,000+ global
clients since
inception
15
Centers of Excellence
with specializations in
cloud, Dynamics AX,
CRM, digital
marketing and more
80
Locations
across 25
countries

5©2019 Avanade Inc. All Rights Reserved. <Confidential>
1,000
Skilled and diverse
professionals –
24% of whom
are women
450
Microsoft Certified
Professionals
300+
Projects with
200+ clients
1
Advanced Technology
Delivery Center in
Cagliari
5
Locations in Milan,
Rome, Florence,
Cagliari and Turin
Our people and expertise in Italy

Alphadata Company Business Case
Client Context
Alphadata Company, possiede un
applicativo legacy sviluppato su .NET
Framework attraverso una architettura
monolitica che attualmente gira On-
premise su Virtual Machines nel proprio
ambiente VMWare.
AS-IS: Business Challenges
• Applicativo non scala
orrizontalmente
• Il rilascio di nuove modifiche è
troppo lento
• Modificando il codice si rischia di
impattare su ogni aspetto dell’
applicativo.
• Costi di TCO attuali sono elevati
Solution Proposed
Cosa: Avanade propone di migrare l’applicativo su Cloud Azure, a seguito della
conversione a docker containers dell’ App., per orchestrarli mediante Azure
Kubernetes Services implementato con un pool di nodi nodi Windows e Linux.
Perchè: ridurre in prima battuta il TCO dell’ attuale soluzione (AKS è un servizio
PaaS) convogliando l’ applicativo monolitico in una architettura a micro serviz,
senza interrompere la continuità di servizio
Come: Applicando il cosidetto “Strangler Pattern” modificando i parametri di
routing dell’ ingress controller per convogliare il traffico gradualmente dall’app
legacy ai nuovi microservizi.
Technology in scope
• Windows Docker Containers
• Azure Kubernetes Services
• Nginx Ingress Controller
• Linux Docker Containers

I PRINCIPI E I DRIVER DELLA SOLUZIONE
SEGREGAZIONE DELLE
RESPONSABILITA’
RIUSABILITA’ QUANDO
POSSIBILE
ALTA AFFIDABILITA E
DISPONIBILITA’ CONTINUA
SCALABILITA’ ORRIZONTALE
VELOCITA’ DI
UPGRADE/UPDATE
AUTOMAZIONE SU OGNI
LIVELLO
AGILITA’ E PORTABILITA’

MONOLITE vs MICROSERVZI
• Cosa sono i micro servizi ?
“Piccoli autonomi servizi modellati
intorno al dominio di business che
lavorano insieme ”
By Sam Newman
• Cos’è un Monolite ?
Componenti e e programmi che
sono interconnessi tra di loro e
interdipendenti

Key Question
Come posso trasformare un applicativo da un architettura
Monolitica ad un architetura a Micro-Servizi in modo graduale ?

Il modello “Strangler Pattern”
«Migrare in maniera incrementale un sistema legacy, sostituendo gradualmente
parti specifiche di funzionalità con nuove applicazioni e servizi. Mano a mano
che le funzionalità del sistema precedente vengono sostituite, il nuovo sistema
sostituisce tutte le funzionalità del sistema precedente fino a quando non è
possibile effettuarne la completa dismissione.»
https://docs.microsoft.com/it-it/azure/architecture/patterns/strangler

Containers e Strangler Pattern 1/5
Punto di partenza: un container contenente l’ intera applicazione monolitica. Ecco
come affrontare una graduale trasformazione verso i microservizi.
Starting Point
Application
DB
Container
Applicativo ospite di un
singolo Container.

Strangle Pattern 2/5
Il secondo passaggio è una parziale, logica, separazione della User Interface
dal livello dei servizi
Front End
DB
Container
Back End
Container

Strangler Pattern 3/5
Il Terzo passaggio è una piena e logica separazione della User Interface
Front End
DB
Container
Back End
Container

IL quarto passaggio è una graduale separazione dei micro-servizi nel layer di
Back End e separazione del Database.
DB 1
Front End
Container
Api Gateway
API 1
Container 1
DB N
API N
Container N

Il Quinto passaggio è la decomposizione del layer di Front-End
DB
UI 1
Container
Api Gateway
API 1
Container 1
DB
API N
Container N
UI 1
Container

Solution High Level Pipeline
Conteinerizzare
Legacy App
Deploy AKS Cluster
Linux
Nodes pool
Deploy AKS
Windows
Nodes Pool
Deploy legacy APP
in AKS Windows
nodes pool
Deploy Ingress
Controller su AKS
Linux Pool Node
Deploy
Microservices APP
.NET Core in
Linux nodes pool
Routing graduale
del traffico verso i
microservizi

Infrastructure Infrastructure
Host Operating System
Hypervisor
Guest OS
Bins/Libs
App 3
Guest OS
Bins/Libs
App 2
Guest OS
Bins/Libs
App 1
Bins/Libs
App/Svc 1
Bins/Libs
App/Svc 2
Bins/Libs
App/Svc 3
Container Engine
Operating System
Convertire a Container Legacy Application 1/2
Conversion to Containers

Convertire a Container Legacy Application 2/2
Install-Module Image2Docker
Import-Module Image2Docker
# Perform scan of Windows source
image
ConvertTo-Dockerfile -ImagePath
c:dockermyimage.wim
Image2Docker
https://github.com/docker/com
munitytools-image2docker-win
Powershell Script
Image2Docker is a PowerShell module which
ports existing Windows application workloads
to Docker. It supports multiple application
types, but the initial focus is on IIS and
ASP.NET apps. You can use Image2Docker to
extract ASP.NET websites from a VM - or from
the local machine or a remote machine. Then
so you can run your existing apps in Docker
containers on Windows, with no application
changes.
Prerequisites
You do not need Docker installed to use Image2Docker - the
only requirement is PowerShell 5.0.
Image2Docker generates a Dockerfile which you can build into
a Docker image. The system running the ConvertTo-Dockerfile
command does not need Docker installed, but you will need
Docker setup on Windows to build images and run containers.

AKS multiple nodes pools
Azure Kubernetes Services
Node Pool Windows Node Pool Linux
Internet Users In Azure Kubernetes Service
(AKS), nodes of the same
configuration are grouped
together into node
pools. These node pools
contain the underlying VMs
that run your
applications. The initial
number of nodes and their
size (SKU) are defined when
you create an AKS cluster,
which creates a default node
pool. To support
applications that have
different compute or
storage demands, you can
create additional node
pools.

AKS Multiple nodes pools business case
Container
Registry
Azure Kubernetes Services
.NET Framework
Legacy App
.NET Core
Microservices
Internet Users Windows Server Core Container Image
Supporta Tradizionale .NET Framework
Application
Linux Containers Image
Supporta .NET core Application
Windows Container VS Linux Containers
.NET Framework
Legacy App
.NET Core
Microservices
epical
VS

Cosa è un Ingress Controller
• Un Ingress Controller è un software che fornisce
un Reverse Proxy, instradamento del traffico
configurabile e terminazione TLS per i servizi
Kubernetes. Le risorse di ingresso di Kubernetes
vengono utilizzate per configurare le regole di
ingresso e le rotte per i singoli servizi di
Kubernetes.
• Un Ingress Controller è un demone, distribuito
come Kubernetes Pod, che controlla l'endpoint /
ingress dell'apiserver per gli aggiornamenti della
risorsa Ingress. Il suo compito è soddisfare le
richieste di Ingresses.

L’uso di Ingress controller in multi node Pools
Ingress
controller
Internet Users
P P P P P P
ASP.NET
Legacy App
.NET Core
Microservices
Sample Picture
PIP

• Preview feature
• Basically we are talking about an additional node pool that can run Windows Server containers
• AKS preview CLI is needed
• WindowsPreview feature must be enabled on the subscription. It uses multi-node pool clusters and
VMSS set to manage the deployment and configuration of the Kubernetes nodes.
Windows Nodes on AKS
> az feature register --name WindowsPreview --namespace Microsoft.ContainerService
> az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/WindowsPreview')].{Name:name,State:properties.state}"
> az provider register --namespace Microsoft.ContainerService
• Above, the command needed to activate the preview features
• On the left, how to install the Azure CLI
• Get the CLI @ https://aka.ms/installazurecliwindows
• Version 2.0.61 required (az –version)

“AKS preview features are self-service opt-in. Previews are provided "as-is" and "as available" and are
excluded from the service level agreements and limited warranty. AKS Previews are partially covered by
customer support on best effort basis. As such, these features are not meant for production use.”
Ref: https://docs.microsoft.com/en-us/azure/aks/windows-container-cli#before-you-begin
Limitations
• You can't delete the first node pool (Because you are using a multiple node pool cluster)
• To ensure your cluster to operate reliably, you should run at least 2 (two) nodes in the default node pool.
• The AKS cluster can have a maximum of eight node pools.
• The AKS cluster can have a maximum of 400 nodes across those eight node pools.
• The Windows Server node pool name has a limit of 6 characters.
Windows Nodes on AKS – Be aware
Because we are using
this feature in preview

Azure CLI – Deploy Commands
The default value for node-vm-
size is Standard_D2s_v3. If you
want to change it see here (*)
* https://docs.microsoft.com/en-us/azure/aks/quotas-skus-regions#restricted-vm-sizes
To ensure your cluster to operate reliably,
you should run at least 2 nodes in the
default node pool
If you get a password validation error, try
creating your resource group in another
region. Then try creating the cluster with
the new resource group.
This command can take up to 10 minutes
to complete

“The HTTP application routing solution makes it easy to access applications that are deployed to your Azure Kubernetes Service
cluster. When the solution's enabled, it configures an Ingress controller in your AKS cluster. As applications are deployed, the
solution also creates publicly accessible DNS names for application endpoints. When the add-on is enabled, it creates a DNS
Zone in your subscription”
Ref: https://docs.microsoft.com/en-us/azure/aks/http-application-routing
HTTP Application Routing
This command deploy two objects inside our cluster
• Ingress controller: The Ingress controller is exposed to the internet by using a Kubernetes service of type LoadBalancer. The
Ingress controller watches and implements Kubernetes Ingress resources, which creates routes to application endpoints.
• External-DNS controller: Watches for Kubernetes Ingress resources and creates DNS A records in the cluster-specific DNS
zone.
> az aks show --resource-group myResourceGroup
--name myAKSCluster
--query addonProfiles.httpApplicationRouting.config.HTTPApplicationRoutingZoneName
-o table
Result
-----------------------------------------------------
9f9c1fe7-21a1-416d-99cd-3543bb92e4c3.eastus.aksapp.io
The HTTP application routing add-on is
designed to let you quickly create an
ingress controller and access your
applications. This add-on is not
recommended for production use.
What to use in for production-ready ingress
deployments that include multiple replicas
and TLS support?

An ingress controller is a piece of software that provides
reverse proxy, configurable traffic routing, and TLS
termination for Kubernetes services.
Kubernetes ingress resources are used to configure the
ingress rules and routes for individual Kubernetes
services.
Using an ingress controller and ingress rules, a single IP
address can be used to route traffic to multiple services
in a Kubernetes cluster.
Ref: https://docs.microsoft.com/en-us/azure/aks/ingress-tls
Ingress Controller for Production Workload
https://docs.microsoft.com/en-us/azure/aks/ingress-tls
Before you begin make sure to
• Have an AKS cluster ready
• Helm and Tiller installed and configured
• The Azure CLI installed and connected to the AKS Cluster
• kubectl installed and configured on your machine
> kubectl get service -l app=nginx-ingress --namespace ingress-basic
Installation steps
1. Install nginx
2. Configure DNS name
3. Install Cert-Manager (the docs suggest Let’s Encrypt)
4. Define a ClusterIssuer
5. Create an Ingress route
This public IP address is static for the life-span of the ingress controller. If you delete the ingress controller, the public IP address assignment is lost.
If you then create an additional ingress controller, a new public IP address is assigned – static IP address can be used.

Single Service Ingress
You can do this with an Ingress by specifying a default backend with no rules
Simple fanout
A fanout configuration routes traffic from a single IP address to more than one Service, based on the HTTP URI being
requested. An Ingress allows you to keep the number of load balancers down to a minimum
Name based virtual hosting
Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address
Different types of Ingress

Ingress route sample with nginx
Things that needs to be pointed out…
• Annotations
• rewrite-target – Syntax & Logic
• Host & rules
Starting in Version 0.22.0, ingress definitions using the annotation
nginx.ingress.kubernetes.io/rewrite-target are not backwards compatible with previous
versions. In Version 0.22.0 and beyond, any substrings within the request URI that need to be
passed to the rewritten path must explicitly be defined in a capture group.
Captured groups are saved in numbered placeholders, chronologically, in the form $1, $2 ...
$n. These placeholders can be used as parameters in the rewrite-target annotation.
In this ingress definition, any characters captured by (.*) will be assigned to the placeholder $2,
which is then used as a parameter in the rewrite-target annotation.
For example, the ingress definition above will result in the following rewrites:
- demo-aks-ingress.eastus.cloudapp.azure.com goes to aks-helloworld
- demo-aks-ingress.eastus.cloudapp.azure.com/azday goes to aks-helloworld
- demo-aks-ingress.eastus.cloudapp.azure.com/hello-world-two goes to ingress-demo

Azure Day Rome 2019 Reloaded - Strangle(r pattern) your legacy application running on AKS Windows Node

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Azure Day Rome 2019 Reloaded - Strangle(r pattern) your legacy application running on AKS Windows Node

Similar to Azure Day Rome 2019 Reloaded - Strangle(r pattern) your legacy application running on AKS Windows Node (20)

More from azuredayit

More from azuredayit (14)

Recently uploaded

Recently uploaded (20)

Azure Day Rome 2019 Reloaded - Strangle(r pattern) your legacy application running on AKS Windows Node