glossary_letter: A

<< Back to Technical Glossary

Application Security Architecture Definition

Application security architecture is a unified design that focuses on potential security risks and necessities involved in a specific environment or scenario. It is part of a move toward a shift left approach that makes application security part of the overall design and architecture of an application rather than introducing security later in testing. Application security architecture as an approach also specifies how, where, and when to apply security controls as part of a reproducible design process.

Application Security Architecture FAQs

What is Application Security Architecture?

Modern applications typically have architectural three tiers, each presenting its own potential security risk profile.

Clients live on the top tier or front end of the mobile, web, or internet of things (IoT) application. Since the goal of this tier is smooth interaction, front end developers tend to prioritize a high-quality user experience. There are numerous attacks on this tier, including denial of service and injection attacks.

The application and data from users live on the middle tier of cloud application security architecture where processing takes place behind a protective firewall and other controls.

The bottom tier is where the backend lives, including cloud infrastructure, containers, operating systems, and anything needed to store data or run the application. Most attackers aim to penetrate this tier.

There are several challenges that modern application and network security architectures face. Although the topic of application security is broad and challenges for each organization may differ, here are a few more common issues that implicate and emphasize the need for secure web application architecture.

Inherited Vulnerabilities

Although there is no substitute for careful developers during the coding process, in modern applications some vulnerabilities are inherent. This is because software systems are constantly evolving, updating, and becoming more complex. In the process, it is a constant struggle to prioritize updates, fixes, and maintenance tasks. The result is lasting legacy code in many organizational environments, and risks to security that modern security tools may be less well-equipped to handle.

Third-Party and Open-Source Vulnerabilities

Frequent use of third-party and open source libraries, especially indirect dependencies, has also produced an attractive attack vector. Open source dependencies cause maintainers to accidentally release packages with vulnerabilities or malicious code. While scanning tools are critically important, they cannot catch all such vulnerabilities, and teams should build application security into the architecture by following best practices and enforcing them.

DevSecOps vs Shift Left

Teams should incorporate security throughout the development process by taking a shift left approach rather than DevSecOps which places scanning later in the software development life cycle. The bottleneck that results as development teams scramble for fixes, and triaging issues, results in many false positives and excessive lost time.

Tools for Centralized Management of Application Security Architecture

Application security teams require tools that allows them to constantly monitor and assess the security posture and each aspect of the application’s architecture. The best tools centralize all monitoring and reporting on a single dashboard.

Application Security Architecture OWASP

The Open Web Application Security Project (OWASP) is a nonprofit that releases a yearly list of the top 10 web application security vulnerabilities. These highlights from the 2021 Top 10 Application Security list (the OWASP Top 10 2021) is based on data on the common vulnerabilities and risk profile of more than 500,000 applications.

This list offers some notable insights. One is that broken access control, previously at #5, is now the #1 threat on the list. Another change is that authentication and identification failures fell from #2 to #7. #3 is injection attacks, while #6 is vulnerable and outdated components. 

Application security testing orchestration continuously integrates security and the development process as part of the overall cloud security posture. It is essential to include all levels of application security as part of this process, from code via dependencies to configuration in the cloud.

According to OWASP, the age of DevSecOps has forced the art of security architecture into the background in many organizations. The application security field must re-introduce leading security architecture principles to software practitioners and adopt agile security principles to catch up to a modern approach.

Application security architecture is a problem solving approach, not a specific implementation, so there is no single “correct” approach or one solution for architecture. A web application’s specific implementation is likely to be revised continuously throughout its lifetime, although changes to the overall architecture will usually be slow and rare.

The primary aspects of any sound application security architecture include: availability, confidentiality, non-repudiation, processing integrity, and privacy. Each of these application security architecture principles must be innate to all applications.

It is critical to the “shift left” approach to ensure that all security controls are present and functional. Application security architecture and design professionals must stay current with agile techniques, learning to code, adopting developer tools, and collaborating with developers rather than coming to the project months later.

OWASP’s application security architecture patterns, found here, depict a specific context for information usage. Based on application security architecture overview diagrams, these IT security architecture patterns are annotated diagrams with NIST controls catalog references.

Patterns that see repeat use across many IT Security Architectures are called modules—the client and server modules, for example. Since most patterns are divided up this way, they are much simpler to read, understand, build, and maintain.

What is the Application Security Life Cycle?

The application security lifecycle and the software development life cycle (SDLC) run parallel to each other. Traditional security approaches secure an application only late in development or after it is running in production. These development practices are earlier in the modern process, with security incorporated from the beginning of the SDLC into the runtime environment.

According to OWASP, Secure Software Development Lifecycle Requirements include:

• Using a secure software development lifecycle at all stages of development
• Identify threats, facilitate appropriate risk responses, plan for countermeasures, and guide security testing for each sprint planning or design change with threat modeling
• Ensure all user stories and features include functional security constraints
• Verify justification and documentation of all application components, trust boundaries, and significant data flows
• Define application’s high-level architecture and each remote service connected and verify security analysis
• Verify implementation of centralized, reusable, secure, simply designed, and vetted security controls to avoid duplicate, ineffective, missing, or insecure controls.
• Verify security requirements, guidelines, coding checklist, or policy is available to all developers and testers

 

OWASP also provides Authentication Architectural Requirements:

When proofing identity and designing authentication, all authentication pathways must have the same strength:

• Use of special low-privilege or unique operating system accounts for all application services, components, and servers
• Authenticate all communications between application components, including APIs, data layers, and middleware, with the least necessary privileges enabled
• Use a single, secure, vetted authentication mechanism that can include strong authentication and detect account abuse or breaches
• Verify consistent authentication security control strength all authentication pathways and identity management API implementations

 

OWASP Access Control Architectural Requirements are as follows:

• Verify the existence and functioning of trusted enforcement points at access control servers, gateways, and serverless functions; never enforce against client
• Access protected data and resources with a single and well-vetted access control mechanism and pass all requests through it to avoid insecure alternative paths or copy-and-paste
• Use roles to allocate permissions, and use attribute or feature-based access control

 

OWASP’s Input and Output Architectural Requirements are as follows:

• Clearly define how process data should be handled based on content, type and applicable regulations, laws, and policy in the input and output requirements
• Do not use serialization when communicating with untrusted clients, or enforce adequate integrity controls (and encryption if sensitive data is sent) to prevent deserialization attacks
• Enforce input validation on a trusted service layer
• Verify that output encoding is located near the interpreter for whom it is intended

 

OWASP Cryptographic Architecture Standards indicate:

Design applications with strong cryptographic architecture to protect data assets based on their classification. Strike a balance on what should be designed with cryptographic architecture during architectural or high level design or architectural stages or sprints. Architectural requirements demand consideration throughout the coding phase, and should be reviewed during security architecture and code review.

In addition:

• All keys and passwords should be part of a well-defined process to re-encrypt sensitive data and replaceable.
• Architecture must never offer easy access sensitive data and should treat client-side secrets—such as passwords, symmetric keys, or API tokens—as insecure

 

OWASP Errors, Logging, and Auditing Architecture:

• Use a common logging approach and format across the system
• Securely transmit logs to a system, ideally a remote system, for detection, analysis, alerting, and escalation

 

OWASP Data Protection and Privacy Architecture:

Identify and classify all sensitive data into protection levels with associated protection requirements, such as integrity requirements, encryption requirements, privacy and confidentiality requirements, and retention requirements.

OWASP Communications Architecture:

• Encrypt communications between components, especially those in different cloud providers, containers, sites, or systems.
• Verify the authenticity of each side in a communication link (such as TLS certificates and chains) to prevent person-in-the-middle attacks.

 

OWASP Malicious Software Architecture:

Use a source code control system, accompanying check-ins with tickets for issues or changes and leaving identifiable users and traceability of all changes.

 

OWASP Business Logic Architecture:

• Define and document all components and their business or security functions
• Verify that high-value business logic flows, including session management, authentication, and access control:
  • do not share an unsynchronized state
  • are thread safe
  • are resistant to time-of-use race conditions and time-of-check

Application Security Architecture Best Practices 

Best practices for application data security architecture are numerous. As explained above, they are flexible, but fall within the OWASP guidelines.

Not every practice will apply to every application or organization. However, some of the most common web application security architecture best practices include:

Simplicity. An application security architecture framework must ensure it is simple and fast to develop and deploy secure code. This empowers the development team to focus on rapid development and functionality while ensuring code is secure.

This also demands easy authentication and centralized authorization that ensures all application, service, and other requests are authorized vertically and horizontally without input from developers. The architecture must use a data access framework that renders cracking open an SQL injection vulnerability impossible.

Layered security. Ideally, enterprise application security architecture should plan for failure while ensuring developing code without falling prey to any of the OWASP Top 10 vulnerabilities is a simple matter. Multiple layered security controls should limit the blast radius of failures and prevent catastrophic breaches.

Conduct regular application and data security architecture reviews. Effective application security architecture review takes a three-pronged approach, assessing technologies such as training and process tools; processes such as controls and policies; and people.

Each of these practices should fall in line with the OWASP guidelines.

What is Application Security Architecture Assessment?

The OWASP Architecture Assessment (AA) ensures that application architecture meets all relevant compliance and security requirements, and mitigates against any security threats identified sufficiently.

The Software Assurance Maturity Model (SAMM) was developed in 2009 and the 3-level application security architecture analysis is an important piece of the OWASP SAMM assessment process.

There are several streams in the process: verification, analysis, architecture validation, and architecture mitigation.

Verification. The first stage verifies that the application architecture is meeting all security and compliance requirements and practices it identifies, both ad-hoc and systematically for every system interface. Verification tests the software during development, ensuring they have reached established requirements and acceptable security levels. It usually includes automatic and manual tests, quality analysis, and other evaluation and verification activities.

Architecture analysis. The second stream reviews the architecture for mitigations against typical threats and against specific identified threats from the assessment. The goal of high-level architecture analysis is to ensure that the infrastructure and architecture properly address the identified security requirements to mitigate threats. The security requirements can be raised and listed according to the necessary verification level through the Application Security Verification Standards (ASVS).

Security requirement compliance verification can be conducted ad hoc or systematically per interface. The analysis for all security architecture components must be performed in a structured way. Continuous, ongoing assessment of weakness and possible improvements in the security architecture practices is important to ensuring optimal performance. Mitigation evaluates the effectiveness of security controls continuously, as well as their strategic alignment and scalability.

Architecture validation. These practices facilitate the visualization and analysis of application security architecture. At the lowest level, this involves defining the general perspective of the architecture and listing security mechanisms. The high-level analysis includes organizational architecture revision, compliance with security requirements, testing the efficiency, scalability, and availability of the implemented security controls, and other functions.

Architecture mitigation. Verify whether existing strategies are sufficient to protect structures and components. Review each threat that is identified ad hoc and systematically and record the impact of security decisions and revisions to architecture.

Implementing security processes effectively in the realm of architectural analysis is closely associated with the joint work of architects, designers, developers, and the security team.

Does Avi Offer Application Security Architecture Solutions?

Yes. Traditional web application security solutions such as appliance-based web application firewalls (WAFs) are complex to manage, rigid to scale, lack application security insights, and require costly overprovisioning to compensate for lack of elasticity. These web application security challenges and web application attacks in increasing numbers and severity fuel the need for a modern, secure web application framework.

Modern application development and deployment approaches that include continuous integration and continuous delivery (CI/CD) methods demand elastic capacity and new strategies for distributed application security. A resilient platform with security baked in from the state is the first line of defense against security attacks. 

In contrast to traditional hardware-based solutions, Avi’s Web App Security is a comprehensive Web Application and API Protection solution that delivers network and application security with a context-aware web application firewall (WAF) to protect against all forms of digital threats.

Avi’s Web App Security solution offers:

• Positive security with WAF learning mode
• Real-time app security insights
• Centralized application security management

 

Avi provides real-time visibility, granular insights, and application security analytics in addition to rule matches and traffic monitoring. Avi’s central control plane and distributed data plane create an elastic application services fabric with centralized policies that enables a rapid response as attack surfaces of new applications, microservices or instances are increased.

The Avi WAF is not a perimeter—it is deployed per application based on specific policies to apply for each app. This opens up a world of customization and scalable security that is just not available with traditional tools.

The optimized application security pipeline and stack approach to web application security delivers web-scale performance with point-and-click simplicity. Avi offers ease of use, visibility, and scalability via its integrated application security stack approach. WAF is only the outermost layer.

Learn more about Avi’s application security platform here.

<< Back to Technical Glossary

Azure Load Balancer Definition

An Azure load balancer is an ultra-low-latency Open Systems Interconnection (OSI) model Layer 4 inbound and outbound load balancing service for all UDP and TCP protocols. Built to handle millions of requests per second, an Azure application load balancer distributes incoming traffic among healthy VMs to deliver high availability. The Azure elastic load balancer further ensures high availability across availability zones by remaining zone redundant.

The Azure classic load balancer allows users to configure the front-end IP to include one or more public IP addresses. Front-end IP configuration renders applications and the Azure WAF load balancer internet accessible.

Virtual machines use virtual network interface cards (NICs) to connect to an Azure software load balancer. A back-end address pool connected to the Azure standard load balancer contains the IP addresses of the virtual (NICs) to distribute traffic to the VMs. The Azure load balancer monitors specific ports on each VM with a health probe to ensure only operational VMs receive traffic.

Azure Load Balancer FAQs

What is Azure Load Balancer?

Microsoft Azure, formerly called Windows Azure, is the public cloud computing platform from Microsoft. Azure offers a range of cloud services for computer, networking, analytics, and storage.

Users build and run applications with these services in the public cloud, and load balancing provides higher availability and scalability by extending incoming requests across many virtual machines (VMs). Users can create a load balancer in the Azure portal.

A load balancer fields client requests, identifies which machines can manage them, and forwards them accordingly. An Azure Load Balancer is a cloud-based system that allows users to control a set of machines as a single machine.

Azure Load Balancer serves as the single point of contact for clients at layer 4 of the Open Systems Interconnection (OSI) model. It distributes inbound traffic that arrives at the front end to pool instances on the backend. The backend pool instances can be virtual machine scale set instances or Azure Virtual Machines. Load-balancing rules and health probes determine how the traffic is distributed.

Public load balancers provide outbound connections and balance internet traffic for VMs inside the virtual network. They achieve this by translating private IP addresses so they are public.

Private, or internal load balancers, that load balance traffic inside a virtual network are used where the frontend is the only place where private IPs are needed. In a hybrid situation, users can access a load balancer frontend from an on-premises network.

Azure Load Balancer Overview

In terms of types of load balancers in Azure, Microsoft Azure offers a portfolio that consists of multiple load balancing and network traffic management services. These can be used alone or in combination, although the optimal solution may require them all, depending on your requirements.

The Azure load-balancing portfolio includes Traffic Manager, Application Gateway, and Azure Load Balancer.

To deliver global DNS load balancing, Traffic Manager assesses incoming DNS requests against user routing policy and responds with a healthy endpoint. Azure load balancer routing methods include:

• Geography-based routing distributes application traffic to endpoints based on user geographic location.
• MultiValue routing enables users to send IP addresses of multiple application endpoints in a single DNS response.
• Performance routing reduces latency by sending the requestor to the closest endpoint.
• Priority routing directs traffic to the primary endpoint and reserves backup endpoints.
• Subnet-based routing distributes application traffic to endpoints based on user subnet or IP address range.
• Weighted round-robin routing distributes traffic to each endpoint based on assigned weighting.

 

The client connects directly to the endpoint Traffic Manager. When an endpoint is unhealthy, Traffic Manager detects it and redirects clients to healthy instances.

Functioning as an application delivery controller (ADC) as a service with various Layer 7 load-balancing capabilities, Application Gateway is essentially the Azure layer 7 load balancer. It enables customers to offload CPU-intensive TLS termination to it to optimize web farm productivity.

Other Layer 7 routing capabilities include the ability to host multiple websites with just one application gateway, cookie-based session affinity, round-robin distribution of incoming traffic, and URL path-based routing. Application Gateway can be configured as an internal-only gateway, an Internet-facing gateway, or a hybrid. A fully Azure managed platform, Application Gateway is highly available and scalable, with robust logging capabilities and diagnostics intended to enhance manageability.

Finally, rounding out the Azure SDN stack is Azure Load Balancer, offering low-latency, high-performance Layer 4 load-balancing services for TCP and UDP protocols. The Azure load balancer manages outbound and inbound connections and users can manage service availability with TCP and HTTP health-probing options, defining rules to map inbound connections to back-end pool destinations and configuring public and internal load-balanced endpoints.

The Azure load balancer architecture consists of 5 objects.

• IP Address. A public IP address if it is intended to be public-facing or a private IP address if it is intended to be internal.
• Backend Pool. A backend pool of virtual machines and rules about which should receive traffic.
• Health Probes. These are probes or rules designed to assess resource health in the backend pool.
• Load Balancing Rule. Combines IP addresses, backend pool, and health probes, together with rules for how to load balance traffic to the backend resources and on which backend port in the backend pool traffic should go.
• Optional NAT Rule. This enables port network address translation (NAT) to one of the backend servers on a specific port in the pool.

 

Using Traffic Manager, Application Gateway, and Azure Load Balancer together can enable many sites to achieve several design goals:

• Internal Load Balancing. The Load Balancer stands in front of the high-availability cluster, ensuring only healthy and active database endpoints are exposed to the application and that only healthy databases receive connection requests. Users can optimize Azure load balancer performance by distributing passive and active replicas independent of the front-end application across the cluster.
• Independent Scalability. The application owner can scale request workloads independently because the web application workload is separated by content type. Application Gateway routes traffic based on application health and the specified rules.
• Reduced Latency. Traffic Manager reduces latency by automatically directing the user to the closest region.
• Multi-Geo Redundancy. If one region fails, Traffic Manager seamlessly and automatically routes traffic to the nearest region.

 

For Azure load balancer troubleshooting tips, information on how to configure a load balancer in Azure, and more, refer to the Azure load balancing page and find Azure load balancer documentation here.

Azure Load Balancer Features and Advantages

Why use Azure Load Balancer? Use Azure Load Balancer to create highly available services and scale applications. Load Balancer provides high throughput and low latency, supports both inbound and outbound scenarios, and scales up for all TCP and UDP applications.

Use cases for Azure Standard Load Balancer include:

• Load balance both internal and external Azure virtual machine traffic.
• Distribute resources within and across zones to increase availability.
• Configure Azure VM outbound connectivity.
• Monitor load-balanced resources with health probes.
• Access VMs in a virtual network by port and public IP address with port forwarding.
• Support IPv6 load balancing.
• Azure standard load balancer provides multi-dimensional metrics that can be grouped, filtered, and broken out through Azure Monitor.
• Load balance services on multiple IP addresses, ports, or both.
• Move load balancer resources, both internal and external, across Azure regions.

 

The Azure load balancer is designed on the zero-trust network security model to be a secure part of a virtual network by default. That network itself is isolated and private, and the load balancer does not store user data. Use network security groups (NSGs) to permit allowed traffic only.

Azure Load Balancer supports availability zones scenarios and can either be zone redundant, zonal, or non-zonal. Increase availability by aligning distribution across zones and resources within them. Just select the appropriate type of frontend needed and configure the zone-related properties.

Azure Load Balancer Disadvantages

There are a few drawbacks to using Azure Load Balancer, particularly compared with more advanced load balancing solutions.

• The Azure Load Balancer does not support PaaS services.
• Azure Load Balancer runs on level 4 of the OSI model for TCP and UDP, so it lacks intelligent, content-based traffic routing mechanisms for URL or HTTP traffic.
• In contrast to many other load balancing solutions, Azure Load Balancer does not act as a reverse proxy or interact with the payload of a TCP or UDP flow.
• For VMs that lack public IPs, Azure translates the source IP address that is private using SNAT with port masquerading to a public source IP address. This outbound flow IP address is public, but it cannot be assigned, reserved, or saved, so it is not compatible with a whitelist system.

 

Is There An Azure Kubernetes Load Balancer?

The Azure Kubernetes Service (AKS) supports both inbound and outbound scenarios on L4 of the Open Systems Interconnection (OSI) model. Inbound flows arrive at the front end of the load balancer then get distributed to backend pool instances.

There are two purposes for a public Azure Load Balancer configuration integrated with AKS:

• Translate the nodes of private IP addresses to a public IP address in the outbound pool to deliver outbound connections to cluster nodes inside the AKS virtual network.
• To create highly available services and scale applications easily by providing access to applications via Kubernetes services.

 

Where private IPs are required on the frontend, a private or internal load balancer is needed. Internal load balancers function inside a virtual network and in a hybrid scenario, users can also access the frontend from an on-premises network.

What Is Azure Load Balancer Auto-Scaling?

Autoscaling allows organizations to scale cloud services such as virtual machine instances or server capacities up or down automatically, based on defined conditions such as utilization levels, traffic, or other criteria. The Azure Load Balancer auto-scaling feature saves money by scaling instances in and out automatically.

How Does Azure Load Balancer Failover Work?

Automatic failover is a core feature of any application load balancer. When an origin within your load balancing configuration fails, failover redirects requests to help maintain system availability. However, because failover protection occurs at the network and application layers of the Open Systems Interconnection (OSI) model, layer 3 and layer 7, Azure Load Balancer alone cannot provide this functionality.

Azure Load Balancer Monitoring

Azure Load Balancer collects metrics and logs and other kinds of monitoring data, in tandem with Azure as a whole. Load Balancer also provides additional monitoring data through:

• Health Probes
• REST API
• Resource health status

 

What is Session Persistence in Azure Load Balancer?

Session persistence, also called session affinity, client IP affinity, or source IP affinity, is a distribution mode. In this mode, connections from the same client will go to the same backend instance in the pool.

Client IP uses a two-tuple hash to route to backend instances: source IP and destination IP. This specifies that the same backend instance will handle successive requests from the same client IP address. Client IP and protocol use a three-tuple hash to route to backend instances: source IP, destination IP, and protocol type. This specifies that the same backend instance will handle successive requests from the same protocol and client IP address combination.

Does VMware NSX Advanced Load Balancer Offer a Microsoft Azure Load Balancer Alternative?

Yes, The VMware NSX Advanced Load Balancer is an Azure load balancing solution. Performance across multi-cloud environments and enterprise-grade application networking services are essential to migrating applications to Azure. As a cloud-native, elastic web application security and load balancing solution for Microsoft Azure with built-in application analytics, The VMware NSX Advanced Load Balancer delivers an enterprise-grade, software-defined solution that includes an Intelligent Web Application Firewall, a Software Load Balancer, and a Container Ingress Controller for container-based applications.

The VMware NSX Advanced Load Balancer Azure platform delivers central management of L4 – L7 application services across any cloud environment. The architecture offers enterprise-grade Azure load balancing services, including application security, caching, content-switching, elastic load balancing, GSLB, predictive autoscaling, real-time insights into application performance, SSL offload, and end-to-end automation.

Find out how much easier Azure migration can be—all without third-party logging tools—here.

<< Back to Technical Glossary

AWS Load Balancer Definition

AWS load balancers accept incoming application traffic from clients and distribute it across various registered targets such as EC2 instances in multiple availability zones. The AWS application load balancer feature allows developers to route and configure incoming traffic in the AWS public cloud between end-users and applications.

A single point of contact for clients, the AWS elastic load balancer only routes to healthy instances and identifies unhealthy instances. Once the target is operational, the AWS load balancer algorithm resumes routing traffic to it.

Load balancing is essential in cloud environments with multiple web services.

AWS Load Balancer FAQs

What is AWS Load Balancer?

AWS Elastic Load Balancing (ELB) distributes incoming application traffic automatically across multiple targets such as containers, EC2 instances, and IP addresses in one or more availability zones. This distributes and balances how frontend traffic reaches backend servers and increases the fault tolerance and availability of user applications. AWS load balancing also monitors registered targets for health and routes distributes traffic accordingly.

AWS Load Balancer Types

There are four AWS load balancer types supported:

• AWS Classic Load Balancer
• AWS Network Load Balancer (NLB)
• AWS Application Load Balancer (ALB)
• AWS Gateway Load Balancer (GLB)

 

The previous-generation AWS classic type of load balancer is now only recommended where users have instances running on an EC2-Classic network. For all other users, AWS Classic Load Balancer features can be replaced by either AWS Network Load Balancer (NLB) or AWS Application Load Balancer (ALB).

(AWS Gateway Load Balancer does not distribute traffic across multiple targets, so its applications are less broad. In terms of AWS load balancer differences this is the most significant for most users.)

Take a closer look with an AWS load balancers comparison:

AWS Classic Load Balancer

This simple load balancer operates both at the request level and the connection level and was originally used for classic EC2 instances. Its primary disadvantage is that it does not support certain features, such as route-based or host-based routing. A well-configured load balancer can improve efficiency and performance by distributing the load among the servers regardless of what they contain.

AWS Application Load Balancer

The Application Load Balancer (ALB) is an OSI model layer 7 load balancer that routes network packets based on their contents to different backend services. In contrast to the classic AWS elastic load balancer which would need to run for each service, an AWS application load balancer delivers AWS layer 7 load balancing that can balance the network traffic of many backend services.

This new generation load balancer offers native support for WebSocket and HTTP/2 protocols. WebSocket allows developers to minimize power consumption even as they configure persistent TCP connections between client and server. HTTP/2 reduces network traffic by multiplexing requests over a single connection.

AWS Load Balancer Classic vs Application Load Balancer

AWS application load balancer performance is higher and supports more features compared with the classic load balancer, such as the following

• IP address registration as targets
• Path-based/host-based routing
• Calling Lambda functions to serve HTTP(S) requests
• AWS WAF load balancer
• SNI
• Enhanced containers via load balancing between multiple ports of a single instance

 

Network Load Balancer AWS

AWS recommends AWS Network Load Balancer (NLB) if the application needs to achieve static IP and extreme performance. In terms of ​​the AWS application vs network load balancer comparison, the NLB is better optimized to manage traffic patterns that are unstable and spiky and workloads that fluctuate rapidly.

NLB delivers high throughput and scales to handle millions of requests per second. This means network load balancer is better suited for achieving extreme network performance and handling bursty workflows at the transport layer. AWS network load balancers also avoid DNS caching problems and work with existing firewall security policies of users thanks to its static and resilient IP addresses. And AWS load balancer TLS termination is only possible with NLB.

How AWS Load Balancer Works

The AWS load balancer increases application availability by serving as a single point of contact for clients. Users can seamlessly add and remove instances from the AWS load balancer without disrupting the overall request flow to the application as needs change over time. In this way, AWS elastic load balancing scales as application traffic fluctuates and can in fact scale to most workloads automatically.

Users add one or more listeners to the load balancer. A listener uses the configured port and protocol to check for connection requests from clients and forwards requests using the configured port number and protocol to registered instances. Health checks ensure the AWS load balancer sends requests only to healthy instances.

The AWS load balancer distributes traffic evenly across enabled availability zones by default. To improve fault tolerance, maintain instances in approximately equivalent numbers across availability zones. You can also enable cross-zone load balancing. This type of elastic load balancing supports even traffic distribution across all registered instances.

Enabling an availability zone creates a load balancer node inside the availability zone. Targets, even if they are registered, do not receive traffic if the availability zone is not enabled.

In addition, even the classic AWS load balancer algorithm works best with at least one registered target in each enabled availability zone, but enabling multiple availability zones for all load balancers. AWS application load balancers require enablement of at least two availability zones to ensure continuous routing of traffic.

Targets in a disabled availability zone remain registered with the AWS load balancer, but they do not receive traffic. Learn more in the AWS developer guide.

AWS Load Balancer Features and Benefits

The AWS load balancer is designed to ensure elasticity of resources and high availability. Here are some of the key AWS load balancer benefits

• High availability and distribution of website traffic to multiple destinations or targets.
• Adjusting without human intervention to major changes in website traffic.
• SSL/TLS decryption and user authentication functions offer high security.
• Hybrid load balancing can assist in migrating cloud resources.
• Continuous auditing and monitoring delivers increased visibility of your applications.
• Support for AWS certificate manager.

 

Here is a closer look at some of the more important AWS load balancer attributes and features.

Amazon EC2 Auto Scaling

• Maintain application availability with Amazon EC2 Auto Scaling and add or remove EC2 instances automatically and with dynamic and predictive scaling features according to defined conditions. 
• Maintain the fleet availability and health using Amazon EC2 Auto Scaling fleet management features. 
• Use predictive scaling and dynamic scaling in tandem for more rapid scaling.

 

AWS Load Balancer Reverse Proxy

AWS Application Load Balancer can be used as a reverse proxy, but it supports no dynamic targets, only static targets. In other words, it supports fixed IP addresses but not domain names.

AWS Internal vs External Load Balancer

How do the AWS internal and external load balancers differ?

An internal load balancer routes traffic to EC2 instances in private subnets which clients must be able to access. Even a Route53 record pointing to an internal load balancer cannot grant access to a client not on the virtual private cloud (VPC).

External load balancers, whose nodes have public IP addresses, are needed for clients who are not on the VPC to connect. External load balancers, sometimes called internet-facing load balancers, have DNS names that are publicly resolvable to the public IP addresses of the nodes. This allows them to route requests from all over the internet.

Internal load balancer nodes have private IP addresses only, and the internal load balancer’s DNS name is publicly resolvable to those private IP addresses. Therefore, internal load balancers can accept and handle requests only from clients who can access the virtual private cloud.

AWS Load Balancer Failover

Use auto scaling groups and AWS elastic load balancing health checks to identify and cycle out failing instances automatically, with no downtime. Each app is deployed to its own cluster of instances. An Auto Scaling Group (ASG) and an ELB control that cluster. The ASG controls how many instances exist in the cluster, and when to adjust that number.

The ASG verifies the health of an instance each time it boots one, and verification can have two outcomes. If the instance passes the health check, the ASG allows it to run and the ELB marks it “In Service” so it can send it incoming traffic.

If something is wrong with the instance or the app on it and the instance fails the health check, the ASG gives it a grace period as the ELB marks it as “Out of Service” until eventually the ASG replaces it.

Monitoring is continuous, and the ELB will mark any instance that fails health checks and stop routing traffic so the ASG can respond and replace it.

AWS Load Balancer Controller

AWS Load Balancer Controller, sometimes called AWS Load Balancer Kubernetes and formerly called “AWS ALB Ingress Controller“, manages elastic load balancers in Kubernetes clusters. It provisions application load balancers to satisfy Kubernetes Ingress resources and provisions Network Load Balancers to satisfy Kubernetes Service resources.

AWS Load Balancer Path Routing

AWS load balancer path routing, also called path-based routing or URL-based routing, is a unique feature of the AWS application load balancer. The ALB forwards requests to specific targets based on configured rules.

AWS Load Balancer Configuration

Use the web-based AWS Management Console interface to create and configure an AWS load balancer.

Before you begin, choose which two availability zones you’ll use for your EC2 instances. In each availability zone, configure at least one public subnet into the virtual private cloud (VPC); these are used to configure the load balancer. In addition, users can launch EC2 instances in other subnets of the availability zones.

Each availability zone should have one or more EC2 instances with a web server such as Ngnix or Apache installed. Security groups must enable HTTP access for these instances on port 80.

Then, use AWS configure load balancer documentation to

• Select which type of AWS load balancer to use
• Complete basic configuration
• Configure a security group
• Configure a target group
• Register targets
• Create a load balancer and test it
• Get more details on how to configure AWS load balancers

Limitations of AWS Load Balancer

AWS load balancers do a good job with basic functions, but they face a few significant challenges.

AWS Load Balancer Latency

AWS load balancer latency is among the system’s most notable limitations. With a classic load balancer several things can cause high latency, starting with faulty configuration. Beyond that, the high latency trouble spots are basically the same for the AWS application load balancer, especially relating to backend instances:

• Faulty configuration
• Network connectivity problems
• And as to backend instances
  • High CPU utilization
  • High memory (RAM) utilization
  • Faulty web server configuration
  • Issues caused by web application dependencies such as Amazon S3 buckets or external databases running on backend instances

 

Scalability: AWS Load Balancer vs Autoscaling

The load balancer and auto scaling AWS have their closest nexus in the updated network load balancer (NLB) offerings. These interact in Layer 4 and can terminate incoming TCP/TLS connections, ensure an onward connection for the upstream target, and determine what that target is.

The AWS network load balancer manages, adds, and removes available targets as a target group, making the upstream target pool elastic. In many ways, AWS network load balancers excel, but they still face a few notable scalability and elasticity challenges.

Target Group Limit

The AWS network load balancer limits the number of frontend server instances that can belong to a target group. According to AWS documentation this is based on a number of quotas, which users may adjust via account management operations.

However, the constraints of AWS load balancer architecture mean that these quotas are more like hard limits for the system. To deal with this you can attempt to increase target size with vertical scaling or use multiple NLBs, but neither solution is complete or offers the seamless experience users hope for.

Connection Stability

When high numbers of established connections are passing through a single network load balancer, they sometimes drop suddenly with no apparent cause. There can also be a delay before the NLB reconnection attempts succeed and the system re-admits traffic.

This problem in connection stability for single NLBs handling high numbers of connections is due to limits in architectural design, and essentially caps the number of connections a lone NLB can maintain.

Other Considerations

Solutions such as AWS application load balancer (ALB) or even NLB lack real-time application analytics, traffic management across clouds, and robust load balancing capabilities. Similarly, virtual appliances cannot support the elasticity and automation cloud-native applications demand, nor can they scale across multiple clouds. And traditional load balancers are designed to be based in appliances, not cloud environments. These legacy solutions also demand tedious management of individual instances and manual configuration, and lack native integration with features popular with developers and AWS APIs.

Does VMware NSX Advanced Load Balancer Offer an AWS Load Balancer Alternative?

Yes. The VMware NSX Advanced Load Balancer Platform offers advanced security, application analytics, application monitoring, full-featured load balancing, multi-cloud traffic management, on-demand autoscaling, and more. The VMware NSX Advanced Load Balancer deploys in virtualized, bare metal, or container environments, far exceeding what AWS load balancers and other legacy tools can do.

Amazon ALB and ELB lack advanced policy support and enterprise-class features, and provide only basic load balancing. The VMware NSX Advanced Load Balancer delivers enterprise-grade full-featured load balancing and advanced policy support:

• Advanced HTTP content switching capabilities
• Comprehensive persistence
• Customizable health monitoring
• DNS services and GSLB across multiple clouds

 

Learn more here.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

<< Back to Technical Glossary

Application Traffic Management Definition

Application traffic management (ATM) refers to techniques for intercepting, analyzing, decoding, and directing web traffic to the optimum resources based on specific policies. Also called network traffic management, it allows network administrators to significantly increase overall network application performance by routing and filtering packets based on content in their payloads or headers. By applying these standards for security, scalability, availability, and performance to any IP-based application users can save money and improve efficiency.

 

Application Traffic Management FAQs

What is Application Traffic Management?

Application traffic management (ATM) refers to controlling and monitoring all application connectivity and availability issues. By enhancing availability, efficiency, and security, ATM addresses capacity and ensures the network is a well-managed, high-value resource.

Application Delivery Controllers (ADC) provide ATM by quickly optimizing the delivery and routing of specific types of data to ideal resources. Unlike legacy appliance-based ADCs, modern solutions use deep packet inspection combined with rules and policies to determine what type of data it is and other application performance metrics, in the process of finding the right organizational servers to route it to. This allows the system to prioritize certain types of data, sending mission-critical data preferentially to high-performing servers.

Application Delivery Controllers and Application Traffic Management

Application delivery controllers, also called load balancers, handle several types of application traffic as they discern how to route data:

Burst Traffic. This is inconsistent traffic (like downloads with large files such as video or images) that comes in bursts and then subsides. This kind of traffic exhausts application availability by immediately consuming a high bandwidth, so load balancers can contain it by limiting bandwidth access.

Interactive Traffic. Interactive traffic consists of short pairs of requests and responses (like online shopping or browsing) that involve applications and end-users in real-time interactions. These exchanges result in poor application response time and reduced bandwidth. Manage interactive traffic by prioritizing requirements over other traffic.

Latency Sensitive Traffic. This traffic is time-sensitive, such as live gaming, VoIP, video streaming, and Video Conferencing. The application depends on a steady stream of traffic and on-time service, but still may experience sudden bursts of traffic despite an ongoing demand for required data packets. A range of bandwidth based on priorities is the way to handle this issue with load balancing.

Non-Real-Time Traffic. Emails and batch processing applications generate non-real-time traffic in which real-time delivery is less critical. Scheduling bandwidth outside business hours is important to effective traffic management here.

Benefits of Application Traffic Management Solutions

A well-run network with smarter ATM delivers several key benefits for organizations:

Simplified infrastructure. A public cloud service that replaces hardware-based application servers is better equipped to scale without sacrificing quality.

Reduced costs. When application performance improves and brings user experience along with it, companies’ costs for customer support drop. A cloud-native process for application delivery and traffic management also saves on maintenance and hardware acquisition costs.

Enhanced productivity. When team members can easily access services and information on applications anywhere, from any device, efficiency is optimal. Applications can perform faster with cloud-native management.

Improved end-user experience. Faster, smoother, more user-centric experiences are possible with efficient cloud-based application traffic management.

Improved security performance. Smarter routing and optimal resource management protect the entire system from internal and external threats and keep applications secure.

Application Traffic Management Best Practices

There are several important best practices for application traffic management to keep in mind.

Data source

Application traffic managers work with two main sources of data: flow data and packet data. The controller acquires flow data from routers and other Layer 3 devices. Flow data informs the system about traffic volumes and the routes network packets travel. This helps improve performance by better using available resources because it identifies unauthorized WAN traffic.

The application traffic manager sources packet data from mirror ports and SPAN to better understand how the application and users are interacting and to track those interactions on WAN. The controller can use these data sets to assess security issues such as suspicious malware.

Real-time and historical data

Real-time data is critical to effective application traffic monitoring, but historical data is also important to optimized performance. Both types of data are crucial to analyzing past events, identifying trends, and comparing new activity to past behavior.

Internal and external traffic monitoring

Most networks are configured with intrusion detection systems, but a huge number of them lack sufficient internal traffic monitoring. This means the entire system is vulnerable to internal damage from a rogue IoT device or corrupt mobile that is inside. This also means that any internal errors or misconfiguration could result in the firewall allowing malicious traffic.

Does VMware NSX Advanced Load Balancer Offer Application Traffic Management Solutions?

Yes. The VMware NSX Advanced Load Balancer delivers multi-cloud application services such as load balancing and ingress controller services for containerized applications with microservices architecture through dynamic service discovery, ATM, and web application security. Container Ingress provides scalable and enterprise-class Kubernetes ingress traffic management, including local and global server load balancing (GSLB), web application firewall (WAF), and performance monitoring, across multi-cluster, multi-region, and multi-cloud environments. The VMware NSX Advanced Load Balancer integrates seamlessly with Kubernetes for microservices and container orchestration and security.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

<< Back to Technical Glossary

AWS Route 53 Definition

Amazon Route 53, part of the Amazon Web Services (AWS) cloud computing platform from Amazon.com normally referred to as AWS Route 53, is a highly available, scalable Domain Name System (DNS) service. Released in 2010, its name refers to both the classic highway US Route 66 and the destination for DNS server requests: TCP or UDP port 53.

AWS Route 53 translates URL names, such as www.wordpress.com, into their corresponding numeric IP addresses—in this example, 198.143.164.252. In this way, AWS Route 53 simplifies how cloud architecture routes users to internet applications.

AWS Route 53 FAQs

What is AWS Route 53?

AWS Route 53 is intended for managing DNS for services and machines deployed on Amazon’s public cloud. The AWS Route 53 DNS service connects user requests to ELB load balancers, Amazon EC2 instances, Amazon S3 buckets, and other infrastructure running on AWS.

Key Amazon Route 53 Benefits and Features

AWS service integration. Obviously, the tight integration of AWS Route 53 with CloudFront, S3, and ELB means it’s easy to route traffic to a static website hosted on S3 or an ELB CNAME record, or generate custom domains for CloudFront URLs.

Simple routing policy. The simplest and most common routing type, this policy merely uses AWS Route 53 to map your site name to your IP. Any future browser requests for that site name would then be directed to the correct IP.

Alias records. An alias resource record can point directly to other resource records instead of an IP address, such as an ELB load balancer, a CloudFront distribution, or an Amazon S3 bucket. This ensures traffic is sent to the correct endpoint even if the IP addresses of the underlying resources change.

Amazon Route 53 failover. In case of outage as determined by health checks, an Amazon Route 53 failover policy redirects users to a designated backup resource or alternative service automatically.

Domain registration. AWS serves as a domain registrar, allowing users to select and register domain names from all top-level domains (.com, .net, .org, etc.) with the AWS management console. This avoids the need to migrate and enables the Route 53 registrar to provide free privacy protection for the WHOIS record.

Geo DNS. Depending on detected user geographic location, this policy routes users to endpoints based on designated resource targets. For example, to limit latency you might want all queries from one region to be routed to a server located in the same physical region.

Health checks. AWS Route 53 conducts health checks and monitors the health and performance of applications. When it detects an outage, Amazon Route 53 redirects users to a healthy resource.

Latency-based routing. A latency-based policy routes users and traffic to the lowest latency AWS region.

Private DNS. Defines custom domain names while keeping DNS information private for Amazon VPC users. Private DNS records allow you to easily route traffic using domain names managed within your VPCs and create private hosted zones. For example, this can allow you to switch quickly between IP-based resources without updating multiple embedded links.

Traffic flow. Routes endpoint traffic based on best user experience.

Weighted round-robin load balancing. Uses a round-robin algorithm to spread traffic between multiple services. By assigning the multiple servers that make up a web service different numeric priorities or weights, you can direct a lower or higher percentage of your incoming traffic to a particular server. This kind of routing can be useful for testing new versions of a software package and load balancing.

How Route 53 Works?

The global infrastructure called the Domain Name System (DNS) translates human-readable hostnames into numerical IP addresses. IP addresses on the cloud can change frequently, as services move between data centers and physical machines. This means the translation and communication process is complex.

Organizations that run machines in the cloud using Amazon Web Services (AWS) need an AWS DNS solution—a way to correctly translate user requests into Amazon IP addresses while adapting to cloud changes and quickly propagating them to DNS clients.

AWS Route 53 is Amazon’s official DNS solution. The following process occurs when a user accesses a web server via Route 53 DNS:

• A user accesses an address managed by Route 53, www.website.com, which leads to an AWS-hosted machine.
• Typically managed by the local network or ISP, the user’s DNS resolver receives the request for www.website.com routed by AWS Route 53 and forwards it to a DNS root server.
• The DNS resolver forwards the TLD name servers for “.com” domains the user requests.
• The resolver acquires the four authoritative Amazon Route 53 name servers that host the domain’s DNS zone.
• The DNS resolver selects one of the four AWS Route 53 servers, and requests details for www.website.com.
• The Route 53 name server searches the DNS zone for the www.website.com IP address and other relevant information and returns it to the DNS resolver.
• As specified by the Time to Live (TTL) parameter, the DNS resolver caches the IP address locally, and of course returns it to the user’s web browser.
• The browser uses the IP address the resolver provides to contact Amazon-hosted services such as the web server.
• The user’s web browser displays the website.

Route 53 Resolver for Hybrid Clouds

In a typical hybrid cloud DNS configuration, the user merges a private center with one of their Amazon VPCs using a managed VPN or AWS Direct Connect. However, because the private cloud to the user’s VPC is a pre-established connection to AWS, when customers perform a lookup across this connection, it sometimes fails. This prompts some users to manually reroute requests using on-premises DNS servers to another Amazon VPC server—potentially one custom DNS server in each VPC.

AWS Route 53 Resolver for Hybrid Clouds or Route 53 Resolver 2 is part of the primary Route 53 service offering. It acts as a resolver for DNS requests between the entities in your VPC and your private cloud. It can perform both outbound communication from VPC to data center and inbound communication from an on-premises source to VPC.

Other advantages of AWS Route 53 Resolver:

Simplification. AWS Route 53 Resolver lets you manage multiple VPCs using a single endpoint for a single region.

Security. AWS Route 53 benefits from the added security of AWS Identity Access Management (IAM). AWS IAM enables secure user control access to web resources and services, and allows for the assignment of permissions to allow/deny access to AWS resources and the creation and management of AWS users/groups.

Reliability. As an AWS-native service, Route 53 is designed to help your system stay running in a coordinated way with all the other AWS services in your deployment. Each feature of AWS Route 53, such as geographically-based and latency-based policies, is designed to be reliable and cost-effective.

Cost. AWS Route 53 efficiently redirects website requests without extra hardware, and it does not charge for queries to CloudFront distributions, ELBs, S3 buckets, VPC endpoints, and certain other AWS resources.

Service credits. AWS Route 53 offers a service level agreement (SLA) specifying a monthly uptime percentage. In any billing cycle with a percentage that fails to meet the service commitment, the SLA provides service credits for the user.

Time to propagate. Under typical work conditions, AWS Route 53 distributes DNS record updates to the DNS server network in approximately 60 seconds.

Amazon Route 53 Limitations

Amazon Route 53 has several important limitations although it is an advanced DNS service with robust features. Here are the most critical:

No DNSSEC support. AWS Route 53 does not support the DNSSEC standard. DNSSEC can prevent man in the middle (MITM) attacks and other types of DNS attacks.

Single point of failure. Used in tandem with other AWS services, AWS Route 53 may become a single point of failure. This is a problem for AWS Route 53 disaster recovery and related issues.

Route 53 Cost. Particularly for businesses using Route 53 with non-AWS endpoints/services, the service is expensive. The visual editor in particular is costly; it is $50/month in addition to the cost of queries for each record type to which you apply a visual editor policy.

Forwarding options. For domains used on an on-premise network, AWS Route 53 lacks forwarding and conditional forwarding options.

Limited Route 53 DNS load balancing. AWS Route 53 load balancer features lack advanced policy support and enterprise-class features and provide only basic load balancing capabilities.

No support for private zone transfers. For example, you cannot appoint AWS Route 53 as the authoritative source for “cloud.website.com” even if you have the root level domain “website.com” registered.

Latency. Although there exist workarounds for routing Route 53 DNS queries to external servers, the queries must be forwarded to external servers after contacting Amazon infrastructure, still incurring latency.

AWS Route 53 Alternatives

Although AWS Route 53 is a natural choice for managing DNS within the AWS ecosystem, there are alternatives. Any third-party DNS provider used in place of AWS Route 53 must be able to route users and traffic to the optimal data center, endpoint, or geography intelligently similarly to Route 53 to achieve the same things.

For cloud hosting, Cloudflare DNS, Google Cloud DNS, Azure DNS, and GoDaddy Premium DNS are all examples of AWS Route 53 alternatives. Built-in integration with automation and deployment tools, including real-time information about your AWS servers and their parameters, including their availability, load, and physical location, can then allow other tools to route traffic according to the chosen parameters. Many enterprises also choose to add load balancer to Route 53 protections already in place.

Does VMware NSX Advanced Load Balancer Offer Route 53 Monitoring Capabilities?

The VMware NSX Advanced Load Balancer platform is a next-generation, full-featured elastic application services fabric that offers application services such as load balancing, security, application monitoring and analytics, and multi-cloud traffic management for workloads deployed in bare metal, virtualized, or container environments in a data center or a public cloud such as Amazon Web Services.

Enterprises use AWS to maximize and modernize infrastructure utilization. Extending app-centricity to the networking stack represents the next phase of this modernization.

The VMware NSX Advanced Load Balancer integrates with AWS Route 53 and delivers elastic application services that extend beyond load balancing to deliver real-time app and security insights, simplify troubleshooting, auto scale predictively, and enable developer self-service and automation. The VMware NSX Advanced Load Balancer provides full-featured load balancing algorithms, automation, DNS services, advanced security including DDoS protection and Amazon Route 53 DDoS protection, visibility and monitoring, multi-cloud load balancing, and reduced TCO for AWS. The VMware NSX Advanced Load Balancer delivers full-featured load balancing capabilities in an as-a-service experience and seamlessly integrated Web Application Firewall (WAF) capabilities.

Learn more about The VMware NSX Advanced Load Balancer’s application services alternative to the AWS load balancer.

For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos.

<< Back to Technical Glossary

Application Modernization Definition

Application modernization is the consolidation, repurposing or refactoring of legacy programming or software code to create new business value from the existing application and align it more closely with current business needs.

Application Modernization FAQs

What is Application Modernization?

Application modernization or legacy application modernization is the process of modernizing the features, internal architecture, and/or platform infrastructure of existing legacy applications. By migrating and modernizing legacy applications, your organization creates new business value from aging applications by updating them with modern, well-aligned capabilities and features.

Many application modernization approaches are focused on bringing monolithic, on-premises applications into cloud-native architecture and release patterns—specifically, modern application development processes such as microservices DevOps—rather than maintaining and updating onsite using waterfall software development processes. This is a critical step, because it is resource intensive and time consuming to meet current business needs while keeping legacy applications running smoothly. This becomes an even greater challenge when software becomes too outdated to be compatible with current systems.

Application Modernization Services

To address some of the challenges detailed above during the migration from legacy to new platforms, legacy modernization services integrate new functionality for the business. Options offered by legacy application modernization services include interoperability, re-architecting, recoding, re-engineering, re-hosting, replacement, re-platforming, and retirement, as well as clarifications to the application architecture and legacy software modernization.

Legacy Modernization Benefits

Application modernization offers insight into the functionality of existing applications, and enables strategic re-platforming of applications to the cloud to achieve scale and other performance gains. The benefits of application modernization include:

Performance. Applications and new feature delivery are faster and perform better.

Cost reduction. Application modernization reduces the amount of time needed to update applications and overall operational costs.

Efficiency. Application modernization improves employee productivity, unlocking new business opportunities, and allows team members to better serve clients by accessing cloud-native technology.

Business benefits. Continuous delivery of best-case end user experiences, independent of changing technology over time, is another benefit of application modernization. Systems can be reshaped and changed and can be deployed rapidly in process-driven ways, mitigating the risk of support loss in legacy software environments.

Application Modernization Tools

There are multiple examples of application modernization technology. Some include:

Cloud-native computing. This model executes functions in the cloud off-premises. Although it does not eliminate the need for a server, cloud-native technology outsources software code to the cloud provider. That code then runs based on individual requests.

Containers and Kubernetes. These enable developers to design scalable, consistent applications that are flexible enough to work across a wide array of environments.

Monolith to application modernization microservices. There are several benefits fueling the transition away from monolithic applications and toward more efficient microservices. The use of microservices makes updates simpler and less costly for architectural reasons, since application components are no longer packaged together.

Application Modernization Challenges

There are several inherent challenges for any application modernization strategy, and each of them impact the search for optimal application modernization vendors for a particular enterprise:

Projects create vendor lock-in over time. As the length of time it takes to modernize applications stretches on, organizations sometimes must select a single container or cloud vendor, which can cause unplanned cost increases later.

Monoliths are difficult to break—by design. Modernizing older versions of many applications such as Oracle, SAP, PeoplesSoft, or Siebel is difficult because these were designed to be unbreakable monoliths. In other words, these legacy applications and their associated data, networking configurations, and security, tend to be tightly coupled with the underlying infrastructure. This close linkage makes individually upgrading application components difficult; even minor updates often trigger a major, slow process.

Application siloing. Within larger enterprises, applications tend to live in silos. For example, different business units may install and run the same applications on completely different infrastructure. This makes testing more difficult, and makes it an even greater challenge for IT to optimize and consolidate infrastructure budget.

Tool fatigue. It can be challenging for the IT operations team to manage a diverse portfolio of applications because the available tools are either application-specific (such as SAP Landscape Management) or infrastructure-specific (such as CloudFormation). It is difficult to weave multiple overlapping product points into a coherent mesh of application delivery services for most IT operations teams, who find mastering this crush of tools and the vendor contracts that come with them overwhelming.

How to Modernize Legacy Applications

Clearly, application modernization challenges typically boil down to complexity and cost. For example, legacy applications may significantly benefit from re-architecting or re-platforming, but the complexity of modernization might outweigh the benefits if the legacy apps are too heavily coupled to existing infrastructure and systems.

Ultimately, successful legacy system modernization relies on strategic selection of application modernization steps designed to forge a clear path to improved ROI and customer experience. For example, the project must clearly demonstrate it will yield benefits of cloud migration, new feature development, performance, speed, or scale, at a reasonable cost.

Application modernization strategies may include the re-architecting, re-building, re-coding, re-factoring, re-hosting, re-platforming, or even the retirement and replacement of your legacy systems. Very old applications that are not optimized for mobile may require re-platforming.

Of course, cloud application modernization solutions are not always focused on rebuilding from the ground up. Application modernization and migration trends hone in on the original structure of the software or application and aligning it with current business processes—and what they are likely to look like in the future. This may be non-invasive, such as linking the app via a web-based front end or a modern cloud service, or it may be invasive and involve heavy re-coding.

Application Modernization Best Practices

To overcome the application modernization challenges discussed above, enterprises must evolve the way they consider modernizing applications. The following are some best practices for developing a mainframe application modernization framework.

Break up monoliths. Create a comprehensive model or application modernization roadmap, including: the intended organizational structure, servers, network configurations, storage configurations, and how the application will deploy on the servers. Break the model down into components, and model all networking between them. This simplifies creating a virtualized application environment using open source and other tools such as containers and cloud APIs and makes this approach possible to implement at scale.

Untether applications and infrastructure. Abstract and separate all enterprise applications from the underlying infrastructure, including all data sources, network configurations, data, and security configurations. This way, application components can run anywhere, using different combinations of infrastructure, without any changes to code, achieving total portability and breaking away from vendor lock-in.

Lower cost with components. The application lifecycle of an organization is composed of various application environments, versions, and deployments. Catalog an application into its essential components so it is simpler to create as many new versions of the application as needed. This dramatically speeds the integration testing, migration, performance testing, and planning processes.

Build application security into the entire application lifecycle. From design to development, the entire service lifecycle should be planned for—including application modernization and security. This keeps applications safer from the moment they are deployed, regardless of their infrastructure.

Manage with modular view. At the heart of the modernization process is a modular view of the application. This enables the organization to manage applications at an individual component level and run and test the application in a virtualized environment. This also enables the enterprise to remain infrastructure agnostic.

Does VMware NSX Advanced Load Balancer Provide Application Modernization?

Just like the data center, cloud deployments require robust application services. For this reason, cloud application services such as load balancing, a web application firewall (WAF), and service mesh for microservices are part of any digital transformation.

The VMware NSX Advanced Load Balancer’s application assessment solutions are future proof in several important ways:

Infrastructure agnostic. Modern application formats and enterprises leverage hybrid environments and use the hybrid cloud like a portal between one workplace and another. The VMware NSX Advanced Load Balancer’s platform works across multiple environments seamlessly, spanning on-premises and cloud environments without decreases in ease-of-use or performance, or increases in cost or complexity.

Centralized management. The VMware NSX Advanced Load Balancer’s offers centralized management, allowing application services to be deployed as many and managed as one.

Elasticity and automation. The VMware NSX Advanced Load Balancer’s integrates with all cloud platforms, offering automation and elasticity everywhere without the need to provision application services.

Analytical insight. Visibility into the health of your infrastructure and applications is critical, and you get that from intent-based, machine learning capabilities with the VMware NSX Advanced Load Balancer.

In an infrastructure and application landscape that is changing rapidly, it’s critical to be ready for cloud migration and application modernization and optimization initiatives.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

<< Back to Technical Glossary

Application Mapping Definition

Application mapping refers to the process of identifying and mapping interactions and relationships between applications and the underlying infrastructure. An application, or network map, visualizes the devices on a network and how they are related. It gives users a sense of how the network performs in order to run analysis and avoid data bottlenecks. For containerized applications, it depicts the dynamic connectivities and interactions between the microservices.

FAQs

What is Application Mapping?

As enterprises grow, the number and complexity of applications grow as well. Application mapping helps IT teams track the interactions and relationships between applications, software, and supporting hardware.

In the past, companies mapped out interdependencies between apps using extensive spreadsheets and manual audits of application code. Today, however, companies can rely on an application mapping tool that automatically discovers and visualizes interactions for IT teams. Popular application mapping tools include configuration management database – CMDB application mapping or UCMDB application mapping. Some application delivery controllers also integrate application mapping software.

Application mapping includes the following techniques:

• SNMP-Based Maps — Simple Network Management Protocol (SNMP) monitors the health of computer and network equipment such as routers. An SNMP-based map uses data from routers to switch management information bases (MIBs).

• Active Probing — Creates a map with data from packets that report IP router and switch forwarding paths to the destination address. The maps are used to find “peering links” between Internet Service Providers (ISPs). The peering links allow ISPs to exchange customer traffic.

• Route Analytics — Creates a map by passively listening to layer 3 protocol exchanges between routers. This data facilitates real-time network monitoring and routing diagnostics.

What are the Benefits of Application Mapping?

Application mapping diagrams can be helpful for the following benefits:

• Visibility – locate where exactly applications are running and plan accordingly for system failures

• Application health – understand the health of entire application instead of analyzing individual infrastructure silos

• Quick troubleshooting – pinpoint faulty devices or software components in seconds by conveniently tracing connections on the app map, rather than sifting through the entire infrastructure

How are Application Maps Used in Networking?

IT personnel use app maps to conceptualize the relationships between devices and transport layers that provide network services. Using the application map, IT can monitor network statuses, identify data bottlenecks, and troubleshoot when necessary.

How are Application Maps Used in DevOps?

Application owners and operations team use app maps to conceptualize the relationships between software components and application services. Using the application map, DevOps team can monitor application health, identify security policy breaches, and troubleshoot when necessary.

What is an Application Mapping Example?

An application map (see image below) provides visual insights into inter-app communications in a container-based microservices application deployment. It captures the complex relationships of containers. An application map can graph the latency, connections, and throughput information of microservice relationships.

Does VMware NSX Advanced Load Balancer Networks Offer Application Mapping?

Yes, The VMware NSX Advanced Load Balancer provides automated service discovery and inter-service application mapping of container ingress. The VMware NSX Advanced Load Balancer’s real-time dynamic map visualizes communications between services, allowing operators to analyze latency, bandwidth, and request rate, and other critical metrics.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

For more application mapping resources see the following:

<< Back to Technical Glossary

ADCaaS Definition

ADCaaS is an acronym for Application Delivery Controller As A Service. It is an on-demand application delivery controller (ADC) including load balancing and other application services. An ADCaaS is a hosted service in the cloud. Using an ADCaaS does not require owning any on-premises load balancing software or hardware.

FAQs

What Does ADCaaS Stand For?

ADCaaS stands for Application Delivery Controller As A Service. The same concept is referred to as Load Balancing As A Service (LBaaS) in environments like OpenStack.

What Is ADCaaS?

ADCaaS is a global application delivery controller offered as an on-demand service. Application delivery controllers (ADCs) provide essential services such as load balancing and application firewall that applications must have to run properly. As the name implies, Application Delivery Controller as a Service (ADCaaS) refers to a service that provides ADC capabilities in an agile SaaS delivery model optimized for cloud computing.

How Does ADCaaS Work?

An ADCaaS offers all the functions of an application delivery controller (ADC), just delivered as a hosted service in the cloud. It is, of course, software-based as opposed to hardware-based, which also includes the virtual load balancer version. The primary role of an ADCaaS is load balancing, but it can also offer application acceleration, caching, compression, traffic shaping, content switching, multiplexing and application security. ADCs accelerate and optimize application performance with the following techniques: application classification, compression and reverse caching.

What Are the Benefits of Using ADCaaS?

As the amount of data traffic increases in the public and private cloud, the need for ADCaaS will also grow. The more on-demand data that organizations require, the more they will enjoy the efficient and cost-effective application delivery provided by ADCaaS use cases. Because ADCaaS is only in the cloud — users don’t have to own any on-premises software — ADCaaS allows companies to have a cloud-first infrastructure policy.

ADCaaS benefits:

• •

Lower up-front cost

• — Software-based ADCs cost less than physical hardware ADCs, especially when depending on cloud computing and the need to load balance hundreds of applications. But ADCaaS takes the savings even further because it’s software on-demand. Companies don’t need to buy a server. Everything is hosted and billed on consumption.

 

• •

Ease of management

• — ADCaaS is easier to manage than on-premises software because the vendor handles any software updates that a customer needs. ADCaaS does not require IT staff for installation, configuration and maintenance, which makes it much simpler than hardware versions. ADCaaS also avoids complicated service and support — or even having to own a server.

 

• •

Agility

— ADCaaS can be procured, installed and configured in minutes regardless of on premises or in the cloud. Software-based ADCs can also be quickly reassigned based on workload demand.

ADCaaS Versus Hardware Application Delivery Controllers

Hardware-based ADCs tied to a physical location do not provide the same benefits as ADCaaS. It’s much easier to manage ADCs built using a completely software-based architecture which is hosted by the vendor for customers to use on demand.

When it comes to load balancing and scaling performance, organizations that depend on rapid growth will find ADCaaS much more easier to use than hardware ADC.

Hardware ADCs are usually offered at various levels of scalability and require configuring new hardware when an organization scale to the next level. With ADCaaS, scalability is possible on demand. The vendor hosts the software and its deployed whenever the customer needs it.

Does Avi Network Offer ADCaaS?

Yes. Avi’s ADCaaS product is called Avi SaaS. It is the cloud-hosted option to deliver application services including distributed load balancing, web application firewall, global server load balancing (GSLB), network and application performance management across a multi-cloud environment. Avi SaaS helps ensure fast time-to-value, operational simplicity, and deployment flexibility in a highly secure manner.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

For more information see the following ADCaaS resources:

<< Back to Technical Glossary

Application Delivery Platform Definition

An Application Delivery Platform is a suite of technologies that handles application services like load balancing, security controls and traffic management in data centers and cloud environments. The application services platform’s role is to deliver applications reliably and securely to end users.

FAQs

What is Application Delivery Management?

Application delivery management is the discipline of achieving fast, predictable and secure access to applications. Application delivery management ensures vital enterprise applications are available and responsive for users, which requires throughput optimization, security, troubleshooting and analytics.

What is Application Delivery Used For?

Application delivery is necessary as consumers increasingly go online to access services or to make purchases. These customers require their transactions to be fast and reliable. Equally, organizations are reliant on applications for their daily operations. To enable access to these online services, application delivery solutions are essential. The application delivery controller (ADC) is the most important part of the application delivery model. An ADC is an advanced load balancer that sits in front of application servers and directs client requests to the servers. The ADC maximizes performance and capacity utilization by directing application traffic.

What is Virtual Application Delivery?

Virtual application delivery (vADC) utilizes a virtual or software-based application delivery controller to provide intelligent and sophisticated load-balancing capabilities. Unlike a hardware-based ADC, the virtual load balancer can run on any infrastructure, including the public cloud. Virtual application delivery also offers network and application innovations like clustering, intelligent architecture and deep packet inspection. These components ensure applications run smoothly and effectively.

What Are the Benefits of a Cloud-based Application Delivery process?

A cloud-based application delivery process offers the following IT benefits:

• Simplified infrastructure: Replaces a hardware-based solution with a public cloud service that is better equipped to scale globally without compromising delivery quality.

• Reduced costs: Companies spend less on support when the user experience improves with application performance. A cloud-based application delivery process also saves on hardware acquisition and maintenance costs.

• Increased productivity: Efficiency is optimized when employees can quickly access the information and services on applications from any device, anywhere. An application delivery process makes it possible for applications to perform faster in a cloud-based environment.

• Improved end user experience: Customers will increasingly use and prefer high performance applications made possible by an efficient cloud-based application delivery process.

What is an Application Delivery Network?

An application delivery network (ADN) provides application availability, security, visibility and acceleration. The technologies are deployed together in a combination of WAN optimization controllers (WOCs) and application delivery controllers (ADCs). The application delivery controller distributes traffic among many servers. The WAN optimization controller uses caching and compression to reduce the number of bits that flow over a network.

What Does VMware NSX Advanced Load Balancer Offer as an Application Delivery Platform?

The VMware NSX Advanced Load Balancer application delivery architecture is purpose-built for the cloud and mobile era using a unique analytics-driven, 100% software approach. The VMware NSX Advanced Load Balancer is the first platform to leverage the power of software-defined principles to achieve unprecedented agility, insights, and efficiency in application delivery.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

For more information on Application Delivery Platform see the following resources:

<< Back to Technical Glossary

Application Service Provider Definition

An Application Service Provider (ASP) provides applications and related services over the Internet. Enterprises rent ASP software for a fee. The software is accessed remotely through a web browser and not installed on a company’s local drives. A multi-tenant version of this model is commonly known as Software-as-a-Service (SaaS).

ASP services have become an important alternative to owning software, especially for small- and medium-sized businesses with limited information technology budgets. Larger companies are using ASP services as a form of outsourcing. Application service provider advantages include reduced IT capital expenditure, easier software and hardware maintenance (such as automatic software upgrades), and better collaboration with mobile users. The application service provider model (or asp model) also works well for specialized applications that would be too expensive to install and maintain on company computers.

ASP services make software less expensive and easier for companies to use by providing automatic upgrades and technical support. Application service providers created the concept of centralized processing or computing — accessing one central copy of the software versus purchasing and maintaining multiple copies on every individual computer.

FAQs

What Are Examples of Application Service Providers?

There are several types of application service providers. Services include:

• Specialist: Delivers a single application for a particular use case such as credit card payment processing or timesheet services.

• Vertical market: Provides the application software an enterprise in a specific industry would need, such as a medical practice.

• Enterprise: Offers broad solutions and software that apply to many different industries.

• Local/Regional: Delivers small business services in a limited area.

• Volume: A specialist application service provider that offers a low-cost package.

Who Are Application Service Providers?

HP, SAP and Qwest are application service providers that formed an alliance to offer SAP’s R/3 applications at “cybercenters” that serve other companies. Microsoft is another application service provider, which has offered its SQL Server, Exchange and Windows NT server on a rental basis.

While application service providers let smaller enterprises use applications on a pay-as-you-use fee, many large companies commit to ongoing contracts in exchange for a fixed number of users or other metric such as compute hours, bandwidth or storage volume.

One application service provider model is to use an advertising to offer software for free. Webmail services like Yahoo, Gmail, Google Doc and various free online logo makers use this business model.

How Does an Application Service Provider Work?

Users of an application service provider remote-access rented software through the Internet using a configured web browser with plugins. The ASP server can be as distant as a different continent. Users save their work to the remote server and perform daily software tasks in the web browser interface.

The application service provider model includes the following features:

• Owns and operates the software applications
• Maintains the servers supporting the software
• Bills on a “per-use” or monthly/annual fee basis
• Provides information to customers through the Internet or a thin client computer

Some application service providers deploy software in multi-tenant access mode. This has become known as Software-as-a-Service (SaaS). Others use virtualization and offer a license to each customer.

How Does VMware NSX Advanced Load Balancer Provide Application Services?

The VMware NSX Advanced Load Balancer provides application services such as, load balancing, intelligent web application firewall and container ingress using a 100% software approach. This allows for unprecedented control, flexibility and insight into the services being used for application delivery and beyond.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

For more information on Application Services from Avi Networks see the following resources: