devopsy.kinsta.cloud

Tag: devops principles

  • Untapping the Potential of DevOps, Part 2: Common Mistakes

    Untapping the Potential of DevOps, Part 2: Common Mistakes

    Many companies are turning to software to differentiate themselves and drive success. But with an increased focus on software comes ever-increasing customer expectations on performance and updates. One of the best structures that IT organizations turn to is DevOps—a strategy that is designed to deliver value quickly and strategically.

    Being successful in DevOps takes careful planning and execution. Is the organization structured to execute on DevOps principles? Is the company aligned in culture and goals? But just as there are commonalities for success, there also are common threads that can lead to failure. When it comes to DevOps, it indeed holds true that failure is an opportunity to learn.

    With that in mind, here are three of the most common mistakes organizations encounter when diving into DevOps.

    Misunderstanding Goals and Definitions

    Many organizations are still grasping at a firm definition of DevOps and what it means for them. Simply labeling existing IT as DevOps isn’t going to make a difference. Furthermore, having clearly defined goals is key for just about any meaningful business endeavor. How can you know that you have succeeded if you don’t have a clear picture of what success looks like?

    Before jumping onto the DevOps train, first understand what it means for your organization and decide on concrete, measurable goals to make sure the transformation is adding value. One of the key benefits of DevOps is it lends itself extremely well to data and measurement. After all, DevOps is about delivering value with velocity. How fast can you get your solutions into the hands of your customers? How close to perfect can you get your releases through automation? This measurability is what makes DevOps so satisfying—embrace it. It is a great feeling to watch the performance of a new streamlined development pipeline improve.

    Fear of Change

    Being fearful of rapid changes and new technologies is a killer of innovation and success. An overly cautious approach with too much manual intervention will stifle the progress of a DevOps transformation. Understand there will be change and the change may be significant for your organization, particularly depending on the current structure and processes. One of the biggest changes may be culturally—DevOps certainly requires different tools and structures, but also requires a change in understanding about how your organization fundamentally views and delivers software. Use DevOps as a catalyst for change—the speed may be daunting but can reap major long-term benefits.

    Overestimating DevOps

    DevOps alone can’t re-calibrate applications or change corporate culture—real leadership is required to push through organizational inertia and bring teams together. This goes back to the cultural change mentioned above. Simply putting DevOps into place and then sitting back and waiting for results will not work. Teams will need DevOps champions, not just at the beginning, but always. DevOps is a constantly growing and changing strategy, built to adapt to customer demands. It holds great power to help teams perform at new levels, but people are always the most important. Empower teams to grow with this new strategy and enjoy the benefits of a sound DevOps strategy.

    Adopting DevOps is necessary to stay competitive in any market. However, while uniting people, tools and processes sound simple enough it can be a much more challenging feat than meets the eye. A DevOps transformation does not happen overnight and bumps in the road are to be expected. However, keeping in mind some of these common challenges can help keep the journey on the right track.

    Bottom line: Take it one day at a time and make sure to optimize a transformation for organizational goals and long-term strategy.

    — Jonathan Fries

  • Principles Systems and Tools – What Shingo Can Teach Us About DevOps

    Principles Systems and Tools – What Shingo Can Teach Us About DevOps

    In my last post, The Power of a Game: What I Learned from Facilitating the Phoenix Project Simulation, we explored how DevOps and Agile practices are built on underlying Lean principles that go back decades to a time before the Toyota Production System. When you look into the history of Lean, it is almost impossible not to encounter the great thinker Shigeo Shingo. Shingo worked closely with Taiichi Ohno (the father of the Toyota Production System) to advance Lean thinking while building the Lean production system at Toyota.

    As someone who attempted to apply Lean to IT long before DevOps came into existence, I have always said DevOps is about creating an environment where it is safe to look deeply, question what is happening, think crazy things, experiment and learn based on outcomes. Ten years ago, I was invited by The Shingo Institute to serve as a teacher, coach and assessor. I had recently been awarded the Shingo prize for my book, Lean IT – Enabling and Sustaining Your Lean Transformation. What I learned from Shigeo Shingo’s writings heavily deepened my understanding of the role of Lean and flow in IT. These ideas are reflected in the Lean Enterprise Pyramid below and it’s amazing how effective they are with Agile and DevOps.

    Principles and IT Excellence

    A principle is a timeless universal truth that controls outcomes whether you believe in it or now. Think of it as a fundamental truth or proposition that serves as the foundation for a system of beliefs and behaviors. Principles govern consequences and outcomes–both positive and negative. “Create customer value” is a core principle in business success. If you don’t believe in customer value, or don’t deliver it, your prognosis is pretty bleak.

    In Lean IT, I introduced some key principles that drive IT success:

    Let’s begin with a working definition of DevOps—a mindset, tool set and set of practices that combine software development and IT operations to shorten the development/operations life cycle to deliver small iterative features, fixes and updates often and in close alignment with business objectives and value creation.

    Consider the Lean principles pyramid from a DevOps perspective:

    • Foundation principles build an intentional culture of trust, respect, focus and learning.
    • Behavior is how we show up and engage.
    • Perspective is a fresh new way of looking at IT work.
    • Flow is the outcome of effective DevOps in action.
    • Capstone of the pyramid fosters a regenerative culture of trust, safety, experimentation, collaboration and innovation.
    • Outcomes are higher quality IT solutions and services, in less time, with less cost with healthier teams.

    For DevOps, Agile and High-Velocity IT of any flavor to be successful, each of these principles must be addressed. You can’t address them all at once, so I suggest beginning at the base while taking steps to enhance flow. If you focus on these two elements, respect for people and flow, you will always be progressing in the right direction.

    Systems and IT Excellence

    Shingo defined a system as a collection of tools and tasks highly integrated to accomplish a specific outcome. The Shingo Model captures the important relationship between principles, systems, tools and results. It also supports three key insights which clarify how to achieve excellence in IT (or any organization). IT needs to get good and then continuously get better with its systems, tools and results (no kidding). Understanding how these elements are informed and reinforced by principles is essential to making this happen.

    The Insights

    1. Ideal Results Require Ideal Behavior
    2. Beliefs and Systems Drive Behavior
    3. Principles Inform Ideal Behavior

    For DevOps and Agile, the Shingo Model provides a logical sequence for change. Put another way, what are the key questions we need to answer?

    1. What do the ideal behaviors of DevOps look like?
    2. What beliefs do our people have today and what beliefs do they need to embrace DevOps? What systems (think: work systems, procedures, policies and technology) do we have in place today, what behaviors do they drive and what needs to change?
    3. How can our understanding of lean principles clarify our understanding of question #1?

    Take a moment and reflect on the role of principles and systems in your transformation. The more you ground your approach in the stability of principles, the greater your chances of success. If you or your organization does not truly believe in these principles, a conversation around which principles you do believe in would be a good place to start.

    — Mike Orzen

  • G2G3 DevOps Simulation: Lessons from the Facilitator POV

    G2G3 DevOps Simulation: Lessons from the Facilitator POV

    The G2G3 DevOps Simulation is a three-round game that gives a complete immersive experience to the participants. It has software that’s controlled by the facilitator and used to see the performance and improvement in each round.

    As a facilitator, I help on the retrospective at the end of each round, as the participants share about what they did and didn’t do well. At the planning stage for each round, the participants decide what they want to change and get to see the result.

    Below is a list of what I focus on as a facilitator.

    Looking at the Same Objective

    Participants in the G2G3 DevOps Simulation learn that, regardless of role, their only objective is generating maximum revenue. This is the common goal. They can see this objective on the screen from the system. The participants begin to understand the goal on round two and by round three the objective becomes clear. This helps them to work in collaboration, working in a “squad” and helping each other to achieve that one common goal.

    Collaboration and Sharing

    The G2G3 DevOps Simulation gives the participants the chance to experience how collaboration and sharing helps in delivering stable products faster. Each team starts helping each other to ensure that their business makes the maximum revenue. They understand the need for delivering the outcome.

    The simulation also shows the challenges of communication between “run the business” and “change the business.” They experience how the communication drops between the two and how to take care of it with better knowledge management.

    Project-to-Product Approach

    The participants learn how to work as a squad—one single team responsible for both development and operations. They learn how the value flows from the time change is requested, until it is deployed and then the deliverable is maintained.

    Business is Most Important

    The G2G3 DevOps Simulation shows the participants that business is the most important—and IT is business. Everyone in the value chain must work toward the same objective.

    Automation

    The simulation also gives the participants the experience of how automation helps in achieving the objectives faster and better. This is clearly shown in the performance report at the end of each round and the comparison can be seen between rounds with more automation in place.

    DevOps: 3 Ways

    The G2G3 DevOps Simulation explains the basics of DevOps, bringing all participants to the same page on various DevOps terminologies, the principles (Three Ways) and DevOps values.

    Conclusion

    The G2G3 DevOps Simulation is a good practice for anyone in any organization who is on the journey of DevOps or is planning to start the journey. The best can be achieved if members from the various departments of the organization participate, which is required to deliver any change.

    — Niladri Choudhuri

  • In DevOps, Figure Out Why Before Considering How

    In DevOps, Figure Out Why Before Considering How

    It has been fairly well-established that DevOps is primarily a function of the underlying culture—about breaking down barriers and shifting roles so that teams and individuals are empowered to come up with innovative ideas and execute them without the burden of traditional corporate bureaucracy. It is also understood that there are a variety of tools and platforms that enable and automate processes. However, before an organization can even get to the “How”—the culture and tools of DevOps—it should be able to answer the question, “Why?”

    I reached out to organizations that have embraced DevOps and leaders in the field to see what they had to say about the “why.” What benefits can businesses expect, and what goals can adopting DevOps help them achieve—or achieve faster, or achieve cheaper?

    “Delay in delivering innovation comes with an increasingly high price tag, perhaps the loss of an entire market to competitors,” says Forrester Analyst Charles Betz. “DevOps accelerates and improves the quality of software delivery, but that is not an end in itself. The increased speed provided by DevOps is essential to achieving the fast product feedback needed for digitally transforming enterprises to stay relevant and competitive.”

    As Betz points out, companies should implement DevOps for the competitive advantage. Dave Lindquist, IBM Fellow and VP of Private Cloud for IBM, puts it another way: “DevOps is at the heart of the digital transformation. It’s how the next wave of disruptions are being developed and delivered.”

    DevOps bridges the gap between development and operations teams. Inspired by agile development and continuous integration, and incorporating their principles, it addresses the challenges of today’s condensed timeline for application development.

    In that way, the line between the “Why” and the “How” blurs into a bit of a gray area. Companies should adopt DevOps with specific goals in mind—a vision for what they expect it to do for them—because simply eliminating barriers or implementing tools and platforms without a strategy in place for what that is expected to accomplishment is likely to be a waste of time, money and effort. On the other hand, it is very difficult to execute or achieve those goals without also successfully navigating the “How.”

    “Enterprises are navigating major technology shifts and demand is therefore higher than ever for simple and consistent automation and management across hybrid infrastructure and application portfolios,” says Marc Holmes, VP of Product and Revenue Marketing at Chef. “Organizations should adopt DevOps practices for both the culture and tooling to create a consistent and collaborative workflow so enterprises can build, manage and deploy software quickly and safely in any environment.”

    “DevOps can have a direct effect on your bottom line. According to a recent study from Enterprise Management Associates (EMA), ‘Companies that excel at DevOps interactions are 11 times more likely to see double-digit annual revenue growth. It doesn’t stop at revenue growth either. According to EMA, 49 percent of organizations also agree that accelerated delivery frequency leads to higher customer satisfaction, and 35 percent find that it enables them to be more agile and competitive,’” notes Chris Lippi, VP of product at NGINX.

    With its focus on automation, DevOps also helps to ensure predictability, efficiency, accuracy and the standardization of operational, development and testing processes. This, in turn, saves time and money by shortening the release cycle, reducing errors and lessening the need for time-consuming fixes. It also frees up resources to focus on more creative endeavors and on tackling larger problems as they arise.

    Lippi sums it up this way: “Once implemented, DevOps tends to prove its business value in terms of time and cost savings. Making the business value of DevOps clear—to the newly unified team and beyond—helps DevOps culture take root.”

    There are lots of tools and practices out there to choose from, and plenty of guidance and advice on how to implement a DevOps culture. Before you go down that path, though, step back and figure out what you hope to accomplish by adopting the culture, tools and practices.

    — Tony Bradley

  • Good News: DevOps is not One-Size-Fits-All

    Good News: DevOps is not One-Size-Fits-All

    Want to try something fun? Ask different groups around your organization what “DevOps” means. It’s fun because the odds are good you’re going to get very different answers, many of which will be vague, if not outright contradictory. This is perhaps unsurprising when even industry-recognized DevOps luminaries tout varying definitions, approaches, tools and methods.

    Here’s what’s not so fun: trying to figure out how DevOps might look at your organization, and what resources and amount of time it would take to do it right. The one thing upon which everyone seems to agree is that “DevOps is a good thing” and something organizations ignore at their peril, in light of the significant competitive edge it provides.

    Here’s the good news: DevOps is not one-size-fits-all. In fact, there are many different facets in defining DevOps relative to your purpose(s). This article will identify some of the axes along which the answers to those questions fall, and sketch how they contribute to the overall picture. By the end, you should be better equipped to navigate your organization through the resulting, thoroughly non-Cartesian witch-space that is DevOps today.

    Axes and Allies

    My use of “axes” in the previous paragraph was neither random nor merely picturesque. It was chosen because it’s a bit of a chameleon, the only English word that can be the plural of three separate noun forms. In short, you don’t know what the word means apart from context. The same is true of DevOps.

    Linguistic pedantry aside, DevOps grew out of the organizational friction between developers and operations, hence the name “DevOps.” But the DevOps movement pearl unquestionably has been layered and shaped by the oyster of today’s development trends: the increased (if not nearly exclusive) focus on web and mobile applications. This is simply because it’s an easy fit, those products often being much simpler to build and deploy than legacy applications.

    This gives us the first axis: the industry (or industries) in which you compete. If you’re building the next great social networking site—please don’t, I beg you!—you’re going to have a tough row to hoe. And you’re going to have to do at at the speed of Web whatever-dot-oh. Because continuous deployment isn’t an option for you; it’s your personal Obi DevOps Kenobi (your only hope). Yet, at the other end of the spectrum, even the most legacy-heavy manufacturing concern can benefit from DevOps principles, though the requisite pace of innovation should be rather lower.

    Industry also can determine the degree to which you accumulate necessary but hard-to-satisfy stakeholders. In the medical industry, for example, keeping your compliance department happy is both essential and more than a full-time job in itself. The DevOps drive to deploy quickly will run straight into the sort of bureaucratic inertia one expects in a heavily regulated industry. You’ll likely need to temper your DevOps expectations and shape your processes to deliver and archive additional content if your industry is more legacy than modern.

    A second axis around which DevOps revolves is the type and level of maturity of products you deliver. The more you lean toward legacy products, languages and processes, the more you’ll likely need to scope and direct your DevOps efforts differently, depending on the answers to a variety of questions. For example, it’s rather a different thing to build, test and deploy a monolithic C++ application than an app intended for the web or mobile devices.

    Ask yourself: How complicated are the true essentials of your build process? Which parts can you tighten? Can you isolate and prebuild components and leverage an artifact management system? What build artifacts must be retained to satisfy support, compliance and other stakeholders relevant for your industry? You’re going to need tools that can handle the load in every sense.

    Similarly, how much testing can you realistically automate for the best payoff? And what sorts of testing will give you the strongest guarantee of success for the effort? Unit tests are a good start, but have you automated your all-up functional tests? What about UI testing? Stress testing? Again, the type of industries you serve and the type of products you create will generate different test demands and degrees of time and effort to automate your test suites.

    A third axis along which to evaluate DevOps is your organizational culture. I’ve heard “legacy” defined as code lacking unit tests, but this seems incomplete. I’d suggest that, in fact, there’s a legacy state of mind as well, by which I refer to the sort of inertia that accretes in products and organizations over time. You’ll find it expressed in “the way we do things.” If that phrase is a discussion-ender at your organization, then you’re going to have a much more difficult time embracing DevOps.

    What allies can you bring to the table to push for necessary change? Attending a DevOps conference or event can connect you with experts with experience in your industry who might be able to recommend materials. The more your organizational attitude “leans toward legacy,” the more you’re going to need a thick bench of allies to make DevOps a reality.

    Leaving a Good Legacy

    If it seems as though I’ve been hammering on the notion of legacy in all its forms, I have. But it’s important to recognize that legacy isn’t always a bad thing; in fact, legacy applications are essential to a non-trivial fraction of our world. Not every need can be met with a web or mobile app. It can be very difficult to tame the legacy beast in all its forms, but it’s nearly always possible to at least trap it in a well-defined cage, then shrink that cage over time.

    DevOps principles can raise your game no matter how legacy your industry, products and personnel are. But it’s important to understand where you fall on all the relevant axes to determine the right scope, methods and tools to deliver the most value. DevOps isn’t one-size-fits-all, but it can be tailored to fit in at your organization.

    About the Author / John Williston

    jwillistonJohn Williston is a veteran software developer for Windows, .Net, and the web. He is currently a product marketing manager at Perforce Software.

  • An Introduction to DevOps

    An Introduction to DevOps

    What is DevOps

    You can ask 10 people for a definition of DevOps and likely get 10 different answers.

    If you want to find a definition of your own, your research will probably begin by asking Google, “what is DevOps”. Naturally, Wikipedia is one of the first result so that is where we will begin. The first sentence on Wikipedia defines DevOps as “a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals.” Well, that’s a fairly dense definition, yet still pretty vague. I think DevOps can be explained simply as operations working together with engineers to get things done faster in an automated and repeatable way.

    So let’s delve into how DevOps works and can better adjoin two traditionally opposing departments.

    Growing pains

    When you are responsible for large distributed applications the operations complexity grows quickly.

    • How do you provision virtual machines?

    • How do you configure network devices and servers?

    • How do you deploy applications?

    • How do you collect and aggregate logs?

    • How do you monitor services?

    • How do you monitor network performance?

    • How do you monitor application performance?

    • How do you alert and remediate when there are problems?

    Combining the power of developers and operations

    The focus on the developer/operations collaboration enables a new approach to managing the complexity of real world operations. I believe the operations complexity breaks down into a few main categories: infrastructure automation, configuration management, deployment automation, log management, performance management, and monitoring. Below are some tools I have used to help solve these tasks.

    Infrastructure Automation

    You no longer have to build a server from scratch, buy power and connectivity in a data center, and manually plug a machine into the network. After wearing the operations hat for a few years I have learned many operations tasks are mundane, manual, and often have to be done at two in the morning once something has gone wrong. DevOps is predicated on the idea that all elements of technology infrastructure can be controlled through code. With the rise of the cloud it can all be done in real-time via a web service. Infrastructure automation solves the problem of having to be physically present in a data center to provision hardware and make network changes. The benefits of using cloud services is that costs scale linearly with demand and you can provision automatically as needed without having to pay for hardware up front.

    Configuration Management

    Configuration management solves the problem of having to manually install and configure packages once the hardware is in place. The benefit of using configuration automation solutions is that servers are deployed exactly the same way every time. If you need to make a change across ten thousand servers you only need to make the change in one place.

    There are other vendor-specific DevOps tools as well:

    In the operations environments I have worked in there were always strict controls on who could access production environments, who could make changes, when changes could be made, who could physically touch hardware, and who could access what data centers. In these highly regulated and process oriented enterprises the thought of blurring the lines between development and operations seems like a non-starter. There is so much process and tradition standing in the way of using a DevOps approach that it seems nearly impossible. From an operational perspective, my first instinct is to understand the application architecture so I can start thinking about the proper deployment model for the infrastructure components. From a development perspective, my first milestone is to make sure the ops team fully understands the application and what it takes to deploy it to a pre-production environment.

    DevOps isn’t just a set of tools, but a philosophical shift that needs that requires buy-in from all folks involved to truly succeed. It’s only through a high-level of collaboration that things will change for the better.