Watch webinar on-demand here https://info.avinetworks.com/webinars/state-of-load-balancing-2020
2019 has been an eventful year for load balancing. Avi Networks is acquired by VMware, who enters the application delivery controller (ADC) market with a software load balancer, web application firewall and container ingress solution. NGINX is acquired by F5 Networks, hoping to tap into the developer communities. We continue to see the rise of multi-cloud and microservices as the leading drivers behind changes in modern load balancing solutions.
In this webinar, we will explore three technology areas:
- A new perspective on “service chain” – how it helps integrate adjacent technologies with APIs to form a self-service portal
- Implications of HTTP3 on the future – why it is interesting to the load balancing industry in particular
- An early prediction on DNS over HTTPS (DoH) – why it can enhance the security, scale and resiliency of the internet
Driving forces:
Digital enterprises need to deliver more applications, faster, and at lower cost
Consistent multi-cloud deployments across data centers and public clouds with enterprise level security
Shift towards cloud-native apps and automation to support DevOps and CI/CD processes
How Avi fits into the NSX portfolio but important to highlight:
Continue to be offered as standalone LB for multi-cloud environments
Plan to have the best integration with NSX and other VMWare products
Transcription
Avi Networks, now part of VMware, has been in business as a load balancer for about seven years (since 2012). We're now part of the VMware family as the NSX advanced load balancer. And VMware has been steadily introducing more and more networking functionality via NSX and other applications services and other functionalities. And Avi fits really nicely into that by providing the application delivery, the load balancing and application security such as web application, firewall, et cetera.
5. Automation – again it’s more than REST APIs and Ecosystem integration. Avi takes the analytics and feed into the controller (”brain”) to achieve autoscaling and full lifecycle management. It allows you to specify an intent, Avi does the automation and orchestration required to achieve the outcomes. What makes automation increasingly important is that it’s the critical step to finally operationalize digital transformation – from vision to reality.
Transcription
So by taking that information, that's really important to be able to provide troubleshooting and meaningful experience there. But it's also important because we can now take that data and use it for the purposes of automation. For automation, there's two elements to this. One is the operational automation. The other is the infrastructure automation.
So from an infrastructure, that means that the Avi controller can natively be talking to the APIs of V Center, of Azure, AWS, you name it, in whatever the environment might be, the Avi controller is talking to those environments, to those controllers. So if you wish to deploy a load balancer or a service engine in a VMware environment, the Avi controller will talk to V Center, find the best location, the best host to deploy a new se.ova, and will automatically deploy that, configure the Nicks, et cetera, and take care of all of that for you. All you said is, "I want to upload or I want to deploy this application into VMware environment". So you're deploying the application or the purchase service that serve ascensions can automatically instantiate and automatically configure themselves for you. And so from an application owner perspective, here's my application, just make it go and the networking just automatically instantiates with it.
The next element to this is the operational automation, and that is that Avi is not an island of technology in and of itself. It needs to be integrated with the surrounding environments, the surrounding ecosystems. Certainly that means something like V Center or Kubernetes or whatever environments like this, but it also means something maybe even more custom. It could be something like automatically configuring the IP addressing by talking to Infoblox or another IPN. We can automatically register virtual services into DNS by talking to something like Amazon's Raw 53. We can integrate with things like [Venify 00:16:47] to automatically configure and pick up SSL certificate through an application.
The point is that by integrating with these surrounding ecosystems, that enables us that the application owner uploads the application and it just works. How it worked, they don't really need to know, they don't really need to care, but the firewalls could instantiate, the IP addressing could be automatically inherited. DDNS could automatically be registered. All of these elements.
Many of these elements are something that Avi has natively baked in, but you can also provide some customization because Avi built on top of a rest API. That means that what you see in the FUI and what you see from the CLI are actually just wrappers for the API. If you're using the GUI, you can right click, click on inspect elements and start mousing over or clicking through the UI and you'll see the API calls that your browser was actually sending and the JSON response that Avi is sending back. Your browser will take that JSON formatted result, put it into a style sheet, shake it up and there is the web page that you see rendered from the GUI. The same is true from the CLI. You can add a -API flag and you'll actually see the API calls that are being exchanged underneath.
The point of this is that it makes it really easy for customers to automate everything on hobby. There's nothing that the API doesn't have access to. Everything we do is exclusively done through the API. That makes it really easy for you to go and build out some customization if that's going to be through Terraform, through Ansible, through VRO VRA, or just custom Python scripts.
This is something that most every Avi customer is looking at, some form of automation, some sort of way to be able to do more with less. As they deploy more and more applications, this is the core underlying element that really has them looking around and trying to figure out how can I do something better? How can I do something more efficiently? That's why they're looking at other load balancers in the first place.
So this is a really key component as to why Avi, so that's something that's really important, is that even if the person that you're talking to is not an API person, what's important about Avi that yes, we have APIs. We have APIs for everything. However, it's really what you don't have to do, what you don't have to code. The fact that Avi automatically can handle things like the capacity management of service engines, the integration with the surrounding ecosystems or cloud environments to talk to AWS to go and spin up more capacity or to handle multiple availability zones, these are things that are traditional load balancers, each and every one of these steps, each and every one of these integrations are something that you, the administrator, would have to do manually. Each and every one of these is something that you have a probability of failure. You have a steep learning curve and it's something where customers are feeling like even though they're buying an off the shelf hardware appliance load balancer, it's still a do it yourself project if you want to do any kind of intelligence on top of this.
This is the point with Avi, is that out of the box it automatically does everything that they need it to do, everything that they were looking at doing. It's these massive projects for the next year. As soon as they see Avi, they realize it's already been done and you just have to double click and start the install and away you go.
Driving forces:
Digital enterprises need to deliver more applications, faster, and at lower cost
Consistent multi-cloud deployments across data centers and public clouds with enterprise level security
Shift towards cloud-native apps and automation to support DevOps and CI/CD processes