devopsy.kinsta.cloud

Tag: devops

Digital Business: Paving the Way for DevOps’ Second Act

DevOps is the buzzword of the moment. It’s at the heart of every strategy—not just CIOs’ IT transformation strategies but also IT vendors’ sales and marketing strategies. The question business unit leaders always ask is, “Is DevOps to improve IT or to boost the business?”

The disconnect is so big between the concerns of today’s DevOps practitioners and business unit expectations on one side and digital competitive challenges on the other that the question is worth asking. Indeed, the proliferation of tech startups and digital services is making competition tougher and forcing business unit leaders to adopt innovation, velocity and timely revenue as their top competitive advantages, helping them to survive their industry disruption and then boost their digital growth.

Let’s say it straight: The many DevOps and even cloud migration projects out there aren’t likely to help business units effectively address the digital economy’s challenges. Automating your application deployment processes with infrastructure as code and continuous delivery infrastructure on their own will never make your company an innovation champion or equip it with the fastest time-to-value in the world. That erroneous belief is nurtured within the IT community; it’s the tangible proof that IT still doesn’t understand the business. Period.

Joe McKendrick, in his fantastic, “The Elusive Mystique of the Digital Enterprise,” and, “Cloud Computing’s Second Act is All Business,” offers insights likely to help business unit leaders remind their CIOs the business reality, “What matters is revenue.” IT innovation for the sake of innovation doesn’t make sense. And Adam Jacob, co-founder and CTO of IT automation company Chef, in a fantastic article, “The Secret of DevOps: It’s Always Been About People, Not Technology,” gives a DevOps vision that’s totally in line with business unit expectations more importantly to more effectively address digital competitive challenges.

Adam Jacob’s System of Thought: The Foundations of DevOps’ Second Act

Adam Jacob defines DevOps as:

Fundamentally being about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.

He adds:

Notice that I don’t mention technology, which may be surprising coming from the CTO of a DevOps-focused company.

He concludes:

Tools matter. But tools exist in service of the prime directive: building highly functioning, highly effective cross-functional teams, that attack your thorniest business problems as a unit, rather than as lone individuals or silos with competing incentives.

This perspective of DevOps unveils an authentic business thinking for IT that I turned into a digital business approach:

It’s represented through the above virtuous circle of principles structured around customer:

Customer is the source of digital wealth: This expresses the proven belief that being customer-focused increases service quality, keeps customers loyal and, in turn, increases his value of the money they spend to buy services. It prevents customer churn caused by changing consumption habits, whereby digital services are increasingly preferred to traditional services.

People make, create and innovate: This principle translates the proven idea that giving staff skills, resources, authority, opportunity, motivation, and holding them responsible and accountable for outcomes of their actions, will contribute to their qualification and satisfaction and ultimately make them committed to the organization’s wealth. It creates work environments and work styles conducive to innovation.

Behaviors and beliefs strengthen involvement and commitment: This principle highlights the demonstrated notion that sharing common beliefs, principles and values creates team spirit, which increases cross-functional collaboration and, in turn, accelerates problem-solving and decision-making. It contributes to the business agility.

Product is the digital wealth driver: It’s the now-acknowledged idea that to succeed in the rising digital economy, businesses must align their application delivery approach to the new product development (NPD) principles. Applications take value to customers. It helps to keep up with the fast-paced digital business environment.

Velocity makes the business responsive to market opportunities: It’s the widely adopted notion that time-to-value is the essential revenue driver that will make businesses digitally wealthy. That principle is enabled by the continuous delivery infrastructure which automates—therefore accelerates—the application delivery processes chain.

This unprecedented vision, dominant on the business side, contrasts with the technocentric approach promoted by the vast majority of IT vendors to increase their sales.

Being honest to customers is telling them this: Implementing continuous delivery infrastructure is not implementing DevOps. It will never, on its own, make the business digitally competitive.

I have no doubt that you’re convinced Adam Jacob, Joe McKendrick and even Ernest Mueller, author of “DevOps: It’s Not Chef and Puppet” are definitely right. The question you might be asking now, which may be provocative is, “Okay, that’s good! How do you implement all that?”

Implementing DevOps’ Second Act Foundations into a Digital Business Capability

The first step toward implementing DevOps is to admit that a new IT paradigm is needed, Adam articulates it that way:

Leaders need to realize that implementing DevOps means changing the technology system as well as the cultural system. They must acknowledge that both are intertwined and, to be successful, both systems must evolve to drive velocity.

It’s not different from the two-dimension IT advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps” and in my online contents, “Become Digitally Savvy in Just Hours. Boost Your Digital Revenue Now“:

DevOps implementation is based on four principles that determines successful business transformation:

Concerns have shifted from technology efficiency to business agility: Forget the outdated idea that IT tools on their own can help your business units succeed. What will make them digitally successful is the combination of technology efficiency and organizational flexibility and agility.

See IT as a two-dimension asset: To win legitimacy among business units, offer a two-dimension vision of IT including the value stream and the continuous delivery infrastructure. Value stream is where value is created and the continuous delivery infrastructure is what enables business agility.

The value stream is where the innovation and agility cultures are built: Transform your business organizational structure into an agile value stream through deploying agile practices and methodologies such as Scrum, Kanban and Exteme programming.

The CD infrastructure is where fast time-to-value is enabled: Automate your applications delivery processes into an accelerated applications delivery chain using automation and continuous delivery tools such as Chef Automation, AWS CodePipeline and Apprenda.

Summing It Up

Experienced DevOps Strategists know that DevOps is the means to an end, and not the end itself. DevOps is an enabler to one or a combination of these business competitive advantages: short time-to-value, market responsiveness, innovation culture and many more.

All the noise surrounding the so-called DevOps tools has to do with technology business—making money through selling IT tools—and absolutely not DevOps.

DevOps isn’t a tool, it’s an IT approach stressing business competitiveness: shorter time-to-value, market responsiveness and innovation.

— Philippe Abdoulaye

January 31, 2017
Culture Comes First in Bringing DevOps to the Mainframe
One of the most difficult challenges in engineering, oddly enough, isn’t technical: the challenge is culture transition management. In my 20-plus years of managing engineering teams worldwide, I’ve led teams through countless organizational adjustments and process improvements toward high-performance and quality, beginning with QA segregation to CMMI to ITIL, AGILE and SAFe.

Today, mainframe organizations have emerged as the focal point for enabling DevOps capabilities and practices. Why the mainframe? Well for starters, business critical applications rely on mainframe data and business components. These applications are mission-essential and that sustained innovation requires solution sets that deliver continuous testing, continuous delivery and continuous feedback on the mainframe platform.

But culture comes first.

Understanding Your Key Players

In conversations with our customers we’ve observed an interesting dynamic emerging within mainframe application development teams. Within these teams are experienced developers who were instrumental in creating the applications that helped make their companies so successful. Over time, many have become set in their ways, adopting a motto of, “If it’s not broken, why fix it?” Such developers are not interested in trying out new things, including programming languages and tools used by the modern-day programmer.

New to the scene are the millennials who have also taken up the mantle of enterprise software engineer. They are a bit more open-minded and bring a different programming language profile, including Java, .NET and C. These developers might be learning how to code APIs with the support of management, and have likely dabbled the basics of how to code iOS apps. Millennial developers are typically much more active online and, as a result, prefer to leverage Twitter and other social channels to stay informed with the development community.

United We Stand

Who, then, should be involved in the journey to realizing DevOps? The answer, of course, is both. Because we’ve heard it reinforced among our users we talk with in the CA Communities every day, at user groups and at prominent mainframe community events such as CA World and SHARE.

You know it, because you probably see it in your organization as well. There are experienced developers: people who have deep knowledge of the applications in place, business intelligence, database tables, cross-application dependencies, batch execution windows and the general experience of how things work on the z/OS platform.

Most importantly, they also know how to avoid breaking what’s working.

And there are the millennial developers: people who are curious to learn about new programming languages, platforms, people who, with the advent of Agile development, and open source have played with things, tested them and are using it to enhance their skill sets.

These people prefer to use modern user interfaces and tools to increase their productivity. Sometimes they might be tentative about making mainframe changes, not willing to risk their careers by breaking poorly documented code.

Culture – Have it Both Ways

While the interests of millennial and experienced developers may at times seem conflicting, both have pivotal roles to play in application development and will benefit greatly from the common sense practices of DevOps and agility that are coming to the mainframe platform. To survive and thrive, teams must unify to facilitate the change process. Most importantly:
- Code must be accessed and modernized at the speed of business. Enterprise developers, testers and architects cannot be afraid to go talk to the “black box” that is the mainframe team.
- Project managers can’t worry that a six-week turnaround for small changes will kill their hopes of meeting their delivery windows.
- The delivery team—QA, release management and operations—can’t afford to sit around waiting for simple deployment steps to happen: when we can automate and integrate to increase deployment frequency.
The promise of DevOps and agility on the mainframe is to fix this, and that’s why our engineering teams are actively building out solution sets that extend DevOps practices to the mainframe, including continuous testing, continuous delivery and continuous feedback.

Curious about what it will take to bring DevOps to the mainframe? Catch some tips and best practices from Forrester Research principal analyst Rob Stroud, or hear from the leaders driving change in their organization in our CA World 2016 Mainframe DevOps panel.

— Aline Gerew
January 31, 2017
Automation Killed QA – It’s Time to Deal With It

Quality assurance (QA) had a good run.

From the time it was considered an afterthought by organizations and software vendors alike to the era of massive outsourcing contracts, followed by significant vendor investments in related tooling, and, finally, its recognition as a critical success factor among high-performing organizations, quality has evolved to become even more important than functionality to end users.

Customer experience, today, is defined by speed and quality above all else. Namely, can I access the information and products that I want in the blink of an eye and get expected feedback based on input? As a result, customer experience has also shifted: It’s all about application experience, not the friendliness of a checkout cashier or sales/service rep.

With this massive shift toward customer experience platforms (think omni-channel) and increasingly lofty expectations, the operative question becomes, How are we enabling velocity in our testing practices to ensure the highest quality while keeping up?

We’ve tried everything from outsourcing to insourcing, investing in tooling, investing in people and even building testing architecture teams to oversee the automation, quality and consistency of testing results. Roughly seven years ago, my top priority for testing teams was to automate 30 percent of our tests. Today, if you are not 100 percent automated, or close to it, you are severely lagging in output.

But what’s next? What if I’ve automated all of my tests and my manual testers have been replaced with automation engineers, but I’m still having quality issues and being perceived as a bottleneck?

The answer is simple. Automate everything.

Makes sense, right? Isn’t everyone telling you that? But what are we defining as “everything” from a testing perspective? Therein lies the problem; we are thinking about testing as its own factory within the larger software development life cycle.

While we believe we are changing this perception by going agile and moving most QA functions into scrum teams, the reality is we still look at testing as a standalone function. Centralized or decentralized, this is the case, and we need to think differently.

Automating for quality begins with defining requirements. How am I ensuring that I’m covering all cases? How do I ensure I’m translating the business requirements properly? These questions, the time it takes to answer them and the risk of human miscalculation all impact quality and velocity.

We must start our automation for quality at the beginning, during establishment of business requirements.

Let me introduce you to next-generation QA. Intelligent “continuous testing” platforms are replacing humans for testing, automating tests, creating data and building test cases. These platforms are able to translate model-based business requirements into complete automation—test cases, test data and test script automation.

Orchestration across your software development life cycle creates your environments, lays down your test data, deploys your software, runs your test scripts and reports results. No more human error, no costly resources and guaranteed test coverage that ensures quality.

Integrating your existing automation around continuous integration, portfolio management reporting, and execution reporting to this framework now gives you the ability to report and automate your ideas all the way through to outcomes.

Early adopters are already doing this. QA as a functional organization is gone. If you aren’t already automating to this end, you are severely behind.

Questions? Comments? Perspective? Have at it in the comments below.

— Ron DeCanio

January 27, 2017
AppDynamics Buy Expands Cisco’s DevOps Agenda

AppDynamics’ $3.7 billion acquisition by Cisco Systems has two major implications for the DevOps space. On a tactical level, Cisco has committed to distributing AppDynamics’ agent software everywhere from the public cloud to individual devices connected to the Internet of Things (IoT) and in between. On a more strategic level, the company is positioning itself to be able to uniquely correlate IT operations data generated by applications and IT infrastructure to give organizations comprehensive visibility into their entire DevOps environments.

During a briefing with analysts and the media this week, Rowan Trollope, senior vice president and general manager of Cisco’s IoT and Applications Business Group, described how his company sees AppDynamics as a linchpin acquisition that propels the company well beyond its well-established networking and server infrastructure base. After the merger is completed, expected sometime in the third quarter, AppDynamics will continue to operate as an independent business unit within the IoT and Applications group, and current AppDynamics CEO David Wadhani will report to Trollope.

Trollope described AppDynamics as a complement to Cisco’s ongoing efforts to drive more recurring revenue. The company, which offers an application monitoring service delivered via the cloud, was poised to shortly go public prior to being scooped up by Cisco. AppDynamics is employed mainly by IT organizations to monitor applications running on public clouds. But Wadhani noted one of the fastest-growing segments of AppDynamics’ business is monitoring applications running in private clouds.

The data AppDynamics gathers in those environments can be correlated against, for example, the data Cisco collects via its Tetration analytics application, which the company launched last year. That capability, Trollope said, will significantly increase the total Cisco value proposition.

In fact, as hybrid cloud computing scenarios based on microservices and containers become more common, Wadhani noted that monitoring of complex applications running in production across multiple clouds will become a more crucial requirement. AppDynamics recently extended its monitoring service to include support for containers deployed in these environments.

Under the leadership of CEO Chuck Robbins, extending Cisco’s reach across the enterprise has become a high priority. Cisco recently abandoned a cloud interoperability service strategy. But its acquisition of AppDynamics suggests the company is shifting its focus to higher-margin software that generates recurring revenues across multi-year contracts.

Following the acquisition, Trollope said Cisco also plans to take advantage of its existing relationships with senior business and IT leaders to advance a vision of DevOps that provides organizations with visibility all the way down to how each customer engages with their IT resources. The issue Cisco needs to navigate is the degree to which those senior executives actually exercise control over DevOps. To date, DevOps has been more of initiative led by developers and IT operations staff than mandates from senior executives.

Wadhani said Cisco’s direct and indirect sales staff should significantly expand the number of organizations that are exposed to AppDynamics services. That means one way or another, DevOps is about to become a much broader discussion across the enterprise.

— Mike Vizard

January 26, 2017
Strategies to Build Trust in DevOps
I’ve been a member of the DevOps community a long time (literally since before it was ever even called “DevOps”). I was a pre-publication reviewer for both “The Phoenix Project” and the recently published “The DevOps Handbook,” and I’m always interested in seeing the outcomes successes software teams have and the failures they overcome, including trust.

While DevOps has proven to be effective in organizations of all sizes—startups and enterprises alike—there are still many who have not yet begun their DevOps journey, so I thought I might share some of my own experiences while introducing DevOps into an enterprise IT group.

When I was the VP of Operations at Big Fish Games, I had the responsibility for production operations at Big Fish’s three production data centers in Seattle, Virginia and Luxembourg. I also had responsibility for internal corporate IT and information security. Our production operations supported around a million game downloads per day. Games were localized into 11 different languages. We processed essentially every major currency, and right before I left Big Fish, we started taking Bitcoin as well. From an IT perspective, Big Fish Games was a global eCommerce company selling digital widgets on the internet. We had around 800 employees in our five offices in Seattle, Ireland, Oakland, Luxembourg and Vancouver, BC.

My first attempt to introduce DevOps at Big Fish failed miserably due to cultural misunderstandings and a fundamental lack of trust between the development and operations teams.

You absolutely need some minimum baseline level of trust in your organization if you are to have any chance at implementing DevOps. Trust is important because you are blurring traditional boundaries between development and operations responsibilities. Including development in production operations can be scary for operations teams. It just feels wrong from a historical ITIL-type perspective, and operations teams may know development as “the people who always break things.” At the same time, it can be scary for development to involve operations in the development process because they may know operations as “the team that always says ‘No.’”

Building Trust

Successfully merging the priorities and goals of development and operations teams to create one cohesive DevOps effort can fail due to cultural misunderstandings and, oftentimes, a fundamental lack of trust. I used three specific strategies to overcome these challenges.

Lose the Term ‘DevOps’

At Big Fish Games, application development teams equated DevOps with developers carrying pagers: an idea that they really did not like. They were highly resistant to this. Every time I brought up DevOps, they thought I was engaged in a secret plot to make the developers carry pagers. What I found interesting about this was that I had no intention of asking developers to carry pagers.

The term “DevOps” covers a large range of continuous improvement techniques. Some organizations have developers carry pagers, and it works for them, but this is certainly not a prerequisite for DevOps. What was worse, I had no idea they were thinking this because they were afraid to bring it up for discussion. We failed in our first attempts to implement DevOps because the trust level between development and operations teams was so low that we couldn’t even tell each other what we were thinking.

I realized two things from this experience:
- Getting rid of a term that scared both development and operations teams would eliminate an unnecessary distraction preventing these teams from coming together to focus on common goals.
- We needed to do something about the trust issues between development and operations before we could succeed with DevOps.
Once I realized this, I immediately stopped using the word “DevOps.” Instead, I talked about continuous improvement and specific continuous improvement methodologies that we wanted to implement, and how these new adoptions would result in shared, organizational-wide growth.

Focus on Methods That Benefit Other Teams

When deciding which of these DevOps, a.k.a. “continuous improvement,” techniques we wanted to implement, I specifically chose ones that would benefit development teams as opposed to ones benefiting operations or other teams. The development teams noticed this over time. They could see I was doing this and that I (the person who ran operations) was going out of my way to help them. This helped build trust. This wasn’t a one-time thing. We did this consistently.

Here’s another simple failure example: I noticed while managing release efforts that release schedules for the various development teams ranged from a couple weeks to a couple months—too long for a hyper-competitive industry like gaming. I asked the development teams if they would like our release engineering team to support daily code releases or even multiple code releases per day. I thought this was an innocuous question. In fact, I thought I was being a little clever by playing dumb here. I assumed I would get an enthusiastic high-five along with a, “Yes, we’d love that! How soon can you make that happen?!”

I was surprised when I received a violent “No! We don’t want that!” This confused me for a while until I realized that the development team thought I was in cahoots with the product management team to put the squeeze on them. In my mind, I was offering to make their release process more lightweight so they could break up their work into smaller, more frequent releases with less stress for everyone, but I didn’t understand their fears and problems. I wasn’t looking at it from their perspective and here was the trust issue rearing up again. They misinterpreted my intentions as nefarious.

I pictured them being able to release code whenever they want, which seemed like something they would like. In their minds, they pictured a product manager constantly randomizing them with demands for new features to be released right there while the product manager was leaning over their shoulder. This was not the kind of problem you could resolve with logic. The solutions and working procedures I was proposing were so far outside the development team’s experience that they couldn’t extrapolate through simple logic from their current state to the world I was describing.

Maximize Daily Interactions Between Development and Operations Teams

It’s easy to distrust someone you don’t know personally or you don’t have to see every day. It’s a lot more difficult to hate on someone you know and work with on a daily basis.

One of the DevOps techniques that I implemented early on was embedding a dedicated operations liaison into each development team. This liaison acted as an advocate for that development team back into operations and they helped smaller development teams navigate their work through a large, complex, centralized operations organization. The operations liaison attended daily development team standups, group meetings and project meetings. This program was a huge success. Development teams saw how their operations liaison helped expedite their work through the operations organization and advocated for their development team’s interests inside operations.

After the development teams got used to working with their operations liaison on a daily basis, we pushed a bit farther and got the development teams to agree to include operations in architectural discussions at the beginning of application design. At first, our development teams were skeptical that operations could provide useful input here, but the important thing is we had developed enough mutual trust that they were not fearful of including operations in the discussions. They were skeptical that we would add any value, but they weren’t afraid that we would cause them problems. This was a big win.

Although it felt a little weird to our development teams to include operations in design discussions, they quickly saw how obtaining input from operations early on, before a product was built, resulted in better quality and fewer headaches for everyone when we launched into production. I also made sure that we put our most senior and diplomatic operations team members into this role.

In conclusion, it is worth repeating that trust is a prerequisite for any organization to succeed with DevOps. This is due not only to problems arising from fuzzy definitions of what DevOps is and is not, but also the seemingly dangerous idea of blurring the boundaries between development and operations organizations. Whatever your definition of DevOps is, fostering an increased level of trust between development and operations teams as a prerequisite for your DevOps journey will ensure that even greater trust—and the positive business impact that comes with it—are your outcomes as well.

Good luck!

About the Author / Paul Farrall

Paul Farrall is the VP of Operations for Skytap. He was most recently vice president of Operations at Big Fish Games where he led the rollout of global infrastructure for the Big Fish cloud gaming platform and implementation of the Big Fish DevOps program. Prior to Big Fish, Paul was the Director of Operations and Chief Information Security Officer at Intelius, a Bellevue e-commerce company. Previous companies also include AT&T Wireless in Bothell, Washington, and GetThere.com in Palo Alto, California (now Sabre). Connect with him on LinkedIn and Twitter.
January 26, 2017
Increasing Your ‘Bionic Footprint’ with DevOps

“The Six Million Dollar Man” was a 1970s TV series. In the show, NASA astronaut Colonel Steve Austin is severely injured in a crash and is “rebuilt” with bionic features that enhance his strength, speed and vision beyond normal human capabilities. The main tagline was, “We can rebuild him, we have the technology.”

I recently was watching an old episode and it got me thinking about how the show is analogous to the genesis of DevOps—specifically, how individuals with an operations background have to “rebuild themselves” to keep up with the speed and direction of the technology industry.

Over the years, there have been several decrees of “Unix SysAdmins are going away.” I have always firmly disagreed with that assertion. Rather, I believe that SysAdmins have to continually evolve their engineering skills to stay relevant and, more importantly, gainfully employed. It was also becoming increasingly apparent that the manual tasks of deploying infrastructure, keeping it patched, monitoring and the myriad other things a SysAdmin performs every day could not keep up with the demands of the increasing pace of the digital world and the onset of cloud computing. Infrastructure is moving rapidly to being automated and programmatically deployed and the talent needs to adjust accordingly to stay relevant.

With many enterprises adopting the agile methodology and moving toward a continuous integration/continuous delivery (CI/CD) pipeline, the culture of DevOps became a reality. Due to the increased velocity, there became a clear need for the core tenets of DevOps culture, which include culture, automation, measurement and sharing (CAMS). In Six Million Dollar Man terms, this was simply “Better … Stronger … Faster.”

Embracing DevOps through CAMS is similar to the superhuman enhancements that composed the rebuild of Steve Austin, which took him from man to bionic man. Here are the four ways that DevOps can increase your enterprise’s “bionic footprint”:

Improve Culture

Even Austin’s bionic features only got him so far; the bionic man had to rely on his team to complete his dangerous missions unscathed. The same is true in the enterprise: Building a collaborative culture is crucial for success. Culture is paramount in maintaining overall velocity without adversely affecting quality. Developers and operations teams need to function in concert to ensure a resilient application and infrastructure.

Increase Velocity via Automation

Automation greatly increases velocity, akin to how Austin’s bionic legs allowed him to run at high speeds and make great leaps. Automating processes saves time, money and lets your team focus on more complex tasks—a win-win for productivity gains.

Measurement

Steve Austin had a bionic left eye that enabled him to see in the dark as well as detect heat. This provided him precise measurements of his surroundings in any situation, enabling him to gain the upper hand against adversaries. Similarly, measurement gives insight into all aspects of the software development life cycle, application performance and other key metrics. Without insight and transparency into measurement, your team is essentially working blind.

Sharing

Austin had a bionic right arm that had the strength equivalent of a bulldozer. Strength and resiliency are increased by teams that work and communicate effectively made possible by DevOps.

To summarize, I strongly believe that the mantra of “Better … Stronger … Faster” should be that of every DevOps team moving forward. DevOps’ parallel of CAMS upgrades your team’s capabilities to perform more productively. There is no end game; the objective is about continuous improvement, velocity and sustainable growth. Enterprises that want to undergo digital transformation need to adopt this cultural approach to increase their “bionic footprint” to succeed.

About the Author / Mike D. Kail

Mike D. Kail is chief innovation officer at Cybric. Prior to CYBRIC, Mike was Yahoo’s chief information officer and senior vice president of Infrastructure, where he led the IT and global data center functions for the company. Prior to joining Yahoo, Mike served as vice president of IT operations at Netflix, where he was responsible for employee technology and various cloud engineering components. He has been widely recognized for his insightful industry commentary on social media Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” Connect with him on LinkedIn and Twitter.

January 26, 2017
How I Bet on DevOps – and Won
One evening in late 2015, after the kids were in bed, I sat down next to my wife and said, “I’d like to do something irresponsible. I want to gamble some of our savings on DevOps. I’d like to buy some stock.”

Nicole Forsgren’s 2014 presentation, “DevOps and the Bottom Line,” opened my eyes to the business impact of DevOps. Then the 2015 State of DevOps Report rolled out with the following tucked into a footnote:

The publicly traded companies that had high-performing IT teams had 50 percent higher market capitalization growth over three years than those with low-performing organizations.

I believed the data. It matched my intuition and experience.

DevOps and the Market

Companies doing DevOps win in the market. In a world where digital transformation has made competition between companies increasingly dependent on their ability to differentiate through technology, the ones who do best in tech are likely to win. As I heard an executive at an airline put it, “Anyone can spend tens of millions on a new Boeing or Airbus jet. There’s no sustained differentiation there. But a great booking experience … a great mobile app … that can win loyalty.”

So I found myself thinking that I sit in the middle of a DevOps community and know which companies are bragging about their DevOps successes. I truly believe it helps the business win.

The Bet, and Winning It

So that brings me back to that evening in December and the proposal I took to my wife.
1. This was gambling. We’d risk only a fraction of our savings.
2. We would buy and hold for one year, then re-evaluate.
3. I would do no research on the companies we’d invest in outside of their DevOps practices. We would assume other public information would be priced in by professionals acting in an efficient enough market.
4. Investments would be in companies “doing,” not “selling,” DevOps. No vendors.
After getting the green-light, I bought a dozen stocks based mostly on the “who talks DevOps at conferences a lot” criteria: Amazon, Bank of America, Capital One, Cisco Systems, Etsy, Live Nation Entertainment, Macy’s, Netflix, Nordstrom, Sherwin-Williams, Target and Verizon Communications.

So let’s talk about a few of these companies. Amazon and Cisco arguably violate the “no vendors” rule. Amazon I’ve excepted, as the company has a good reputation for DevOps internally, and many of the other retailers included are motivated to DevOps by fear of Amazon. They’re included as a hedge against Amazon killing all retail. In fact, Amazon was my only retailer to beat the S&P. Over the past three years, I found Cisco’s talks of its transformation at conferences (including IBM’s) compelling. Further, the hardware-to-network functions virtualization (NFV) transformation they’re going through seems similar enough to a retailer’s brick-and-mortar to e-comm to warrant inclusion.

My employer, IBM, is not included because it is a vendor and as an employee its performance already has a big effect on my life. Etsy and Netflix are my “unicorn” contingent. Etsy crushed it for the year (+38 percent). Netflix underperformed (+6 percent) and was a major drag through the first half.

Retail and e-commerce was generally a weak segment with Live Nation (Ticketmaster), Macy’s, Nordstrom, Sherwin Williams and Target all underperforming the S&P 500. Compared to a retail index fund (XRT), all but Nordstrom and Target came out ahead, though. It was a rough year for the segment, but those investing DevOps seemed to outperform their competition.

All in all, the approach beat the S&P 500 by about half for the year, albeit with considerably more volatility.

Good Sentiment, Sketchy Investment Strategy

That said, a deeper look at this approach makes me think it was more luck than skill. While I believe that high-performing IT yields business wins, I didn’t actually know which companies have high-performing IT. The DORA team has the best data. I don’t. A big financial institution is likely to have more techies than Facebook. Do a handful of them presenting at conferences really say much about their thousands of colleagues? I have doubts.

DevOps transformations, like Agile transformation, are hard to do at scale. It’s the scale that counts, and will generate the business differentiation. Some transformations led by brilliant champions will end up failing. Mid-year, I was at one of our DevOps networking events talking with someone from one of the companies in this list and suggested that they must be nailing DevOps given what I heard at conferences. The answer was, “Not really … we’re kind of starting over and the people championing DevOps have all left.” I’m not surprised that company is one of my underperformers.

Sophisticated investors will point out approaches for managing exposure to segments and better isolate DevOps effects from overall market moves. Not researching and using those is another flaw in the approach.

And yet, if picking stocks at random would yield average results, but DevOps helps company win, and people talking about DevOps likely represent companies with more DevOps than others, it’s not shocking to see this strategy happen to get lucky.

What Will I Do Next?

My focus will remain on ensuring the IBM UrbanCode business embraces DevOps practices, mindsets and approaches in every way and supporting IBM’s overall transformation. While transforming myself, I’ll remained focused on helping my clients with their own transformations. Check out some DevOps success stories.

As for investing, I’m not a gambler at heart and may simply close down this experiment while I’m ahead and pick a nice index fund. Or, I may refine the picks to only take those that are publicly talking about how they spreading these practices to thousands of practitioners.

Disclaimer: I’m a techie, not a financial advisor. I recommend improving your own business with DevOps. I do not have a recommendation for how you should invest. Past performance is not indicative of future results. This experiment could have gone badly, and for a while in the first quarter, it looked as though it would. Please don’t take risks you can’t afford based on the experience of a rank amateur investor like myself. This experiment was mine and mine alone. I speak for myself, not my employer.

About the Author/ Eric Minick

Eric Minick is a technical evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last 10 years helping organizations large and small adopt continuous integration, delivery and, now, DevOps. He is a frequent speaker on the topic, and co-authored “Application Release and Deployment For Dummies.” Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products. Follow him on Twitter at @ericminick.

— Eric Minick
January 25, 2017
Defining DevOps: Not Theory, nor Implementation

Ask a dozen engineers, developers, testers or their managers what their definition of DevOps is and you will get likely very different answers from each of them. Some may say it’s primarily about culture, others may say it’s about accelerating or automating the release of software and infrastructure changes and some may use the mantra, “People, over process over tools.”

What no ones seems to be able to agree on though is how to define the boundaries and constituent parts of what DevOps is really all about. It is all-encompassing, it seems to cover topics as varied as continuous improvement, collaboration, a whole raft of processes from agile, through testing to operations procedures, audit, compliance and customer feedback to collaboration. It seems to be attempting to cover every facet of life in this small part of development and IT operations that we live in—and because it’s so broad no one can really agree on what it means.

My suggestion is that we should try to narrow the definition of what DevOps is in an attempt to create some boundaries so that it can be considered more of a discipline than a utopian goal. For this reason, let’s consider some of the core concepts—culture, communication, collaboration, continuous improvement—as things that are important to its implementation, but not the thing itself. These are aspects of high-performing teams and should use a different lexicon outside of the DevOps world.

So culture should not be considered part of DevOps?

Put simply, any initiative that fundamentally reshapes an industry through a fundamental change in its objectives, process and delivery mechanism implicitly needs the support, buy-in and leadership of those involved. Much of the cultural aspects of DevOps seems to be around these areas—but if you are attempting to radically change the way any industry works, then these are common goals that use management and leadership theory that are not restricted to change within a narrow segment of software development and IT operations. These leadership challenges exist not only within the teams responsible for the delivery of software and IT operations—but in many industries that undergo disruptive change.

Should culture be a primary factor in implementing a DevOps initiative?

Now, this may sounds like a contradiction to what’s been said above but the answer is, of course, yes. However, the culture of any organization should be at its core. The culture within a law firm is important, as it is in a research lab or within a retail organization. If we take retail as an example, when a retailer implements just-in-time (JIT) delivery, which is analogous to what certain aspects of DevOps is trying to achieve—the faster delivery of goods, automation, small batch, feedback loops, metrics, audit, collaboration of disperse part of the supply chain—how much priority is based on whether the employee’s need to be bought into the idea before the initiatives were started? I would suggest not much; it was a management decision, based on shareholder value and the competitive advantage it would provide over competitors. Now that DevOps has become much more mainstream, I think we should think about it in a similar fashion. Retailers that have not implemented JIT are either out of business or very niche. We should no longer be thinking we need to get staff buy-in; the world has moved on, it’s happening, it’s mainstream and if your not on board, then get a job elsewhere. If you work in a shop and put some goods in the store for sales that have not been delivered by JIT, then you get fired. Simple as that.

Is DevOps really the same as JIT Delivery?

No, of course it’s not. JIT was a top-down, strategic management decision to implement on its workforce. It did not come from the grass roots, it did not come from a philosophy and belief from those at the coal face that there is a better way to deliver goods to customers, it was not a revolution by checkout staff that demanded that no longer should their managers buy from suppliers on a golf course and return to the store and tell them to make it work. The DevOps culture, by which I mean the culture within the DevOps community, is so inspirational because they shunned the top-down approach to implement bloatware and chose to go off piste—collaborate with their piers and change the face of an industry in a revolutionary way. They demanded that they know best.

Too many Brents

For all the talk of culture however, this industry we work in has far too many Brents (as in the indispensable engineer in the Phoenix Project, who is the only person who can fix the problem, but is also the root cause of all the issues). I am often baffled at the irony of the no hero’s mantra that is all too often exposed in the DevOps world, but many of the most talented engineers I believe do crave a hero status. They derive a lot of their self worth from the work they produce and consider themselves a snowflake, even if their servers aren’t. They write complex scripting frameworks in Ruby or Python and are attracted toward complex and powerful tools that they enjoy using, engineering themselves into a position where they derive brent-like satisfaction and create some job security. I’m not necessarily being to critical of such an approach, but I do find it guiling that at the same time believe they are part of a cultural revolution.

But do the engineers know best?

I think it’s hard to argue that, certainly if compared to 10 years ago, that the broader influence of DevOps has not only made software delivery and IT operations a much more exciting and dynamic environment to be working in—but is also delivering huge business value and competitive advantage for those organizations that have embraced it. Was culture and philosophy a key driver to achieving this? Absolutely. But much as Ben Horowitz espouses in the “Hard Thing About Hard Things,” you need a team to take a business to a certain level, and once it has reached a certain level of success it needs to be taken forward by specialists, not generalists who brought it to that point. I believe we have reached that point.

DevOps is now becoming mainstream and may benefit from being subdivided into different areas of specialization. As a startup, there is fun, excitement and a belief that you can change the world. Individuals that thrive on that often enjoy the variety in the work, performing a variety of functions within the organization—maybe some software development, support, pre-sales and marketing. But as an organization grows, specialization is required, there is a marketing team, support team, pre-sales and engineering team. This is a reality of working in a growth organization. There is no longer one team that does everything, but they are split out into specialization, collectively bringing the whole organization to a stronger place. DevOps has grown up—and needs to demarcate specializations to take it to the next level.

So how should the boundaries of DevOps be defined?

I would propose one of two things. DevOps remains the overarching philosophy of how we make the world a better place, underneath it sitting some more defined disciplines which are less related to the philosophy. So we don’t have the concept of a DevOps engineer, but instead they are roles such as automation specialist. Or perhaps, if I’m honest the way I felt when I started writing this blog is that we (and I consider myself part of the DevOps engineering community), now it has become much more mainstream, allow it to be taken forward by specialists disciplines, of which engineering is one, but the cultural, philosophical and management practices are no longer in the startup realm but need to be taken forward by the “grown ups.”

The philosophy and implementation should be separated

Ultimately, I think there needs to be some separation from philosophy of what DevOps is and the constituents parts of it. My primary reason for writing this blog, if I’m honest, was I am becoming bored of the DevOps bandwagon. The whole DevOps concept is is meant to conjure exciting and positive ideas how we can make the world a better place … but spring turns to summer, turns to fall, and successful startups turn from dreamers with passion to having VC backers or being owned by private equity.

This is not meant to be a negative point though—anyone who creates a start up ultimately wants it to go on to become a grown up. And Patrick Debois may be the founder of the startup, but DevOps is now a publicly listed company.

About the Author / Dave Sayers

Dave Sayers is a co-founder and technical services director of MidVision, a provider of Release Automation and Continuous Delivery Software. He works closely with customers and partners on DevOps and Automation initiaitves throughout Europe and North America and is responsible for devising and managing the partner and channel strategy. Connect with him on LinkedIn.

January 24, 2017
Automation, ChatBots Can Improve DevOps
At its heart, the goal of DevOps is to foster better communication between the development team and operations team at an organization. When these two teams are systematically connected, they can easily stay in sync on most issues and there is strong coordination in building and delivering the product to customers.

Automation and ChatBots can play a big role in the connecting development and operations. They open the door for companies to go beyond simply being alerted when something happens in a chat application, allowing an employee to take action after receiving the alert either in an automated manner or by providing guidance to the employee on which actions to take.

Automation: Creating Smart Alerts That Don’t Require Follow-Up

Monitoring applications, systems, virtual machines and networks are a key part of any operations team. There are a number of tools that are used for this purpose, including CloudWatch, Splunk, Rollbar, Pingdom and Newrelic. These tools typically alert the operations teams when there are issues. Engineering teams, on the other hand, use tools such as JIRA and Github to track tickets and manage their agile development process. Alerts from the tools used by operations are helpful, but they still require some manual follow-up. For example, imagine a critical alert is reported by one of the tools because of a product issue. Follow up on this alert would require:
- Creating a ticket in JIRA/Github with all the relevant information to help diagnose the issue.
- Escalating that ticket so that it gets looked into right away.
- Keeping the required people in sync as the status of the issue changes.
This entire process can be automated. When automated, the workflow operates like this:
- When the monitoring tool senses there’s something abnormal, like error rates above certain thresholds or a critical failure, alerts are sent and a ticket is created in JIRA or Github automatically with all the relevant information about the issue.
- Taking this a step further, based on the type of issue, it can be automatically assigned to the right person and even post a message on the appropriate Slack channel.
- As engineering works through the issue, everyone is automatically informed in Slack when the ticket is updated.
The key to getting this scenario automated is to leverage an integration and automation platform that is powerful enough to handle complex workflows, yet easy to use so that these automations can be built in minutes. Users don’t want to work for your automations, they want their automations to work for them. With that in mind, the platform should also be flexible so changes can be made to the workflows without any engineering effort (i.e., an automation platform where integrations and automations can be built and changed without any coding).

ChatOps: Monitor and Orchestrate via Chat Platforms

With all the apps being used by DevOps, it is difficult for any team to stay on top of monitoring and managing issues while also taking actions across all these tools. Studies show that app hopping is not efficient and results in constant context switching, which negatively impacts productivity.

ChatOps allows users to stay on top of everything including orchestrating workflows right from chat platforms such as Slack. To make ChatOps work, users need a bot that works in tandem with an integration and automation platform. The bot works with all business apps (even the tough ones with custom objects such as Github and Salesforce), is customized to meet the specific needs of the business and can extend to address all operational needs.

Here are three ways users can leverage bots for better DevOps:

Smart, actionable alerts: Rather than have a firehose of alerts coming in, users can define various thresholds, monitor velocity of alerts and, based on these settings, post an alert to the relevant channel or person on Slack. Bots can also prompt the person to take action based on the notification.

Stop services, virtual machines: Bots can connect with any app, or service that has a HTTP/REST API. Not only can they monitor various apps and environments, they also can start and stop them.

Workflow orchestration: Various workflows such as managing incidents, escalations and deploying code are all triggered and managed through Slack.

Automating DevOps has significant benefits in overall increased engineering and operations productivity. The key to automation success is to select an integration and automation platform that is secure, resilient, can handle complex workflows, can be easily customized to meet the specific needs of the business and can be managed through Slack. It should be easy to use so automations can be built fast and changed easily as workflows change. Automation and ChatOps will streamline business workflow, keep the important players from both development and operations informed and increase productivity for everyone involved.

About the Author / Gautham Viswanathan

Gautham Viswanathan is the founder/head of products at Workato, www.workato.com. He also leads the team in creating Workbot For Slack, a bot designed to be customizable and allow you to do work in your apps right from Slack. Gautham has a deep background in integration platforms and was previously the head of products and engineering at TIBCO. Connect with him on LinkedIn.
January 24, 2017
5 Ways DevOps Can Help Improve IT Security
You already know DevOps can make software delivery faster and more efficient. But did you know it can help to keep software more secure, too? Here’s how.

DevOps refers to a set of practices and cultural priorities related to the way software is designed, produced and deployed. It emphasizes collaboration between developers (the people who write code), IT Ops (the folks who manage software in production) and everyone in between—such as software testers and designers.

When done properly, DevOps greatly reduces the time it takes to bring software from idea to implementation to end user delivery. It also adds efficiency to the software delivery process in many ways. It allows different team members to work in parallel, for example. It also ensures that coding problems are found early in the delivery pipeline, when fixing them requires much less time and effort than it does once a bug has been pushed into production.

DevOps and Security

But making software delivery faster and less costly isn’t the only thing DevOps does. DevOps also helps make software more secure.

It does this in several ways. Consider the following:
- Visibility. DevOps encourages constant communication between all members of the IT organization. That maximizes each team member’s visibility into the software being developed. In so doing, it places as many eyeballs as possible on the code, at all stages of delivery—which maximizes opportunities for your staff to find security flaws before code is released into production.
- Automation. In the DevOps world, software delivery tasks are automated as much as possible. With automation comes consistency and predictability—and a much lower chance that human error during a manual process could introduce a security vulnerability.
- Fast updates. DevOps enables a much faster pace of software delivery. That means that security bugs (and bugs of all kinds, for that matter) can be squashed very quickly by rolling out a fix.
- Tool-agnosticism. With DevOps, you can use whichever tools or programming frameworks you like. You’re not bound to particular platforms or vendors. That’s important from a security perspective because it empowers you to adopt the tools that are most secure for your needs—not the ones you’re locked into because you have an outdated, inflexible software release process.
- Agile technology. While DevOps doesn’t require you to use any specific type of tool, DevOps teams tend to favor next-generation architectures and technologies, like microservices and containers. These help to make apps more secure by reducing attack surfaces and enabling quicker reaction. If you deploy your app using containerized microservices, it becomes harder for attackers to compromise your entire app, because an attack against one microservice doesn’t give them control of the other ones.
DevOps isn’t a silver bullet when it comes to cybersecurity, of course. Keeping your systems and data secure requires careful planning on a number of fronts and implementing a variety of tools.

But DevOps—especially a highly automated, DevOps-based release process—should be one important weapon in your cybersecurity arsenal.

— Chris Tozzi
January 23, 2017