This is a niche topic as it only adds to those interested in load balancing in general and NSX-ALB specifically but I’m here to talk about one of the architectural choices made by NSX-ALB that caught my attention from my amateur POV.
Some people might disagree with me on how Avi has such a wide selection of features, and if they’re more worth of this discussion,
but in my opinion, this is one of the few features that only Avi created by choice not by following community standards on what features should load balancers include off the shelf.
“Can you explain what this feature does?”
To start, this feature basically allows you to have blank templates for your load balancing choices and configurations, and these blank templates aren’t actively used once you write them down, they have to meet minimum required rules to be active on your environment.
As an example of this feature, let’s suppose you’re deploying a virtual service (Application) using Avi.
you can get to your Avi system and choose “create a VS” and have most of your virtual service configuration done and saved without having to deploy it immediately once you save.
And to reach the deployment phase of this template, the essential requirements for this virtual service would be:
- Functional virtual IP
- Service engine group
- Server pool (the servers we’re load balancing for).
If anyone of these fails to exist on the Virtual service setup page, and it turns from a live deployment to a template waiting to deploy later on.
This blank template could also contain other blank templates within its configuration like:
- Advanced features (Layer 7 request and response policies)
- Various load balancing algorithms
- Health monitoring profiles, etc.
“So why is this a big deal?”
This feature exposes a lot about the Avi architecture without saying it directly,
for this feature to exist, it means that Avi is loosely coupled with its own objects and other integrations as well.
And this freedom of not having your software hardwired to objects allows for more creativity during the design and planning phase,
and better yet, it allows you to treat these objects as different entities with their own specs, logs, and integrations.
This makes it way easier to debug errors and interact with these objects because now you can actually see a clear line separating between the Avi system and its objects,
so, by knowing which side of the line the bug/error landed on, you can actively pursue it without having to check up on the entire system.
“Who benefits from this feature?”
Literally everyone, implementation engineers, consultants, support specialists, because at some point, everyone has to wait for someone’s approval on deployment choices, but they don’t want to configure the system again on deployment date, they want it to be as easy as publishing an old draft you already wrote on social media.
let me just say that this was the feature that made me think of NSX-ALB (Avi) as a different beast from other load balancers (AWS ELB, F5, etc.)
But as of now, the official documentation focuses more on features like scale out / scale in operations, which were initially developed by Avi,
but then got picked up by other load balancing solutions really quickly, then became standardized in load balancing development.
And even back then when Avi was still not acquired by VMware, most reviews such as the one done by Gartner on Avi and its functional comparison to things Route53,
it seemed like their eyes were stuck to the new security features and high analytical capabilities but not the engineering ingenuity that managed to collect different styles of operations and implementation within the same system.
The way I see it, to implement such architecture isn’t an easy feat, it creates a better flow between system components,
but it requires much more complex coding process and would require software architects to jump through a lot of hoops to reach this with minimal conflict between the different resources and implementation done by each dev team handling their own Avi-object.
That’s why in this article I wanted to expand more on what I found through my practical experience and what I admired in this pursuit of a cleanly built product.
-I’d like to mention that these views are coming from my usage of the product as a normal user with no access to any confidential info on the product itself-
