devopsy.kinsta.cloud

Tag: devops process

Unconventionality within Constraints

What do dependency resolution, situational awareness and superheroes have in common? Meet Chris Corriere, a DevOps/software engineer at Autotrader speaking on creative ways to maximize usage of all of the above. Mark Miller, community advocate and senior storyteller at Sonatype, caught up with Chris to learn more about what his team is up to.

Corriere: I’m Chris Corriere, and I’m a DevOps engineer at AutoTrader.

Miller: Can you give us an overview on how you’re using Nexus?

Corriere: We use Nexus for dependency resolution. Part of that is to insulate our enterprise infrastructure from general third-party dependencies. We’re able to filter that down with our internal repo and make sure that our developers are using things that are pre-approved, that we’re allowed to track and update. We also use it to move around internal projects that have cross-dependency between applications in-house.

Miller: How are you enforcing pre-approved dependencies?

Corriere: They are generally around who has access into Nexus and who is allowed to improve and pull things into Maven Central. But there are ways around that. There are ways to sneak things into builds. If a developer really wants to get something in then, sometimes when you’re troubleshooting, you find some of those clever solutions. There’s definitely an element of striking balance between that, of making sure they’re able to experiment and get the tools in they need to get their job done, but not exposing any liability or risk in the process by pulling something in that’s not trusted.

[soundcloud url=”https://api.soundcloud.com/tracks/270488651″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”450″ iframe=”true” /]

Miller: If somebody isn’t using a binary repository, what could you tell them that would get them to use one?

Corriere: Consistency within the build environment is one of the main draws to me, that and reusability of code. I think that doubles back into situational awareness—depending on how they’re measuring their organization, what they’re looking for in terms of improvement, and where there’s room the optimize. There’s probably a lot of interruption in build, a lot of different permutations. I’ll say in different solutions, it could be more standardized and more consistent across teams. You can get by without it. But you’re probably doing a lot more work for the same end result. Without a repo, there’s a lot more drama, a lot more heartache involved.

—

“Without a repo, there’s a lot more drama, a lot more heartache involved.”

—

Miller: I would think that the more developers you had, the more you would actually have a real need for it.

Corriere: I would say the most creative solution I’ve seen is teams get pretty consistent results with using source control and builds at particular revisions. But in that instance you have to have the build to succeed. You have to get through the build, and that’s going to take time even if it doesn’t break. Your repository is putting everything after that step where it’s ready to go. You know it’s built. You know it’s safe. It didn’t get into the reboot. It didn’t make it through the filter.

Miller: Have you guys done anything cool with Nexus?

Corriere: I wouldn’t say anything too out of the ordinary. There’s some overlap into how we’re leveraging it that looks more like configuration management, which is unconventional. Depending on the project, you’re able to check some things from Nexus and how they will stand up [against] a lot of your environmental dependencies outside of just a job application. It can dip into the version of Java you’re running, different inch grips, and other things that nest into each other. That gets you to sort of square one to launch a lot of our standard internal apps. Again, back to the situational awareness, given some of the constraints of the teams we were working with, it’s something I ran across and it felt a little left handed at first. But when you stop and look at it, they were able to get the ball moved down the field within the constraints that they were given. At the end of the day, it works.

Miller: Are you using any continuous integration, continuous delivery?

Corriere: Yeah. I don’t think that’s a boolean of a value. We’ve got a lot of it end over life cycles, and we’re running continuous builds. We’ve got some in-house tooling around that, and we also run Jenkins. There’s always room to accelerate, improve and optimize it. We’re moving to more continuous delivery. We really want to start getting things out closer to prod. But you always start with the left side and move out from there, and try to debate quality from step one where there’s lower risk. I’ve seen AutoTrader make a lot of good strides in that over the past couple years.

—

“There’s always room to accelerate, improve, and optimize it. ”

—

Miller: Final question, if you were going to be a superhero, would it be in Dev, Ops or Sec?

Corriere: I’m going to go with security because I think there’s some development and operations involved in that if you’re doing it right. I don’t think you should be blue team or red team. I think team purple is where it’s at. You really got to come at it from both ways to get the job done today.

—

“I don’t think you should be blue team or red team … purple is where it’s at. You really got to come at it from both ways to get the job done today.”

—

Miller: Excellent. Thank you, Chris.

Corriere: My pleasure.

If you loved this interview and are looking for more great stuff on DevOps, I invite you to download the “Continuous Delivery and DevOps Reference Architectures,” highlighting real-world DevOps practices from organizations including PayPal, IBM, Adobe, USPTO and many more.

August 15, 2016
REP SPOTLIGHT: Glenfis AG
1. Tell us a little about your organization: Based in Zurich, we offer consulting and training services since almost 20 years. We see ourselves as an independent enabler for the digital transformation, helping our customers getting fit for the digital age. To this end, we use the ‘Glenfis Principle’ – a holistic approach that, alongside theoretical knowledge, attaches particular importance to the mediation of practical skills (competence), which can be used to successfully and lastingly deploy this knowledge in the company or organisation (Implementation).
2. What other topics do you teach or consult on? Topics include:
  – Cloud & Sourcing
  – Lean, Agile & DevOps
  – Value Chain Service Models
  – Training and Awareness (Cloud, ISO, ITIL, Cobit, Security, Agile, DevOps)
  – Security & Cyber Resilience
  – Change Enablement
3. What type of interest in DevOps are you seeing in your region? As everywhere the interest of DevOps is rapidly growing, in Switzerland this in not different. For many it’s really to understand in a first step what DevOps is about and why it is relevant for them. In Switzerland we deal a lot with financial institutes with a high level of legacy and regulations, the question is often how to apply DevOps practices in such an environment.
4. How do you think that DevOps contributes to the business’ value stream? DevOps is all about getting faster and better and this is how it positively influences the value stream. And DevOps does it in a holistic way by looking at the value stream end-to-end, from idealization to $$$.
5. What topic area in DevOps excites you the most? Dev’s and Ops’ finally talking to each other!
6. Why should enterprises and individuals consider formal DevOps Training? Before starting any change initiative, it is paramount that everybody gets a common understanding. This is especially true for DevOps, as it includes a wide range of Agile, Lean and ITSM practices. A training or special awareness sessions definitely facilitates this.
August 10, 2016
REP SPOTLIGHT: Xellentro Consulting Services

DevOps Institute: Tell us a little about your organization.

Xellentro: Xellentro Consulting Services LLP is an emerging global provider of project, program and portfolio management, IT service management consulting and training services. Established in 2012, with headquarters in Bangalore, India, Xellentro works closely with its clients in tackling their most difficult organizational development challenges. Xellentro is a specialist organization that works with its clients to identify improvement areas and uses experienced consultants to enhance their business and development processes.

While the realm of management consulting is vast and a number of firms provide a range of advisory services—starting from niche areas to general management domains—what differentiates us is our practitioner’s approach where we don’t limit ourselves only to advisory and rather prefer to stay on till envisaged benefits are realized and final outcomes are delivered. We bring in huge experience across industry verticals.

DOI: What other topics do you teach or consult on?

Xellentro: ITIL Foundation, Intermediate, Practitioner, Expert, Scrum Master and Product Owner, PRINCE2, PRINCE2 Agile, MSP, MoP, PMP, Lean Six Sigma

DOI: What type of interest in DevOps are you seeing in your region?

Xellentro: There is interest mainly from corporates.

DOI: How do you think that DevOps contributes to the business’s value stream?

Xellentro: This will be a good extension to the ITSM and with Agile being used everywhere, DevOps will have a great value.

DOI: What topic area in DevOps excites you the most?

Xellentro: The concept of having both Development and Operations working together is very important to finally deliver value to business.

DOI: Why should enterprises and individuals consider formal DevOps training?

Xellentro: To really understand the culture change and not focus on only the tools/automation part of it.

August 10, 2016
Intersections: DevOps, Release Engineering and Security

With emerging ideas, innovation and talents, the lines between DevOps, release engineering and even security are rapidly blurring. I invite you to sit down for a moment with principal consultant, J. Paul Reed, and listen to his take on what the intersection between these once individualized fields entails—and may even foreshadow.

Derek Weeks: Good morning, Paul. There’s a lot those pursuing DevOps can learn from release engineering practices. I know you’ve got a lot of experience to share, so let’s get started.

J. Paul Reed: Good morning, it’s good to be here. My background is release engineering, although these days I am actually called a DevOps consultant. I have about 15 years experience doing that. That’s what my presentation is about: sort of the intersection between DevOps, rugged DevOps and release engineering, and wanting to explore that with the security and rugged DevOps communities.

Weeks: In your presentation, you touched on the culture between security and DevOps and also release engineering—that a number of organizations have challenges with, and that’s the “Culture of No.” There’s a lot of, “Hey, we want to move faster at higher velocity. We have new requirements that we’re trying to push out to market, and we have these new practices that we’re moving forward with. Can security come and play with the DevOps team?”

Reed: I actually put up a tweet that a lot of people liked on one of my slides: “If your answer to every question is ‘no,’ do not be surprised when people start pouring effort into ways to not even ask.” This idea that if your answer to everything is “no,” then that is seen as a bug or a blockage like on the internet, and organizations will just route around it. I think security found that out in a very visceral, hard way. In release engineering, it’s the same thing.

—

“If your answer to every question is ‘no,’ do not be surprised when people start pouring effort into ways to not even ask.”

—

One of the reasons that Git became so popular is because developers didn’t have to ask if there was permission to create branches. They created an entire infrastructure and ecosystem around not having to ask. I think that’s one of the risks we run, and it’s one of the similarities.

One of the interesting things we’re finding with DevOps—because that idea of getting new traction and people do want to move faster—is we can frame the work that we do in the context of that pipeline. By identifying and optimizing some of the business value that is part of that pipeline, businesses are receptive. Developers are receptive. Different parts of the business are receptive in ways I’ve almost never seen in my career, and it’s great to be a part of that. From a rugged DevOps or security perspective, I think if we could move that work into the pipeline, not only do we make it visible in terms of the costs and trade-offs, but then also we could possibly do more. It’s part of that whole. There are lots of presentations talking about this idea of shift left, that you can shift that work from your perspective further up into the stream so that you can address it earlier and actually have a chance at fixing the problem.

In talking with Josh Corman and a lot of the rugged DevOps people, they always talk about how at the end of that process, they would rubber stamp: “Yes, this is secure.” Because even if wasn’t really secure and it was bad, what were you going to do? As a release engineer, that resonated with me because we felt like that all the time. We were kind of doing a bunch of work at the end, and there was no time to do it right. So a lot of times, it was skimped on.

Weeks: When you think about the way traditional security works, how early can we think about rugged DevOps shifting left?

Reed: Yeah, I don’t think it’s so much about getting everything right at the beginning, per se. I think that the question is how far forward can we shift into that process. I think if you can shift that all the way to the beginning, that is possible. The beginning is where you define your pipeline.

A lot of people define that pipeline as commits, that is developers writing code. Some people will define it actually at the product management stage, so even earlier than that. Or that kind of agile story phase, I think you could certainly integrate it there. This is sort of what I was exploring in my presentation. I open with the slide on what is the intersection of release engineering and Rugged DevOps, and I say I don’t actually know. It’s a very emergent field.

—

“There’s no shortcuts to production…They put the financial resources and the engineering resources into building the pipeline that moves code quickly through it.”

—

I spend the next few slides talking about sort of the crossover in making that bar. There are a lot of similarities there. I think when you’re talking about pushing that stuff forward, it’s about the more tools that you can make part of that pipeline, like release engineering tools. So for us, that might be something like: How do we track what developers create as dependencies in the work that they’re doing? So how do we make that a little bit easier in time for them to say, “Yeah, I’m using this version of that, and it’s integrated here from a release engineering perspective.” Then from the security perspective, you can take that information and use it to do different types of security testing or penetration testing. If you can move that earlier in the process, that’s what it will do. Then how early you do that really is a function of how good you get at this sort of thing.

I don’t think we’ve seen this with security entirely yet. We’re still recognizing the value with release engineering and companies are hitting it out of the park. They just put everything in there and continue delivering pipeline. There’s no shortcuts to production. There’s no back door to get stuff deployed. They put the financial resources and the engineering resources into building the pipeline that moves code quickly through it. Then once you do that, you can augment that pipeline with more and more features, if you will. One of those might be moving security way forward in that process.

Weeks: Are there old ways to do things that just won’t work in the new universe and you have to adopt new tools or practices?

Reed: I do hear a lot of, “Well, we can’t do X because of Y” — “Y” being one of those cut old ways that you’re talking about. One of the things we continually see at conferences is idea of the answer being, “We can’t do X because of the old way.” In fact, in security, you see this all the time: “I can’t do X because of audit compliant stuff.” But case study after case study says: If you’re willing to rethink the framing on the way you do audit compliance and work with your auditor—if you’re willing to look at the problem slightly differently—then you can achieve those results. Because we have all this proof, when people say, “Oh, we can’t do X because of the old way,” my question is, “Are we thinking of the problem in an old frame or in a more traditional framing that is not sewn enough?”

Now that’s not to imply the concerns people bring up are invalid. That’s the initial question that you had, which was about people. If they have a lot of knowledge, they might be worried, “Well, I can’t automate things this way as well as I can test them.” I talked in my presentation about how release engineering is undergoing a fundamental shift. I’m very upfront about the fact that if you are a release engineer and you are not building continuous delivery pipeline and involved in the support and service of that continuous delivery pipeline, your job is probably not going to be there in five to 10 years. That’s just the way the world works. A lot of people think, “Oh, okay, that’s unfortunate,” or whatever.

—

“If you are a release engineer and you are not building continuous delivery pipeline and involved in the support and service of that continuous pipeline, your job is probably not going to be there in five to 10 years.”

—

I’ll give you a QA (quality assurance) example that I thought was really innovative.

Organizations spend a bunch of time automating a test and the initial response is, “Well, if you automate all of those tests, what are the QA engineers going to do?” It turns out that because QA engineers are so good at looking at a product and coming up with the requirements, they need a lot of that totally valuable knowledge forwarded into the value stream. They are having those QA engineers doing requirements analysis and working with product management to firm up the actual requirements that go into the continuous delivery pipeline. What was fascinating about it was that it’s not that the organization was, “We are going to automate you out of a job and then we’re going to fire you, so go automate yourself into a script.” People are like, “I’m a person, not a machine.” You have that whole conversation, and they end up doing more interesting work.

They put them working on that continuous delivery pipeline in the requirements analysis. It’s totally different than what you might expect. It’s going to be the same with security and release engineering. For security especially, we’re going to see a lot of that work go. There’s a set of compliance work you can do in an automated fashion. Once that is automated, I see a lot of discussion about red team, blue team … kind of wargaming type of thing. And it frees up time to do that and to work as a team in that way. Because you can’t automate all those things, or at least today you can’t. I think everybody in the security space would agree that it’s more interesting work than running around, if you’ve got a huge project, with a black binder with a bunch of rules.

Weeks: One of the concepts that really resonated with you was the software supply chain. How does that concept fit with doing release engineering right and doing rugged DevOps right or incorporating security into DevOps?

Reed: Yeah, the supply chain idea is something that was fascinating the first time I heard it. In fact, it’s one of the things that Josh and I spent a bunch of time talking about it when we first met. I think it’s a great way to frame a problem. I’m sad that I didn’t think of it, actually, and the reason is because release engineers think about that all the time. We’ve thought that was our role for 20 to 30 years, for as long as release engineering has been around. It’s this idea of knowing what the dependencies are, dependency management tracking and trying to make sure that you don’t pull in bad dependencies—whether they are tainted because of the license or containing malicious software. This problem has only gotten worse with open-source software, and that’s also something that from a supply chain perspective we talk a lot about.

—

“I told this story about an engineer who was missing a DLL from the build. They just Googled for the DLL and downloaded it, and threw it on all the build machines. That was pretty scary.”

—

That was one of the things that I wouldn’t think keeps release engineers up at night as much as it keeps security engineers up at night. Where is our software coming from, and what issues may it have in it? That’s not something traditionally developers, for whatever reason, seem to think about and that’s not to denigrate them. A lot of times they’re under deadlines, like we are. They go to the internet. They grab whatever version of the library. In fact, the one I usually see is the upgraded version because there’s some API that they need or something like that. There’s a concern there, when you think about it, of where that’s coming from. I told this story about an engineer who was a missing DLL from the build. They just Googled for the DLL and downloaded it, and threw it on all the build machines. That was pretty scary.

One of the slides in the presentation I think is really critical is: “If you have one vulnerable library in your product, that is a security problem. If you’ve got multiple versions of the same library and multiple versions of those are vulnerable, that’s a release engineering problem.” That’s one of the best ways upfront that release engineers can contribute to rugged DevOps and contribute to the security space in terms of helping to detangle that problem. More interestingly, once you’ve detangled that problem, you have to figure out how to make it so that that just doesn’t turn into spaghetti again.

I’ve detangled that problem multiple times usually, by the way, not so much in a security context but in a licensing context.

—

“If you have one vulnerable library in your product, that is a security problem. If you’ve got multiple versions of the same library and multiple versions of those are vulnerable, that’s a release engineering problem.”

—

The way you do that, again, is shifting left. Moving that forward where you have a way that as developers put libraries into the product, new code that isn’t written by them because there’s a dependency there that was well-documented. You can do that audit in kind of a continuous fashion so that maybe an artifact that you build is a list of library conversion. Then from an automated security testing perspective, we can compare that against a list of CD (continuous delivery) use or known issues.

Weeks: I did a lot of research at Sonatype on the software supply chain and one stat boggles my mind. Out of the top 100 components companies were downloading, they downloaded an average of 27 versions of each of those components in a single year. When you think about the complexity and the technical debt, and if there’s security debt in that at all, you only need 100 parts and yet you’re using 2,700 parts. Why would you ever want to do that?

Reed: One thing I’ll point out is that I think the industry’s moving in some sense in the wrong direction. What mean by that is you’ve got your Java you’ve built in this to make it really, really, really easy. From the command line, you just pick up libraries from the internet. Who knows where they came from. Node makes this trivial. In fact, Node was built around npm, the package manager. All of that is online. In fact, it’s even worse. One of the things I get called in to help with a lot these days is—and I kind of giggle at this, just because of the dichotomy—people were so interested in Git for so long because it was like offline Git, offline commit. It’s great, right? You can build offline, and people always use the example of when I’m commuting home on the train, I can commit blah, blah, blah, and that was the big reason for doing it.

Now we’ve moved with Node and some of the tooling around Java so that our software builds literally require us to talk to the internet to download packages. There’s this big push for offline operations. But it’s fine that no download needs 68 billion versions of libraries, and everything is “self-contained.” But if you’re going to look at a Node package, it’s got versions of those things stocked in there. That’s a feature, not a bug. Right? In certain platforms—you see this with RubyGems, when the Ruby Gems site went down, nobody could deploy their web applications. That’s a fundamentally broken engineering design in my opinion. Not that it’s easy for developers to get that. But that our build processes, our deployment processes, rely on those things. And they rely on us as developers to say, “I want version 1.2.4 of that library, and that 1.2.4. is the same version that you use.”

I posted a slide about versioning, and that’s a very release engineering problem. As an example, Open SSL made a mistake in their versioning and instead of bumping the version like they should have, they repackaged binary. I suspect the reason that they did that is because they published all the CVEs (common vulnerabilities and exposures) with that version number and everybody is like a hawk watching Open SSL. So they couldn’t bump the version number easily. Open SSL can’t be flexible in their release engineering anymore because they’ve been so traditionally horrible at it. Right? We’ve made it really easy to stuff all of those components into our products, but we really don’t know what we’re stuffing in there.

If you look at it, we end up worrying about a lot of the same things. I think a lot of the nuts to crack, if you will, in the rugged DevOps community are maybe 50 [percent] to 80 percent release engineering problems. Strengthening that extra feature of security in there, to make that part of it, especially with the supply chain, will work really well.

—

“A lot of the nuts to crack, if you will, in the Rugged DevOps community are maybe 50 [percent] to 80 percent release engineering problems. Strengthening that extra feature of security in there, to make that part of it, especially with the supply chain, will work really well.”

—

Weeks: J. Paul Reed, thank you very much. It was a pleasure talking to you, I really enjoyed the conversation. We’ll look forward to seeing you again soon.

Reed: Awesome. Thank you.

If you loved this interview and are looking for more great stuff on rugged DevOps, I invite you to download this awesome research paper from Amy DeMartine at Forrester, “The Seven Habits of Rugged DevOps.”

As Amy notes, “DevOps practices can only increase speed and quality up to a point without security and risk (S&R) pros’ expertise. Old application security practices hinder speedy releases, and security vulnerabilities represent defects that can leave a company open to cyberattacks. But DevOps practitioners can leap forward with both increased speed and quality by including S&R pros in DevOps feedback loops and including security practices in the automated life cycle. These new practices are called Rugged DevOps.”

July 25, 2016
State of DevOps Report: Reaping Results

The newly released 2016 State of DevOps Report concludes that DevOps is “no longer a mere fad or buzzword,” but rather an established set of practices and cultural patterns. Yet, a closer look at this year’s findings reveals progress is far more substantial than any matters of perception.

The report was conducted and analyzed by the experts of DevOps Research and Assessment (DORA) and sponsored by CA Technologies. Among its findings is proof that high-performing organizations that have embraced agile and DevOps methodologies deeply are outperforming massively those that have not. And the gap is widening.

The State of DevOps Report also shows leading DevOps practitioners are appreciating benefits that span nearly every area of their business. If I know my colleague Gene Kim, he will assert this point exuberantly on our upcoming State of DevOps Report Webcast.

It’s noteworthy that high performers are surpassing incredible milestones related to core elements of the applications life cycle. Examples include deploying code 200 times more frequently than low performers, driving 2,555 times faster lead times, 24 times faster recovery times and producing three times lower change failure rates. This is evidence that DevOps is having the desired outcome on applications delivery, software quality and organizational velocity. It also shows organizations truly committed to wholesale transformation of culture and process are actively succeeding.

At the same time, the State of DevOps Report shows employees working at organizations enjoying this success are more satisfied with their jobs and more closely engaged with their companies. Chalk this up to the halo effect of operating in a fundamentally more sensible, innovative fashion. Cultural change is undoubtedly the greatest hurdle to DevOps advancement. Here’s proof that if you can navigate the process, your workers will be happier and more productive.

Using Employee Net Promoter Score (eNPS) as a barometer, the report finds that employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work. They also were 1.8 times more likely to recommend their team as a great working environment. Previous studies have found that such an air of positivity can be directly correlated with improved business outcomes, researchers noted.

Shifting the manner in which you build applications to better adapt to changing customer expectations is a necessity. That’s what began driving this movement years ago. That said, proof it also makes it easier to keep valued software engineering and IT operations employees should not be overlooked.

In addition to positive conclusions on the impact of continuous delivery and improvement of test data management, the report offers some important metrics related to return on investment. This is nothing short of landmark, as for decades we have struggled to make a hard case for IT investment beyond implied competitive advantage. It actually was impressive that last year’s report highlighted such a “predictive relationship between IT performance and organizational performance.”

One such new measurement of note is that high-performing teams occupy the least amount of time responding to unplanned work and rework—efforts widely recognized to be results of flawed processes. On a related note, DevOps leaders spend 49 percent of their time on new work‚ surely, in many cases, the next “must-have” feature which impacts competitive standing and, ultimately, the bottom line.

This report is fantastic. It reaffirms powerfully that so many of the promises made about DevOps over the last few years are neither hype, nor overstated. The gap between the leaders and laggards is growing. Industry landscapes and business models are being redefined.

This is critical transformational work that every organization must adopt to survive.

Are you on board? Download the full State of DevOps Report here.

June 23, 2016
DevOps Matchmaking: APM + CI = A Perfect Marriage

As anyone who has ever been set up on blind dates by friends can attest, finding the right match in today’s world is a tricky feat.

There’s a lot of evidence suggesting that the frantic pace of life makes such matchmaking more difficult than ever. That said, when the right set of complimentary traits exist and there’s a willingness to find common ground, things can work out.

Spike Jonzian-notions of artificial intelligence aside, certain technological partnerships are increasingly being perceived as “a perfect marriage” within the context of DevOps automation.

Register today for the upcoming webcast: “Using APM to Turbocharge Continuous Integration”

These technological matrimonies closely support the underlying tenets of DevOps methodology—collaboration, experimentation and increased velocity. In fact, it’s easy to wonder why no one ever conjoined them before. But we were using traditional waterfall development and operations and so couldn’t conceive of such a thing. On the other hand, emerging availability of tooling supporting new integrated workflows represents a significant catalyst.

Finding the Perfect Fit

One such DevOps confederation getting a lot of attention is the matchmaking of continuous integration (CI) and application performance management (APM) technologies. Tying together these once-disparate systems makes a lot of sense, despite the fact that few tools would seemingly appeal to more (traditionally) polarized constituencies.

Continuous integration has been a staple of the development community for many years. It emerged as teams evolved the practice of long build times into more frequent check-ins to deliver code and look for potential errors more quickly. Today, with the rise of CI tools such as the Cloudbees Jenkins platform, some development teams are touting tens of thousands of builds per day.

On the other end of the spectrum, squarely on the turf of IT operations, APM has been evolving rapidly over the past few years as organizations have sought to improve use experience and applications reliability via dedicated monitoring. Enabling this ability to identify and address emerging issues has resulted in APM becoming the fastest-growing segment in the IT ops management market, according to Gartner.

DevOps matchmaking factors in when you bring these tools together to create an automated workflow that spans their respective use cases. A cross-functional team can leverage APM-level monitoring and KPIs within the domain of CI and testing to identify potential performance obstacles introduced in new code. Doing so then rather than waiting to respond later in the applications life cycle benefits everyone.

Reaping the Benefits

For example, say an e-commerce applications developer has implemented a new inventory search functionality—something considered a key differentiator by business management. The developer knows this feature could rely heavily on some back-end database system and wants to ensure it’s tested properly, even as the code is being introduced.

Integrating APM and CI allows the entire team to monitor the process and test various conditions related to the update, tracking multiple builds and looking out for related performance issues. Such integration also allows for centralized tracking of other key attributes such as build number, status and build date, to further ease management.

Most importantly, by tying these two critical aspects of the applications delivery life cycle together, the collaboration and feedback loops required to truly embrace DevOps methodology become ever more valuable as these core Dev and Ops functions become intrinsically linked.

If this type of DevOps advancement gets your heart pumping, you’re not alone. Later this month, we’ll host a webcast here on devopsy.kinsta.cloud featuring experts from CA Technologies and Cloudbees. They’ll be discussing the benefits of matchmaking with APM + CI integration. They’ll also detail real-world benefits organizations leveraging integration of our respective technologies (CA APM and Cloudbees Jenkins) enjoy.

We obviously feel that this is a DevOps tooling marriage that will mature, change and stand the test of time. We’d love to garner your questions and feedback on the topic.

Which is all good, because thankfully there’s no such thing as Tinder for DevOps … yet.

June 21, 2016
Rep Spotlight: Global Lynx

DevOps Institute: Tell us a little about your organization:

Global Lynx: Global Lynx is a leading and fast-growing IT consulting and training company that assists companies and government agencies improve the competence and skills of their IT organization, enhance the maturity of their IT governance and improve the quality and effectiveness of their IT operations, services and processes.

Since 1996, Global Lynx experts have helped organizations in five different countries, improving—and often transforming—their IT operations through the implementation of effective frameworks for IT governance, ITSM (IT services management), PMO (project management office) and information security.

As an Accredited Training Organization (ATO), Global Lynx also offers a wide variety of IT courseware covering different areas, standards, frameworks and methodologies, and at various levels of expertise.

Global Lynx trainers are experienced consultants, certified in multiple IT disciplines. They have actual firsthand experience in their areas of IT expertise, as well as experience in delivering training programs.

DOI: What other topics do you teach or consult on?

Global Lynx: IT service management, IT corporate governance, IT audit, information security, cyber resilience, IT risk management, cloud computing, project management, SCRUM, business continuity, process design and implementation, and enterprise value creation.

DOI: What type of interest in DevOps are you seeing in your region?

Global Lynx: Companies are interested in obtaining a common understanding of DevOps concepts and best practices, and they are focusing on deploying these practices organization-wide.

DOI: How do you think that DevOps contributes to the business’s value stream?

Global Lynx: The digital disruption all industries are experiencing, has created the need for IT to be embedded in every single business unit. Solid DevOps practices will help IT organizations deliver higher value to their customers, as value is delivered through operations, but it is defined and enabled in the development stages. Value should be managed not only in operations, but rather from the early stages of the service life cycle. A mature IT organization cannot have a poor collaboration and communication culture; without this, value creation will be limited to technical value instead of real business value.

DOI: What topic area in DevOps excites you the most?

Global Lynx: How DevOps interfaces other frameworks and how all of them can work together toward creating value to the customer.

DOI: Why should enterprises and individuals consider formal DevOps training?

Global Lynx: DevOps is all about people, and it is enabled by people. If a person is not committed, that person will do little to support the DevOps initiative. People need to go through formal DevOps training to learn what DevOps is, and how their role impacts the initiative and how they contribute to value creation. Certification is a plus, as it gives people a personal benefit. People will naturally react positively to something they own, because they will believe in it.

June 3, 2016
What is a DevOps ‘Best Practice’?
In IT, we love our frameworks. Whether agile, ITIL, lean, cobit, six sigma or others, our thirst for “best practice” guidance seems to be unquenchable.

The concept of a “best practice” is an enigma. Who decides if a practice is actually the best? And best for whom? While an “adopt and adapt” mentality is advocated in most frameworks, there is still a tendency to benchmark efforts against and conform to published best practices. Whether promoting “best in breed,” “world-class,” or “best practices,” many organizations swing these terms around as some form of competitive advantage.

Is it really? Shouldn’t business outcomes be the real competitive advantage and measure whether IT’s practices are really the “best” to meet customer requirements?

The DevOps Institute was founded in 2015 as a global learning community for emerging DevOps practices. Since our launch, we have intentionally avoided any reference to DevOps “best practices.”

We believe that DevOps practices are constantly emerging and, in many cases, being proven in the wild.

Through research, interviews, conferences and the experience of our Regents and partners, DOI’s goal is to identify, capture and share emerging DevOps practices through knowledge, education and certification models that best serve the learning community and enterprise IT. We feel it is premature to certify an individual as an “Expert” or “Master” when the expertise and mastery needed for successful DevOps is not clear and may not be appropriate in a single person.

DevOps is fairly young. It does not have a single body of knowledge. There is disagreement on whether it is a philosophy, movement or framework. Despite that, DevOps is crossing the chasm from innovators to the early majority faster than any other IT framework. Why? Perhaps it is because DevOps speaks to many of the cultural and technical challenges that IT has been amassing for years.

So instead of focusing on best practices, let’s agree on DevOps’ core principles:
- Go faster
- Shorten feedback loops
- Experiment and learn
- Cultural transformation
- Deliver business and customer value constantly and consistently
No doubt, some practices have clearly risen as being critical to the realization of DevOps’ core principles:
- Agile software development
- Continuous integration
- Continuous delivery pipelines
- Automated and continuous testing
- Proactive monitoring
- Improved communication and collaboration
Still, over the past year, DOI has seen additional practices gain interest
- DevSecOps/rugged DevOps
- ChatOps
- Agile service management
- Lean
- Immersion practices (Garage, Lofts, Dojos)
- DevOps teams
What will emerge next year? Who knows—but that’s the exciting part of DevOps. As time passes, there is less contradiction and more supplementation. Each emerging practice seems to complement and fine tune what came before.

Even without a standard definition, DevOps is already encouraging organizations to examine their proprietary practices, identify gaps, assess their automation and, most importantly, engage in collaborative discussions. Transformations have taken seed without defined best practices. That’s awesome! Let’s not quell the momentum by attaching a static set of best practices.

Will DevOps’ best practices eventually be agreed? Maybe. DevOps touches almost every aspect of IT management—people, practices and automation. That’s a tall order for a set best practices. Certainly some will try to publish their version of a “definitive” DevOps body of knowledge. Even “The DevOps Handbook,” an important book publishing later this year, was built as a collaborative effort between many of the early founders of the DevOps movement. Their perspective and insight will be awesome but not finite.

I understand the frustration by the lack of a single body of knowledge and prescribed best practices. In past frameworks, the body of knowledge was both a enabling tool and constraining limitation. Bodies of knowledge are difficult to keep current. For DevOps, let’s embrace the concepts of spirit of sharing, collaboration and continuous innovation by promoting an inclusive and collective body of knowledge of emerging practices.

If we settle on a set of DevOps best practices, are we actually inhibiting the very values that we are trying to instill? I hope not.
May 27, 2016
Tales of DevOps Discovery Part 2: Definitions Matter
Definitions Matter: Step Two in a DevOps Transformation

The first post in this series on DevOps Discovery discussed the importance of asking fundamental questions of stakeholders to facilitate alignment on priorities and establish a mission statement when beginning a DevOps transformation. Part 2, below, reviews definitions of common DevOps-related terms and provides examples of how failure to agree on such terms can hinder your transformation.

The industry is full of terms such as continuous integration, agile, continuous delivery, DevOps, etc. The practices described by these terms often are defined differently by various industry “experts,” resulting in stakeholders in the software delivery process having different understandings of what constitutes these practices. Some will state they are already following the practices; others will state they do not. Some will believe the objectives unachievable, while others will be bullish on the prospects; differing interpretations blocking agreement on the organization’s current and target states. If stakeholders cannot agree on the current state (or the start point) and the target state (or the destination), it is impossible to “map a route” for the journey to DevOps.

For example, let’s look at how some define continuous delivery:

Continuous Delivery – Definition 1:

A software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing and releasing software faster and more frequently.

The approach helps reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

Source: Wikipedia

Continuous Delivery – Definition 2:

Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

[Continuous Delivery Blog Post by Martin Fowler]

You may read the above and initially think there is no difference in the definitions but, note that the first definition addresses deployment of software with the statement: “A straightforward and repeatable deployment process is important for continuous delivery,” whereas the second definition addresses deployment of software with the statement: “Build software in such a way that the software can be released to production at any time.”

This distinction may seem trivial, but it is the often the source of confusion between the practices of continuous delivery and the practice that is commonly called continuous deployment. In contrast to continuous delivery, which states that every software build “could be released,” continuous deployment is loosely defined as “the practice of releasing every good build to users.”

When establishing your target state for the DevOps transformation a seemly slight confusion such as this can result in pushback from stakeholders concerned that continuous deployment is unachievable or too disruptive. These sentiments include:
- Business: “We cannot gather, spec and track our requirements at that rate.”
- Operations: “There is no way we can support daily delivery into production, ensure security, uptimes and perform our day-to-day work. It takes us an entire weekend and multiple attempts to deploy today.”
- Customers: “Our compliance team needs three months to review and approve every new version of our accounting system.”
The confusion and potential pushback exemplify the need for establishing baseline definitions and alignment at the start of a DevOps transformation, and doing so in the specific context of your organization. The importance of points such as how far it deploys varies with the organization—some organizations can support continuous deployment to production multiple times a week or even multiple times a day, such as Netflix does. Other organizations, such as providers of critical financial systems, may never pursue this cadence of deployment. Be sure to apply these industry practices pragmatically as fit for your organization, not dogmatically based on generic industry definitions.

Let’s look at a couple of definitions of DevOps:

DevOps – Definition 1:

“DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between Development and IT Operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between the two business units.”

[Webopedia]

DevOps Definition 2:

“DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.”

[Wikipedia]

Like the example with continuous delivery, these two definitions also are very close. Yet on detailed observation, it is clear the first definition describes DevOps as being focused on relationships (i.e., culture and collaboration). The second definition extends this to include the “automating the process of software delivery and infrastructure changes,” giving consideration to tools and technical practices such as continuous delivery.

Does this matter? Yes. Often if the executive sponsors and key stakeholders do not account for the need to establish tools and technical practices and only focus on relationships, there is a high chance for unrealistic expectations for timeline, budgets and results. Conversely, if the need for changes in culture and process are not considered and the DevOps transformation focuses only on tools and technical practices, the efforts are also unlikely to yield the expected results. A DevOps transformation must account for the trinity of “People, Process and Tools.”

When considering DevOps, it objectives and the objective of its component practices it is useful to establish a clear idea of the relationships between theses practices. It is often useful to visualize them as below:

The DevOps Transformation Triangle

DevOps is the “What,” the target state as defined by a set of guiding principles. Agile development, continuous integration and continuous delivery are the “How,” a collection of process, practices and tools that together build the foundation for a sustainable DevOps implementation.

In the next section, we will review some of the initial discovery questions asked when beginning on a DevOps transformation, provide real-world examples of answers from various stakeholders in real organizations, and analyze those answer to better understand the journey to DevOps.
May 27, 2016
State of DevOps Survey – The Ultimate Feedback Loop

If there’s any consistent criticism of the larger DevOps movement, it’s that the talking heads and industry gadflies are driving the conversation, not the people in the trenches.

All the thought leadership panels and “how-to” content (including the written and AV materials on this very site) make for great watercooler discussion, but lack the input of those dev, ops and IT management pros who are actually living the DevOps experience, some critics have said.

Well, fair enough. Talking heads are paid to talk. Thought leaders are chosen to lead the debate at conferences and on webcasts. Bloggers blog. Reporters report. This is simply the way of the world. Certain voices are heard via the channels they frequent. It is, as so many people are fond of saying these days, what it is.

So what about everyone else? What of the people reading this stunning prose and listening to these talks while rolling their eyes based on the connectivity of it all to their real-world experience? How can their voices be heard?

Independent of jumping into the blogsphere or applying to speak at said industry events – which you should, btw – there’s one significant opportunity available to anyone who cares to take the time – participating in industry research.

Over the next few business days, citizens of the DevOps world will have their last chance to contribute to the industry’s most widely read and respected research project, the State of DevOps Report.

If you haven’t done so already, take the time to fill out this year’s survey, and make sure that your voice is heard when the subsequent report is published in June. Sure, it takes a little time, about 15-20 minutes; but that’s because it goes to the trouble of exploring the real-world issues that weigh most heavily on today’s practitioners.

Why is this particular project so important, or even credible? Consider that the minds behind the survey and analysis resulting in the 2016 State of DevOps Report are those authors and talking heads that actually get the most respect.

Backed by DevOps Research and Assessments (DORA), the independent think tank operated by a partnership of Jez Humble, Gene Kim, and Nicole Forsgren – perhaps the most respected voices on the landscape, along with Nigel Kersten, the project is categorically aimed at surfacing the truth about DevOps adoption today – not merely promoting the interests of vendor sponsors.

Like previous iterations of the report, the 2016 edition will focus on topics including IT performance, technical practices, culture, lean management, and organizational performance. This year’s survey also examines several new areas, including the ROI of IT performance, security and compliance, and containers.

To further entice participation, project leaders are also offering free tickets to the DevOps Enterprise Summit, along with forthcoming books from some of the industry’s leading advocates to a lucky few who take the time to get involved.

DevOps success is fundamentally based on the notion of increased collaboration and continuous feedback among the people scattered across the SDLC. Likewise, the legitimacy of this research project is utterly dependent on the input of as many real-world practitioners as possible.

If you’re one of those individuals, and you really care whether or not everyone else involved in the advancement of DevOps understands what this all means to you, do yourself a favor and participate.

Much like an application being built using DevOps practices, this quality of this project will be directly determined by the degree to which anyone with insight is willing to get involved and build toward optimal results.

Take the 2016 State of DevOps Survey… today!

April 15, 2016