devopsy.kinsta.cloud

Tag: sdn

Infrastructure as Code is SDN for Ops

As we continue to recognize the importance of DevOps—particularly its automation and orchestration aspects—to achieve the agility necessary for continuous deployment of apps, the question of how the term “Infrastructure as Code” (IaC) applies to traditionally network-bound systems and services is bound to crop up more frequently. After all, in addition to core IP-based networking characteristics required for an app to communicate and serve up content, an entire ecosystem of app services that support, secure and scale it must be considered.

IaC is driven by the application of development principles to network infrastructure. Configuration, scripts, templates, profiles and the like are treated as code, in that they should be reviewed, versioned and provisioned from a centralized repository (one hopes on-premises) rather than managed as discrete network elements.

In a recent article in TechBeacon, Boyd Hemphill, director of evangelism at StackEngine, noted, “The basic principle is that operators (admins, system engineers, etc.) should not log in to a new machine and configure it from documentation.”

Christopher Null, CEO of Null Media and author of the article, then wrote, ” … But IaC is a concept that extends beyond simple infrastructure automation. IaC requires applying DevOps practices to automation scripts to ensure they’re free of errors, are able to be redeployed on multiple servers, can be rolled back in case of problems, and can be engaged by both operations and development teams.”

The idea is that you can describe any given service as a set of artifacts and deploy (and redeploy) them at will. So rather than set up a system and configure it directly, its configuration any associated artifacts (such as profiles or templates) are treated as code and stored in a common repository. A controller—the orchestrator—is responsible for distributing those artifacts when necessary. The controller uses an API (or protocol such as OpenFlow) to manage the configuration of services across a distributed infrastructure. It’s decoupling the service definition from the service and its platform.

Read that again. It decouples the service definition from the service and its platform and assigns responsibility for provisioning and configuration to a controller. Kind of like decoupling the control plane from the actual forwarding and switching actions (the data plane) and assigning operational responsibility to an external controller.

At its simplest, treating infrastructure as code is separating configuration from the platform and enabling a software-driven or software-defined approach to provisioning, configuring and managing infrastructure. It’s applying the principles of software-defined networking (SDN) to operations, rather than to devices and systems.

But as Null makes clear in his article, IaC goes beyond just automation and orchestration, adopting the best practices of development with respect to code reviews, versioning and management of that “code” to ensure consistent, predictable and repeatable deployments.

It’s all driven by software, ultimately, and deployed by software, and defined by software but always under the auspices of the operational experts: the engineers and architects.

Treating infrastructure as code is basically applying the architectural principles of SDN to operations itself. It’s SDN for ops.

April 22, 2016
Continuous test and monitoring essentials for SDN and NFV
The prior blog Continuous Test Monitoring DevOps Healthbeat discussed the importance and suggested practices for testing and monitoring test trends. This need is amplified when the system that is being tested and monitored is a network of co-operating applications, infrastructures and devices such as networked components of next generation Software Defined Networks (SDN) and Network Function Virtualization (NFV) systems. In networked systems a problem with any network component such as end-user applications, network interface devices, network control plane, network data plane, load balancers, firewalls, network administration, orchestration, and network virtual infrastructures can seriously impact user and network services performance. The number, variety, topology and versions of components and their host environments present special challenges for DevOps continuous testing and monitoring.
In an SDN and NFV world all production topologies and network variations must be tested and results must be monitored or the results will be uncertain. Despite the complexity, or perhaps because of it, continuous testing and monitoring must be optimized to ensure that testing and results analysis for each CI/CT cycle keep pace with accelerated continuous testing and longer term continuous test monitoring is necessary to assure overall delivery confidence for each release and longer term product performance trend in a positive direction. Individual test results or a fixed number of test campaigns can only tell you so much.

Unless the results of testing and test analysis are continuously monitored and results aggregated over multiple test and release cycles for all network nodes and all topologies then there is no way to build sufficient sustainable confidence in the long term health of the SDN network and NFV components. The combination of topology-aware continuous testing solutions together with continuous test monitoring tools that can aggregate results over the entire set of network resource can provide a longer term strategic view of test results that is necessary to collect, aggregate and organize test results data to gain confidence in network components and services for each release and evolution over multiple releases.

Below are some suggestions in a checklist format that have proven useful for continuous testing and monitoring for sustainable high performance SDN and NFV systems and services.
1. Determine continuous testing and monitoring priorities: Some examples of problems that continuous testing and monitoring can help with include intermittent failures caused by the virtual network infrastructures, virtual network functions, network administration, orchestration and management, 3rd party network and end-user systems compatibility, network performance, network fault-tolerance features. The best practice for continuous testing and monitoring indicates that the problems of most concern to a specific network system or service will be tested and result trends will be monitored.
2. Regression test network systems and services even though there were no expected changes: Unintended consequences of indirect changes may impact performance so automated regression suites should audit all production network test topologies and version variations areas occasionally just to be sure. Typical examples that are often caught by this are features important to audit functions, system backwards compatibility features and upgrade/downgrade administration features.
3. Select continuous test and monitoring tools that collect and report trends:
  Tools that can correlate and report test results across multiple network nodes and topology variations can find intermittent bugs or problem trends. Thresholds and email alerts and dashboards that highlight short term results views from long term results views are especially valuable.
4. Use continuous test monitoring results to diagnose and resolve problems:
  Intermittent failures and problems that only become apparent when test results are presented as trends over a long term trend are easier to diagnose when a large data set is accumulated and filtered by most probable cause tags. Once a diagnosis is determined, the root cause can be verified through targeted retest cases that set all the conditions in accordance with the diagnosis. Once confirmed then the offending design can be refactored to handle or avoid the failure condition.
The above is a partial list of suggestions for continuous test monitoring that have been proven to support sustainable SDN and NFV network systems and services. At Spirent and Zephyr we think continuous testing and monitoring is critical for successful DevOps. You can hear more about our views on this topic by reviewing our joint webinar at:
Overcoming DevOps Challenges

What do you think of these suggestions and do you have others that should be mentioned?

About The Authors ⁄ Marc Hornbeek & Sanjay Zalavadia

Marc Hornbeek is Sr. Solutions Architect of DevOps continuous test solutions at Spirent Communications, Infrastructure Test Optimization (ITO) BU. He recently managed DevOps at Spirent. He has performed as the primary architect of test automation tools and champion of test automation for firms ranging from start-ups to large multi-national companies. He published more than 30 articles and has been a speaker at numerous conferences and user forums primarily regarding topics related to continuous automated testing and DevOps.

Sanjay Zalavadia is responsible for driving custom success at Zephyr. This includes training, consulting, customer support and client management. Most recently, as the Associate Vice President for Patni Computers Telecoms IT Managed Services Practice, he established IT Operations teams supporting mobile content providers. Sanjay brings more than 15 years of leadership experience in IT and Technical Support Services teams across multiple geographies for both large and small companies. Sanjay has a graduate degree from the Manipal Institute of Technology in India
October 28, 2015
What IT expects from SDN is DevOps

There was much excitement in the air when the announcement that Docker had acquired SocketPlane. Not the least of which was emanating from my corner of the world, where DevOps for network (the whole network) is something you’ve noticed I pretty much live and breathe.

The announcement was couched as an SDN (Software-Defined Networking) play by containerization-leading Docker. Which might be confusing at first because, well, Docker (and to be more general, containers) are generally associated with DevOps, not SDN.

Ah, but therein lies the rub, doesn’t it? While the original precepts of SDN were most definitely not DevOpsy in nature, it (like every other trendy term in tech) has evolved to focus as much (if not more) on what are certainly DevOps-like principles and goals than on technical specifications and standards.

Consider, for example, this recent Avaya sponsored, Dynamic Markets report (gated) on “SDN Expectations.”

The first data point to examine is the ranking of “problems” experienced by respondents. The number one issue (38%) was downtime caused by human error. The second (tying with a network-failover issue at 37%) was complexity of configuring services and applications across the network.

If these aren’t typically problems that are said to be resolved by DevOps – particularly with attention paid to collaboration and automation – I’ll eat my hat. And yes, I often wear hats, it’s a quirk I have.

And just as interesting was this table illustrating not just problem areas, but how many respondents had the problem and how many expected SDN to solve them:

If you ignore the network management tuple, the top two problems are definitely often associated with DevOps as issues that can be resolved with collaboration and automation and some measurement thrown in to boot.

SDN has evolved, at this point, to focusing more on network automation than it does on automated networks. The difference is actually profound as it relates to DevOps, as the former is really about management, about configuration and provisioning and automation of processes designed to extend CD across the entire application deployment lifecycle into the production environment. It’s about codifying and encapsulating configurations in templates and centralizing state of the network in order to engender better agility in both moving forward and falling back when things go awry.

SDN today really is (or should be) a subset of DevOps, focusing on network infrastructure operations rather than app infrastructure operations. But the same principles and goals are very much aligned between DevOps and SDN, between the network and the application infrastructure. That’s a critical convergence starting to appear that’s necessary, as when you dig into IT and its problems delivering apps on time these days, it’s mostly the network that’s still in the way.

The network is identified often as a key IT pain point and usually the pain is related to the provisioning of services and applications across the network. High costs of networking is also cited, and that is largely due to the complexity of the network and the amount of operational sweat and blood that goes into manually provisioning, configuring and testing the various pieces of network infrastructure required to deploy the services business needs to deliver applications.

SDN may continue to be referred to as SDN, if only to emphasis its focus on network infrastructure, but the reality is that it’s DevOps. DevOps for Networks.

Which brings us right back to why a DevOps-related, containerization company like Docker would swallow up an “SDN”-focused start-up like SocketPlane.

Because what IT expects from SDN is really DevOps. And if DevOps is ultimately about culturally change and breaking down silos, the folks who focus on the network can’t be (and shouldn’t be) isolated from the folks managing the application infrastructure.

Docker’s move brings software-defined networks together with software-defined operations under (what should be) an IT encompassing concept: DevOps.

April 2, 2015
The Last Frontier in the Software-Defined Data Center

Three years ago, technology pioneer and venture capitalist Marc Andreesen famously proclaimed, “Software is eating the world,” and, more recently, industry research firm Gartner – in its top predictions for 2014 – declared, “The business is IT.” Combined, what do these statements mean for today’s enterprises? Simply put, with the continued migration toward a software-based world, a modernized IT infrastructure means the difference between business success and failure.

Over the past 10 years, technology companies have seized this opportunity, delivering massive innovation in IT to help organizations transform business models, processes and infrastructure to succeed in an increasingly online world. Key among them has been the use of software to break the 1:1 relationships between application architecture and physical hardware infrastructure, enabling major technology movements such as cloud, SaaS, and big data.

As each part of the infrastructure gains this abstraction process, commoditized, templatized services emerge, improving availability and performance, simplifying operations, and driving further innovation.

The Last Frontier Ahead
The data center is undergoing a revolution in migrating to a software-defined model. As a result, the move to the abstraction layer approach – the software-defined approach – is underway for all five fundamental infrastructure components of the data center:

Compute
Storage
Networking
Security
Data access

Technology vendors have evolved most of these components to operate in this software-defined model. But data access has lagged – it’s the last frontier in successfully building the software-defined data center. Until the benefits of the abstraction approach extend to the data access layer, data center operations will remain compromised.

The Common Thread: Breaking the 1:1 Chain
The software-defined data center breaks the 1:1 relationship that has existed previously for IT functions. This approach holds true whether that 1:1 relationship tied hardware switches that provide the fabric to the vLAN domain or applications to database servers. By allowing the software to abstract the data from the physical device, and treat the device as just a resource rather than a physically bound container for the data itself, software creates high-performing services that can be infinitely scalable and infinitely available.

What innovation in each part of the software-defined data center enabled, and how can we achieve that benefit in the last frontier of data access? Here’s a look.

Making Computing Capacity Elastic – Virtual Compute
Compute resources were among the first to undergo the migration to virtualization. VM has enabled the fast and easy provisioning of compute resources. With the ability to easily add or remove virtual machines (VMs) based on load requirements, access to computing resources has become magnitudes more simplified. Running many VMs simultaneously, organizations benefit through improved system availability, performance and resource utilization.

Slashing Storage Costs, Automating Provisioning – Software-defined Storage (SDS)
Software-defined storage (SDS) decouples the programming requirements for storage-related tasks from the physical storage hardware. By managing and automating storage through software, SDS has allowed organizations to simplify storage functions, including configuration and provisioning, as administrators no longer have to consider hardware attributes. The end result is that storage resources can be more efficiently and easily allocated as needed within an enterprise.

Simplifying Network Operations – Software-defined Networking (SDN)
As VMs rapidly multiplied, they became deployed in large and disparate environments. With networks scaling across thousands of typical machines and hundreds of thousands of VMs, organizations needed a solution that wasn’t tied to the switch.

The OpenFlow protocol delivered an important stepping-stone in the development of software-defined networking (SDN). Separating the programming of routers and switches from the underlying hardware, OpenFlow lets switches and controllers talk with each other. Other technology vendors have also contributed with solutions to separate the control plane from the physical network, enabling VMs to easily move from one physical server to another without limitations.

With the ability to program the network free of hardware, SDN has simplified network operations and vastly improved the provisioning of large, complex networks.

Simplifying Data Asset Protection – Software-defined Security
Software-defined security abstracts security resources away from dedicated appliances, such as physical firewalls or wire sniffers. This model lets organizations establish security parameters without changing the physical hardware, so administrators can easily extend security policies across a cluster or data center as needed. Software-defined security can make it easier for administrators to spot susceptible behaviors, for example. Unlike traditional security, which depends heavily on manual detection and administration, software-defined security leverages automated processes to alert organizations to possible security breaches.

Delivering Continuous Application Availability – Software-defined Data Access
Companies are just now starting to address the data tier, the key communications layer between the database elements and applications through software-defined data access. Some larger companies, such as Google and Facebook, have built their own proprietary data abstraction layer, while other companies are bringing these capabilities to the mass market.

One growing approach is to leverage SQL load balancing software to create a transparent, intermediary layer between the applications and databases. With database load balancing software, organizations can separate the application from the database, removing application complexity by avoiding having to program database structure into the applications. This approach provides for flexibility in how the database components are deployed and scaled, enabling automatic failover and other load balancing functionality with no application engineering.

Without changing a single thing at the database or application layer, software-defined data access provides dramatic benefits. It enables zero downtime for applications, boosts application performance, and reduces both hardware and license costs.

Conquering the Last Frontier

A software-defined data center ushers in new growth opportunities. It eliminates the technical obstacles that can consume operational energies and streamlines IT to improve customer interactions, driving new revenue streams and innovative social opportunities.

With so much business value wrapped up in easily and always accessing data, getting to the software-defined data access layer is crucial to business agility and success.

About the Author/Michelle McLean

As Vice President of Marketing at ScaleArc (link), Michelle is responsible for overseeing all of the company’s marketing strategy and initiatives. She has more than 20 years of networking and market positioning experience. Prior to ScaleArc, she held director of product marketing positions at Silver Spring Networks, ConSentry Networks, Peribit Networks, and Trapeze Networks, and prior to that, she was director of strategic marketing at Pluris. She previously served as program director at the research firm META Group, providing technology and strategy direction to global 2000 enterprise clients. Before that, she tracked technical developments, networking trends, and vendor strategies as a journalist for two leading networking publications, LAN Times and LAN Magazine. Michelle earned her BA in English from the University of California at Berkeley. ScaleArc social links: Facebook, Linkedin McLean social links: Twitter

February 5, 2015
DevOps needs infrastructure multi-tenancy

DevOps will, under whatever moniker you want to give it – NetOps, DevOps for Networks, operationalization – continue to make inroads into the network infrastructure because ultimately it’s part of the application deployment lifecycle. While DevOps folks call it “application delivery” the reality is that an application is not ready to deliver to a user (internal or external) until all its requisite services have been provisioned and configured.

Yes, infrastructure and network devices are increasingly API-enabled and supportive of a variety of tools and frameworks most often associated with DevOps – Puppet, Chef, OpenStack, VMware – and those more commonly associated with just the network – Arista, Cisco ACI, and OpenDaylight.

But it takes more than APIs. APIs do not inherently bestow upon devices the ability to support multi-tenancy. That is, the isolation of services unique to a team (or application) required to effectively deploy application-supporting infrastructure services within what is traditionally a shared environment.

According to ThoughtWorks Technology Radar (jan 2015) partitioning infrastructure along team bounds is becoming an imperative to removing roadblocks in the application deployment lifecycle:

Many of our customers have made DevOps a reality in their organization with delivery teams that build, deploy, and support their own applications and services. Unfortunately, a regular roadblock on that journey is allowing teams to have superuser privileges in production environments. In most organizations, the production environment is shared, and therefore risky to provide access widely. It is effective when we can partition infrastructure along team bounds,so that those teams can have safe isolated access to do their work, without risking impact to other systems. Where cloud environments are used, this is much easier to implement, aligning account structures to team boundaries. [emphasis mine]

This has always been an issue where shared services are relied upon. A change to support one application (or team) can be disruptive or cause issues for another application or team. Thus, most infrastructure and network teams staunchly refuse to let anyone in the application or operations side of the house play with their toys.

They are the network ninjas; guarding their configurations with their very lives.

It’s this kind of conflict that needs resolution if we – as a unified IT organization – reach goals of improving the time to market and frequency of deployment. It doesn’t matter if the app team can deliver an app in 3 weeks if it takes 3 months to deliver it to the customer because of overloaded network and infrastructure staff.

There are two good solutions to this problem*.

1. The governance over more application-affine infrastructure services – load balancing, caching, proxies, etc… – is necessarily moving closer to the application and under the control of app and operations teams. This is supported by concepts like Network Service Virtualization, proposed in Lippis Report 217 as well as the increasing adoption of open source proxy-based (virtual and software) services. This model assumes continued shared network and infrastructure services as appropriate while migrating per-application services to the more agile, operational architecture.

2. The introduction of multi-tenancy in infrastructure architecture provides a similar approach while still maintaining shared resources (hardware). A single, high capacity system is able to host multiple, virtual instances of its services, each dedicated to either teams or applications, as is the organization’s need. This approach spreads the cost of the hardware resources across the entire organization while allowing a more per-application approach to provisioning, configuration and ultimately, cost. Isolation addresses the concerns of shared resources and configurations that can cause consternation among network and infrastructure teams because the underlying shared system is managed by them while role-based control over application services is offered to teams or designated responsible individuals.

Both approaches are valid and in many cases both architectural solutions will be used to resolve the issues caused by traditionally shared infrastructure.

The key takeaway here is that there are answers to the need for partitioned infrastructure that are supportive of DevOps-driven workflows and processes and can certainly provide a path toward ensuring a more seamless, time-sensitive end-to-end application deployment process.

* Oh, I’m sure there’s more, but right now these appear to be the best two options.

January 22, 2015
You Might Already be Doing DevOps in the Software-Defined Data Center
I was out reading the Internet and came across a report from EMA (Enterprise Management Associates) regarding the state of the Software-Defined Data Center (SDDC) in 2014. After perusing the data and highlights, I was surprised (and yet should not have been) to find so much DevOps-related content and concepts within. Neither should I have been surprised to find significant mention of software-defined networking (SDN). It makes sense, in a puzzle-fitting-together kind of way, that SDDC comprises software-defined operations and software-defined networks (and probably software-defined storage but it’s too early in the day for me to contemplate that).

In any case, a significant percentage of organizations take advantage (today) of software-defined operations and networking, based on the report:

Which of the following technologies, structures or processes does your organization take advantage of?

4. Cross-functional processes to orchestrate provisioning and management of storage, network and server resources (57%)
5. Solution for server administrators to provision their own storage volumes (56%)
6. Continuous/centralized capacity management for physical, virtual and cloud resources (55%)
9. Policy-based automation of infrastructure for routine adjustments without human intervention (50%)
10. Software Defined Networking (virtual overlay network) (48%)
11. Software Defined Networking (separated control plane from delivery plane) (46%)
13. APIs for developers to provision their own app environments (servers, network and storage) (42%)
14. Configuration management solutions (Puppet, Opscode Chef, SaltStack, ServiceMesh, etc.) (41%)

More telling, perhaps, of how critical DevOps is to enabling the SDDC is the emphasis put on not just automation but on process. When asked what respondents believed were the “most important aspects of the Software Defined Data Center”, number 2 and 3 focused on deployment and automation of applications and infrastructure:

Best-practice, repeatable configurations of software and infrastructure for workload deployment (46%)

Orchestration and automation to easily deploy applications across silos (44%)

In case you weren’t entirely convinced, yet, “operational analytics” (we might call it “measurement” or “metrics” here in DevOps land) came in number four with a respectable 42% of respondents.

There’s more in the report, some less relevant but for the most part, reading this SDDC report left me with a decidedly DevOps after taste. Which was kind of a minty chocolate coffee taste, in case you were wondering.

The concepts typically associated with DevOps are not necessarily peculiar to DevOps or SDN. They’re generally part of a larger trend to operationalize all the things: the network, the storage, the compute, the security. The business goals of SDDC are strikingly similar to those promoted by DevOps and SDN – reducing risk, lowering opex, improving stability and time to market. The collaboration through creation of interfaces designed to promote repeatable, consistent (and measurable) handoffs between groups is present and looms as large in SDDC as it does in DevOps.

The point is that DevOps may, in fact, be in the adoption process right now under the guise of another name in an organization near you – or around you. If you hear someone saying software-defined something, check it out. You may be surprised to find out that someone has snuck in DevOps through another door, under a different name.
December 10, 2014
Network Engineers as Programmers? Not so fast.

It is interesting, as the triplet new waves of hype evolve – cloud, SDN, and DevOps – that we are repeatedly hearing The Voice of Reason say things like “All network engineers need to be programmers”. While this is certainly not the only voice that demonstrates what I’m talking about, an example of it is Kirk Byers’ commentary on Network Computing’s site. (http://www.networkcomputing.com/data-centers/programming-an-essential-skill-for-network-engineers/a/d-id/1297898) I do not know Mr. Byers, and want to be clear, he’s not the only one portraying this wisdom, so the reference is merely that – a reference to the syndrome I discuss here.

In DevOps, certainly having staff members that understand both application development and network engineering is a bonus. Being one of those fabled unicorns, I also know that they’re few and far between. I’ve worked with some great ones over the years that “just get it”, and they certainly add value to an automation project that involves networking. But there is a reason that there are few of us that understand both.

I’m a programmer. I’m a very good programmer. In the course of my career, I’ve also become very good at strategy and even technical marketing. I learned networking because of my career path. When I chose to gear my career at new challenges, there were many. From datacenter administration to IT management, from storage and servers to networking to security, from cloud to embedded. I’ve enjoyed every aspect of my career, but I’m still ‘a software guy’ at heart… Just one that knows about networking, storage, and servers at a deep level.

The thing is, my knowledge is not some magical formula. There are people in your enterprise that know all of this, and not all of them are software people.

I’m just suggesting we stop and think about it. When making the move to DevOps, there is a need for a certain set of skills. Those skills absolutely do not have to be vested in a single individual. There’s more overhead if you’re coordinating efforts, but think about what is going into place – automation scripts (of one form or another, no matter what tools you use) that have to have a big initial push to get developed, and then, unless your environment is in perpetual flux, just get used and occasionally modified.

This does not require retraining of the entire networking staff. In fact, in maintenance mode, those scripts are not generally going to require regular work. Indeed, the largest changes to these scripts will occur as part of a pre-planned project that can take them into account.

Looked at another way, developers sometimes need to deal with networking issues… Does that mean all application developers need to be retrained as network engineers?

And there’s a risk. If you decide all of your network staff needs to learn how to code effectively in whatever language and/or tool you settle upon, some of them are likely to leave. Because they’re network engineers and not application developers for a reason. Just as I am at heart a developer, they consciously chose network engineering. For the amount of maintenance required after the initial push to get the automated portion of DevOps into place, one network engineer who is also interested in development is plenty. It doesn’t have to be the whole team. If it did, then all network engineers would need to be security engineers also, no?

It’s a wave. It will wash over your IT shop in stages, cresting with the workload required to get the automation part of DevOps running, then receding, leaving ripples, but not a ton of water behind. Treat it as such. Get the help necessary to fill the gaps, put a team together that can address all the issues, then let them all go back to their roles, with added (and reduced) responsibilities that DevOps brings. Let developers do the development, working in tandem with network engineers. Find the network engineer that is most interested in development, and have them sit with the developers, working it out, getting everything right and learning what the scripts do. Then let that person handle maintenance, and let the developers roll back until the next major project needs teamwork.

In the context of network engineering, system engineering, and application development, it’s a project, not a lifestyle change, to automate things. We know how to do projects, they don’t generally involve upheaval and retraining of entire teams.

But if you’re still convinced you need the unicorn that can do it all, give me a call. That is, after all, what my firm does – bring knowledge both broad and deep to the table to help you solve problems – but honestly, most organizations don’t need someone like me nearly as much as they need a process, a list of attainable goals, buy-in from IT management for the manhour investment, and a plan.

August 13, 2014
Is SDN just DevOps for the network?

The answer depends on your definition of SDN.

(more…)

July 22, 2014
What “Programmable” Means

One of the most often used words these days to describe emerging architectures and technology is (drum roll please) “programmable.”

Now, from my used-to-be-a-developer-and-architect-turned-infrastructure-geek perspective, I know what that means. It means I get to write code. But to what purpose that code is put to is a question that’s rarely answered. So today we’re going to answer it because, well, my used-to-be-a-developer-and-architect-turned-infrastructure-geek persona likes to talk about code.

When you hear the term programmable used in the context of Software-Defined Networks (SDN) they’re talking about the same things that “programmable” means in the context of Devops: programmatic control of both the data and the control path.

The easiest way to visualize the difference between these impressive sounding terms is to recognize that the data path is inside and the control path is outside.

What that means is if you’re interacting with the data path, you are participating in it. You can inspect it, evaluate it, and transform it and, perhaps more importantly, you can make decisions based on data in flight. That’s powerful for the network, because a variety of Devops patterns are based on this very concept and require the network for implementation. Consider, for example, the implementation of an A/B testing pattern. The basic premise of the pattern is that somehow the identity of a user is known and, based on their membership in a defined group (beta testing customers, roles within the organization, volunteers from the community, etc…) they are routed to different versions of the same application to determine how differences in the UI impact behavior.

Notice the term routing, which implies it is a function of the network. The reason programmability is critical is two-fold: one, you must be able to identify the user as belonging to a specific group and two, you must be able to dynamically route based on that information. The former, identification, could ostensibly be accomplished using fixed lists IFF (If and Only If) it is possible to map a user to some variable readily accessible to the network, which traditionally means things like IP and MAC addresses and TCP ports. Most folks will immediately recognize that today this isn’t enough (and actually it hasn’t been enough since the days of the mega-proxy, but I digress). The information that’s needed is much higher in the networking stack at the application layer, aka in the OSI model as Layer 7. Which means you’re probably going to have to dig into HTTP headers and maybe the payload to get the data you want. That requires programmability in the data path, inside.

To really make the pattern scale (and to make it flexible enough to support a phased approach to beta testing) you probably don’t want group membership to be a static, fixed thing. So now you’re going to want to extend your implementation to include making a call to a database or identity store (LDAP, AD, etc…) to get current information. That requires programmability in the data path, inside.

So what programmability in the data path means is the ability to use code to direct the behavior of some “thing” in the network, be it an application proxy or a load balancer or what have you. You can’t easily do this through configuration-based proxies because they don’t allow for the execution of the domain logic necessary. There are a limited number of interactions you can achieve with configuration-based systems because of the logic they’re hard-coded to execute,and most of them don’t include calling out to a data store to look-up arbitrary information.

Data path programmability = Code in Flight. So you now you know where the name of the blog came from. This developer-and-architect-turned-infrastructure-geek finds the intersection between programmability and networking irresistible.

Okay, so that’s data path programmability. What about control path programmability?

Well, that’s the easy part. Control path programmability is on the outside. It’s the APIs that enable automation and orchestration of provisioning and configuration. Control path programmability is how you integrate infrastructure into command control systems like OpenStack, Puppet and Chef. Infrastructure comes with varying degrees of API-enablement, some extremely granular and others less so, depending on the particular function and maturity of the vendor.

So what you can do with the control path depends on the API, but in general it enables things like provisioning new services – think configuring a new virtual server in Apache and all the settings that accompany it – or start up and shut down functions that enable rolling maintenance across a set of devices or servers to avoid downtime.

But all control path programmability is on the outside, enabling integration and management without having to learn a CLI or configuration file syntax.

SDN and Devops use both programmability to reach relatively the same goals: scale of operations, rapid provisioning of services, to decrease the possibility of human error (the fat finger factor) and to introduce flexibility into systems that were previously bound to fixed processing and configuration-based paradigms.

Programmability in the network is going to enable a variety of new patterns, processes and services and as traditional infrastructure becomes more and more programmable through the adoption of architectural approaches like SDN, Devops is going to see more and more opportunity to apply its maturing expertise in leveraging programmability to a much wider audience.

March 24, 2014
Ops is dead, long live DevOps

Yes, that’s a bold statement, but if the vibe at the recent AWS re:Invent conference was any indication there are a number of methodologies, technologies, and companies working to make that a reality. This article isn’t focused on whether this is a good or bad thing (my personal belief is that ops will always be a critical part of the IT delivery process). Regardless, it is critical for IT operations personnel to understand the implications of this tectonic shift. As Marc Andreessen, founder of the venture capital firm Andreessen Horowitz, has said, “software is eating the world.” As a result, ops professionals must have the ability to automate tasks that used to be managed manually. Whether or not you think that is the death of ops as we know it I will leave to you, but it does mean we will live in a world where DevOps will offer distinct advantages.

Before we dive into what this change means to ops personnel, let’s review the underlying assumptions. The fundamental driver at the a high level has been the DevOps movement. Yes, DevOps is quickly becoming the buzzword dejour, but the underlying principles are lasting and changing IT to its core. DevOps is about integrating the various functions that it takes to release software or applications: software development, quality assurance, operations, and security among many others and rapid iteration. The process of integrating these tasks is accomplished through new processes and automation. Different functional areas such as development and operations are brought into the process earlier, and their processes are automated to the extent that they can be. This results in fast cycle times, increased quality, and hopefully increased innovation for the business. All of this is accomplished through software – at each functional level.

Some technologies that have enabled this massive shift include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), automated configuration management, server management tools, virtualization, and software defined networking. IaaS and PaaS offerings are eliminating the need for organizations to procure, provision, and deploy servers. Further, this class of technology is also dramatically reducing the need to deal with the network layer. This allows organizations to concentrate on their applications and development, and focus less on their infrastructure. The amount of time and effort spent on server and network configuration is minimized. Configuration management solutions are enabling the automation of server setup. An organization’s technology stack can be pushed, pulled, cloned and copied versus manual configuration thereby saving time and adding consistency. Top performing organizations employing DevOps go a step further and automate the scaling of capacity based on utilization. To reduce day-to-day operational activities and costs, organizations are also automating the management of servers, including users access, patches, security, and other areas through both traditional written code and SaaS solutions. Another area changing the game for ops personnel is software defined networking (SDN), which is effectively morphing data center and hardware functions into software programs.

In short, DevOps and associated innovative new technologies are driving a paradigm shift in the way operations is done. No longer are ops personnel required to manually provision, configure, and manage the network, servers, and application stack. Combining technologies from organizations such as AWS, Rackspace, and SoftLayer along with configuration tools such as Chef and Puppet drives the provisioning and configuration of applications through software automation rather than manual effort. Once applications are deployed, the underlying infrastructure can be managed with tools such as my own company, New Relic, this author’s own JumpCloud, and others. Ops personnel have more companies than ever focusing on helping them automate the tasks that they need to deliver applications for their organizations.

The result from all of this effort is that ops as we know it won’t exist in the future. The network operations wizard that could manually troubleshoot routing and switching issues, provision servers quickly, and tweak configurations will be tasked with automating those tasks through software. Some of that automation will be through code that ops person writes herself, some delivered by third party providers, and other portions delivered by open source or SaaS-based solutions. But, don’t shed tears for the forced obsolescence of the IT ops people. They will still exist and perhaps be more important and powerful than ever. In fact, because of DevOps ops personnel will in essence be set free from mundane, repetitive “busy work” to perform higher value tasks as well as managing over the software and systems at work. The black magic of enabling different layers of the stack to function together will be less about art and more about science, or rather good software. Solutions will be engineered to work together and be tied together through code. Caveat: yes, service providers and some large enterprises will still run their own data centers and networks, but the same reasons that DevOps works in IaaS or PaaS will apply to private data centers or private clouds as well.

If all of this trends toward being true as we see it happening today, what are the opportunities for ops personnel to be at the forefront of this shift? Beyond embracing DevOps – which many operations personnel are doing already – learning to code is the most critical step that ops professionals can take. Many ops professionals already know how to script which is absolutely a minimum, but many will need to go further. Embrace the DevOps movement and push further towards the development side by learning how to code. There are any number of amazing services to teach us how to code or code better. Take the step. It may be the difference between a vestige of the old school versus driving the new world in your organization. The second significant step you can take is to automate your job. Leverage the very best automation tools to code your network, server, and application infrastructure. Not only will you spend less time on these tasks manually, but you will increase availability, reliability, and performance. In most organizations, that’s more than a gold star. Finally, make the mental shift that operations in the future will be less art and more science. DevOps is driving action through data, and the technology stack is responding to this demand with more telemetry than ever. Problems are now solved through understanding performance, availability, and other metrics. And code.

DevOps is the future. Automation is key. Code is the answer. Developers and ops are in it together for the good of their organizations. Ops pros that embrace this will win! Ops is Dead, Long Live DevOps!

March 12, 2014