I think we forget that we have trained a generation of children to commit mass shootings. “Video Trainings” like Call of Duty and Battlefield should be declassified as “video games” because killing is not a game. Likewise, we should re-sensitize to how alluring the symbol of a gun is to adults who need to feel powerful.
NRA and Magazines
Yesterday, a neighborhood friend posted a photo of gun magazines in epic display at one of our local chain pharmacies. After mulling over what this meant for about this for 2mins, I responded:
Granted, this is a liberal-as-fuck move, using social media to push against a brand publicly to take ownership for businesses and corporate contractual obligations. Thank you, yes it is.
If you’ve ever really worked with a kid, you know that getting down to eye level with them really helps to engage and motivate them. So stuff like this at their eye level is bound to engage and motivate them,
What really concerned me is that there’s a population of adults now who are apparently consuming this shit enough for there to be a rampant market for it…in the most liberal state in the United States. Either this anti-pattern was creeping up on us over years, or there’s some serious money being pumped into this retrograde mindset that proposes the 2nd amendment meant for AR-15s to an inalienable right.
I highly doubt it was a rogue decision by a single branch manager because, having flown to Minnesota and Wisconsin this week, I saw with my own eyes that this was a reoccurring trend, same thing in Detroit. Like a signal to people who would use these kinds of fire arms that they should stock up quickly. A reminder that you can only safe if you pack more than the next guy, that enough bullets will solve any problem. I can’t even imagine what it’s like in the southern states right now, maybe they’re gearing up to stage a Confederate overthrow.
It’s the money that bothers me. To get this many separate magazine titles on a local rack, magazine not gun surprisingly, there have to be some serious contracts in place. This goes along with what the manager told a community member when confronted by the senselessness of this:
So vendors (of the magazines) must approve a change to floor placement in pharmacy chains? Sounds awfully like a well-known contractual obligation to me. Why would a gun magazine retail distribution contract stipulate that all gun magazines must be placed on the bottom rack? You must be 18 in order to become a legal consumer of a gun. Why wouldn’t the magazines want to promote at eye level of their legal consumers?
“Mommy, Daddy, why don’t we own a gun?” is a powerful thing for a parent to hear. And because you can get gun loans with no background checks in some states, practically anyone can rapidly resolve that question in lethal force.
I think the problem here is multi-level. Brands like Delta, United, MetLife, Bank of Omaha, Enterprise, Windham, and soon others publicly denounce the NRA while for-now-president Donald Trump and goons like Wayne LaPierre equally denounce gun control efforts. Figureheads aren’t innocuous, they embolden an already primed generation. And on that…
NRA and Video Games
When I was a kid, video games were a cursed luxury. I paid for my own Famicom…I mean, Nintendo Entertainment System…and games too. Repairs even, when I spilled cereal into the thing (don’t ask me to reconstruct that memory please).
My conservative Christian parents begrudgingly lent me scant amounts of time on the family TV, that is until someone had the bright idea to put the NES on a small black and white TV that my recently passed Grampy had left to me. Spoiler: it was me. I am an engineer and things just occur to me sometimes. And I wanted to beat every goal that some big kid who made the game set for me. Inside there, I could do great things, certainly better than out in real life.
In my ‘Xellenial’ generation, most parents either didn’t understand video games or otherwise weren’t the type to care about much else. I made sure that in my house, video games would be a family activity. The one’s we chose are puzzle-solving, narration read requiring, fun incentivizing pieces of amazing art by teams of people who love what they do. While some people struggle to get their kids to care about books at all, ours read so quickly through everything we bring home from the library that they create their own stories, which are more than often very interesting.
My partner and I have chosen to be very intentional parents. We feed our kids the best we can afford. We limit screen times to the weekends. We don’t subscribe to religion. We are kind and sincere people. We will never give our kids phones because they will pay for them if it’s important enough to them.
So it’s easy for me to view video games as a good thing in my house. That’s not so kids who have been given technology and no constraints. The habit is formed to scratch the itch to get what you want, to win, to watch the next one, until it’s done. Unconstrained screen time encourages obsessive-compulsive personalities in kids.
Please just go to a GameStop and look at all the highest grossing titles. They’re mostly first-person shooters like Call of Duty, Battlefield, Destiny 2, Wolfenstein, Sniper, Rising Storm, and get this…”Get Even”, a story who’s heroine has to shoot her way out of dungeons, office buildings, and SCHOOLS.
Killing is not a game. Interactive killing stories are not video “games”, they are early video “trainings”. Take away the killing, like in Mario Odyssey, where multi-player and assist mode help various ages in a family all progress through problem-solving challenges together, and you have an actual video “game”.
[Note: listening to the Super Mario Odyssey background soundtrack, it’s really great to hear that the musical director took the time to create an 8-bit version of the 44k version for the switch between 3D and 2D gameplay. That’s like a little gift for me as a parent who grew up with these themes.]
Titles that include violence should be barred from sale as “video games” and be regulated under federal law the same as movies and other adult forms of entertainment. To these video game vendors, you make blood money and you should be eradicated along with the mental disease you spread.
“I would not squelch legislative efforts to deal with what is perceived by some to be a significant and developing social problem. If differently framed statutes are enacted by the States or by the Federal Government, we can consider the constitutionality of those laws when cases challenging them are presented to us” says U.S. Supreme Court Justice Samuel Alito. [ref]
A “Developing Social Problem”
Is gun violence really a ‘developing social problem’? Well, let’s consider two facts: 1) if someone shoots someone else in public, that’s a social problem and 2) gun violence is definitely developing.
There are other statistics that indicate that gun sales are going up while homicides by gun is going down. The margin variance in units per home is often plotted against a seemingly dramatic drop in incidents of violence. The type of violence matters if we consider what kids have been “trained” to do: pick up a weapon, find a way out of a building, kill what gets in your way. The mentally ill underage in this country have an easy onramp to becoming a statistic more like this:
“The practices and beliefs of the founding generation establish that ‘the freedom of speech,’ as originally understood, does not include a right to speak to minors (or a right of minors to access speech) without going through the minors’ parents or guardians,” says Justices Clarence Thomas.
That’s right, so when major pharmacies branded chains with managers that are members of my local community contractually decide to allow the NRA to engage with my children about owning a gun, when families allow children to play shooting games without limits, and when we don’t confront these situations without hesitation when they arise, this is what creates a fatal national epidemic.
What do we do about it?
I drove to my pharmacies, grocery stores, and convenience stores to look for these displays. Find a few, tell them about the social movement and how they don’t want that massive bad PR and inevitable sales dip next month due to boycott, and sometimes things change:
Still at eye level to a 2 year old, but at least the surface area for little eyes is reduced. I’d rather have Rachel Ray glaring at them than the muzzle of an AR-15.
Testing in a DevOps culture is very different from traditional QA scenarios. I talk to all kinds of teams, from Fortune 100 to startups, all on the journey to adapt and innovate. What happens to testers in this new world?
This article is a bundle of content related to why and how software teams can align and improve their testing strategy. I addresses “right fit” to across org and process, cost center vs. value stream, and many other dynamics in testing culture.
This article describes how DevOps teams can quickly spin up a reliable, cost-effective Selenium grid for automated testing in minutes.
What Is Selenium & Selenium Grid?
If you’ve never heard of Selenium before, climb out from under that rock.
Selenium is a test automation framework that lets you script interactions against your web apps and run them in popular web browsers. Selenium Grid is a management service that coordinates the use of many instances of these browsers. You can point your Selenium scripts to a Grid, specify which “capabilities” (OS version, browser version, etc.) it would like in an interactive session, then drive actions in that browser session to verify functional correctness of a target app or website.
This is what it typically looks like in Selenium code:
Pretty simple, really, for what’s really going on under all the layers of code and HTTP protocol communications.
Why Use a AWS for Your Selenium Grid
There are plenty of services that host Selenium-compliant grids, such as Sauce Labs and Browser Stack, and I recommend you consider one of the many SaaS options if you don’t want to maintain and upgrade a grid on your own. However, if your team has reasonable automation skills and the human resources to do so, the benefit of a DIY grid is complete control for a fraction of the cost associated with hosted services.
Though I abhor the idea of paying hundreds of dollars per month for only a few parallel browser instances, a word of warning about DIY grids over SaaS alternatives:
You don’t get same-day support for the latest browsers and OS versions
You don’t benefit from script-to-driver version independence
You don’t get infinite scalability without some serious effort
You don’t get 24/7 operational oversight unless you pay someone to do it
If you (and your team) are okay with the above disclaimers and simply just want a quick, cheap way to spin up a grid, then the steps below suffice:
Launch a Ubuntu linux distro to act as the Docker host.
I used an t2.xlarge at $0.19/hr to get 4vCPU variable and 16GB memory. Also set SDA storage to 32gb.
In the security group you created/assigned during EC2 instance setup, add the following inbound rules:
4444 (Selenium Hub)
5900-6000 (VNC for various browsers)
Verify that your grid contains the browsers you spun up:
Connect to VNC remote services on instances using the ports assigned in the above docker run commands. On a Mac, I recommend VNC Viewer.
Reference your grid in a Selenium script, using port 4444:
[picture of code]
Now when you run your script(s), particularly in parallel, you should see nodes on your grid running your automated script.
How Is a Selenium Grid Better Than Local Execution?
Well, for one, it’s not popping up multiple browsers on your workstation while you’re trying to get other work done. In build and continuous integration scenarios, you need to run automated Selenium scripts on an environment that doesn’t include the laptops your developers take home with them at night.
You also want your test environment to be as versioned and reliable as possible, so having an on-demand grid that can be scripted as an AWS YAML descriptor and that meets your manual, on-demand, and CI testing requirements is a modern must.
Why Did I Write This Tutorial?
I’m a sometimes performance engineer. I needed a disposable Selenium Grid to show how to use a subset of browser sessions during a large load test to collect real-user experience metrics in NeoLoad. I didn’t want to pay hundreds of dollars for a monthly subscription to something I could build in about 30mins.
Why am I running a subset of real browsers as part of a load test? That, my friends, is the really interesting part that I discuss in a later post.
Paul: All right so welcome everyone my name is Paul Bruce and once again I’m back here with a member of the DevOps community, Dave Fredericks. Now Dave you organize the DevOps Boston event is that correct?
Dave: Yeah that’s correct. I’ve participated as a volunteer organizer for the last three years, involved for the last four.
Paul: Excellent…and I got a chance to meet you beforehand, I think at one of the DevOps Days Boston meetups, but then also we got to chat at the event and it was a really good event. I think a number of different things were really just cohesed really well, particularly from my point of view, the collaborative open spaces. Can you tell us a little bit about what that’s like how that got into the conference schedule?
Dave: Yes, certainly. So open spaces is a really interesting kind of platform that’s unique to DevOps Days. Basically how it works is everybody comes up with topics during the event after listening to some of the keynotes. Some discussions that are interesting to individuals, a lot of times you want to add on your personal perspective into, not only offering new ideas or maybe even some suggestions, but asking specific questions.
A way of being able to do that is by getting everyone together at the event over common topics. You basically vote on different topics that are of interest to you and they can actually go anywhere from cultural to personal to technology as a whole.
The idea is, there’s a few rules, it’s basically:
what’s being said is what needs to be said
who’s there is the people that need to be there
when it starts and when it ends is the time it starts and ends
Those are the only kind of guidelines that we go by and the idea is to get people who usually wouldn’t be open to public speaking to be able to have a chance and an opportunity to either share some ideas, ask questions specifically and directly to different individuals and to have an open forum.
The real values that come out of it are real specific dialogue, the biggest thing is new introductions and relationships that are created.
The hope is that throughout the year after the event, a DevOps stage event is for you to be able to get contact information of individuals who are in the same space, at the same stage as yourself to have an outside outlet to be able to bounce ideas off of through the year as you start to face some of the challenges as you as an engineer try to solve problems.
Paul: Yeah that was one of those things that really clicked for me, being part of a number of those open spaces, I saw exactly what you said which was people were far more likely to comment and to share and ask questions. And in a larger audience and I think the other element of that is the fact that not only do they get the share but they get instant feedback.
And this is one of those core tenants I think of DevOps, in my mind, is this concept of continuous learning. But you don’t learn unless you know what’s going on and you don’t know what’s going on unless you [as an organization] radiate information which is typically facilitated by feedback loops. So whether we’re talking about technology feedback loops or real people feedback loops, I think that’s really helpful.
So can I back up for a second and ask you a slightly broader question about DevOps: in your mind how would you define DevOps?
What Is DevOps, Really?
Dave: Great question. You know these this is one that in our community we talk a lot about, especially for folks who are outside of quote-unquote “DevOps thought process”, knowing that it’s something that’s taking off as a force in the software world.
One of the things we do is to talk about how do we define DevOps. The biggest thing for me is DevOps means different things to different people and it’s all about context and perspective, where you come from and where you’ve been and what challenges you’re trying to solve. So when I meet somebody new who’s in this space and they’re starting to kind of either chant or evangelize to me without first getting a baseline perspective as to where I’m at and what I was doing and what I’m trying to solve, immediately has me question, “okay, are you trying to push your ideals down on me?”,
This is what DevOps means to me: getting folks to work together in an efficient collaborative manner to solve a common goal, period.
It has nothing to do with tools. It has nothing to do with process. It has nothing to do with frameworks. It’s all about getting people together, teaching context, having empathy, understanding what somebody’s doing, why they need to do it, and what what they’ve been doing in the past. You share your ways of doing it and then together when you have a sense of “okay, I know why this person has to do things, I know the reason why they’re thinking this way”, you can efficiently solve problems and for me that’s that’s what DevOps is to the core, right there.
Paul: So one one thing I heard from that is it starts with people, right? It doesn’t start with tools, it doesn’t start with how you’ve been doing it; it starts with people and really understanding the context and the perspective that they bring to the table. Is that right?
Dave: Yeah, Paul, you you nailed it right there. It starts, it continues, and it ends with people. Ultimately I take the concepts and the core principles of DevOps, and you can apply that to any industry, any product, any delivery, any manufacturing, and it really is bringing people together to work more efficiently to solve a common problem.
What Is DevOps Not?
Paul: And so actually people are doing that, you’ll hear the prevalence of these amalgam terms like DevSecOps, DevTestQAOps. And I kind of take issue with that in the sense that I understand how important terminology and clear labels for things. As a practitioner and engineer, as soon as somebody starts to blow out a term to mean “all the things”, my red flags get raised up instantly.
That doesn’t mean that [DevOps] doesn’t include other people, but can you tell us a little bit about how important the scope is of DevOps to you? And just kind of following that up with some context, I was able to speak to Ken Mugrage from the DevOps Days Seattle, and he was very clear about how if we blow it out into all the things, “DevOps” loses its value.
And so I put this to you: why is a pantheistic term, if DevOps grows to that, why is that a problem?
Dave: No, that’s a great thought. I want to take this back a little bit to identify why are all these actions added on, how and why this is how [DevOps] is being branded in this way. This was a discussion that I have, especially with growing teams.
One of the biggest things I talked about with organizations is, first and foremost, technically there is no DevOps engineers. So why label it that way?
There’s No Such Thing as a “DevOps Engineer”
When I started working with a lot more enterprises, I helped organizations transform their development to be much more modern so that they can have quicker release cycles and feedback. It’s one of the things that used to frustrate me, was like “hey, we need five DevOps engineers!”. That doesn’t mean anything to me, you got to explain on a day to day basis, what is this person doing, and ultimately, why are you labeling these folks as DevOps engineers?
And I I had some interesting feedback which came from the product marketing side. They were like, “Dave, we’re in the enterprise. We’re used to big long deploys of software in order to get it to our customers, and a lot of times we don’t know if our customers are even getting any value out of what we’re producing. When we’re releasing every year and waiting for six months to get the actual feedback from our customers, it doesn’t make any sense.”
So you see this large swath of folks trying to get into this space to build software quicker to have faster feedback to be able to add more value to end users.
These individuals don’t really understand this whole open source community, they don’t understand how the strength of the community is really the value.
“So we don’t know how to really market. We don’t know how to communicate to the group in a way for us to be able to blanket it all together. So we just scoped it into this thing and we call it #DevOps and everything gets that kind of label to it.”
From my experience what I’m starting to see is a lot more of these organizations who are specific to security, to testing, in a way of being able to catch and grasp that member of the audience, it’s “let’s throw it in, Dev and Sec Ops, Dev Quality Ops. What starts to happen in my mind and what I’m what I’m worried about is that people start to lose the real purpose.
Paul: So basically the exact same thing that happened to Agile. Everybody forgot to have agility as one of the core tenants that people check in on, on a regular basis such that they internalize that, and that is where their activities and their tools flow from, right?
Dave: Yes exactly. If you start to get too focused on the terminologies and the labeling of things and forget the context as to why you’re practicing it, ultimately the further down stream you get and the more generations that start to get folded into the process, they’ll start to lose the actual scope, “hey we’re trying to get people to to work together in a more collaborative manner to be efficient and to be able to deliver quickly.”
How to Be a Good DevOps (Citizen, Vendor, Employer)
Paul: Yeah, one thing that I did recently was put out an article (and thank you you, you had shared it to a number of people and I think that’s half the reason why I got some attention). It was essentially how to be a good DevOps vendor. It took the approach of looking at it from the customers perspective. The implementation of that was over a simplified customer journey and then chronologically through that journey, I went through and basically made statements from an outsider’s perspective onto different groups whether it be product, marketing, sales.
Back to your perspective, I get that it has to fundamentally start with people because people are what build teams and teams are what build software and software is what affects us. But the team affects us and individuals affect us, and so it does make sense to keep that as a core of value, to consider personal responsibility and also the responsibility of the team to have these cultural aspects present.
But unfortunately I think what happens is that we do need tools and you know, conferences are notorious for needing some kind of funding and becoming self-funding is really hard, and so out comes sponsor packages and I mean it’s an ecosystem. All software is eventually, in most people’s minds, going to make money and so this is where I was coming from, understanding that there is no such thing as a DevOps vendor or a DevOps tool or a DevOps job/position. Yet the fact is that when you’re closely aligned with the thinking of another person and “DevOps” is the term they’re using, it’s easy for these vendors to kind of bring that in and pull that into their messaging.
So I guess my my point of view on that is that we are gonna have to deal with that but it’s kind of a constant battle against the pantheism of trying to “all the things” a term [DevOps] but in the meantime we also do have to represent those tenants to more than just the developers and operations. If you really want to sell to developers and operations or teams that are looking, or they have internalized DevOps, they’re going to be looking at the world from this interesting perspective. And they’ll be looking across the tool chain to figure out who sounds like they’re blowing smoke up [you know where].
If a tool vendor or a service provider does not understand the core of DevOps, then their messaging, their selling process, their product ideation…it’s all not going to jive with the real market.
After after a recent Boston DevOps meetup we dove into this for what like an hour and a half, and just really talked about how do we actually do this. My concern is that when we start to move this into the enterprise (and by the way, the good principles of DevOps should be moveable to the enterprise, right? If they work, they work, and it’s a matter of fitting to context) that I think, while the core of it is culture, we can’t just live in this sort of kumbaya world.
We really have to figure out how to scale DevOps principals up and out into the enterprise setting so that, by the way, these good principles have a positive impact on things like automated insurance, things like machine learning in terms of healthcare, defense and government settings.
So I’m working on that on the side but in the meantime, what do you think about scaling to the enterprise? What does that even mean for DevOps?
How DevOps Is Re-writing Management Decisions
Dave: Yeah, that’s a great point. It’s an interesting challenge. There’s a lot of organizations who are facing it. Right now, I’m dealing with situations where we’re starting to see a lot of enterprise buy instead of trying to build it themselves. One thing they have is capital and resources. So the idea is, “if we don’t know or we can’t make it, it’s the bye versus build, like why go out and try to do what people already are being really successful in doing in something that we don’t understand too well? Let’s just go ahead and absorb some of these startups…”
Paul: Do you mean actually purchasing startups in order to just fill that technical gap in an organization? So I don’t want to name names, but I’m thinking of a very large enterprise that just recently bought up one of the most well-known API monitoring services out there, and people are freaking out like “oh gosh, what’s going to happen, are they going to de-culture this awesome group of guys and gals?”
Dave: I’m dealing with the same thing within an organization, a large security company buying a smaller more nimble security product with a lot of open source options. They’re putting out there trying to create groundswell to get this tool for free into the hands of engineers, let them play with it so they can understand how it works and create some kind of a swell within the engineering teams and then we’ll come up to the top start talking to the executives about, “Hey, what challenges are you facing in this broad space?”, where you’re trying to protect not only year your customers information but also information about your company.
As they start to have that type of dialogue, all of a sudden the executives within the organization starts to look down, talking to their engineering group and saying “hey, what do you know, what have you played with, what do you think is interesting, how do you think we should be solving this problem?” You’ve already created that initial lift of inertia in engineering, then they say hey let’s go with this product…we already know how it works, we’ve been you tooling around with it. Win-win, right?
So this is a completely different way of thinking of how enterprises used to be selling products into their customers. It was always a top-down approach…let’s talk to the executives who have the purchase power, float it down and then they’ll disseminate that information in the way that we roll it out into the engineering team. That’s how you could do it in the old-school way. Now in today’s new world, a lot of tools are available for you to play with for free and when enterprise organizations start to try to come into this space, they’re really kind of blindsided by this whole new content creation process.
Selling Into DevOps Takes Understanding DevOps
What I’m starting to see is they’re at least now recognizing we do not know how to sell to this to this community of this group. We know we really want to get into the space, we want to do it the right way, what do we do right and you know to your point with your article, I’ve shared your article with all of the enterprises that I’ve have been talking to me about this problem because I can’t teach them about the thought process of open source.
I mean, we can look back in the 60s, the MIT days, where the two groups kind of split off. A lot of us in the DevOps space already have the mentality of like “hey, you know we want to be able to share a lot of this stuff but we do want value for hard work we do”. But for the most part there’s different ways of doing it versus everything is being paid for with the enterprise mentality.
What I’m starting to experience is there’s a lot of organizations out there that are realizing it’s exponential value once they start to get into this community and…
the brand loyalty within the DevOps community is tremendous
…but the challenge that is in front of us right now is really the learnings piece and I’m thinking it’s a leadership issue (this is my own personal view). It’s enterprise leadership that needs to get out of the way and allow for new blood to come in to be able to understand the kind of movement. I’ve been doing a little, as much as I can to try to influence old leadership. It’s a challenge and a lot of it has to do with success syndrome. You’ve been doing it in certain way for decades. It’s a great case study that we’re gonna be able to kind of sit back and watch in the next five years
Calling All Researchers: Inclusion Means You Too!
Paul: Yeah and you know, there’s so much going on, no one person can do it alone. So without plugging any commercial products of any kind (that’s not my motion) I have started something called the iterativeresearch.org, which is essentially a bunch of contributors to research. As they go along, it could be lightweight contributions, simply just pocketing articles and getting into a feed of people who pay attention, it’s writers too, but the point is it’s not on a brand that’s connected to a pay-for services. And you know I would love, for this conversation to really start flowing in that direction because I think it takes many perspectives, right?
The core of this is it’s an inclusive conversation, not an exclusive one.
So understanding that you are a busy man and we’re at the top of our time, are there one or two things that you want to give a shout-out to or any particular resources that people can go to, events, communities, open-source forums, anything like that?
Get Out to a DevOps Tribe Near You!
Dave: Yeah, you know, thank you so much for the opportunity first and foremost, we’re gonna have to do it again! One of the things I really would highly recommend to folks who are interested in getting more involved, start to look at some local meetups that you have going on. There are some great folks within every community in whatever city, whatever small town, who are interested in sharing ideas and in thoughts in challenges. All you have to do is get out there and look. Go find your tribe! The biggest thing is don’t sit back and wait and sit on your hands and expect for interest to come to you.
The whole constant learner, the Kaizen mentality, be better tomorrow than you are today, be better today than you are yesterday. It lives and dies in DevOps and the way to do it is start to talk to folks who you’re not used to talking to.
Don’t be afraid get out there introduce yourself and have a good time. Life is learning.
Paul: Cool. So that’s David Frederick’s everyone and thank you David for spending the time with me. Do you prefer going by David, Dave?
Dave: Dave, David, either way.
Paul: Dave/David, I’ve really enjoyed it was great being able to spend some time. We’ll circle back. Thank you so much! Cheers!
Open source software (OSS) is a foundational part of the modern software delivery lifecycle. Enterprise teams with DevOps aspirations face unique challenges in compliance, security, reliability, and sustainability of OSS components. Organizations-in-transformation must have a complete picture of risk when integrating open source components.
This article explores how to continuously factor in community and ecosystem health into OSS risk analysis strategy.
The Acquisition Process for Open Source Software
Developers need to build on the successes and contributions of others. Having the flexibility to integrate new open source components and new versions of existing dependencies enables teams to go fast, but external code must be checked and validated before becoming part of the trusted stack.
Including someone else’s software is an important moment of engagement. Enterprises typically wrap a formal ‘acquisition’ process around this process, where the ‘supplier’ (the entity who provides the software/service) and the ‘acquirer’ (the entity who wants to integrate the software/service) contractualize.
Though there are already commercial approaches to introducing software packages safely by companies like Sonatype,Black Duck, and others, my question extends beyond the tools conversation to encompass the longer-term picture of identifying and managing risk in software delivery.
Enterprises care deeply about risk. Without addressing this concern, engineering teams will never actualize the benefits of DevOps.
This is a tangible application of the need for DevOps to not only apply at an individual team level, but in the broader organization as well. It takes alignment between a team who needs software and teams providing compliance and legal services to all do so in an expedient manner that matches the clock speed of software delivery.
Communities Empower Enterprises to Address this Gap
Today in a Global Open Source Governance Group Chat, I asked the question:
“What are some methods for determining how significant a supplier/vendor OSS and community contributions are, relative to acquirer confidence?”
This question stems from my involvement with the IEEE 2675 working group, particularly because I see:
Prolific use of OSS use in DevOps and in enterprise contexts
Reluctance and concern (rightly so) around integration of OSS in enterprise software development and operation in production
The convergence of compliance and automation considerations
How important transparency and collaboration is to the health of OSS, but also to the supply and acquisition processes in a DevOps lifecycle
As open source projects (like Swagger/OADF for instance) become increasingly important to enterprise software delivery, health and ecosystem tracking also becomes equally important to any new components being introduced.
My point-of-view is that organizations should prepare a checklist for software teams to construct a complete picture of risk introduced by OSS (not to mention proprietary) components. This checklist must include not only static analysis metrics but support, engagement, funding, and contribution considerations.
Measuring OSS Project + Community Health
The group had many suggestions that I wouldn’t have otherwise thought about, another reason for more people getting involved in dialogs like this.
There are already providers of aggregate information on open source community health and contribution metrics such as CHAOSS, a Linux Foundation project, and Bitergia. This data can be integrated easily into dependency management scripts in Groovy, npm, Ant, Maven, etc. and at the very least written in to a delivery pipeline as part of pre-build validation (BVT is too late).
The group also identified some key characteristics of OSS community health not necessarily tracked by established services, such as:
Same day response on reported issues, even if it’s simply acknowledgement
PRs under the “magic number” of 400 lines of code…tends to be the limit for # of bugs and useful feedback
Outage response, sandbox availability
Distribution of component versions across multiple central repositories
More to Come…From YOU
As I integrate both my own learnings and other voices from the community into the larger Enterprise DevOps conversation, the one thing that will be missed is YOUR THOUGHTS, whether your in a large organization or simply in a small team.
In a conversation today with Ken Mugrage (organizer of DevOps Days Seattle), the scope of the term ‘DevOps’ came up enough to purposely double-click into it.
‘DevOps’ Is (and Should Be) Limited In Scope
Ken’s view is that the primary context for DevOps is in terms of culture, as opposed to processes, practices, or tools. To me, that’s fine, but there’s so much not accounted for that I feel I have to generalize a bit to get to where I’m comfortable parsing the hydra of topics in the space.
Like M-theory which attempts to draw relationships in how fundamental particles interact with each other, I think that DevOps is just a single view of a particular facet of the technology management gem.
DevOps is an implementation of a more general theory, a ‘next’ mindset over managing the hydra. DevOps addresses how developers and operations can more cohesively function together. Injecting all-the-things is counter to the scope of DevOps.
Zen-in: A New Management Theory for Everyone
Zen-in (ぜんいん[全員]) is a Japanese term that means ‘everyone in the group’. It infers a boundary, but challenges you to think of who is inside that boundary. Is it you? Is it not them? Why not? Who decides? Why?
By ‘management’ theory, I don’t mean another ‘the silo of management’. I literally mean the need to manage complexity, personal, technological, and organizational. Abstracting up a bit, the general principals of this theory are:
Convergence (groups come together to accomplish a necessarily shared goal)
Inclusion (all parties have a voice, acceptance of constraints)
Focus (alignment and optimization of goal, strategies, and tactics)
This article is intended for everyone involved in buying or selling tech, not just tooling vendors. The goal is to paint a picture of what an efficient supply and acquisition process in DevOps looks like. Most of this article will be phrased from a us (acquirer) to you (supplier) perspective, but out of admiration for all.
Developers, Site-Reliability Engineers, Testers, Managers…please comment and add to this conversation because we all win when we all win.
Note: As you read the following statements, it may seem that I bounce around talking to various group in a seemingly random fashion. This is actually a result of looking at an organization through the customer lens across their journey. As organizations re-align to focus on delivering real value to customers, our paradigms for how we talk about “teams” also change to include everyone with a customer touch point, not just engineering teams.
1. Make It Easy for Me to Try Your Thing Out
(Product / Sales)
Make the trial process as frictionless as possible. This doesn’t mean hands off, but rather a progressive approach that gives each of us the value we need iteratively to get to the next step.
(Sales / Marketing)
If you want to know what we’re doing, do your own research and come prepared to listen to us about our immediate challenge. Know how that maps to your tool, or find someone who does fast. If you don’t feel like you know enough to do this, roll up your sleeves and engage your colleagues. Lunch-n-learn with product/sales/marketing really help to make you more effective.
I know you want to qualify us as an opportunity for your sales pipeline, but we have a few checkboxes in our head before we’re interested in helping you with your sales goals. Don’t ask me to ‘go steady’ (i.e. regular emails or phone calls) before we’ve had our first date (i.e. i’ve validated that your solution meets basic requirements).
(Product / Marketing)
Your “download” process should really happen from a command line, not from a 6-step website download process (that’s so 90s) and don’t bother us with license keys. Handle the activation process for us. Just let us get in to code (or whatever) and fumble around a little first…because we’re likely engineers and we like to take things apart to understand them. So long as your process isn’t kludgy, we’ll get to a point where we have some really relevant questions.
(Marketing / Sales)
And we’ll have plenty of questions. Make it absurdly easy reach out to you. Don’t be afraid if you can’t answer them, and don’t try to preach value if we’re simply looking for a technical answer. Build relationships internally so you can get a technical question answered quickly. Social and community aren’t just marketing outbound channels, they’re inbound too. We’ll use them if we see them and when we need them.
(Marketing / Community / Relations)
Usage of social channels vary per person and role, so have your ears open on many of them: Github, Stack Overflow, Twitter, (not Facebook pls), LinkedIn, your own community site…make sure your marketing+sales funnel is optimized to accept me in the ‘right’ way (i.e. don’t put me in a marketing list).
Don’t use bots. Just don’t. Be people, like me.
(Sales / BizDev)
As I reach out, ask me about me. If I’m a dev, ask what I’m building. If I’m a release engineer, ask how you can help support your team. If I’m a manager, ask me how I can help your team deliver what they need to deliver faster. Have a 10-second pitch, but start the conversation right in order to earn trust so you can ask your questions.
2. Help Me Buy What I Need Without Lock-in
(Sales / Customer Success)
Even after we’re prepared to sign a check, we’re still dating. Tools that provide real value will spread and grow in usage over time. Let us buy what we need, do a PoC (which we will likely need some initial help with), then check in with us occasionally (customer success) to keep the account on the right train tracks.
(Sales / Marketing)
Help us make the case for your tool. Have informational materials, case studies, competitive sheets, and cost/value break downs that we may need to justify an expenditure that exceeds our discretionary budget constraints. Help us align our case depending on whether it will be coming out of a CapEx or OpEx line. Help us make it’s value visible and promote what an awesome job we did to pick the right solution for everyone it benefits. Don’t wait for someone to hand you what you need, try things and share your results.
Pick a pricing model that meets both your goals and mine. Yes, that’s complicated. That’s why it’s a job for the Product Team. As professional facilitators and business drivers, seek input from everyone: sales, marketing, customers!!!, partners, and friends of the family (i.e. trusted advisors, brand advocates, professional services). Don’t be greedy; be realistic. Have backup plans on the ready, and communicate pricing changes proactively.
Depending on your pricing model, really help us pick the right one for us, not the best one for you. Though this sounds counter-intuitive to your bottom line, doing this well will increase our trust in you. When I trust you, not only will I likely come back to you for more in the future, we’ll also excitedly share this with colleagues and our networks. Some of the best public champions for a technology are those that use it and trust the team behind it.
3. Integrate Easily Into My Landscape
Let us see you as code. If your solution is so proprietary that we can’t see underlying code (like layouts, test structure, project file format), re-think your approach because if it’s not code, it probably won’t fit easily into our delivery pipeline. Everything is code now…the product, the infrastructure configuration, the test artifacts, the deployment semantics, the monitoring and alerting…if you’re not in there, forget it.
Integrate with others. If you don’t integrate into our ecosystem (i.e. plugins to other related parts of our lifecycle), you’re considered a silo and we hate silos. Workflows have to cross platform boundaries in our world. We already bought other solutions. Don’t be an island, be a launchpad. Be an information radiator.
(Product / Sales / Marketing)
Actually show how your product works in our context…which means you need to understand how people should/do use your product. Don’t just rely on screenshots and product-focused demos. Demonstrate how your JIRA integration works, or how your tool is used in a continuous integration flow in Jenkins or Circle CI, or how your metrics are fed into Google Analytics or Datadog or whatever dashboarding or analytics engine I use. The point is (as my new friend Lauri says it)…”show me, don’t tell me”.
(Sales / Marketing)
This goes for your decks, your videos, your articles, your product pages, your demos, your booth conversations, and even your pitch. One of the best technical pitches I ever saw wasn’t a pitch at all…it was a technical demo from the creator of Swagger, Tony Tam at APIstrat Austin 2015. He just showed how SwaggerHub worked, and everyone was like ‘oh, okay, sign me up’.
Truth be told, I only attended to see what trouble I could cause. Turns out he showed a tool called Swagger-Inflector and I was captivated.
– Darrel Miller on Bizcoder
(Sales / Product)
If you can’t understand something that the product team is saying, challenge them on it and ask them for help to understand how and when to sell the thing. Product, sales enablement is part of your portfolio, and though someone else might execute it, it’s your job to make sure your idea translates into an effective sales context (overlap/collaborate with product marketing a lot).
(Product / Customer Support)
As part of on-boarding, have the best documentation on the planet. This includes technical documentation (typically delivered as part of the development lifecycle) that you regularly test to make sure is accurate. Also provide how-to articles that are down to earth. Show me the ‘happy path’ so I can use it as a reference to know where I’ve gone wrong on my integration.
(Product / Developers / Customer Support)
Also provide validation artifacts, like tools or tests that make sure I’ve integrated your product into my landscape correctly. Don’t solely rely on professional services to do this unless most other customers have told you this is necessary, which indicates you need to make it easier anyway.
(Customer Support / Customer Success / Community / Relations)
If I get stuck, as me why and how I’m integrating your thing into my stuff to get some broader context on my ultimate goal. Then we can row in that direction together. Since I know you can’t commit unlimited resources to helping customers, build a community that helps each other and reward contributors when they help each other. A customer gift basket or Amazon gift card to the top external community facilitators goes a long way to gaming yourself into a second-level support system to handle occasional support overflows.
4. Improve What You Do to Help Me With What I Do
(Product / Development / Customer Support)
Fix things that are flat out broken. If you can’t now, be transparent and diplomatic about how your process works, what we can do as a work-around in the mean time, and receive our frustration well. If we want to contribute our own solution or patch, show gratitude not just acknowledgement, otherwise we won’t go the extra mile again. And when we contribute, we are your champions.
Talk to us regularly about what would work better for us, how we’re evolving our process, and how your thing would need to change to be more valuable in our ever-evolving landscape. Don’t promise anything, but also don’t hide ideas. Selectively share items from your roadmap and ask for our candid opinion. Maybe even hold regional user groups or ask us to come speak to your internal teams as outside feedback from my point of view as a customer.
Get out to the conferences, be in front of people and listen to their reactions. Do something relevant yourself and don’t be just another product-headed megalomaniac. Be part of the community, don’t just expect to use them when you want to say something. Host things (maybe costs money), be a volunteer occasionally, and definitely make people feel heard.
Be careful that your people-to-people engagements don’t suffer from technical impedance mismatch. Sales and marketing can be at booths, but should have a direct line to someone who can answer really technical questions as they arise. We engineers can smell marketing/sales from a mile away (usually because they smell showered and professional). But it’s important to have our questions answered and to feel friendly. This is what’s great about having your Developer Relations people there…we can nerd out and hit it off great. I come away with next steps that you (marketing / sales) can follow-up on. And make sure you have a trial I can start in on immediately. Use every conversation (and conference) as a learning opportunity.
Build the shit out of your partner ecosystem so it’s easier for me to get up and running with integrations. Think hard before you put your new shiny innovative feature in front of a practical thing like a technical integration I and many others have been asking for.
(Development / Community / Marketing / Relations)
If there is documentation with code in it and you need API keys or something, inject them in to the source code for me when I’m logged in to your site (like SauceLabs Appium tutorials). I will probably copy and paste, so be very careful about the code you put out there because I will judge you for it when it doesn’t work.
(Marketing / Product)
When you do push new features, make sure that you communicate to me about things I am sure to care about. This means you’ll have to keep track of what I indicate I care about (via tracking my views on articles, white paper downloads, sales conversations, support issues, and OPT-IN newsletter topics). I’m okay with this if it really benefits me, but if I get blasted one too many times, I’ll disengage/unsubscribe entirely.
Summary: Help Me Get to the Right Place Faster…Always
None of us have enough time for all the things. If you want to become a new thing on my plate, help me see how you can take some things off of my plate first (i.e. gain time back). Be quick to the point, courteous, and invested in my success. Minimize transaction (time) cost in every engagement.
At often as appropriate, ask me what’s on my horizon and how best we can get there together. Even if I’m heads-down in code, I’ll remember that you were well-intentioned and won’t write you off for good.
NEXT STEPS: share your opinions, thoughts, suggestions in the comments section below! Or ping me up on Twitter@paulsbruce or LinkedIn.
Chloe Condon presented on how containers and IaC (infrastructure as code) can help us skip over the ‘staging server’ part of traditional deployment strategies. This article is a loose transcript of taking points from her talk at DevOps Days Boston 2017.
What’s Wrong a Staging Environment?
Feedback from a traditional staging environment is too slow. The only thing the reviewer knows is if unit tests passed, the rest of the tests are run after that. “Staging” is usually reserved for integration, functional, UI, and performance testing (i.e. complete feedback). Too little, too late.
We’re all too familiar with the question “who broke staging?”. The fragility and centrality of this staging model creates bottlenecks. Also, the very first time something is brought into pipeline usually happens in staging and that’s when ‘broken’ occurs.
There’s lots of “friction” between environments. Dev/test/staging are often not equivalent and are configured differently, causing deployment between environments to be a hastle. Flows across these environments are time-consuming (environment variables and files missing).
Code changes are being tested more extensively in staging, which means there’s little room for timely feedback.
The great thing is now, we have containers. We can run every build, package it in a container, then run tests on it in the same pipeline. Microservices are well-suited for this type of model, but also distributed stacks (like a web app, database, and supporting APIs) benefit from this model too.
Additionally, most stages of testing can be containerized. Leaving performance and scalability off for a moment, that enables us to run integration, functional, and security testing as part of a complete containerized package.
The problem still remains: we have the rule that staging has to be as close to prod as possible. This might serve some of those tests (like performance and security), but is largely dis-optimal for unit, integration, and functional tests. Performance tests could also be run earlier to provide us a better heads-up about degradations that creep in over time. In practice, late-stage environments don’t match reality and this causes friction..
So let’s reconsider the premise that all of our non-unit testing has to be run in a shared environment that bottlenecks us. This helps us shift feedback to the left. (Chloe says to insert Beyonce clip here.)
So now the container we’re handing off is much more complete: it includes a more complete set of self-testing capabilities that we can ask our pipeline to run for us.
You can hand off containers to your customers (usually internal but maybe even external) and with composition, you have confidence that the bits they’re running are the same as what you tested and what you want them to have.
Infrastructure as Code
Team should define what code is part of the process. When people are able to spin things up automatically on their own, this streamlines an important part of their process. Visualizations help a lot, which is why CodeFresh and other platforms have visual controls over the package and deploy process.
Infrastructure-as-Code (IaC) includes Dockerfiles, but also deployment scripts. If it’s code, treat it like it’s important because otherwise it’s outside the flow of delivery.
Paul’s take: IaC also includes a whole bunch of other stuff too. For example:
Your team agrees and has an in-depth knowledge of how to push healthy code artifacts into the pipeline. No one is an island, others’ contributions need to be readable and easily debuggable.
A resilient process (i.e. pipeline) including dynamic build/package/test semantics enables contributors to focus on the ‘push’ and feedback rather than the semantics.
Information radiators along the process must cater feedback as granularly as possible: individual contributor first, then channel, then team. ChatOps bots give you immediate feedback about breakage as soon as it occurs.
A complete IaC artifact list will require collaboration between multiple contributors, which facilitates communication. Just make sure that empathy and positive reinforcement is part of your management strategy.
Questions from the Audience:
Q: “How do you describe the state of the code in PRs?”
Chloe: “Badges in the repo, some conventions, success flags on Codefresh.”
Q: “How often do people actually use this for pre-stage vs. just going to prod?”
Chloe: “For lots of people, they maintain separate branches for multiple environments. Then you can introduce new versions dynamically.”
Q: “In more complex systems, is there a composition management layer?”
Chloe: “This is the beauty of the compose files. When you treat them like code, this makes management a lot easier.”
Tom McLaughlin presented on iterative security, incorporating security into DevOps cycles through early detection and prevention of vulnerabilities. His slide are here. This is a loose transcript of taking points from his talk at DevOps Days Boston 2017.
Breaches in Practice vs. Theory
Tom made the point that breaches often occur in areas that aren’t covered by development or security teams because vulnerabilities escape due to a lack of objective and continuous risk assessment.
Code still has passwords and tokens in it. Lots of assumed knowledge going from dev to prod. Account access and password policies, patching, is usually handled by someone else. Leads to “good luck, it’s up to you” syndrome.
There’s also security paralysis. When we don’t think we know how to do something, we just won’t. And we’re rewarded for accomplishing things. So long as disaster doesn’t strike, we get by.
Why Do We Suffer from Security Breaches?
Mostly, we get distracted. 0-day exploits, crypto weaknesses, hash collisions. We get distracted by logos and discussion threads, but not patching the system. We get caught up in all of this stuff instead of actually doing what improves security.
Think about all the publicly exposed mongodb and Elasticsearch instances you’ve seen…being proactive isn’t always hard, but is rarely incentivized well.
We don’t do a good job explaining how to get from where you are to where you should be. We also don’t always practice critical thinking. What is you goal? What is your posture about security? Proactive, reactive?
We also don’t always have a wealth of layered instructional content. There’s a lot of information at the extremes (101 and advanced tutorials), but most of us are in the middle.
Solve the Problem Like You’re At Work
So then let’s develop a threat model together, as an example. Let’s start by being realistic. What kind of org and product matters? Align with your company on risk management policies and processes.
Also take care of the easy stuff: USB sticks over man in the ceiling.
“Do you still use a service after it’s been breached? I leave that up to you.”
Decompose the system. Map out your architecture and understand the systems. Look at the perimeters, how are credentials proliferated? Understand your data pipeline, where is your really valuable data stored?
Take time to consider things like exposed net ports, unpached containers, weak secrets…there are tools for this. These tools can be found in later slide here.
Putting a Response to Security Threats into Action
Two words: impose constraints. To find which constrains work for you and start with a simple discovery process that includes:
Time, how long to solve? Timebox solutions, defensible use of existing time.
Complexity, how hard is it? Ask deep questions, iterate over which help.
Risk, how risky is the problem and solution?
Secrets management is a first start. Tom pretty much pwns this space and I encourage you to seriously check out his extensive work on the topic here.
In terms of tactical actions you can take today, Tom mentioned these few, but of course there are more:
At the code, start with at least something like git-crypt.
Ask yourself, what should be thrown out before it goes anywhere else?
In configuration management scripts:
Developing a master re-key strategy is a great exercise to flesh this out.
Storage…a tool like sneaker for S3
Really makes you ask questions…who/how are buckets managed.
We need to be better at security, continuous or otherwise. We need to act. There are simple things you can do, but they need to be aligned to your team/organization risk strategy. And make it easy for others to do the right thing, so that it’s far more likely to happen without imposing huge effort cost.
Tom’s a great speaker, engaging and fun to listen to. He is also a huge community contributor and even runs a distributed DevRel (developer relations) slack group. Tom is currently working on the CloudZero team.