ADC is a service, not a server
ADC (and all components of app delivery) need to be abstracted services and not servers. Physical or virtual servers should be worker nodes, with no value or state, that can be scaled-out, scaled-in, or replaced at any time.
This not only enables future designs on ephemeral platforms like Kubernetes but empowers current network designs to be vendor and cloud neutral, fault-tolerant, and multi-location.
By example, an ADC template should be able to run in AWS, Azure, and on-premise VMware. Whenever a cloud instance is lost a replacement is automatically provisioned and put into service. Should load increase the ADC workers are scaled out automatically. If a datacentre goes offline traffic is directed to another automatically.
This agile mesh of ADC workers fulfilling the service requirements for one or more applications enables true, scalable, flexible application delivery for modern enterprises.
You must use control-plane / data-plane architecture
To address the explosion of services, and the changing nature of where they exist, a true control-plane / data-plane architecture is required for managing ADC endpoints. Specifically, this means that your control-plane (central management) is able to:
- be in constant communication with all your worker nodes;
- be able to deploy new nodes, self-repair nodes, and shut down unnecessary nodes;
- store all your configuration files, rulesets, etc centrally to deploy anywhere;
- entirely recreate a worker node with no human interaction to scale or repair;
- store and provide metric and telemetry information for all workers;
- provide a global on-platform GSLB for routing traffic to changing nodes.
This design ensures that you have no value in the data-plane, that worker ADCs or nodes have no state, and that you can scale without limitation due to controlling the configurations and routing to worker clusters.
ADC needs to be everywhere
Every ADC provider needs to support running on any platform, to the degree that you are available as vendor-neutral container or binary that can run on any modern Linux platform.
This is due to platforms being a spectrum and not a destination. A service-mesh load balancer means you need another vendor for cloud, and another for on-prem. ADC will act as the ingress (and mesh) for VMs, Clouds, Edge compute, Containers, Service Mesh and everything in between. This creates several technical requirements:
- ADC workers must be extremely lightweight, able to deliver high performance on edge and light compute containers.
- ADC workers must be truly platform and vendor neutral. The most practical realisation of this is the ability to run on any Linux system, allowing clients to deploy the solution to every location they have applications.
- ADC workers must be able to scale-out or scale-up to handle load in varying architectures, e.g. tin vs containers (more cores vs more pods).
- ADC workers must be able to handle monolithic workloads and deployments, as well as east-west and microservice deployments.
Failing to fulfil these requirements pushes organisations to have bifurcated deployments with different vendors, a powerful ability of the DevOps engineer, but a risk with security and orchestration solutions where you require policy management and ADC intent to be unified.
The network must drive itself
As far as is possible, the network must drive itself using AI, ML, automation and other statistical techniques. This is to say that scaling-in, scaling-out, self-repairing, mitigating attacks and more should all be automated functions.
As clients reach hundreds, and then many thousands of endpoints the practicalities of managing, and securing, a network of that size mean that the ADC fabric must be intelligent.
Human rulesets and operators cannot account for measuring the threat level of a certain DoS that’s hitting 300 out of 500 nodes. At the same time worker ADCs cannot think of themselves as individuals but rather part of a larger intelligent fabric. By example, rate limiting POST requests to 1 per second is useless if you have 450 ADCs that are individually tracking request rates. You are allowing 450/second to a smart attacker.