Programmability in the Network: Blue-Green Deployment Pattern

#gluecon #devops Intelligent handling of requests whether for testing or migration or upgrades requires programmability in the network.

Cory von Wallenstein, CTO of Dyn Inc, gave a great presentation at Glue 2013 on upgrading infrastructure. If you weren't at Glue (or were and missed his presentation) you can check it out on SlideShare. The premise of Dark Architecture is based on Martin Fowler's Blue/Green deployment pattern. Developers will recognize this DevOps pattern as similar to A/B testing patterns.

Martin sums up in his Blue/Green Deployment Pattern blog:

The fundamental idea is to have two easily switchable environments to switch between, there are plenty of ways to vary the details. One project did the switch by bouncing the web server rather than working on the router. Another variation would be to use the same database, making the blue-green switches for web and domain layers.

Cory's application of this pattern, which he calls Dark Architecture, engenders a continuous deployment pattern capable of transitioning from an existing architecture to a new (and potentially in-progress) architecture while retaining the ability to rapidly rollback (or fallback, whichever you prefer). In both Dark Architecture and A/B testing patterns, the idea is to slowly siphon off some identifiable portion of traffic. In some cases this may be to test a new version of an API or to enable migration to the new API and client by matching appropriate versions on both the client and the server-side application (or API).

In both cases, the match should optimally be made in real-time, meaning as the requests arrive some "thing" in the network figures out which version of the < API | Application | Architecture > should handle each request.

This requires programmability in the network; the ability to programmatically inspect requests as they flow through the network and determine based on layer 7 (application layer) properties how the request should be handled. This requires programmability because the specific information on which you want to base the decision - API version, URI, client device or version, etc... - is likely unique to your application. You need to be able to programmatically extract certain pieces of data from the request and then use them to inform infrastructure elements such as load balancers or proxies on how to direct every request.

This kind of capability is critical to enabling agile business and operations because nothing is as constant as change, and it is nearly impossible today to forklift upgrade hundreds or thousands or more consumers (or employees) across multiple devices to a new version of the application. But you still have to do it, somehow, unless you're going to bloat the application (or API (or both)) by always and forever, amen, enabling backwards compatibility. To version before 1.0. That's not feasible in today's rapidly evolving and fast-paced application ecosystems. APIs mature rapidly and often deprecate calls. This same pattern can be used to manage the transition from deprecated API methods to more current methods - including transforming data if necessary.

That's because programmability in the network enables a programmatic, development-oriented means of dealing with traffic in a real-time manner.

This is not the programmability often referenced with respect to SDN, which is more about enabling the development of applications that perform a specific task on traffic as it is inspected by the controller. Nor is it the programmability that enables management and automation of network devices through control plane APIs. This is programmability in the data path, while data is flowing, in real-time.

It's about routing at layer 7 (application layer), enabling a dynamic, robust and intelligent network capable of directing traffic based on application details.

Programmability in the network is a critical component for devops and developers looking to enable continuous delivery of applications, APIs, and architectures.