Welcome!

@DevOpsSummit Authors: Pat Romanski, Liz McMillan, Elizabeth White, Yeshim Deniz, SmartBear Blog

Related Topics: @DevOpsSummit, Java IoT, Linux Containers, Containers Expo Blog, @CloudExpo, SDN Journal

@DevOpsSummit: Blog Feed Post

Minimal (Network) Exposure

A lesson from object-oriented principles that should be applied to the network

One of the primary principles of object-oriented programming (OOP) is encapsulation. Encapsulation is the way in which the state of an object is protected from manipulation in a way that is not consistent with the way the variable is intended to be manipulated. The variable (state) is made private, that is to say only the object itself can change it directly. Think of it as the difference between an automatic transmission and a standard (stick). With the latter, I can change gears whenever I see fit. The problem is that when I see fit may not be appropriate to the way in which the gears should be shifted. Which is how engines end up being redlined.

An automatic transmission, on the other hand, encapsulates the process of shifting gears (changing the state of the engine) and only major transitions - reverse, park, drive, neutral - are accessible by the driver.

In an object-oriented paradigm, this is how the state of an object is isolated and protected from manipulation in a way that may introduce instability or cause other logical errors in processing. If we modeled a car using an OOP object it might look like this:

car-modeledThe actual code within each of the OPERATIONS can manipulate the STATE of the car, but it does so using well-defined rules. You can't just reach in and change the state without going through the OPERATORS. Period.

What this provides is the means to do logic and error checking, ensures consistency, and means that every other part of the system that might touch that object can be assured of the integrity of its state.

So, what does all that have to do with networking and infrastructure and DevOps and SDN and... ?

Quite a bit, actually.

One of the reasons SDN and DevOps, for that matter, is so critical to the next generation of data center architectures is its ability to centralize the state of the network. Right now it's all over the place. Literally. The state of any given network is not well known because it's distributed across every router, switch and layer 4-7 service that comprises "the network." It makes troubleshooting difficult, to say the least, and there's no good way to predict how a change in the state of the network will impact, well, the network.

An object oriented approach to the network, in general, says "let's centralize state, and provide a single interface through which it can be modified." In other words, there is a single authoritative source for the state of a network.

This is the approach that Cisco has taken with its Application Centric Infrastructure (ACI). It's the approach that OpenFlow-based SDN takes, and it's generally the approach that devops is taking to treating infrastructure as code. That's the theory. To realize this in practice requires that "the network" be API-enabled, to allow the dissemination of state and telemetry necessary for the authoritative source to maintain an accurate view of the state of the network.

The danger, however, is that we end up with a bunch of infrastructure and network devices that expose state via APIs through which operators and engineers end up directly manipulating configurations. Unfortunately, it is often the case that changing one single variable on a network device can be as devastating as opening Pandora's Box. Because of the way in which different devices relate policies and ACLs and routing tables to different objects - IP addresses, VLANs, etc... - a single change can have significant repercussions.

Similarly, the order in which various objects are configured can impact the overall stability and success of a configuration. By offering up a highly granular API and leaving consumers to their own devices (ha! pun not intended, but not regretted, either) they can easily shoot themselves (or their network) in the foot.

Providing a more policy, application-focused approach to provisioning and configuration reduces the possibility of these incidents and improves the stability and therefore reliability of the network services upon which applications rely. Encouraging engineers and operators to leverage application-driven provisioning and management rather than a line by line, API call by API call functional approach reduces the API surface area required and returns to exploiting encapsulation to preserve and protect network state by ensuring consistency in how that state is changed.

This software-defined, API-driven approach is a whole new world for networking and operations because it deviates from the direct touch world in more ways than just moving from CLIs to APIs.  It's also about encapsulation; about moving from standard transmissions to automatics and trusting that the manufacturer of the car does indeed know best how and when to shift from one gear to another.

hat_tip

H/T: This article on encapsulation in code is a good read that doesn't require a lot of understanding of development that may be of interest (and helpful) to operators and network engineers http://java.dzone.com/articles/evil-getters-and-setters-where

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

@DevOpsSummit Stories
"Our strategy is to focus on the hyperscale providers - AWS, Azure, and Google. Over the last year we saw that a lot of developers need to learn how to do their job in the cloud and we see this DevOps movement that we are catering to with our content," stated Alessandro Fasan, Head of Global Sales at Cloud Academy, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
Five years ago development was seen as a dead-end career, now it’s anything but – with an explosion in mobile and IoT initiatives increasing the demand for skilled engineers. But apart from having a ready supply of great coders, what constitutes true ‘DevOps Royalty’? It’ll be the ability to craft resilient architectures, supportability, security everywhere across the software lifecycle. In his keynote at @DevOpsSummit at 20th Cloud Expo, Jeffrey Scheaffer, GM and SVP, Continuous Delivery Business Unit at CA Technologies, will share his vision about the true ‘DevOps Royalty’ and how it will take a new breed of digital cloud craftsman, architecting new platforms with a new set of tools to achieve it. He will also present a number of important insights and findings from a recent cloud and DevOps study – outlining the synergies high performance teams are exploiting to gain significant busin...
Enterprise architects are increasingly adopting multi-cloud strategies as they seek to utilize existing data center assets, leverage the advantages of cloud computing and avoid cloud vendor lock-in. This requires a globally aware traffic management strategy that can monitor infrastructure health across data centers and end-user experience globally, while responding to control changes and system specification at the speed of today’s DevOps teams. In his session at 20th Cloud Expo, Josh Gray, Chief Architect at Cedexis, covered strategies for orchestrating global traffic achieving the highest-quality end-user experience while spanning multiple clouds and data centers and reacting at the velocity of modern development teams.
In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals – as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost.
When shopping for a new data processing platform for IoT solutions, many development teams want to be able to test-drive options before making a choice. Yet when evaluating an IoT solution, it’s simply not feasible to do so at scale with physical devices. Building a sensor simulator is the next best choice; however, generating a realistic simulation at very high TPS with ease of configurability is a formidable challenge. When dealing with multiple application or transport protocols, you would be looking at some significant engineering investment. On-demand, serverless computing enables developers to try out a fleet of devices on IoT gateways with ease. With a sensor simulator built on top of AWS Lambda, it’s possible to elastically generate device sensors that report their state to the cloud.