Cloud Connectivity

In this lesson, we’ll take a look at different topics related to cloud connectivity:

• Cloud connectivity: the different options to connect to public cloud providers.
• SD-Access: Cisco’s SDN solution for enterprise campus networks.
• SD-WAN: the new software method to configure and manage WAN connections.
• Virtual switching: how we connect virtual machines and containers to the rest of the network.

There is a lot to cover so let’s get started.

Cloud Connectivity

When organizations just start with public cloud services they often use VPNs over the Internet to connect their on-premises applications to the public cloud services.

VPNs over Internet have several advantages:

• Cost: Internet access is cheap compared to private WAN.
• Availability: Internet access is available almost everywhere.
• Migration: easy to switch to another cloud provider because you can reach them all over the Internet.
• Mobile users: if you have many mobile users then they can access cloud services whenever they have an Internet connection.

There are also several disadvantages:

• Bandwidth: depending on your users and applications, your Internet connection might not have enough bandwidth.
• Quality of Service (QoS): the Internet is best-effort. You can prioritize your traffic when it leaves your router but there is no end-to-end QoS.
• SLA: most ISPs don’t offer any SLAs. If they do, your Internet connection could be almost as pricey as a private WAN solution.

If you have applications with certain bandwidth/latency/jitter requirements then VPN over the Internet might not be the best solution.

Fortunately, all large cloud providers offer dedicated connections. We’ll take a look at the top 3 cloud providers: Amazon AWS, Google Cloud, and Microsoft Azure.

Amazon AWS Direct Connect

Amazon AWS offers Direct Connect, a dedicated connection from AWS to your office, datacenter, or co-location.

You can use 802.1Q VLAN tags for multiple virtual interfaces. This allows you to use one VLAN to access public services like S3 with public IP addresses, and another VLAN for private resources like EC2 instances with private IP addresses.

You can get speeds between 1 and 10 Gbps. Lower speeds are available through APN partners that support AWS Direct Connect.

Google Cloud Dedicated Interconnect

Google Cloud Dedicated Interconnect provides a physical connection between the customer and the Google Cloud network through a Google supported co-location. You can get speeds up to 10 Gbps per circuit and there is a maximum of eight circuits per Dedicated Interconnect connection. If you don’t need as much speed, you can use the Partner Interconnect option for speeds between 50 Bps and 10 Gbps.

Microsoft Azure ExpressRoute

With Microsoft Azure ExpressRoute, you connect directly to Azure, Office 365, and Dynamics 365 over a private WAN connection. You get access to all regions within the geopolitical region. With a premium add-on, you get connectivity across all geopolitical regions in the world. You can get speeds up to 10 Gbps.

Multicloud Connectivity

At the beginning of the cloud era, organizations typically had one or a few applications in a single cloud. Later, they started using more services but stuck to the same cloud provider.

Nowadays, there are many different cloud providers and they offer different services. Many organizations are interested to use the best services from each cloud provider so they look into multicloud strategies. This makes sense since each cloud provider offers different services and has its own strengths and weaknesses.

With a multicloud strategy, you are not locked in to one cloud provider and you can build your solution based on the best services from multiple cloud providers.

There are providers like Intercloud who offer a private connection that connects to multiple public cloud providers. This allows you to connect to all cloud providers without using each cloud provider’s own dedicated connection option.

Software Defined Access (SD-Access)

Enterprise networking can get pretty complex. There’s usually a campus, some remote branches, remote workers, and we connect everything together with WAN connections. We have many devices on the physical layer including routers, switches, firewalls, wireless LAN controllers, etc.

There is a lot going on in the logical topology: we have VLANs, VRFs, routing protocols, access-lists, firewall rules, etc. We configure pretty much everything manually with perhaps a bit of network automation to make our lives easier.\evolving-technologies-cloud-connectivity-sd-access-1080p.mp4

Back in 2007/2008, SDN showed up with the promise of automating everything and getting rid of the CLI by defining everything in software.

SDN however, is mostly about datacenters. In the datacenter, everything is about applications. In an enterprise, it’s about (mobile) users and devices. We have users working everywhere using laptops, tablets, and smartphones.

Enterprise networks use a lot of hardware appliances. New firewall? Order a Cisco ASA. Extra wireless LAN controller (WLC)? Order another WLC appliance.

Wouldn’t it be nice if we could spin up new services for our enterprise networks, similar to how cloud services work? If you need a new firewall, just click on a button and it starts a new vASA. Need another WLC? Hit the button, and it starts a virtual WLC.

This is one of the promises of Cisco’s SD-access: complete automation of your enterprise network, similar to how SDN/cloud solutions work. Here’s what it looks like:

There are five main components:

• Fabric
• APIC-EM Controller
• Identity Services Engine (ISE)
• Network Data Platform (NDP)
• DNA center

Fabric

Let’s start with the fabric. This is where you find all hardware components that you are familiar with: routers, switches, wireless LAN controllers, access points, etc. This includes devices that run IOS and IOS XE.

SD-access uses an underlay responsible for forwarding traffic; it’s only job is to provide a transport mechanism. We keep the underlay network simple. We use an overlay network for the different services. The overlay network is flexible and programmable. Why this separation?

You don’t see this separation on most campus enterprise networks but it makes sense. For example, if you want to support a new application on your network then perhaps you have to change an existing access-list. If you change this access-list then it could also affect other applications in your network. You might want to implement the access-list changes during maintenance hours. If you mess up, you can always do a rollback.

With an underlay and overlay network, changes to the overlay network won’t affect your underlay network. It’s similar to using tunneling protocols like GRE or DMVPN. You can mess around with the tunnels, but it won’t affect the underlying network.

We use APIs to configure the hardware devices and to launch new services. It’s still possible to use the CLI for troubleshooting.

The fabric consists of three key components:

• Control plane: based on Locator Identity Separator Protocol (LISP)
• Data plane: based on Virtual Extensibe LAN (VXLAN)
• Policy plane: based on Cisco TrustSec (CTS)

LISP simplifies routing by removing destination information from the routing table and moving it to a centralized mapping system It’s similar to DNS, a router sends a query to a central LISP mapping system and asks where a destination address is. This results in smaller routing tables and requires less CPU cycles.

We could use LISP on the data plane, but it can only tunnel L3 traffic. SD-access uses a modified version of VXLAN on the data plane, one of the reasons is that VXLAN supports L2 encapsulation.

On the policy plane we use Cisco TrustSec, Scalable Group Tags (SGT), and the SGT Exchange Protocol (SXP). We add endpoints that require a similar network policy to a shared group, and we add an SGT to the group. The SGT is a tag that is separate from a network address and you can attach network policies (QoS, PBR, etc.) to it.

This allows you to create network policies without mapping it to IP addresses or subnets. The SGT is added in the VXLAN header.

APIC-EM Controller

The APIC-EM controller is Cisco’s SDN controller for enterprise networks and supports IOS/IOS XE devices. You can use this as a standalone product.

SD-access uses the APIC-EM controller as the SDN controller to control all devices in the fabric. The APIC-EM controller is controlled by DNA center.

DNA Center

DNA center is the portal where you manage everything. It’s web-based, and right now only available as a hardware appliance. If you ask me, that’s strange considering SD-access is all about virtualization. They will probably release a virtual version sometime.

There are four key attributes of DNA center:

• Design
• Policy
• Provision
• Assurance

You can take a look at DNA center for yourself with the Cisco’s Sandboxes. You can log in directly into the DNA center GUI with username “devnetuser” and password “Cisco123!”.

Design

This is where you design your entire network:

• Build the network hierarchy: add sites, buildings, etc.
• IP address management: add the network and subnet addresses you want to use for your networks.
• Network settings: configure DHCP, DNS, SNMP, and Syslog servers. You also create QoS and wireless profiles here.
• Image repository: manage all IOS/IOS XE images of your devices in one place.

Policy

This is where we configure everything that is related to network policies. You create the policies and DNA center translates your policies into configurations for the hardware devices in the fabric.

Provision

This is where we add new devices to the network and where we apply network policies to devices.

Assurance

Assurance is where you monitor the entire network. You can see an overview of all network devices, (wireless) clients, and applications. You can monitor the health status and an overview of all issues in the network.

ISE

ISE is Cisco’s AAA product and has been out for a while now. ISE applies the policies you create through DNA center.

NDP

This is a new Cisco product. NDP is the analytics engine that analyzes all your logging information, NetFlow, SNMP, etc. It collects metrics of everything in the fabric, including devices, users, and “things” (Internet of Things). You can monitor everything that NDP collects through DNA center.

Software Defined WAN (SD-WAN)

Software Defined WAN (SD-WAN) is hot nowadays. Why?

Private WAN connections like MPLS are reliable but also expensive. WAN connections are usually a big chunk of the IT budget, so it’s understandable that organizations are interested in replacing their private WAN connections with regular Internet connections to reduce costs.

To understand SD-WAN, we first have to talk about some “problems” with traditional WAN connections. We can choose between private WAN connections or public Internet connections. Let’s compare these two options:evolving-technologies-sd-wan-1080p.mp4

• Cost: private WAN connections like MPLS are way more expensive than regular Internet connections.
• Time to deploy: it takes longer to deploy a private WAN connection than a regular Internet connection.
• SLA: Service providers offer SLAs for private WAN connections that we don’t have for regular Internet connections. There are providers who offer SLAs for “business” class Internet connections, but these are usually way more expensive than regular (consumer) Internet connections.
• Packet loss: Internet connections have a higher packet loss rate compared to private WAN connections like MPLS.
• QoS: Internet connections don’t offer any QoS. You can prioritize your outgoing traffic but that’s it, the Internet itself is like the wild west. Private WAN connections often support end-to-end QoS.

The way we use our WAN has also changed throughout the years. Most organizations had an HQ, remote users, and perhaps some branch offices. Branch offices were connected to the HQ with private WAN or VPNs over the Internet. Remote users used remote VPN over the Internet to connect.

Nowadays, organizations also run their own applications in the cloud instead of on-premises, and they use applications like Office 365 or Gsuite. Our traffic patterns look different now:

What about network management? Each router has its own control plane, and we use the CLI to manually create our router configurations “box-by-box”. This is time-consuming and prone to errors. We can use network automation tools to make our lives easier, but the control plane remains decentralized.

SD-WAN promises to save money by using a combination of Internet and private WAN connections and make network management much easier.

One problem with SD-WAN is that each vendor has a different idea about what SD-WAN is. I’ll give you a basic overview of what SD-WAN is about. An SD-WAN solution has parts of the control plane centralized and is built with network automation and orchestration in mind. We create network policies globally and push them to all routers from a central location. You could create a QoS policy and push it to all your 500 branch routers with a single mouse click. We don’t use the CLI anymore. Instead, we have a GUI and use APIs to configure and manage our WAN connections. Some vendors still support a CLI if you want to do some troubleshooting.

We use multiple WAN connections and active/active per-application load-balancing. Let’s say we have a site with a fiber, cable, 4G, and DSL connection. SD-WAN monitors all these WAN connections and keeps track of performance metrics like the throughput and delay. It selects the WAN connection with the lowest latency and highest throughput.

When a certain link fails then it can fail over to the next best option. It can also do this on a per-application level. You could use the fiber connection for traffic to the public cloud and the cable connection for low-priority FTP traffic. It protectson traffic over public Internet connections with IPSec.

SD-WAN could be an alternative to an expensive private WAN link with an SLA that promises “five nines” of uptime (99.999%). The idea behind it is that multiple WAN connections are always more reliable than a single WAN connection.

Cisco SD-WAN Solutions

Cisco offers three SD-WAN solutions:

• • Intelligent WAN (IWAN)
  • Meraki SD-WAN
  • Cisco SD-WAN (Viptela)

IWAN is Cisco’s first SD-WAN solution for the ISR platform and intended for hybrid WAN (MPLS and Internet) or Internet-only connections.

Behind the scenes they use some familiar protocols:

• DMVPN with QoS
• Wide Area Application Services (WAAS)
• Application Visibility and Control (AVC)
• Performance Routing (PfR)

Meraki SD-WAN is for existing Meraki customers that are interested in the advantages of SD-WAN. Here are some features that it offers:

• Apply bandwidth, routing, and security policies from a central location to all WAN connections (MPLS, Internet, 4G, etc.)
• Centralized network visibility and control.
• QoS and bandwidth management with Meraki traffic shaping
• Dynamic policy and performance-based path selection with automatic load balancing.
• Secure connectivity with cloud applications, remote offices, or datacenters.

Cisco SD-WAN (Viptela)

Cisco acquired Viptela, a major SD-WAN player, in 2017 and re-branded it to Cisco SD-WAN. This is Cisco’s enterprise SD-WAN solution.

Components

This solution consists of four main components and one optional analytics component:

• vManage (management)
• vSmart (controller)
• vEdge (routers)
• vBond (orchestrator)
• vAnalytics (analytics)

Let me explain these components.

vManage

vManage is the Network Management System (NMS) to configure and manage the entire SD-WAN solution. You can use a GUI or REST API to access it. This is where you create device configurations and network policies. vManage also alerts you when there are events or outages.

vSmart

vSmart is the control plane of the architecture. vSmart controllers advertise routes, security, and policy information. Cisco SD-WAN uses the proprietary Overlay Management Protocol (OMP) for this. vSmart implements the policies that you configure through vManage.

For example, imagine you create a policy through vManage where real-time voice traffic requires a latency of less than 100 ms. The vSmart controller downloads the policy, converts it into a format suitable for the vEdge routers and then implements it on all vEdge routers.

All vEdge routers peer with a vSmart controller, it’s a hub and spoke topology. It’s similar to a BGP route reflector or a DMVPN NHRP server. The vSmart controller only lives in the control plane and is never in the data plane.

vEdge

vEdge is the software or hardware routers at your sites and responsible for the data plane. vEdge routers connect to a vSmart controller through a Datagram Transport Layer Security (DTLS) connection. If you want to use hardware, you have the following options:

• Viptela vEdge: 100, 1000, 2000, or 5000 series routers.
• Cisco ISR and ASR: the IOS XE SD-WAN software image allows you to use Cisco SD-WAN on the ISR 1000, ISR 4000, and ASR 1000 series.
• Cisco ENCS: similar to the ISR series, you can use the IOS XE SD-WAN software images for the ENCS 5000 series platform.

If you want to use software, you have two options for VMs:

• vEdge Cloud
• Cisco Cloud Services Router (CSR)

vBond

vBond is the orchestrator. It authenticates vSmart controllers and vEdge routers and coordinates connectivity between them. It tells vEdge routers where and how to connect to vManage and vSmart controllers. vBond requires a public IP address so that all devices can connect to it. When a vEdge router joins the SD-WAN, the first thing it talks to is the vBond orchestrator.

vAnalytics

vAnalytics is an optional analytics service. It gives you visibility of applications and your infrastructure in the entire SD-WAN. You can use it for forecasting, and it gives you recommendations about your traffic and WAN connections. This can be useful to figure out whether you need to upgrade or downgrade certain WAN connections.

Cloud or on-premises

You can implement Cisco SD-WAN with a combination of cloud and on-premises options:

• The vEdge routers and vBond orchestrator are available as hardware or VMs.
• vManage and vSmart controllers are only available as VMs.

You can run the VMs on-premises on ESXi or KVM, or host them at cloud providers like Amazon AWS or Microsoft Azure.

Cloud onRamp

In the traditional model, you find all on-premises infrastructure and applications in a central HQ site or data center. We connect our branch offices in a hub and spoke topology and route all traffic from the branch offices to the HQ or datacenter.

Organizations nowadays often use cloud SaaS applications like Office 365, Gmail, or Salesforce. Instead of running everything on-premises, we also use IaaS services in the public cloud.

The traditional hub and spoke model where we connect and route all branch traffic to the main site or datacenter doesn’t work anymore. Cisco SD-WAN connects sites directly to these SaaS applications or IaaS services using one or more WAN connections.

There are two options:

• Cloud onRamp SaaS
• Cloud onRamp IaaS

Cloud onRamp SaaS monitors the performance of all WAN connections from a branch office to a SaaS application. Each path gets a “quality of experience” performance score from 0-10, 10 being the highest score. It makes real-time decisions to choose the best performing path between the end users at the branch office and the SaaS application in the cloud. You can monitor this in the vManage GUI.

Cloud onRamp IaaS extends the SD-WAN network into the public cloud. Through vManage, you can automatically create vEdge cloud routers in the public cloud provider infrastructure. This allows you to connect directly from your on-premises vEdge routers to the vEdge cloud routers at the public cloud provider.

Virtual Switching

VMs and containers both require network connectivity. Since they are virtual, we also need virtual networking. In this section, we’ll talk about how VMs and containers connect to the network.

Virtual Machines

VMs have virtual NICs (vNIC) which connect to virtual switches (vSwitch). A vSwitch is similar to a normal layer two switch, but it’s virtual. We use a vSwitch so that a VM on a hypervisor can communicate with other VMs or external networks outside of the physical server through the physical NIC (pNIC). You can create one or more vSwitches on a hypervisor.evolving-technologies-cloud-connectivity-virtual-switching-1080p.mp4

One issue with vSwitches is that you have to configure them on every hypervisor. This can become an administrative burden if you have lots of hypervisors. To make our lives easier, we can use distributed virtual switching. This is a feature that aggregates the vSwitches in a cluster of hypervisors and treats them as a single distributed switch.

Distributed virtual switching has advantages:

• Centralized management of all vSwitches in a cluster.
• Configuration consistency.
• Allows network policies and statistics to migrate when a VM migrates from one hypervisor to another.

Here is an overview with examples of native and third-party vSwitches you can use for different hypervisors:

Hypervisor	Native vSwitch	Third party vSwitch
vSphere	Standard vSwitch Distributed Virtual Switch	Cisco Nexus 1000V Cisco VM-FEX IBM DVS 5000V HPE 5900v
Hyper-V	Native Hyper-V Virtual Switch	Cisco Nexus 1000V Cisco VM-FEX NEC Broadcom
KVM	Linux Bridge Open vSwitch (OVS)	Cisco Nexus 1000V Open vSwitch (OVS)
XEN	Open vSwitch (OVS)	Open vSwitch (OVS)

VMWare stopped support for third-party vSwitches since vSphere 6.5U2.

Containers

Containers also require network connectivity. We use virtual bridges instead of virtual switches. Docker is the most popular container engine at the moment so let me give you an example of what Docker networking looks like:

Docker creates a virtual bridge called Docker0 and assigns an RFC1918 private range subnet to it which is not in use on the host machine. Each container connects to the Docker0 bridge with a vEth interface that appears as the eth0 interface in the container. Each eth0 interface receives an IP address from the subnet of the Docker0 virtual bridge.

This allows all containers on the same host to communicate with each other. If you want containers to communicate with the outside world, then Docker uses Iptables and NAT to forward ports from the outside physical interface to the vEth interface.

This setup with the Docker0 virtual bridge and port forwarding is fine for a single host. If you have multiple hosts, lots of containers, require networking between containers, and want to scale containers then it’s best to dive into container orchestration like Docker Swarm or Kubernetes. Kubernetes is the most popular option today, something we will discuss in another lesson.

Conclusion

In this lesson, we talked about quite some items:

• Cloud connectivity:
  • The advantages and disadvantages of VPN over the Internet to access public cloud services.
  • Private WAN connections for the big three cloud providers.
  • Why most organizations look for a multicloud strategy nowadays.
• SD-Access:
  • Cisco’s SDN solution for enterprise campus networks.
  • The different components of the SD-Access architecture.
• SD-WAN:
  • What SD-WAN is and why it is such a hot topic nowadays.
  • The three Cisco SD-WAN solutions:
    • Intelligent WAN (IWAN)
    • Meraki SD-WAN
    • Cisco SD-WAN (Viptela)
      • We took a closer look at Cisco SD-WAN and its different components.
      • We discussed Cloud Onramp so you can connect directly to SaaS applications and IaaS services in the cloud.
• Virtual switching:
  • How VMs use vSwitches to connect to the network.
  • How docker containers use virtual bridges to connect to the network.

I hope you enjoyed this lesson, if you have any questions, please leave a comment.

Compute Virtualization (Containers and Virtual machines)

In this lesson, we’ll take a look at the differences between virtual machines and containers.

Virtual Machines

Back in the days, a physical server would only run a single operating system with one or a few applications. We started with CPUs with a single core, then hyperthreading, and then multiple cores. The amount of memory in a single physical server also increased and became more affordable. evolving-technologies-compute-virtualization-1080p.mp4

One of the reasons virtualization is now so popular is that servers were under-utilized. We can easily run multiple operating systems and multiple applications on a single physical server. A virtual machine is pretty identical to a physical server except it’s virtual. We have virtual hardware (CPUs, memory, storage, etc.) which runs on a hypervisor.

The hypervisor is the server virtualization software that runs on the physical server. This is where we create virtual machines and configure how much CPU cores, memory, storage, etc. each virtual machine has. There are two hypervisor types:

• Type 1: this hypervisor runs directly on hardware, which means you can assign more resources to virtual machines. Examples are VMware ESXi, Citrix Xen, KVM, and Microsoft Hyper-V.
• Type 2: this hypervisor runs on top of an operating system like Microsoft Windows, Apple MacOS, or Linux. We usually use a type 2 hypervisor on desktops or laptops. Two popular hypervisors are Oracle VM Virtualbox and VMWare Workstation. If you have never played with virtual machines before, give Virtualbox a try. You can download it for free.

Even a type 1 hypervisor has something of an OS. For example, VMWare ESXi uses a proprietary kernel called the VMkernel. It’s very lightweight compared to a “full” operating system like Microsoft Windows or any Linux distribution.

When the hypervisor or the underlying physical server crashes, all your virtual machines disappear. Fortunately, there are products so you can migrate virtual machines from one physical server to another with no downtime or noticeable latency.

One advantage of virtual machines is that we are familiar with physical servers. It’s easy to understand, it’s a server, but virtual. We can use all the management and security tools we know to manage our physical or virtual servers.

One disadvantage of virtual machines is that there is a lot of overhead. For example, let’s say I want to run the freeradius application. A virtual machine with the Ubuntu 18.04 LTS operating system and nothing else installed is already ~3400 MB. Freeradius and its dependencies require about 5 MB. This brings my total storage to 3400 + 5 = 3405 MB.

That’s 3405 MB of storage only to run a simple application. Starting a virtual machine can take minutes, it has to boot the OS and start your applications

Containers

Containers are sometimes called light-weight virtual machines, but they are nothing like virtual machines.

A container is a “package” that only contains an application and its dependencies, nothing more. This package is stored as a container image. Containers run on top of a container engine, which runs on top of an operating system.  Starting a container is very quick since the operating system is already running. Containers are isolated from each other by the container engine.

Containerization has many advantages:

• Small: the container image only has the application and its dependencies, nothing more. This results in a small container image. For example, I created a container image with freeradius. It’s only ~ 5 MB and has everything you need to run freeradius.
• Fast: you don’t have to start a virtual server with a virtual BIOS and virtual operating system. Spinning up a container is as fast as starting an application and only takes milliseconds.
• Portability: The container image has everything the application needs. I can create a container image on my local machine, then ship somewhere else like a remote server. If it runs on my computer, it will run on other computers or servers.
• Isolation: containers run on the same operating system but are isolated from each other. When one container crashes, it doesn’t affect the other containers.
• Scalability:  You can add more identical containers when you need to scale out. Since containers are small and start quickly, you can scale out and in easily.
• Immutability:  container images are built based on a “blueprint”. The freeradius image I mentioned earlier is a Docker container; the blueprint is called a Dockerfile. When you change your code, you build a new container image.

Are there any disadvantages to containers? Containers are isolated from each other on the process level which could be less secure than a virtual machine which is fully isolated.

Another issue is security. Containers are based on a blueprint which is basically like a snapshot. You build the container image from the blueprint, and the container doesn’t change anymore. If you want to update your container, you rebuild a new container image. This is different from a (virtual) server which you configure to install the latest security updates automatically.

Be careful that you run no container images that are outdated and might have vulnerabilities. For example, take a look at the Apache container images on Docker hub:

The container image with the “alpine” tag has vulnerabilities. We can click on the tag to see the vulnerability:

This vulnerability could be dangerous. It might also be unwise to run a public container image on your production network. When you build your own container images, you need to ensure you check them for security vulnerabilities and rebuild them when needed.

Docker is the most popular container platform. Other options:

• rkt (rocket)
• LXD
• Linux VServer
• Windows Containers

If you never played with containers, try Docker. You can download it for free, and it runs on Microsoft Windows, Linux, and Apple MacOS. Docker Hub has plenty of container images to test.

Conclusion

Virtual machines and containers both have advantages and disadvantages. Here is an overview of the differences between the two:

	Virtual Machine	Container
Overhead	A lot of overhead since you we virtualize all hardware.	Almost none since we run the container directly on the host OS with the container engine.
Performance	there is a small performance hit because of the virtual hardware.	Almost no performance hit compared to running the application natively on a host OS.
OS	Each virtual machine has its own OS.	We use the host OS.
Startup time	takes a few minutes to start the OS and the application.	it takes a few milliseconds to start the application.
Storage	Lots of storage space wasted because of the OS.	Container images are small; we only have the application and its dependencies.
Isolation	Fully isolated	Isolated on the process level so could be less secure.

I hope you enjoyed this lesson, if you have any questions, please leave a comment.

Cloud Workload Migration

Migrating applications to the cloud require planning and research. In this lesson, we’ll take a look at five steps to migrate your on-premises workload to the cloud.

Application discovery

Our first step is to discover, analyze, and categorize your on-premises applications. Not all applications are suitable to migrate to a cloud environment. Here are some items you need to consider: evolving-technologies-workflow-migration-1080p.mp4

• Specialized hardware requirements: does your application run on specific hardware? Cloud providers offer different CPU types, including x86 and ARM. Most cloud providers also offer GPUs.
• Operating system: Does your application run on an operating system that the cloud provider supports or can you make it work on another operating system?
• Legacy databases: does your application run on old database server software that a cloud provider might not support?
• Security: does the application have any security measures? Older applications might not get updates anymore which might be acceptable in an isolated on-premises situation but not in the cloud.
• Performance requirements: does your application have specific performance requirements? Can a cloud environment meet these requirements? Is your application sensitive to delay?

Application types

There are two kinds of applications. Ones that work in the cloud, and those that don’t. We call applications that don’t run in the cloud legacy applications. These applications were designed to run on traditional (virtual) servers. Let’s discuss the difference between the two application types.

Legacy applications

Most applications are legacy applications but with some modifications, we can make them work in the cloud. This is best explained with an example:

WordPress is a popular CMS. ~30% of the websites in 2018 run on WordPress. Even if you never worked with WordPress before or installed a web server, you can probably understand this example.

If you want to host WordPress yourself in the “traditional” way then we have a process that looks like this:

1. Select a (virtual) server with a certain amount of CPU cores, memory, and storage.
2. Install a Linux Distribution as the operating system.
3. Install all required packages:
   1. Apache: our web server software.
   2. MySQL: the database server.
4. Download the WordPress files and upload them to your server.
5. Add the database name, username, and password to the wp-config.php file.
6. Launch your website.

You can perform the above steps manually or use installation scripts to automate these steps.

When your website grows and attracts more visitors, you can scale up and add more CPU cores and/or increase the memory of the server. When your server dies, you have a problem. You can always install a new server and restore a backup.

With traditional servers, our servers are like pets. We manually install, upgrade, and repair them. They run for years so we treat them with love and care. Perhaps we even give them special hostnames.

Another name for pet servers is snowflake servers.

Cloud applications

Cloud providers offer virtual servers so you can repeat the above steps on a cloud provider’s virtual server. Running your website on a virtual server from a cloud provider is the same as regular Virtual Private Server (VPS) hosting, we end up with a “pet”.

In the cloud, we start new servers on-demand when we need them and we destroy them when no longer needed. Servers and other resources are disposable so we treat them like cattle. We want to spin up servers quickly so there is no time to manually configure a new server. To achieve this, we need to create a blueprint and configuration we can use for all servers.

To create a blueprint, we use a configuration management tool to define “infrastructure as code”. We configure the infrastructure we need in JSON/YAML files. Examples are Amazon AWS CloudFormation or Google Cloud Deployment Manager. Terraform is a configuration management tool that supports multiple cloud providers. To install and configure the servers, you can use deployment tools like Chef, Puppet, Ansible, and Amazon AWS CodeDeploy. Another option is to use containers which we discuss in another lesson.

When it comes to cloud computing, we want to keep cattle, not pets. If you are interested in building cloud-compatible applications, then you should take a look at the Twelve-Factor App Methodology. It’s a baseline that offers best practices to build scalable (web) applications.

Let’s walk through an example of how we can run our legacy WordPress application in the cloud:

Infrastructure as code

We create one or more configuration files that define our infrastructure resources:

• Template for our web server(s).
• Template for our database: we use a SaaS solution like Amazon AWS RDS, Google Cloud, or Azure Database for MySQL for this.
• Template for a load balancer: if you have over one web server then you need a load balancer to distribute the incoming traffic.
• Template for autoscaling alarm: when the CPU load of our web server exceeds 50%, we want to start a second web server.
• Template for shared file storage: our web servers need shared access to certain files. I’ll explain this in a bit. You can use a SaaS solution like Amazon AWS Elastic File System (EFS), Amazon AWS S3, or Google Cloud Filestore for this.

Having your infrastructure as code makes it easy to create and replicate resources.

Version Control System (VCS)

You should store your configuration files in a Version Control System (VCS). The advantage of a VCS is that it keeps track of changes in your files and it’s easy to work on the same files with multiple people. Git is the most popular open-source VCS. Github is a popular website where you can create git repositories to save your files.

We also store our WordPress files in a git repository. whenever you make changes to your website, you add them to the git repository. This makes your application stateless.

If you want to try git, I recommend Gitlab. Github is popular for public git repositories but Gitlab allows you to create unlimited private git repositories for free.

Deployment tool

We configure a deployment tool to install required packages for Apache, clone the WordPress git repository and any other configuration files needed. When we launch a new web server, the deployment tool automatically installs and configures the new server.

Shared file storage

WordPress uses different files and folders. We have PHP and CSS files for the website and we store these in a git repository. When we start a new web server, we copy these files from the git repository to the local storage of the web server.

There are two problems though. Many legacy applications expect that they can create or modify files and folders.

If you want to update a WordPress plugin, the web server deletes the old plugin files and installs the new plugin files. We can work around this by using a local development web server we use to install a new plugin. When the plugin works, we add the new files to our git repository and build a new web server with our deployment tool.

The other problem is about file uploads. For example: when you upload an image to your WordPress website then the image is stored on the local storage of the web server. When we destroy the web server, the image is gone. To work around this, we redirect the WordPress images folder to shared file storage. You can do this on the operating system level with an NFS file share or with a WordPress plugin that uploads images to S3 directly.

Considerations

Besides figuring out if you can make your applications work in the cloud, here are some other items to consider:

• Service model: which cloud resources (IaaS, PaaS, or SaaS) will you use?
• Cloud deployment type: which deployment type (public, private, community, or hybrid) suits your requirements?
• Availability: do you make your application available in one or multiple regions? How much redundancy do you need?
• Complexity: how difficult is it to migrate the application to the cloud?
• Security: are there any security considerations when you move the application to the cloud?
• Environment: how will you implement your production, development, and staging environments?
• Regulatory compliance: does this apply to your organization?
• Dependencies: does your application have any dependencies that you can’t move to the cloud?
• Business impact: how critical is the application? You might want to start with a less critical application when this is your first migration.
• Networking: how will you access the application? Is your WAN connection sufficient?
• Hardware dependencies: does your application have any hardware dependencies? Can you run the application in the cloud?
• Cost: don’t underestimate costs. In the cloud, you pay for all resources and there are quite some costs you might not think about beforehand. Data transfer rates, log file storage, etc.

Migration strategies

There are different migration strategies if you want to move your on-premises applications to the cloud. Gartner describes five migration strategies:

• Rehost: move the application from on-premises to a virtual server in the cloud. This is a quick way to migrate your application but you’ll miss one of the most important cloud characteristics, scalability.
• Refactor: move the application to a PaaS solution so you can re-use frameworks, programming languages, and container you currently use. An example is moving your Docker containers to Google’s Kubernetes Engine.
• Revise: some applications require changes before you can rehost or refactor them in the cloud. An example is a complex python application you need to break down and modify so you can run it on a serverless computing platform like Amazon AWS Lambda or Google App Engine.
• Rebuild: get rid of the existing application code and re-create all code to use the cloud provider’s resources. Rebuilding your application from scratch with the cloud in mind allows you to use all cloud provider features but there is also a risk of vendor lock-in.
• Replace: get rid of your application and replace it with a SaaS solution. You don’t have to invest time and money in developing your application to make it suitable for the cloud but migrating your data from your application to a SaaS application can also introduce problems.

Cloud providers also offer migration strategies:

• Google Migration Center
• Amazon AWS 6 strategies
• Azure Migration Center

Evaluation and testing

Once you have analyzed your applications and decided on a migration strategy, evaluate and test your options:

• Perform a pre-migration performance baseline of each application.
• Research and evaluate different cloud providers, their services, and SLAs.
• Evaluate automation and orchestration tools. Are you going to use tools from the cloud provider or tools that are not tied to a specific cloud provider?
• Evaluate monitoring and logging tools. Do you use a tool like Amazon AWS CloudWatch or an external solution like Datadog or Elasticsearch?

Once you have evaluated your options, you can test your migration.

Execute and manage migration

If this is your first migration to the cloud, take it easy and start with the “low hanging fruit”. Start with a non-critical easy to migrate application. During this migration, you can become familiar with the process, fine-tune it, and document the lessons you have learned.

After migration

Once the migration is complete, perform a post-migration performance baseline and compare the results with your pre-migration performance baseline. Cisco has a product called Cisco AppDynamics that does the work for you. AppDynamics collects application metrics, establishes a performance baseline and reports when performance deviates from your baseline.

Conclusion

You have now learned about the steps required to migrate your on-premises workload (applications) to the cloud:

• Application discovery: figure out the requirements of your applications and research if they are suitable to run in the cloud.
  • Legacy applications are designed for traditional servers.
    • Traditional servers are our “pets” or “snowflakes”. We install, update, and repair them mostly manually and care for them.
    • You can make changes to some legacy applications to make them work in the cloud.
  • In the cloud, we run resources “on-demand”, there is no time to manually install a server.
    • We define our infrastructure resources in configuration files with a configuration management tool. We call this “infrastructure as code”.
    • We use a VCS to store configuration files.
    • We use deployment tools to install new servers automatically.
• Migration strategies: there are different strategies to migrate your applications to the cloud. The Gartner migration strategies are popular, cloud providers also offer different migration strategies.
• Evaluation and testing: once you have analyzed your applications and decided on a migration strategy, you need to evaluate all cloud providers and options.
• Execute and manage migration: start with a non-critical application that is easy to migrate so you can fine-tune and learn the process.
• After migration: compare your pre-migration performance baseline with your post-migration performance baseline.

I hope you enjoyed this lesson. If you have any questions, please leave a comment!