When Programmability Extends Beyond the Platform

#SDAS #SDDC A programmable platform should be more than just lipstick on a CLI

The term programmability is, like every other term associated with hype-driven trends, used to describe a wide range of capabilities. In general, when applied to "the network", programmability implies one of two things: an API through which a network element can be configured and managed and/or a scripting mechanism that enables direct interaction with the data path.

These two aspects of programmability provide integration between data center elements (control plane) as well as enabling extensibility through the creation of new services on the platform (data plane). But they don't speak to a third capability - the invocation of external services as a reaction to some data center event.

For example, a data center "event" might be the depletion of capacity in the face of high demand. Elasticity (the automatic scaling up and down of a service or application) demands action be taken. That action, ideally, is automated. The overall system should understand when capacity limits are about to be breached (both in the upward and downward direction) and be able to take the appropriate action - provision additional capacity or decommission capacity.

Most "network" elements are not capable of taking this action directly. Load balancing platforms for the most part are the first service to recognize a need to change capacity, but are rarely able to take action other than sharing that information with an external system. For most load balancing platforms that's because they lack the programmability necessary to do so. They may be programmatic at the control plane and even on the data plane, but they are not imbued with the ability to execute logic on an event-driven basis.

Platforms that are so imbued (and they do exist) are able to do so.

Let me illustrate...

The vCloud API Programming Guide has a robust set of interfaces through which a vAPP (which in VMware jargon describes a complete "application") can be managed. You can, through this API, power on (provision, launch, etc...) and shutdown (decommission, power off, etc...) a given vAPP. A programmable platform can leverage those APIs to enable rapid elasticity.

HERE COMES the (COMPUTER) SCIENCE

Interestingly, a scalable application consists of at least two things: a load balancing service and a pool of application resources. How far you can take that to implement actual elasticity depends entirely on the availability of APIs through which you can manage application instances (virtual machines) and the programmability of the platform upon which the load balancing service is deployed.

Assuming you have what you need, your environment looks something like this:

Health monitoring enables the service platform to know when there's a problem, that's critical for high-availability. The platform also understands the capacity limits of each virtual instance. Now, let's say demand is suddenly spiking (the source is irrelevant). Given the strategic location of the service platform, it is the first system in the data center able to recognize that capacity limits are about to be breached.

The question is, what does the service platform do about that?

Well, in most systems it's just going to share that information with an external orchestration/management platform. In most cases, in fact, it's going to share it passively; that is, the information won't reach the management platform until the management platform asks for it. It's a polling system, not a proactive push from the service platform.

That means that it's possible that capacity will be reached and users will start experiencing delays or even time-outs before the management platform even knows there's a problem.

In order to realize elasticity that actually ensures high-availability and responsiveness of applications, we need something more proactive. The service platform must participate either by pushing a capacity reached notification to the management platform or, if it's able to, simply instructing the management platform to provision the additional resources necessary to ensure capacity is expanded before limits are breached.

This requires that the service platform is not only programmable at the control and data path planes, but also at the configuration layer. It must be able to not only recognize a breach of thresholds but then act on that breach. In this case, acting means initiating a process that will result in the provisioning of additional resources required to ensure continued availability and performance. As demand wanes, another threshold can trigger a reverse process in which an instance is decommissioned*.

Now, you can certainly design your data center in myriad ways to deal with elasticity and availability. If you've got the right service platform - one that's programmable in more than just the traditional two-pronged approach - then you've got another option available to you. An option that's more proactive and leverages what is an existing strategic point of control in your network architecture.

* Provisioning is easier and less complex than decommissioning, as the latter requires careful attention to existing connections and essentially means the load balancing service must manage the process of stopping new connections while maintaining existing ones until users complete their session (quiescence).