What is cloud computing?

Have you ever wondered what cloud computing is? It’s the delivery of computing services over the internet, which is otherwise known as the cloud. These services include servers, storage, databases, networking, software, analytics, and intelligence. Cloud computing offers faster innovation, flexible resources, and economies of scale.

Why is cloud computing typically cheaper to use?

Cloud computing is the delivery of computing services over the internet by using a pay-as-you-go pricing model. You typically pay only for the cloud services you use, which helps you:

• Lower your operating costs;
• Run your infrastructure more efficiently;
• Scale as your business needs change;

To put it another way, cloud computing is a way to rent compute power and storage from someone else’s datacenter. You can treat cloud resources like you would resources in your own datacenter. When you’re done using them, you give them back. You’re billed only for what you use.

Instead of maintaining CPUs and storage in your datacenter, you rent them for the time that you need them. The cloud provider takes care of maintaining the underlying infrastructure for you. The cloud enables you to quickly solve your toughest business challenges, and bring cutting-edge solutions to your users.

Several networking services in Azure are dedicated to application delivery. Azure Front Door and Azure CDN are services that allow us to create applications for global delivery and take advantage of the global network of Azure data centers. Leveraging this capability, we can provide the same experience to our users, irrespective of their physical location.

Create a front door instance

Azure Front Door is used for the global routing of web traffic for applications distributed across different Azure regions. With front door, we can define, manage, and monitor the routing of our web traffic and enable quick global failover. It enables us to deliver our applications with the best performance and high availability.

Front door is an L7 load balancer, similar to application gateway. However, there is a difference as regards global distribution. In terms of global distribution, it is similar to another service—traffic manager. Essentially, front door combines the best features of application gateway and traffic manager—the security of application gateway and the distribution capability of traffic manager.

The successful sample rate ensures that endpoints in the backend are available and determines how many samples are sent at a time. Successful Sample defines how many requests need to be successful in order for an endpoint to be considered healthy.

Latency Sensitivity sets the tolerance between the endpoint with the lowest latency and the rest of the endpoints. For example, let’s say the latency sensitivity setting is 30ms, while the latency of endpoint A is 15ms, that of endpoint B is 30ms, and that of endpoint C is 90ms. Endpoints A and B will be placed in the fastest pool as the difference in latency is lower than the sensitivity threshold, and endpoint C is out as it’s above the threshold.

Routing Rule defines how traffic is handled and whether specific traffic needs to be redirected or forwarded. If URL rewrite is enabled, we can construct a URL that will be forwarded to a backend. If caching is enabled, front door will cache static content for faster delivery. Front door also includes a number of configurable options and rules that can help your web applications deliver a customer- and brand-centric service.

Azure Application Gateway is essentially a load balancer for web traffic, but it also provides us with better traffic control. Traditional load balancers operate on the transport layer and allow us to route traffic based on protocol (TCP or UDP) and IP address, mapping IP addresses, and protocols in the frontend to IP addresses and protocols in the backend. This classic operation mode is often referred to as layer 4.

Application gateway expands on that and allows us to use hostnames and paths to determine where traffic should go, making it a layer 7 load balancer. For example, we can have multiple servers that are optimized for different things. If one of our servers is optimized for video, then all video requests should be routed to that specific server based on the incoming URL request.

Create an application gateway

Azure Application Gateway can be used as a simple load balancer to perform traffic distribution from the frontend to the backend based on protocols and ports. But it can also expand on that and perform additional routing based on hostnames and paths. This allows us to have resource pools based on rules and also allows us to optimize performance. Using these options and performing routing based on context will increase application performance, along with providing high availability. Of course, in this case, we need to have multiple resources for each performance type in each backend pool (each performance type requests a separate backend pool).

Using these additional rules, we can route incoming requests to endpoints that are optimized for certain roles. For example, we can have multiple backend pools with different settings that are optimized to perform only specific tasks. Based on the nature of the incoming requests, the application gateway will route the requests to the appropriate backend pool. This approach, along with high availability, will provide better performance by routing each request to a backend pool that will process the request in a more optimized way.

We can set up autoscaling for application gateway (available only for V2) with additional information for the minimum and maximum number of units. This way, application gateway will scale based on demand and ensure that performance is not impacted, even with the maximum number of requests.

Azure Load Balancer is limited to providing high availability and scalability only to Azure VMs. Also, a single load balancer is limited to VMs in a single Azure region. If we want to provide high availability and scalability to other Azure services that are globally distributed, we must introduce a new component—Azure Traffic Manager. Traffic manager is DNS-based and provides the ability to distribute traffic over services and spread traffic across Azure regions. But traffic manager is not limited to Azure services only; we can add external endpoints as well.

Create a traffic manager profile

Traffic manager provides load balancing to services, but traffic is routed and directed using DNS entries. The frontend is an FQDN assigned during creation, and all traffic coming to traffic manager is distributed to endpoints in the backend. The default routing method is Performance. The performance method will distribute traffic based on the best possible performance available.

For example, if we have more than one backend endpoint in the same region, traffic will be spread evenly. If the endpoints are located across different regions, traffic manager will direct traffic to the endpoint closest to the incoming traffic in terms of geographical location and minimum network latency.

Azure Load Balancer is used to support scaling and high availability for applications and services. A load balancer is primarily composed of three components—a frontend, a backend, and routing rules. Requests coming to the frontend of a load balancer are distributed based on routing rules to the backend, where we place multiple instances of a service.

This can be used for performance-related reasons, where we would like to distribute traffic equally between endpoints in the backend, or for high availability, where multiple instances of services are used to increase the chances that at least one endpoint will be available at all times. Azure supports two types of load balancers—internal and public.

Create an internal load balancer

An internal load balancer is assigned a private IP address (from the address range of subnets in the VNet) for a frontend IP address, and it targets the private IP addresses of our services (usually, an Azure VM) in the backend. An internal load balancer is usually used by services that are not internet-facing and are accessed only from within our VNet.

Traffic can come from other networks (other VNets or local networks) if there is some kind of VPN in place. The traffic coming to the frontend of the internal load balancer will be distributed across the endpoints in the backend of the load balancer. Internal load balancers are usually used for services that are not placed in a DeMilitarized Zone (DMZ) (and are therefore not accessible over the internet), but rather in middle- or back-tier services in a multitier application architecture.

We also need to keep in mind the differences between the Basic and Standard SKUs. The main difference is in Performance (this is better in the Standard SKU) and SLA (Standard has an SLA guaranteeing 99.99% availability, while Basic has no SLA). Also, note that Standard SKU requires an NSG. If an NSG is not present on the subnet or network interface, or NIC (of the VM in the backend), traffic will not be allowed to reach its target. For more information on load balancer SKUs, see https://docs.microsoft.com/azure/load-balancer/skus.