DEVOPSdigest

Writing elegant, effective, flawless code is totally in the hands of the developer. When you accidentally drop in an infinitely recursive loop that takes your whole app down … well, you kick yourself, fix it, and pretty much just hope nobody else saw it.
 
You may even get to have a say in the stack it runs on to ensure there's nothing in there that could get in the way of smooth operation. Nobody loves finding out that the Linux instance is old and buggy, or that somebody forgot to update JQuery to the latest release — but, with a little interrogation and tenacity, things like that can be found and fixed.
 
The big hurdle remaining just outside your grasp, though, is the network your app ultimately flies across: the Internet itself. When everyone in Boston decides to watch the series finale of The Leftovers the moment HBO drops it, and the peering connections between all the local ISPs and HBO's CDN get slammed, your app can suffer if it coincidentally shares these linkages regardless of how much effort you put into making it hyper-efficient.
 
And given the efforts we put in these days to deconstructing monolithic applications, and using distributed microservices to make us more agile, the potential for app performance to take a nosedive because of unseen (and unanticipated) network congestion and outages is only getting greater. If even one of the dozens of APIs you call as the app opens is blocked by network problems, the entire user experience can fall apart.
 
There is help at hand, though, in the form of new ways to program network awareness directly into your code. There are many different words, acronyms, and marketing nonsense naming this, but let's call it Delivery as Code (DAC). Think of it as Infrastructure as Code, but instantiated and refined within the application rather than across the network.
 
The core principle of DAC is pretty simple, actually: don't try to hit any microservice at a particular location. Rather, hit a dynamic traffic manager endpoint that will automatically calculate which of several options to use for that microservice and the best route to get to it. Think of it like hitting a load balancer, instead of a specific server, inside a LAN, except that it's designed to work from the client over the unmanaged Internet, as well as within internally-managed data centers.
 
How could the traffic manager actually know which endpoint to direct your request to? In a perfect world, the answer is that it is part of a broader platform that doesn't just direct traffic — it also measures, analyzes, and acts on a broad swath of user experience data.

For instance, a system that tracks availability, latency, and throughput across and between networks, CDNs, and ISPs, will have a clear sense of where congestion exists, and where the clearest paths between your app and its desired APIs are.

Configured correctly, the system would also take into account all the possible endpoints you have within your own network: that way, it would have the option of directing requests between your own building and the farthest reaches of the Internet, based on an objective virtual map of Internet traffic.
 
By embedding DAC instructions within your code, then, you can remove the uncertainty of network delivery fluctuations from your development process. You can know that each microservice or API call will automatically be directed to the most efficient endpoint — and if your app is running slow it's because of something other than network congestion (ouch).