DevOps gives wing to your development efforts Would you revolutionize your development practice if it could get faster, better, and more strategic for the business? DevOps is a fast-evolving discipline with the potential to accelerate your development efforts. It can align developers and technologists with business objectives in a culture of collaboration that allows everybody to contribute from their talents and skills. It’s all about gathering the best people for the job and enabling them to succeed. In this ebook, we consider what it takes to pull off a successful DevOps practice and see it through to achieving the outcomes the business needs. Understanding DevOps and its enabling culture . . . . . . . . . . . . . . . . . . . . . . 2 A short crash course on the history of DevOps, the ideas behind it, and the key elements in making the effort succeed: talented collaborators scaling new heights, using purpose-built technologies and proven practices.
Defining DevOps DevOps, short for development operations, is a discipline adopted by companies that create software either for internal use or for sale to customers. DevOps is a set of team roles, tools, values, and processes that enable developers and IT operations to build, deploy, and continuously improve the best possible code with great speed and efficiency.
Building momentum for excellent innovation. . . . . . . . . . . . . . . . . . . . . . . . . . 6 Collaboration translates into speed and top-quality development efforts when your teams can rely on optimized infrastructures and processes. Important practices include continuous integration and deployment (CI/ CD), multilevel testing, measuring results, and ensuring the integrity of data and applications. Creating a compelling business case for DevOps. . . . . . . . . . . . . . . . . . . . . . 9 Don’t adopt DevOps just because it’s a great idea, although it is. You can project a likely ROI and tangible benefits from DevOps based on waste you can eliminate and measurable improvements you can achieve. Other companies’ successes help you determine what to assess and track as you begin and evolve a DevOps practice. Getting started today. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Assemble the right people, give them a purpose and an environment to unleash their creativity, and define an evolutionary approach to DevOps based on business priorities.
1
DEVOPS FOR FASTER, BETTER DEVELOPMENT
UNDERSTANDING DEVOPS AND ITS ENABLING CULTURE DevOps—short for development operations—is an essential discipline that you can’t do without when you develop and deliver microservices or want to benefit from an agile development approach. However, you can achieve better business outcomes with DevOps even if you decide not to create microservices or are still in the early stages of adopting agile methodology. Experienced development and program managers insist that DevOps should be an element of every software development effort. They will also warn you that DevOps is not a shot in the arm for IT operations that lack momentum or efficiency. Companies should not encourage their technologists and developers to think of it in these terms and approach the DevOps team with assistance requests that are ultimately unproductive.
DevOps history 101
DevOps started in 2007 when Patrick Debois, an agile developer from Belgium, decided it was time to resolve nagging frictions and bridge procedural and cultural gaps between teams of developers and IT operations. Debois saw that agile practice could serve as a framework for more connected and productive ways of working, and it also could guide infrastructure management in addition to software development. The DevOps approach was further defined by people meeting at Velocity conferences. It took off when the people responsible for some of the world’s largest, high-traffic websites adopted it. The key idea behind DevOps is that the business is not receiving the best value when the development team simply hands code to technology operations. Under these conditions, users don’t receive new functionality as efficiently as they should, and disparate development and operations teams never do their most productive work. DevOps bridges the gap between creating new software code and bringing the functionality to users by means of optimized, generally automated processes and an infrastructure that can facilitate a fast, ongoing succession of testing, deployment, and integration steps.
2
DEVOPS FOR FASTER, BETTER DEVELOPMENT
DevOps as a cultural evolution in your business
Process automation and creating an infrastructure for continuous integration and continuous deployment (CI/CD) is critical to achieving the scalability of code development, quality assurance, and deployment in one uninterrupted flow. Just as important is creating a culture where developers and operations teams work together seamlessly. The effectiveness of even the most powerful automation tools and optimized processes will be limited if you can’t rely on people taking full advantage of them or of the concepts behind them. That’s why many DevOps experts maintain that fostering the right culture is Many DevOps experts the most foundational and urgent effort that has to maintain that fostering happen for DevOps to succeed. When you review the DevOps experiences of different companies, it soon becomes clear that all of them have introduced automation as much as they can, and most rely on sound processes and tools for monitoring code quality. But they are far apart when it comes to DevOps team culture and sharing.
the right culture is the most foundational and urgent effort that has to happen for DevOps to succeed.
Who should be on the team?
The cultural change to enable DevOps rests on the attitudes and skills of people. On your DevOps team, you need a spectrum of skills, such as developers, solution architects, infrastructure experts, cybersecurity specialists, and database administrators. But not everyone will be a good fit for the DevOps environment. In addition to mastering their art, your DevOps people need to understand what drives the business and what its goals and strategy are. That also implies open communications and alignment with the product owners who are in many companies the role that identifies and prioritizes business requirements and presents them to developer teams. DevOps, developers, and product owners alike need to have the ability to see their work in the context of the organization’s objectives and in its impact on everybody else on the various teams. DevOps contributors have to know, for example, how to code, automate, or test, but they also need to be committed to understanding and connecting with their developer and business colleagues and performing their projects from a holistic perspective. Practically by definition, anybody joining a DevOps team should be ready for a collaborative, team-centric approach to reaching shared goals. For many of us, that was not what professional training and skills development looked like, so this can be easier for some people than others, even with the best of intentions. Flourishing DevOps practices almost always involve a number of people with a rich, well-rounded experience in multiple disciplines—development, architecture, security, database management, quality assurance, and so on. These individuals are more likely to have
3
DEVOPS FOR FASTER, BETTER DEVELOPMENT
the required empathy and broad perspective that enable cross-team collaboration than people who have dedicated their entire working lives to one aspect of the art of technology. Some professionals will thrive under those circumstances, and others will prefer to exercise their skills without worrying about the big picture. It’s almost impossible to challenge and change these fundamental attitudes. However, professional generosity and collaboration have the potential to unleash a level of creative genius that more isolated, traditional practices lack. Without the basic drive to working in sync with the entire team it’s usually not realistic to expect, for example, that a developer will focus on the handful of lines of code that address an issue instead of remaining content with thousands of lines of code that could achieve the same result with much greater labor and complexity.
Professional generosity and collaboration have the potential to unleash a level of creative genius that more isolated, traditional practices lack.
From the pioneer stage to a mature practice
Some companies have asked their first, small, newly formed DevOps teams to work a subset of required software functionalities to establish their working methods, ensure optimal interpersonal chemistry, resolve potential process inefficiencies, and validate their tools in a proof-of-concept. An explorative project could also be a model for prioritizing efforts based on what the business’ priorities are, and it can help establish a consistent, centralized process for feature requests to be adopted and moved forward by the DevOps team. Equipped with findings from the proof-of-concept, the team can introduce whichever improvements that make sense before they broaden DevOps into a standard practice for all development efforts and hire more people for it. That gives the company a checkpoint to understand what might change for the better with DevOps and make sure the executive team is fully on board and committed to making DevOps successful. Businesses should not push the people in a new DevOps initiative to achieve immediate results. It can take several weeks before the team has created a good blueprint for an expanding DevOps practice. Companies unintentionally sabotage their DevOps initiatives when they understaff their DevOps teams. As a rule of thumb, a ration of ten developers to one DevOps team member is healthy and sustainable. Failure becomes more likely when a single DevOps manager has been made responsible for an effort that demands a concerted team. The person in that function will not be able to engage in real collaboration, but is reduced to a sort of approving or coordinating role. It’s questionable if that could still be seen as a real DevOps practice.
4
DEVOPS FOR FASTER, BETTER DEVELOPMENT
The right tools align with your goals and company culture
Many tools are available to help you automate and manage CI/CD, testing, team communications, and just about any process you can imagine, including monitoring, service discovery, configuration management, and ensuring security. As with any software selection, use your best evaluation practices and perform exacting diligence before you commit to a product. Talk to the vendor’s other customers, perform a controlled proof-ofconcept, and make sure any tool-related conversation and action keeps in mind the results your DevOps practice has to produce for the business. It’s important that software tools are easy to use and make content and communications searchable and readily available. Their effectiveness entirely depends on the users in your teams. Even powerful software cannot change people’s attitudes, but it can help them collaborate and achieve shared results when they are ready to step outside of their individual limitations.
Your best practice is making sure that software tools can help you reach your goals, not adopting a widely used product as the safest choice.
You might think of popular or often-discussed software products as de-facto standards, but alternatives remain available and might fit your needs more closely. Your best practice is making sure that software tools can help you reach your goals, not adopting a widely used product as the safest choice. Also, not every DevOps practice relies on specialized tools. Some DevOps teams and developer organizations make documentation available on internal blogs and will even include in position descriptions that new hires should read the published articles. Elsewhere, DevOps team members are tasked in rotation with giving presentations and demonstrations about critical aspects of their work or the direction of their projects.
5
DEVOPS FOR FASTER, BETTER DEVELOPMENT
BUILDING MOMENTUM FOR EXCELLENT INNOVATION The key result for any DevOps practice is continuous improvement for the business in its journey toward objectives everybody in the organization understands and supports. That, in turn, requires progressively improving code—the constant flame that keeps companies alive and growing. And those steady code improvements require practices and infrastructures that enable gifted people to make a strong contribution with an unceasing momentum. Often, this is represented as striving for the highest possible levels of automation and extensive, multilevel testing and monitoring with sustained feedback loops to the developers. But automation, testing, and monitoring need to happen in front of the strategic backdrop, or they’ll sooner or later run out of steam, leaving people disoriented.
‘Continuous’ never stops
For many DevOps practices, CI/CD provides a great framework for delivering code that can make ever-improving business outcomes possible while reducing cycle times. Like DevOps itself, CI/CD involves a cultural and practical team realignment and tends to succeed more easily when it’s supported by top-level executive sponsorship. Continuous integration feeds into continuous deployment and relies on a pipeline of code to be processed. The right tools can help streamline this effort, which largely depends on the collaborative openness of the contributors. Creating and maintaining a pipeline that syncs with business priorities is an important endeavor that needs to be planned well for the automation of coding, integration, and testing to be truly effective and not simply mechanize an otherwise haphazard process. Netflix has shared its DevOps experience, including dramatic improvements in the speed of integrating, testing, and delivering new code. Results like these take strong teams of talented people to be unalterably committed to their shared success and that of the company. They also require thorough, holistic planning and thought, appropriate budgeting and resource allocations, and diligent selection and successful
6
DEVOPS FOR FASTER, BETTER DEVELOPMENT
deployment of the right tools and infrastructures. The most successful CI/ CD practices are those where stakeholders took the time to optimize their processes and determine which activities to automate, what sequence to follow in doing so, and what automation should look like when fully operational. The most successful CI/CD practices Almost as important, they had to decide what not to automate, or at least not with are those where stakeholders took the a high priority. Finally, they had to draw on time to optimize their processes and their creativity and resourcefulness to get the development, DevOps, and testing determine which activities automate, teams to work hand in hand.
Before code reaches users
what sequence to follow in doing so, and what to automation should look like when fully operational.
You sometimes find that people imagine continuous deployment as providing capabilities to users, but that is not what it means. Continuous deployment really refers to implementing newly written code in a non-production environment and thoroughly testing and troubleshooting it before certifying it as ready for delivery to users. The DevOps team will always work in rapid sequences of integrating and testing code, but business stakeholders should get to decide how it is to be released, and to which user population. Validating new code in a production environment is generally seen as a “worst practice”—the risk of disrupting processes and user productivity is not acceptable. To avoid compromising the master software, many teams work with a clone. They use this to review their code and address issues before they commit it.
Measuring your results
If you can’t measure your improvements, they don’t really exist, and it becomes difficult to build on them. At the least, metrics for assessing the success of automation should include reductions in repetitive, time-wasting efforts that dilute team efforts. Monitoring needs to keep tabs on the health of system components and allow technologists to immediately respond to potential failures or opportunities for performance enhancements. Many CI/CD teams research the most meaningful metrics and package them in a dashboard or other indicator that is easily consumable for the people who need to see it. Graphic displays similar to traffic lights are popular especially with extremely busy stakeholders. Known examples of metrics chosen intuitively or almost randomly before determining their relevance are usually associated with a loss of direction or failing efforts.
Security concerns finally receive the attention they deserve
Security is an overwhelming, high-priority concern almost anywhere in the realm of digital technology, but it has only recently become prominent
7
DEVOPS FOR FASTER, BETTER DEVELOPMENT
in DevOps and CI/CD. Given that CI/CD and the continuous deliveries of software capabilities to users are highly consequential for businesses and expose global infrastructures to new code, the potential security risks are significant. This aspect of the CI/CD discipline is evolving rapidly. Currently, approximately half of the companies practicing CI/CD perform security testing while the others leave that gap open until later, or don’t address it at all. The common perception by engineers and developers that security testing will slow processes When you introduce security and delay code delivery does not help matters. However, the right configuration and customization measures and testing into your of the testing tools can avoid even minor slowdowns.
CI/CD, they have to harmonize
Today’s security testing tools are not yet easy to with the organization’s security integrate and automate within the CI/CD process. Many DevOps teams are optimizing tools to run and data management policies. incremental, static application security tests that can connect to their tracking systems and metrics dashboards to highlight possible concerns. Most security testing tools come from an older generation of technology and don’t smoothly fit into today’s cloud-centered environments with containers and microservices. Technologists are making progress in updating these resources for the cloud era, so they can operate with microservices and containers without disrupting them. This requires changes in how application security testing tools create and store data and how they accommodate such conditions as the always changing IP addresses of containers. When you introduce security measures and testing into your CI/CD, they have to harmonize with the organization’s security and data management policies. You also need to help the DevOps and developer teams understand that they have a dual role when it comes to cybersecurity: they are impacted by effective security and could find their identities, intellectual property, or processes at risk if security is weak. In an initial response to mounting concerns, some companies have increased the emphasis on security by making developers accountable for it to the same degree that they are responsible for software functionality.
8
DEVOPS FOR FASTER, BETTER DEVELOPMENT
CREATING A COMPELLING BUSINESS CASE FOR DEVOPS When you potentially disrupt career trajectories and established notions of how work should be done, you can expect pushback. It’s one thing if current practices have been failing and the health of the business is poor. But when it comes to DevOps, microservices, or agile methodologies, you aren’t likely to come across failing companies. Instead, you encounter highly successful businesses and gifted people who are committed to making a greater impact. Organizations may chart their own, convoluted paths to implementing DevOps, and the effort may look overly complex or costly in the interim, before it yields results. What you may run into are such manageable obstacles as cultural roadblocks, resource constraints, or unrealistic expectations that demand dramatic results too soon. As you establish the business case for DevOps, it’s helpful if you can point out successful experiences from other organizations to demonstrate that the approach works. Those are readily available. You can learn from and about Netflix, Facebook, Amazon, Twitter and Pinterest, and other enterprises. Resources like TechBeacon and Stackify have provided highlevel summaries of DevOps success stories.
If there is a DevOps ROI, how can I measure it?
There is no agreement as to whether it’s appropriate to look for a return on investment from DevOps. Some say doing so is misguided and cannot be done in a meaningful way, because it is too difficult to tie DevOps investments to financial outcomes. Instead, you should try to assess if the ROI of your software product is improving. That debate is neither settled nor does it look like it’s soon going to run out of steam. That means there’s something potentially to be gained from attempting to establish the ROI of DevOps—especially in the case of companies that have newly implemented the practice after developing and launching software in a different way. In any case, it’s neither easy nor meaningful to try to separate the costs and returns of DevOps from
9
DEVOPS FOR FASTER, BETTER DEVELOPMENT
an evaluation of the entire development organization, together with its infrastructure and resources. The DevOps emphasis on meaningful, tangible, achievable results lends itself to applying measurements. You can with relative accuracy determine the cost differences in people’s time, software tools, computing power, and infrastructural resources. Organizations generate waste Depending on the scale of your effort, the cost impact of DevOps on power consumption in your data center when they do not define could be significant if you reduce your draw on server their business requirements and storage resources, or if processes become vastly more efficient or faster. and let development pursue
Identifying the costs and impacts of waste
directions that don’t align with what users need.
If you are steeped in agile and the underlying lean principles, you can find ways to identify waste in your development processes—even if the outcomes were great and the business is successful. Companies are reluctant to go on record about this, but one hears about it from developers and technologists at events, or in their blog posts and other publications.
Organizations generate waste when they do not define their business requirements and let development pursue directions that don’t align with what users need. They also produce waste when they don’t dedicate enough of the right people and skills to agile development. Or, when they don’t consider their resources and processes in a holistic, contextual manner and create expensive, productivity-killing bottlenecks—for example, when testing cannot keep up with development, or when opportunities for automation and streamlining in processes are disregarded. Waste is also produced when companies’ agile practices are not mature and there is a huge deployment backlog. In other organizations, waste may be generated late in the software lifecycle, when there is no effective feedback channel from customers and users to drive product improvements, and developers’ efforts are partly misguided. When it comes to new technologies, companies often create waste by spending too much, effectively subsidizing somebody else’s experimentation, or because team members may not understand how they can operate innovative products at optimal efficiencies. Many businesses invest far too much in servers when they could instead consolidate services and resources, and achieve better performance, by virtualizing or shifting applications to the cloud.
Assessing the value of improvements in code and business operations Many organizations have found that CI/CD makes it possible for them to accelerate development cycles and yet produce code with greater
10
DEVOPS FOR FASTER, BETTER DEVELOPMENT
quality. If your organization is in the business of selling software to other businesses, DevOps and CI/CD could reduce your time-to-market and make it easier to meet customer commitments. Those changes, in turn, could have a substantial financial impact. If your new code is launched and used in-house, assessing the difference may not be as straight-forward. The better a job you did at defining your user stories and aligning your development and DevOps teams with business priorities, the easier it will be to connect DevOps with such positive changes as:
»» Improved performance and responsiveness of applications »» Increased user productivity »» Faster, more accurate business processes »» Higher employee satisfaction and retention »» Greater momentum of innovation in engineering or product design groups where people rely on the functionality you provide
Such events have a financial aspect and contribute to the ROI of DevOps. However, it may take lengthy, painstaking research to verify and document this. Much of what you will be interested in measuring is negative and therefore hard to come by. You need to think about, research, and document observable changes in, for example:
»» Application crashes »» Flagging user productivity »» Slowing processes »» Customer complaints »» Other undesirable events that no longer happen, or not with the same frequency as before
When you no longer experience certain problems, their cost impact also disappears, contributing to your DevOps ROI. Be warned: negative events can be difficult to measure with any accuracy.
11
DEVOPS FOR FASTER, BETTER DEVELOPMENT
GETTING STARTED TODAY DevOps is neither magic nor mystery. The practice is still relatively new and evolving rapidly, but you can take advantage of documented best practices and case studies to get off to a good start. The right tools and infrastructure elements are essential, and you should consider them right after the top priority: the people, attitudes, and skills you need on your DevOps team. Attracting the right professionals and enabling their success is where most of your attention and energy should be directed. The company’s executive and technology leadership need to sign off on any DevOps efforts and be apprised of any news from team leaders. The HR exec will be one of your most important partners in long-term DevOps success. Keep in mind that DevOps is not now or never. You don’t need to convert your entire current development organization to a DevOps shop when you start out. Select an area where you can spot waste and name opportunities for improvement, or identify a software capability where it would make a real difference for the business to have it created faster or at better quality. Run a limited, closely defined DevOps trial with your most talented and committed people, evaluate the results, resolve the bottlenecks, and expand it when you and the team feel ready to expand the effort.
Read our related white paper on microservices.
About Tiempo Tiempo is widely recognized as one of the leading software engineering companies in the US. Using a combination of nearshore engineering resources, high-performance teams and relentless focus on client outcomes, Tiempo designs, builds and deploys software that makes lives better.
Contact us at:
[email protected] 602-910-4646
Tiempo is headquartered in Tempe, Arizona, with four worldclass software development facilities in Mexico. Tiempo has been recognized annually by Inc. Magazine as one of the Fastest-Growing Private Companies in America. U.S. HEADQUARTERS 1050 W. Washington St, Suite 120 Tempe, AZ 85281 USA
HERMOSILLO 545 García Morales Blvd. Hermosillo, Sonora, México
GUADALAJARA 2464 Justo Sierra Guadalajara, Jalisco, México
MONTERREY CIT2 Eugenio Garza Sada Monterrey, Nuevo León, México
GUADALAJARA San Dinisio 25 Jardines de San Ignacio Zapopan, Jalisco México
www.tiempodev.com
12
DEVOPS FOR FASTER, BETTER DEVELOPMENT
