devopsy.kinsta.cloud

Tag: devops philosophy

  • Successful Digital Transformation Starts With Developers

    Successful Digital Transformation Starts With Developers

    Digital transformation (DX) continues to be a primary focus as companies both large and small look to become more agile, improve and accelerate the delivery of product and service offerings and enhance data-driven business decisions. The C-suite typically leans on IT departments and developers to champion such transformations, designing the software and tools that will lead the experience both internally with staff and externally with customers. The challenge often lies in the fact that most organizations lack the software resources to drive a successful transformation. In addition, research has found that 45% of executives don’t know where to start with DX projects, resulting in added pressure on the developers who hold the technical knowledge but may lack the managerial expertise for a successful rollout.

    So, with IT having the opportunity to be the hero or the scapegoat of a DX initiative, where should development teams start? Typically, digital transformation requires development transformation, so you can start at home, by modernizing the way you develop and deliver software. Doing this also significantly improves the odds of a successful digital transformation and puts development in the driver’s seat.

    Here are four factors to prioritize before kicking off a DX project:

    Buy vs. Build

    A DX initiative requires a number of digital tools and software applications, some of which can be purchased through third parties while others may need to be built in-house, depending on the desired goals of the program. Organizations must determine whether they want to build or buy new software solutions, and the answer is almost always mixed. Most developers believe that each application can be built in-house, while the C-suite often encourages purchases from a third party to accelerate adoption. Before starting to code, ask yourself if the solution you need should be bought or built. Oftentimes, the same goal can be achieved through a purchased solution, empowering you and your team to spend more time customizing those solutions rather than starting from scratch while focusing on the projects that will have the biggest impact on the business—ultimately accelerating time to completion.

    Accelerated Rate of Change

    Once applications are built and available to the public, you can expect bugs to be identified and requests for improvements to be made at an accelerated rate. Developers are constantly making software updates, but when applications are being used to support DX, the rate of change for business requirements is going to speed up, especially when those applications are customer-facing. Developers will need to learn fast and iterate quickly, so it’s important to establish an agile culture within your team.

    Adopting a DevOps philosophy often will be the most successful approach, as it enables your team to test and troubleshoot quickly and enact change across the platform. This approach also assists the rest of the organization in adopting DX practices, delivering a more seamless experience and universal data-sharing. Developer teams must be wary of traditional quarterly or annual planning cycles that create silos, slow agile processes and hinder successful implementations. By breaking down these silos, your team will gain better insight into what is and isn’t working and enable swifter improvements, creating a culture that embraces the changes that come with DX.

    Modular Software Architecture

    Software architecture is incredibly important, as it directly impacts the team’s ability to react to rapid change. A more loosely coupled, modular architecture puts the developer team in the best position to evolve quickly with fewer dependencies, enabling them to make updates and replace components over time to meet business objectives and customer demands. The ability to reconfigure or replace components without having to recode the entire system also assists in build-versus-buy decisions, with developer teams purchasing add-ons to incorporate into a system and solve problems quickly.

    DX Outside of Organizational Barriers

    We work and collaborate in a digital ecosystem. External APIs, third-party data-sharing and interoperability are all requirements as organizations roll out new tools as part of a DX initiative. DX comes down to building a digital ecosystem that flows outside of the organization, whether it is employees working remotely or customers integrating your tools into their existing solutions. Your company’s software needs to accommodate these capabilities to enable a more seamless and well-rounded DX approach.

    DX is a Journey, Not a Destination

    A successful DX initiative should be seen as a culture shift, not an end result. The digital world is not static, and DX is a practice that enables an organization to learn fast and be lean and nimble. As soon as you’ve reached one milestone, there’s a whole new set of rules to play by to get to the next, requiring the developer team to recalibrate. By taking a realistic, process-oriented approach, the developer team will have the mindset and tools necessary to make DX successful.

    — Jeff Fried

  • DevOps’ Chicken Or Egg Origins

    DevOps’ Chicken Or Egg Origins

    When acolytes explain the DevOps movement to the uninitiated, they usually run into a chicken and egg line of questioning. What is DevOps, really? Is it a culture? Is it a pattern of processes? Or is it a technology? What comes first?

    The ratios of the perceived importance of each of those elements may shift depending on who you talk to in the DevOps community. But the inevitable answer to these questions is usually that DevOps depends on at least a little of all of them, but probably on culture above all else.

    “I think it’s first and foremost cultural. The development team is a tribe. So is operations.  They have norms.  They have things they value.  They have things that they reward and admonish,” says Josh Corman, chief technology officer for Sonatype, a component lifecycle management firm. “Developers are incentivized to cause change.  And ops people are incentivized to prevent change, to promote stability.  So they were natural enemies.  And when they work it out and align to each other’s tools and incentives, they’re able to go faster.”

    Therein lie the historical roots of DevOps, agrees Andrew Storms, senior director of DevOps at cloud security firm CloudPassage, who explains that it is an answer to the blame game that inevitably occurs in the old model.

    “I think that existing corporations or companies or groups are probably doing DevOps in response to existing pain,” he says, explaining that in previous non-DevOps shops he worked at, it was inevitable that development would write a piece of code, throw it over the fence and let ops catch the heat when trouble brewed. “The question is, why is the person at the end of the train always feeling the pain for something that originated at the beginning of the train? To me, DevOps says, ‘There is no train.’ There’s no more division of who’s in trouble for anything. Everybody is on the same darned team.”

    It’s for this very reason that Jez Humble, a principal for the consultancy ThoughtWorks and co-author of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, says that the fundamental ingredient to successful DevOps is trust.

    “You need to trust each other. Developers can’t just assume the ops people are all dumb and don’t know anything about code or are just command line monkeys. And the ops people can’t assume the developers don’t know anything about how systems work in real life,” he says. “These assumptions make it all a big finger-pointing exercise.”

    A lack of trust is the underlying roadblock to better teamwork between dev and ops, but it can be difficult to achieve within enterprises.

    “In small organizations people trust each other because they can see each other and work with each other and must learn to trust to get anything done,” he says. “But as organizations scale you lose that human contact.”

    It’s replaced instead with brittle and bureaucratic processes that only feed into those distinct walls between each tribe. However, as organizations feel the pain that’s inflicted by those bureaucracies that have evolved so far in IT and by the walls thrown up as a result, they face a choice. Engender that trust and a culture that allows  dev and ops to simplify processes and tear down the walls, or face further roadblocks that will hurt the business.

    From there, it is a matter of establishing behavioral and process patterns that are a hallmark of DevOps cooperation.

    “I think ‘patterns’ is the right word for it. People get hung up on this textbook or technical definition of DevOps.  And while there are certain common processes and things like Kanban boards and Scrums, and sometimes it’s a hybrid of Agile, sometimes not that ,” Corman says, “what matters the most is an attitude to fail fast and iterate, to continuously look for ways to increase flow, to automate, instrument and find and root out weakness. And to be responsive to new ideas of the business, or new ideas of your install base, or new market pressure.”

    According to Corman, the beauty of DevOps is that it’s a ‘jump ball’ for IT, so there are no set processes that make or break whether a shop is DevOps or not.

    “It’s in a state of flux, and the cement hasn’t dried.  It’s a singular opportunity to redefine the way we engage with the business and drive value, the likes of which we will not see again for 30 years,” he says. “It’s very, very rare.”

    And while few within the DevOps community would say it is defined by technology, it certainly is enabled by it.

    “To me it is more a cultural shift than a tool shift, but that tools shift presents a huge change in the way IT runs,” Storms says, explaining that instrumentation and orchestration tools like Puppet and Chef makes it possible to achieve continuous improvement and fast iterations. “So does it come about through the cultural change or the technical change? I think, actually, neither. I think it happens at the same time. That’s the force multiplier, that two plus two equals five kind of thing.”

    But like tectonic shifts, changes in IT happen sometimes all of a sudden, but mostly in increments.

    “One part of it is focusing on what we can do every day to make things a little better for everybody. You have to proceed incrementally and accept that it’s going to take time,” Humble says. “You can’t say, ‘Well, we’re going to adopt Agile now across the whole organization—go!’ There has to be enthusiasm from the people on the ground to do this stuff and then you have to work together though a process of experimentation and trial and error to work out how to make it work in practice, probably with a small group of people initially.”

    Even with that force multiplier, Storms says, you’ll still see positive steps forward by establishing an element of DevOps one at a time.

    “Even if you’re in a difficult situation where you can’t have the force multiplier of culture and technology changes at the same time, just one or the other is still going to be a big win,” he says. “Let’s say you just took the one piece of ‘Let’s move our dev and ops teams together and make them be friends,’ you don’t necessarily have to orchestrate and instrument like crazy to win. But you can also do the opposite and just picked the orchestration piece and say, ‘Hey, ops people, stop doing things by hand.’ You send them to Chef conferences and make them learn Ruby and guess what? Their skill sets just went through the roof.”