staging-devopsy.kinsta.cloud

Tag: DevOps methodologies

There are Few Enough Silver Bullets

I was working through this week’s blog this morning, and it was laser-focused on a narrow topic. I had examples of why too much of a good thing is bad, how absolutism about methodology is hurting the majority of organizations out there, and how to get past this issue to keep improving what IT does for the organization.

And I was nearly done when I decided that there are far too many areas of IT that suffer from absolutism, so I’d offer general symptoms and steps that work to get out of any of them.

What do I mean by ‘absolutism’? Well, it used to be—and, in a couple of areas, still is—true that people would say, “We are an X shop.” And mean it. If you were a Cisco shop in the 1990s or 2000s, that is all you bought. Competitors were not allowed; nor was consideration of competitors. This applies to methodologies as well as product categories. In fact, today it applies to various methodologies more than products.

And it’s bad for the organization, no matter where it comes from. While with vendors, it streamlines purchasing and offers the (in)famous “single throat to choke”, it also causes inefficiencies in costs (from your perspective, they are a monopoly, and some large vendors gained infamy by trying to take advantage of that fact), and causes people to do things in the least efficient way because that’s what the chosen methodology/solution requires.

Sometimes, we manage to do the dance and avoid “One True Way”—take the move to cloud and continuation to multi-cloud, for example. While cloud vendors do not offer customers much leeway in pricing or priority (we customers are all cattle, not kittens), multi-cloud still offers us the opportunity to use the cheapest or best-suited cloud vendor without much drama.

Many times, we are not so effective at avoiding the idea of a silver bullet. Take Agile. If there was a One True Ring of this decade in IT, I’d want it to be containers, but it would actually be Agile. Most IT departments zealously guard that Agile is the One True Way. Early-stage new product development is astoundingly well suited to Agile, and we needed it—if just for that part. Late-stage product maintenance, where changes are not feature-laden monuments to systems complexity, are also really well-suited to Agile and we should be happy to have it. In between? Large updates that can span data centers—or even continents—with a geographically dispersed workforce and hundreds (or more) of hours of development to get one sub-feature completed? Not really a great fit for Agile, and while many of us have said that for years, here is hoping things are changing. As I’ve said before, as maligned as waterfall was, it did the job for decades and handles large complex projects well. Maybe we need a replacement more in line with the times; one that incorporates what we’ve learned from Agile. I’d love that, actually. But what we don’t need is “We’re an Agile shop.” It is less useful than when it was said about products (at least if you only chose a single product, you got single sourcing and streamlined purchasing. With methodologies, you don’t even get that).

Note: Agile is an example, not the point of the post. Avoid “One True Way” across your organization. Root it out and examine it. Sometimes, a single solution with a single specialized skillset is the perfect answer—at least for now. Far too often, “We are an X shop” is someone’s preference codified into corporate policy.

To get past One True Way, you have to be there showing its weaknesses to management. There is some skill overlap when allowing multiple approaches or products, but if management starts prattling about that, simply point out the number of development and/or CI/CD environments the org is currently supporting. To show the overhead, track hours spent. Staff shortages have been endemic to IT for years. Make certain you know how much time is spent in overhead for the product or process, and try to map that to what could have been achieved with that time. It’s not perfect, but it will be illustrative. And don’t stop. Do your work, but point out every time that One True Way makes the job harder or more expensive.

You are nailing it. Don’t let things like Agile keep you from churning out great apps for the company. I’ve been on teams where the time spent in process overhead was dragging down the ability to deliver quality. Fight that. Keep kicking it, and use the best tools/processes for the job.

June 8, 2022
Transforming the Security Team Into a DevOps Partner
Securing DevOps environments is an increasingly important concern for chief information security officers (CISOs) and security teams. While developers often recognize security is important, it is not their top priority. More typically, the DevOps team prioritizes delivering new capabilities and features to the business and customers, often as part of a larger digital transformation initiative. And, developers often view security as something that will slow down deployments.

Security teams usually have limited DevOps knowledge or expertise. Too often the result is that DevOps adoption begins and even takes hold inside an organization before the security team gets involved. Consequently, security vulnerabilities are not always adequately addressed in DevOps environments and can drive unnecessary risk.

Integrating Security in DevOps

The priority is for the security team to take the lead in integrating security into the DevOps processes before poor practices become entrenched. But as both teams are often siloed and don’t tend to work collaboratively, how can security teams better engage, energize and collaborate with their DevOps counterparts to strike the right balance? In a nutshell, how can organizations bring their DevOps and security teams into alignment and establish collaboration for stronger overall security?

There are a few crucial steps to take to achieve true integration of security and DevOps.
1. Establish the Requisite Skills to Get in the Driver’s Seat. Effective collaboration requires effective communication. While developers write the actual code, it’s important for security teams to gain knowledge about programming languages along with how applications are built, tested and deployed automatically. This will help them have more meaningful discussions and credible conversations. Security professionals can start by learning some of the fundamentals: PowerShell, Python and Rust, as well as how DevOps tools use REST calls and containerization technologies–particularly Docker and Kubernetes.
2. Make it Easy for Developers to Do the Right Thing. You can’t be the manual cog in their completely automated process. Make it easy for developers to do the right thing by training them in secure coding practices and implementing a self-service model for security capabilities. For example, you could provide security policy as code that can be integrated into the developers’ automated processes.
3. Establish Effective Ways to Collaborate. Set up formal systems to ensure DevOps practitioners understand security risks and implement good security practices across the organization. Consider how best to deploy security resources into existing or new organizational models and structures. This includes establishing centers of excellence, community leaders, security champions and embedding security team members inside development teams.
4. Get Developers to Think Like Attackers. Educate DevOps teams on specific attacker tactics, show how sample code modules could expose secrets and provide examples as user stories. For example, “As an attacker, I would scan the organization’s code repositories looking for secrets.” Take the team through a penetration testing exercise or engage a red team to demonstrate how an attacker would compromise a CI/CD pipeline.
5. Adopt Agile and DevOps Methods. Security should begin utilizing agile and DevOps methods within their own teams, not only to gain a deeper understanding of DevOps methodologies but also to achieve greater efficiency by automating tasks or delivering capabilities in smaller increments more frequently.
The bottom line is, it is crucial to understand how other enterprises approach secrets management challenges across DevOps and cloud environments. This can help encourage collaboration and help fast-track the security team’s own efforts. Ultimately, this will ensure agility is not just implemented for the sake of innovation, but companies reflect on their processes and prioritize security to make the most of their transformation.

— Josh Kirkwood
July 16, 2019
4 Traits of High-Performance Digital Leaders

Businesses that have retooled their culture, their hierarchy and their business mindset toward the use of technology are consistently outperforming their more traditional peers. According to the newly released Harvey Nash/KPMG CIO Survey 2019, digital leaders are the top 30% of businesses that are extremely effective at leveraging digital capabilities to advance their business strategy. The survey showed that digital leaders are beating the competition more handily than their cohorts on some of the most important business metrics followed by CEOs, including time to market, customer experience, response to change and profitability.

As the report explained, organizations don’t spontaneously become digital leaders and they don’t create their success by “pedaling harder in their traditional IT function; in fact, for many organizations the concept of a traditional IT department is an anathema to them.”

The study showed that organizations that have established themselves as digital leaders tend to have incredible support and commitment from the top of the food chain. Whereas only about 58% of CEOs at most other firms want their technology projects to make money versus save money, 78% of CEOs at digital leaders see technology capabilities as their proverbial goose laying golden eggs. In the same vein, digital leaders are also much more likely to have a top technology leader—be it CIO or chief digital officer—reporting directly to the CEO and sitting on the executive team.

“There is a chicken and egg question–is the technology leader influential in these enterprises because the board supports them, or does the board support them because they are influential in their own right?,” ruminated report authors on the board access and influence that CIOs have at digital leader organizations. “The truth is, it’s probably a mixture of both.”

Regardless of how that relationship evolved, the tone from the top is helping digital leaders to hone themselves through some common winning practices and modes of operating. The report found that these organizations tend to exhibit four common traits, many of which have significant cross-over with the practices and principles of technology organizations that have embraced DevOps transform their IT delivery models:

An Emphasis on Modern IT Delivery Speeds

In fact, one of the most stark differences between digital leaders and everyone else is that they are far more likely to have leveraged DevOps to accelerate innovation. The study showed that these organizations are more than three times as likely to use agile or DevOps methodologies enterprisewide to speed up feature delivery. What’s more, digital leaders are also fully buying into the old DevOps ethos of innovating fast and failing faster. Digital leaders are similarly almost three times as likely to pivot quickly from small experiments, scaling up quickly on success or stopping quickly on failure of these small pilots.

Strong Business-to-IT Collaboration

“Digital leaders are swapping control for influence and investing time in business relationships,” according to the report.

The report showed that whereas only about 18% of most traditional technology functions work collaboratively with business leaders to deliver technology change, that spirit of cooperation is alive and flourishing at 54% of digital leaders. In fact, technology executives at digital leaders are less likely to look down on business-driven spend as rogue or shadow IT, but instead as business-managed IT that’s sanctioned and even encouraged. At the same time, technology decision-makers are more likely to influence and govern these business-managed IT decisions than at other organizations.

Focus on Value Rather than Technology

The report showed that digital leaders have an “expansive mindset,” meaning that they’re much more likely to think of technology in a big-picture way. So they look at technology delivered as long-term products rather than short-term projects. And success is not viewed through traditional technical SLAs, but instead “… through the lens of business performance, often tied to measures like customer or employee experience, lifetime value, loyalty, uptake and time to market.”

Additionally, this expansive mindset combined with high levels of collaboration with the business has most digital leaders putting together cross-functional digital teams that combine IT and business staff. These organizations are three times as likely to invest in training non-IT people in IT skills.

Fanatical About Data

Finally, all of that experimentation and work is driven by data. The report showed that “data is at the heart” of digital leader organizations. Digital leaders are more than three times as likely to maximize the value of all of the data they hold, and almost four times as likely to maintain an enterprisewide data management strategy than other organizations.

This use of data is helping them provide business leaders with actionable customer insights, to improve operational efficiency and to get a better line on risks and opportunities the business will face in the future.

“Digital solutions are the oxygen that allow a business to breathe and run at market speed,” said Steve Bates, global lead of the CIO Advisory Center of Excellence at KPMG. “This year’s survey provides compelling evidence of the transformational progress digital leaders are making. It is up to the rest to catch up and join them.”

— Ericka Chickowski

June 21, 2019
Agile and DevOps: Where the Rubber (Literally) Meets the Road

Do Agile and DevOps methodologies apply outside of technology? More specifically, can we apply them to sport? I decided to answer these questions by analyzing the application of Agile and DevOps principles within my road-cycling team.

For those of you who don’t know, cycling is a very data-driven sport. While we are training and racing, we have a live feed showing data on our computers, which are attached to the handlebars. We see data such as power (watts), heart rate (bpm), cadence (rpm) and much more. Monitoring and analyzing this data allows us to work within our limits to ensure we aren’t overloading ourselves while performing to our highest capabilities. We measure our limits through tests over time periods such as 30 seconds, five minutes and 20 minutes. The results of these tests form specific thresholds that we work within to maximize the benefits of training and racing. We can set up automated alerts in our bike computer to warn us if we are overexerting ourselves or we can keep an eye on the screen to measure this ourselves.

In a mature DevOps environment, we work toward monitoring at the service level to understand usage, performance, environment and application health and more. This doesn’t just help us to find the problem, it allows us to set up self-repair protocols within our infrastructure if the monitoring tools report any alerts.

We run the cycling team like a startup, where everyone wears many hats. We operate in small, loosely coupled units; everyone rides together without silos, but then we also have specialties which come out during the sessions. For example, the climbers are better at riding fast uphill, so they work together at times, as do the powerful sprinters with the sprints and so on. The important point is that we don’t segment ourselves solely to these responsibilities – the sprinters still have to get themselves over the climbs and the climbers still have to practice sprinting. We never know when one of us will have to try to fill in for a teammate. We understand each other’s roles and the importance of that person within the team.

We learn as we go. We can’t rely solely on one person in the team, even if they are the strongest. Let’s say the A rider has a crash 2km before the finish – what do we do? The lead out train all move one place up the line, so the guy who was supposed to be the last man left to support the sprinter in the final move, will now be the sprinter. We have setup a self-healing system with very low mean time to repair. Flip back to DevOps – some bad code has made it through your pipeline. You can’t solely rely on the person who wrote the code to solve this problem. In the ideal world, we use version control to assist other people within the team to figure out exactly how to repair the issue. We can design the system to self-heal by automatically reversing the failed change to an earlier state.

Everyone in the team understands that they have a cross functional role. This doesn’t mean that we don’t have specialisms or areas that we like more than others, it just means we are a team of doers. This compares to a team working effectively with DevOps principles. It doesn’t matter if you started your career as an applications developer or systems administrator—you must get the work done and solve problems for the greater good of the organization.

Bicycles and DevOps Cycles

Essentially, your entire role as someone who practices DevOps is to make everyone else’s life easier through implementing processes and tools that help to increase productivity and reduce errors. In a cycling team, everyone is working for the success of the entire organization, not just for themselves. The DevOps role can compare to that of a domestique in cycling.

For context: In cycling we ride directly behind the wheel of the person in front, with maybe an inch between our front wheel and the rear wheel of the other rider. We do this because it uses approximately 30 percent less power for the person behind. The domestique is responsible for making the other person’s job easier. They don’t work for individual glory but sacrifice themselves for the greater good of the team.

The DevOps architect or engineer in your organization (disclaimer: Yes, I believe that it’s everyone’s responsibility to practice DevOps methodologies, but often there is a person who has the strongest knowledge of DevOps and how to implement this across the organization) does not spend their day thinking about how to show off about some awesome code they wrote or the system they built. They are thinking about how to make your day-to-day processes easier and solve problems for the good of the team.

Pulling the pace at the front of the peloton. This is called the ‘lead out.’ The pace is kept so high that other teams can’t attack or ride ahead. The aim is to drop the final rider off ahead of the other sprinters and as close to the finish line as possible.

We train, fail fast, continuously learn and succeed together. In the words of Kiichiro Toyoda (founder of Toyota Motor Corporation), “They do not have the expertise gained from the failures it took to produce the original. … The thieves may be able to follow the design plans and produce a loom, but we are modifying and improving every day.” So, you can steal their plans but without knowing their failures and ongoing development, you won’t create the same product. In comparison, another cycling team could find the blueprints of how we train and try to do the same, but they won’t understand how we operate as a unit. They won’t understand our failures and what we have learned to advance to where we are now.

We practice continuous improvement and continuous learning. We constantly try to better our previous performances. If we win a bike race, we don’t go home, put our feet up and say, “We are the best team, nobody else will beat us”—we analyze our performance and it’s more than likely there are many things we could have done better, even if we did win the race. Why do we do this? Because on a different day, if minor mistakes are made again, the other teams might get the better of us. In the tech world, we may have achieved our fastest, most secure deployments to date with very few failures, but are we going to rest on our laurels and cease to improve? This is the antithesis of what we should be doing in DevOps environments—we should be constantly looking to better our previous work. At the organizational level, the business itself needs to stay competitive and ensure that customer demands are being met; technology allows the business to stay on track with these targets.

Our processes worked very well, and they continued to improve. This was helped by the implementation of chatOps to develop our culture and collaboration. When I joined the squad, we communicated via email. This was slow, clunky and generally not the best way for a team of 16 people to communicate. Our inboxes were constantly full, and we sometimes missed messages. Enter Slack. At first, some of the guys were closed off to the idea of change—“Why don’t we just use email? It’s so much easier,” they said. It really wasn’t easier to use email instead of Slack; it’s just that they didn’t want to change and learn to use a new tool, even if it only took a few hours to get comfortable with it.

This is a common problem I see when trying to implement DevOps tools in enterprise organizations. Even if working with Docker or Kubernetes is going to bring huge benefits for people, sometimes they just don’t want to change from what they know. We practiced empathy and explained the benefits, while showing the improvements in a short space of time. Similarly, we do this as DevOps consultants when guiding cultural and procedural transformations at enterprise organizations. Anyway, we ended up using Slack and before I knew it, the entire team culture had changed for the better. We used the various channels to keep things organized such as “racing,” “team rides,” “ICE” (In Case of Emergency), “coaching,” “random” and others. The culture improved because we were able to bond, have fun and joke with each other without fear of disrupting important conversations in other channels. Our coach is based in Santa Monica and we are based in New York, yet we feel as though he is with us on every training ride.

I’ve seen Slack, Trello and other collaboration tools being used to improve collaboration in remotely dispersed teams. So why does improving culture matter? Shouldn’t people just focus on doing their job? Yes, of course they should. I’m not saying that this should be a distraction. But bringing your teams together means that they are more likely to collaborate in times of need. This will help your global teams with communication and collaboration. It will also help with employee satisfaction because people will feel a greater sense of belonging.

Conclusion

To summarize, Agile and DevOps methodologies can be applied outside of technology. These principles and practices can be implemented across entire organizations. They can help manage change and transformation while increasing productivity through automation and the adoption of modern technologies for cloud computing. Don’t get caught up in the DevOps tools.

Crossing the finish line @ The New York State Criterium Championships – March 2018

— Conor Delanbanque

April 20, 2018
Sneckdowns In IT Operations

What IT operations professionals can learn from the actual paths people take through tools and processes, and the differences from the expected usage model.

It has been a snowy winter across much of Europe, and although the snow is now beginning to melt in most places, there are still substantial sneckdowns to be seen across our cities.

If you’re not familiar with the term “sneckdown,” it describes those areas of streets that are not actually used, as revealed by the unmarked snow that settles on them.

Transportation planners have even been known to use sneckdowns successfully as planning aids.

The world of IT should learn from this example. We may not have anything as whimsical as snow to help us, but on the other hand, we do have enormous amounts of data. Let’s investigate some examples, starting with IT operations.

Restate My Assumptions

IT operations has a bunch of assumptions baked in, but just like with street layouts, some of them may be obsolete, leftovers from a previous generation of technology. My own hometown dates its founding back to Roman times-218 B.C., to be precise-but the sorts of design choices that Roman colonists might make to facilitate chariot and ox cart traffic have had to be updated significantly-first to accommodate motor vehicles, and then again to ensure that the motor vehicles did not crowd out other forms of transportation such as bicycles.

Similarly, much of IT operations is based around the notion of a ticket, which describes and encompasses an atomic problem. This ticket has a single owner at any one time, and is processed sequentially through a series of steps. This is the operations equivalent to the waterfall model of development.

These assumptions used to be reasonable in previous eras of IT technology, when a simple failure of a single piece of equipment was enough to trigger an incident. That incident ticket could easily be paired with the specific piece of equipment that was impacted, and from there a simple lookup would return the responsible group, who could then be assigned the ownership of the ticket.

These days, that model is largely obsolete. Hardware, especially virtual hardware, is cheap enough to be made multiply redundant. Automated functions such as load balancing ensure that single failures are rarely enough to cause an actual incident. Instead, multiple failures have to occur in the right sequence—or the wrong one, depending on your point of view. Meanwhile, operators are drowning in a sea of red alerts, unable to find and focus on the few actionable ones because processes require them to respond to everything. Finally, when a real ticket does make it through the noise, it gets bounced around from team to team, as harried operators try to work out whether it’s their problem or somebody else’s.

Operators are human, after all, and over time they develop their own paths through and around this rigid process, just as people walk and drive their own paths through the snow.

Examples of IT Operations Sneckdowns

Users Working Together

One big IT operations sneckdown is collaboration. Instead of using the ticketing system and its rigid assumptions, operators work around it, using alternative methods to work together and share information with each other. The goal is to deliver full-stack operations for the entire complex business service that is being supported by the team.

The problem with sneckdowns is that if there is no city planner watching and measuring, eventually the snow will melt and leave no visible trace of the paths that people take around their city. In the same way, the risk to the wider organization is that as people work and collaborate in alternative, unofficial tools—whether IRC or Slack—information gets stuck there and does not make it back into the official knowledge base, where it is available to be consulted and reused over time.

Sneckdown Recommendation: Recognize that the nature of modern IT and network architectures means that there may be no single owner of a problem. The rapid rate of change, too, makes it almost certain that any owner will not be documented in a static database somewhere. Instead, modify processes to recognize this multiowner approach, and enable users to work easily with each other without having to play ticket ping-pong.

The Right Tool for the Job

This overlaps with another sneckdown: unofficial tool adoption. In the same way that operators might start using an unofficial collaboration tool to route around limitations in the official service desk process, they might look at Kanban to share task status, or start building libraries of automated diagnostic and remediation actions. The problem is that the rigid official policy often does not accommodate these extensions, and indeed has no mechanism to do so.

Sneckdown Recommendation: Modern operations tools need to offer flexible interfaces to enable integrations and extensions to be done in a safe way. This way, if a particular integration does not work out or needs to be upgraded, that can be done without disruption to the wider process and to any other integrations that are working well.

Look into the Shadows

The final sneckdown—at least for this snow storm—is shadow IT. In the same way that much of our universe is theorized to be made out of dark matter, not visible to our current tools, a growing proportion of IT spending is happening outside the “official” IT budget. This also means that whatever is bought with that budget is outside the official IT operations and support process. That’s all very well on paper, but if the tool Sales or Marketing were relying on to do their jobs goes down, somehow, IT operations is still going to get the call to fix it.

Sneckdown Recommendation: There isn’t an easy short-term fix for this one—no way to shovel it out of existence. Instead, IT operations professionals need to work on this issue from two angles. The first is to address the causes of shadow IT, those rigidities and frictions that make people look for outside solutions rather than engage with their in-house IT departments. When everything is properly aligned, the IT department has a lot to offer in terms of understanding of How Things Are Done inside the organization. The other angle is—yes—to make it easier to accommodate solutions that might have been procured originally as shadow IT. Figure out how to engage with support processes for SaaS solutions that people adopted on their own; if it’s working for them, it’s up to you to keep it working! The benefit is that this alignment will reduce the need for constant injections of energy by sysadmins and operators to keep things running: the Second Law of IT Ops.

Conclusion

Compared to city planners and transportation activists, we IT professionals actually have it pretty easy. We’re not reliant on particular weather conditions for our data, but rather, we have enormous amounts of data at our fingertips all the time. It’s up to us to look at the data with open minds and read the conclusions that are already there. The hard part, of course, is putting those conclusions into action, especially when that requires changes to widely accepted processes, but that is also an opportunity to revisit those processes and make sure they are still as fit for purpose as when they were first adopted.

If you’re interested in what that process looks like, there is an interesting event series: Game Day ITSM & Incident Management Workshop. The next Game Day is in Chicago on March 21, but there is a whole series running, so there is probably an event near you soon. It’s a fun time, and also a great opportunity to rethink some assumptions and look at where some sneckdowns might be that could be incorporated into your planning.

— Dominic Wellington

March 13, 2018
Operations Management Puts the ‘Ops’ in DevOps

Awareness and anticipation of operational management, best practices can improve your app at every stage of its life cycle

How important or interesting you find the “operations management” aspects of DevOps methodologies likely depends on your background, experience and how many operational horror stories you have lived through. If you have been on the hot seat when services are impacted, woken up in the middle of the night when major outages occur or dragged into blame-battle war room calls while you and your team scramble to restore service, then the importance you place on operations management may be very high.

However, if you have avoided such experiences, it would surprise no one if the operations management aspects of DevOps are not top of mind. When everything is smooth sailing, then it is understandable that you might be reluctant to make any significant changes to your daily routine. However, in agile, fast-moving environments, things can go wrong very fast, even if your organization separates duties intentionally to create an “operational firewall” to keep ill-advised code or configuration changes to a minimum. Using effective ways to lend your app expertise to assist during impactful situations can make your life much easier and limit disruption to conducting your other duties.

You may work in an organization which is new to owning and managing operations management tools. It is becoming more common for organizations outside of a central IT operations team to do so as scopes of responsibility expand. Several analyst firms have published recent studies that nearly half of purchase and usage of operations tools is already done outside of IT operations teams. This trend is predicted to grow to the majority in a few years.

Configuration and automation tools are also becoming more commonly owned outside the data center. Such shifts in responsibility make efforts of operational skill-building, incident readiness and resolution more challenging. As the number of different groups deploying these tools expands, the likelihood of overload of notifications, alerts, events and general operational noise starts to rise dramatically. Note: I will be presenting a webinar on how new operations management tools can help you carry out the best practices, join me in this conversation Thursday, Oct 26.

Organizations deploying new apps and management tools in the cloud naturally look to manage those workloads from the cloud as well. Other organizations with legacy applications often are managing digital transformation leading to transformative projects for operations management. Whether your organization is already leveraging cloud-based tools or you are part of an organization undergoing transformation, you may have the challenge of a hybrid set of workload deployments, both cloud-based and on-premises. For your organization, this could mean finding a pragmatic complementary approach to deploy and manage the new, cloud-based applications and their associated management tools. Such an approach may not need to be isolated from your current tools and methods. Sufficient tool interoperability could support a federated, phased path.

In this blog series, we will explore the common operational challenges many DevOps teams are facing today, how traditional IT operations best practices could be leveraged for use in a DevOps methodology and how new operations management tools can help you carry out those best practices to meet your goals on an on-going basis.

Here’s a preview of the forthcoming blog topics:

Let the Noise Wail Without Going Deaf

Unless your applications and services exist in a vacuum sealed chamber of silence, agile development, continuous rollouts and updates and infrastructure system changes create a plethora of events that range in severity of impact, validity and meaningfulness. Those events tend to come from multiple monitoring and configuration tools or reflect many different parts of your applications and underlying services. This mixture of events and alerts leads to what is commonly known as operational “noise.”

Smart Ops Action: Taking the Right Action for Ops Traction

Empowering anyone in your organization who contributes to restoring service when incidents occur can ensure their time is well spent, with the intended results. All too often, operations teams effectively identify and triage incidents, yet fall short of empowering first responders to actually resolve problems. Bolstering your team’s efforts to take the actions necessary to resolve the situation at hand and restore service promptly is achievable—if done right.

Boring is Best! How Can You Thrill Your DevOps Stakeholders with Boredom?

Strive for stability and structure in production without stifling development agility. Don’t try to thwart the innovation and chaos that results from agile development and constant rollouts—get structure and stability where you have control so you can focus your talented team members to be supportive, valuable contributors to innovation and agility.

Fuel innovation and make your stakeholders smile with boredom by effectively turning chaos into stable operations.

If you’re a veteran IT operations practitioner with years of experience helping your company’s applications, services and underlying infrastructure run efficiently, these tips may be obvious. Hopefully you’ve been successful advocating these best practices to your development and line of business colleagues.

If you are new to operations—and especially if you are amongst the growing population of DevOps professionals who are understandably reluctant to conduct triage, investigation, diagnosis or resolution of operational incidents—rest assured there is relief. Tried-and-true best practices carried out with new, easy-to-use tools can empower your team to conduct these unwanted tasks like a seasoned veteran, regardless of operational experience. Learn more.

About the Author / James Moore

James Moore is Principal Offering Manager, IBM, responsible for offering management and strategy for IBM HybridCloud Operations Insight solutions including IBM Cloud Event Management, Runbook Automation and Alert Notification. James joined IBM from the Candle acquisition in 2004, where he was product manager for Candle’s Application Response Time product lines. James has over 15 years’ experience in event management, application performance management, and business service management. Connect with him on LinkedIn and Twitter.

October 16, 2017
Why DevOps is like fitness or religion
What is DevOps?

I noted in a blog post last summer that limiting DevOps to a single definition is challenging. The Wikipedia entry for DevOps contains a variety of possible explanations that seem to disagree in some ways:
- It’s a “software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals.”
- The goal of DevOps is “to maximize the predictability, efficiency, security and maintainability of operational processes. This objective is very often supported by automation.”
- It “targets product delivery, quality testing, feature development and maintenance releases in order to improve reliability and security and faster development and deployment cycles.”
- It “aids in software application release management for a company by standardizing development environments.”
All of these are true, and yet none of them is necessarily THE definition of DevOps.

A recent ZDNet post titled Why there will never be one do-it-all DevOps tool proclaims, “There is really no such thing as a specific DevOps “tool”—and don’t buy into the “DevOps” labeling many vendors are attaching to their solutions. Successful DevOps depends upon a multitude of tools and methodologies that can help organizations better align their software development and release cycles.”

The question, “What is DevOps?” isn’t like asking, “What’s the temperature today in Phoenix, AZ?” or, “What’s the fastest land animal?” Those questions have precise answers that are based on measurable, irrefutable metrics. The answer is the answer and it isn’t really open to debate.

“What is DevOps?” is more like asking, “What is the best fitness program?” or, “Which religious belief system should I subscribe to?” There is a vast array of answers and passionate beliefs on all sides. But, there really isn’t so much a “right answer” as a “right answer for you”.

When it comes to fitness, there seems to be as many diet and exercise programs as there are people trying to get fit. Books, magazines, and infomercials are filled with extraordinary examples that “prove” that a given fitness program or philosophy works…at least for the subject of the story. There are some elements that are universal truths like exercise is better than being sedentary, and making healthy eating choices is better than eating an entire cheesecake for dinner. Almost everything else is subjective. There are too many variables involved that make people, and how they respond to different diet and exercise programs, different.

DevOps is also like religion. Most people don’t choose their faith. They’re raised from birth to follow in the footsteps of their parents, and their religion is more or less predetermined. Religion is also personal. While some will insist that there is only one true faith and that theirs is the only real religion, most people recognize that religious faith is very subjective and it’s a function of finding the belief system that makes sense to you.

DevOps is like fitness and religion in that what it means to an organization, and how it is first implemented, is influenced by the existing culture and infrastructure—the IT the company was “raised on”. DevOps is also like fitness and religion because there is no “one-size-fits-all” answer to the question “What is DevOps?”

It isn’t a defined process—it’s more of a concept or philosophy. It isn’t a product or service that can be packaged and sold—it’s more a collection of the products and services that enable you to embrace the concept or philosophy. To some extent, DevOps is whatever works for your organization to automate routine tasks, reduce redundant effort, streamline operations, and remove unnecessary obstacles so people can get things done as efficiently as possible.
January 21, 2015