No DevOps-in-a-Box – InApps Technology is an article under the topic Devops Many of you are most interested in today !! Today, let’s learn No DevOps-in-a-Box – InApps Technology in today’s post !

Read more about No DevOps-in-a-Box – InApps Technology at Wikipedia

You can find content about No DevOps-in-a-Box – InApps Technology from the Wikipedia website

“Remember Nicholas Carr? He actually had a point,” stated Nicole Forsgren during her keynote address to close CloudBees’ DevOps World 2018 in San Francisco last month. She was referring to the best-selling former editor-at-large of Harvard Business Review who in 2003 published an article entitled “IT Doesn’t Matter.” There, Nicholas Carr suggested that the novelty of information technology was already wearing thin, and that it would eventually find its permanent place in the global economy alongside refrigeration, locomotion, and all the other formerly exciting commodity services.

“Back in the ‘80s and ‘90s, the days that Nicholas Carr was writing his article about,” Dr. Forsgren continued, “all we did was we bought technology, we plugged it in, we walked away. Or we bought something, installed it, and we left. It was kind of amazing, because it was easy. We were on ‘easy mode,’ we checked it off our list, we collected our fat bonus checks, and we left.

“The challenge of that is, if I can buy a server, plug it in, and walk away, so can any of my competitors. So it doesn’t get me ahead. I don’t win from that. If anyone else can do the same thing just as easily as I can, if anyone else can write a check, it doesn’t get me ahead.”


We’ve introduced you to Dr. Forsgren in InApps Technology before; she’s the CEO of DevOps Research and Assessment (DORA), and the principal researcher for the annual State of DevOps study, the most recent edition of which was published just weeks ago. Her latest book, entitled Accelerate: Building and Scaling High Performing Technology Operations, was also recently published, and the book-signing ceremony here stretched out like a queue for a major concert or an iPhone release. It’s absolutely fair to say she has a disarming, often captivating, certainly commanding, stage presence.

Carr, in the intervening years since that article was published, has had to resort to other methods to attract people’s attention. Currently, his personal blog features a 5,800-word recitation of the various published citations of his work by others, most of whom appear to have disagreed with his premise, or perhaps just with his title. We do live in an era, after all, when being publicly disputed manages to give one a sense of validation.

Read More:   Update Spark Closes in on Real-Time Processing with Redis Pairing

So it might come as bad news to Carr that Forsgren validated a good portion of his premise in fewer than 100 words — certainly shorter than the average Facebook post. Her kind words, however, were just a staging ground for the eventual sting.

“If that’s how you view technology, you’re doin’ it wrong,” she asserted, followed by a pause that spoke at least as loudly as the statement itself.

“There is no DevOps-in-a-box. Yes, this is me trolling half the industry right now, ‘cause they’re trying to sell DevOps-in-a-box. It won’t work.”

The very phrase “information technology” derives from a movement to isolate and identify classes and elements of work that are “undifferentiated” — that contribute a minimum of consumer-perceived value, if any at all — and to remove as much human effort expenditure from that work as possible. DevOps is only the latest permutation of this movement. Some perceive this removal as implying a delegation of talent to a task that does generate value; others view it as a necessary component of corporate downsizing. Either way, it leaves both organizations individually, and the global economy as a whole, faced with perhaps millions of highly skilled, experienced workers, in a trade that is transitioning away from them.


Several of these people are looking to heroes for help. It’s only fitting that one of these heroes looks like he could have been drawn by Bob Kane.

“You need to give a s__t,” declared Baruch Sadogursky, head of developer relations for software development pipeline service JFrog. Wearing a red T-shirt, a parachute fabric vest, a black top hat, and sporting a prominent black beard visible from the opposite side of a soccer stadium, Sadogursky has developed his own uniquely successful means to attract and hold an audience’s attention.

“People need to care about getting better,” he continued, during a conference session of his own. “There’s tons of examples of, I would say, old-school enterprise-y corporations, but these people don’t really give a s__t about getting better. They do what they do, and no one cares.  It all eventually translates into money… Hiring the people who give a s__t costs money.  And that means, you need to justify this investment to the business, by providing them — going back to the question of why we should improve at all — with those insights that better releases lead to better quality, to better customer satisfaction, and to beating your competition to the market.”

Read More:   Update The Challenge of Machine Learning and How DevOps and the Edge Will Modernize Data Science

His point is that automating the software and service delivery processes of an organization is not an automatic process — in short, that automation is not automatic. It requires the same class of human effort and oversight that IT operations professionals, formerly charged with automating infrastructure and “keeping the lights on,” have always provided. As he told his audience, JFrog itself has had to undergo similar procedural adjustments itself.

“Another aspect of willingness to do stuff,” Sadogursky went on, “is job security, especially about quality and the engineers that do manual QA [quality assurance]. Because it’s very, very clear that they are the first on the way out.  If I automate my QA, and I automate my release engineers, my release engineers and my QA engineers just go home.”

A decade ago, when there were fewer options for how QA processes could take place, he said, JFrog had a large team of release engineers.  Its release cycles were considered fast back then — three months, a mere quarter of a year.  Since that time, the company has moved to a model that Sadogursky calls liquid software. In fact, in a book with co-authors Fred Simon and Yoav Landman, he’s working to make this phrase officially coined.

JFrog managed to make this transition while letting go of zero engineers from its original workforce. “Not only we didn’t fire anything; we actually tried to hire, and cannot find enough people,” he said.

“Because while there are people who will definitely go home because they cannot do anything else, this is the minority. The majority will find their place in the new organization, working with new technology, improving the process, and actually the faster we release, the more work we do, the more working hands we need.”


Sadogursky referred to data from what he called “Nicole’s report” (in this segment of the industry, everyone knows who “Nicole” is), revealing that the software release cycles of the highest-performing organizations in her study were over 2,500 times faster than those of low performers. That data is evidence enough, he believes, that a properly managed transition should leave few casualties in its wake. “This fear is really not justified,” he pronounced slowly.

Read More:   Doing Cloud Native DevOps the right way

“DevOps is Dev and Ops,” Forsgren told a packed session prior to her book signing Wednesday. “We cannot accomplish the overarching goal while also sacrificing the other team. Global measures, focusing on outcomes, not output.”

One of the points that she may have had the most difficulty getting through to listeners (even the ones who perceive her as “Nicole,” or for whom I suggested to her we print “Team Nicole” T-shirts) is that the metrics she so highly values in her work should not represent the outcomes for the organizations that put them to use. In other words, the measurements themselves should not be the barometers of success for any organization, but rather the outcomes of those metrics put to positive use. Metrics are indicators, and as she’s said on multiple occasions, the metrics an organization chooses to value over others will directly translate to its values, and even its morals. But metrics are not goals, just as speed itself is not the finish line.

“Think about metrics that are easily gained or that can be automated,” she advised her audience. “Anyone here have a ticket system? Tickets can be automated. I know of organizations where a ticket gets opened, especially by end customers — this is the worst — and it automatically gets closed.  The ticket’s closed, everything’s fine! But if that’s your only end metric — speed to resolving tickets (“Killed it!”) — or if it has to be closed within a certain number of days, I can automate that too. I can close it and reopen it back. But what’s the goal? Not everything that can be counted, counts.”

Baruch Sadogursky and Nicole Forsgren represent two voices of inspiration and hope in this often scary and uncertain industry. I think we may need about 2,500 times more of these people if we expect to make it through this next decade.

CloudBees is a sponsor of InApps Technology. The company helped pay travel costs for the reporter to attend DevOps 2018.

Photography by Scott M. Fulton III.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: JFrog.


Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download


      Success. Downloading...