I attended DevOps Days in Silicon Valley, June 27/28, to learn more about what DevOps is, and what matters to the people who care about DevOps.
The location was the Computer History Museum in Silicon Valley, which is an excellent venue for such events, and a fascinating place to visit in its own right. The staff were helpful and the facilities clean, well laid out and a pleasure to spend a couple of days in.
NetOps is DevOps?
Being from a networking background, my colleagues and I are familiar with the role of network operations (NetOps). When we hear “DevOps”, then, the tendency is to draw a parallel between the two ideas in a way that leads us to imagine that DevOps is like NetOps, but at a layer above in the "orgitectural" stack.
That’s not quite it, or even very close.
NetOps is a well defined role in the networking world, and one can belong to a “NetOps” team. By contrast, in one conversation at the event, someone claiming to be from a “DevOps” team was quickly disabused of the notion that there could even be such a thing. To think that way is to potentially miss the point.
DevOps is, first and foremost, a cultural phenomenon. It has much to do with the admirable desire for us all to just “get along” and understand each other better. To remove barriers between teams, share tools and practices, have a common stake in success and generally see that delivering business value requires that the flow, from development to delivery, needs to be an integrated and automated continuum.
There is a hard technical edge to DevOps too. This is not just wishful thinking, it is manifested in a desire to automate all that can be automated, to remove the need for human error and intervention, and to increase quality at scale. All of that requires some hefty technical expertise also.
Since these are arguably goals that apply to network engineering and operations too, there are clearly lessons to be shared between NetOps and DevOps, which is a point I shall return to below.
How DevOps Days Works
DevOps Days is, in effect, a franchised community effort. The basic pattern is to obtain a venue, sponsors to pay for the venue and food, and then invite people along to have a chat. Whilst there are formal proposals for content, most of what draws people to the event is about what happens in the “Open Spaces”. This is where the attendees self-organise to discuss what they want. The pictures below illustrate how that works.
This is all about sharing: sharing your questions, concerns and experience. It works well. People come to a discussion, potentially worried and confused, and walk away with more knowledge and ideas than they started with, and less worry and confusion. Pretty good value for the $100 it costs to attend.
The Major Themes
The pictures for the open spaces also help to illustrate some of the major themes: culture change; the trade-off between standards and choice; impact on processes; accessibility and correctness; workflow to deploy; institutional inertia; API design; business value; cloud; women in IT; and so on.
The cultural change theme had several amusing illustrations. In one, a marketeer explained how she was motivated to work more closely with her engineering colleagues. She was faced with the task of marketing a release that appeared to have no unifying theme, just a bunch of random bug fixes. She settled on the notion of “with love”, but clearly felt she ought to be able to do better next time, and she wanted to help illustrate how we, the attendees, could too.
In another, a chap recently from operations explained that he had joined a development team in a “DevOps” role (pace the notion that there is no such thing, which helps to illustrate the useful diversity of opinion in this space) and that things were going quite well. Nevertheless he seemed to concerned, whilst the reaction of everyone else was: “And your problem is, exactly?”. It turned out that there was only one of him, and that the other developers did not want to work on “operational” tasks. The general advice was not to position the tasks as “operational”, then, rather, say, build or test automation. It was all about positioning.
Another of the key technical themes in the conversations I took part in was “automation”. Everything in the develop, test deploy and monitor lifecycle, that can be automated, should be automated, to achieve quality at scale.
What makes this interesting is not the automation per se (though see the many technology vendors selling such things below), but what this means for one’s organisation and the roles that people play in it.
In one conversation, an attendee sought advice on how to transition team members doing manual testing, who did not have the skills to contribute to test automation. Advice included the options to retrain, to reposition as different roles in a scrum, as test designers, optional retirement, and similar. A lot of good ideas, respectful discussion and a high degree of satisfaction all round, both with having had the opportunity to contribute, and in having a problem lessened.
No technology event would be complete without actual technology, of course, and the exhibitor’s space, shown in the picture below, was an interesting sample of the various vendors in this space.
Below is a list, in alphabetical order, of the various technology providers I met with. There were also other exhibitors I did not have time to meet with.
It is clearly early days in this space, and there are several similar concepts with varying implementations. This is clearly a good thing, at this stage, as it drives innovation and provides choice. I have no favourites, and I have restricted myself to a brief description of each based on their own web site positioning text.
So What are we Doing About it?
There clearly is an intersection between the DevOps ideas and the networking world. All that can be automated includes network configuration and monitoring too. The emerging concept of network programming, and Linux container based deployment into network devices, echoes similar themes in container based cloud deployment. IT service delivery has to be automated all the way through the IT stack. Any issue in the network will have an impact on IT services that needs to be analysed and correlated with data from IT services monitoring.
So, yes, the two worlds do need to be brought together. As much as the DevOps concepts have to offer to automation in the networking world, so, too, do the operational and fault management practices in the networking world have to offer IT, especially cloud based IT.
The Cisco people attending the event were looking for insights to help us understand what we need to do to help our customers down this path. We are not completely new to what is happening here of course. We have long supported Puppet Labs through investment, for example, and recognize the excellent work that they are doing.
My colleague Jason Pfeifer has already done some interesting work in this space, described in his blog at Puppet Labs, as well as this video. In addition we have NXOS support and we have been using Puppet to deploy WebEx Social.
To help such ideas grow, Cisco’s DevNet has teamed up with CollabNet to create an integrated environment to support a network programming systems development lifecycle (SDLC), based on the Cisco VIRL virtual networks technology.
At DevOps days, I was kindly introduced, by Paul Peissner of CollabNet, to John Willis and Dave Nielsen, who helped organise the event. John and Dave are keen to do something, similar to DevOps Days, focused on the intersection with the networking world, enabled by emerging network programming concepts.
Some ideas of what that might look like are illustrated in Jason’s blog above, and in John W’s Alice In Wonderland - DevOps and OpenStack Networking presentation.
We did that as described in this DevOps4Networks blog.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.