devopsy.kinsta.cloud

Author: contributor

  • IT Organization: Blend, Don’t Divide

    IT Organization: Blend, Don’t Divide

    Bi-modal is the new normal, but the best way to approach this is to blend operations, not create separate groups.

    There’s been much ado lately about the transition of enterprise IT from traditional, steady operations to a highly agile and services-based operation. Companies of all sizes are moving to the cloud and adopting DevOps, yet many must maintain legacy systems for years to come. Pundits and analysts such as Gartner suggest that CIOs need to split their organizations into two: the Mode 1 group (traditional, “lights on” operations) and Mode 2 (the business-innovating group). In fact, Gartner is so bullish on this idea that the research firm is predicting that 72 percent of enterprises will be operating in a bimodal structure by 2017.

    Yet dividing and conquering won’t work. By creating two separate groups, with likely two different leaders, there’s bound to be tension and turf wars. Overlap of duties will happen, and higher costs may result. Regardless, the two groups will still need to work together—but may have little incentive to do so.

    Let’s take a step back. Bimodal is just another name for transitions that IT organizations have been through many times in the past: analog vs. digital, mainframe vs. client/server, batch vs. interactive, native vs. web-based, on-premises vs. cloud and so on. Creating walls between existing and emerging processes and technologies doesn’t make much sense. It’s possible to manage “old” and the “new” requirements and projects in tangent.

    Instead of creating walls, Mode 1 and Mode 2 processes can coexist and employees with different perspectives can help each other as the company transitions to its next phase of innovation. Over time, the entire organization will shift to the most progressive, efficient and business-aligned way of delivering IT.

    IT organizations should think more holistically about building cross-functional teams made up of the best members to serve that team’s particular purpose. Those teams may have mobile app developers and DevOps managers sitting side by side with network engineers and system architects who have developed deep specialties in enterprise databases and data center infrastructure over many years. There may be Waterfall teams and DevOps teams, and individuals managing cloud providers working closely with data center managers implementing converged infrastructure. It all begins with the business requirements and designing a strategy that is inclusive of both required legacy systems and future, cloud-based initiatives.

    But wait, aren’t the most progressive companies Mode 2 from top to bottom? The answer is no. Companies such as Amazon, Google, Netflix, Facebook, Apple and LinkedIn are IT innovators that also manage solid and stable internal environments.

    It was only in mid-2015 that Apple announced its migration of the Siri application platform to the Apache Mesos platform. This didn’t happen overnight. The team responsible for Siri realized that it could cut costs and increase flexibility for ongoing support and development. It was an evolutionary move focused on front-end scalability and allowing a clustered approach for scale and management—arguably a very Mode 2 approach. That said, it’s also widely known that the data sources for Siri are a mix of traditional RDBMS and No-SQL—massive data repositories handling millions of transactions 24/7. These platforms require Mode 1, utility-grade availability constructs.

    LinkedIn is another innovator running a distributed architecture that blends Mode 1 technologies (data layer and business engines) with Mode 2 clusters focused on presentation of new and existing initiatives.

    Ways to Blend Effectively

    Here are some ways to approach a blended IT organization that incorporate both Mode 1 and 2 technologies and processes without building walls:

    1. Create a best-of-breed environment. Evaluate your applications and create an architecture plan. Identify existing applications that require modernization. Create a clear picture of the gap between current and desired state. Build an architecture for your applications that leverages one or more platforms that can adapt to your application architecture goals, both present and future.
    2. Balance out your weakness. Most large companies in traditional industries will be heavier on the Mode 1 orientation regarding skill sets, tools and processes. To jump-start a transition toward Mode 2 operations, consider hiring people from software startups with ample experience developing, scaling and maintaining cloud-based systems under rapid time frames. These are the people whose failures bring the perspective necessary to empathize with your Mode 1 teams. They might even appreciate the Mode 1 team’s experience.

      Conversely, if your organization is already a strong Mode 2 operation, know that scaling your business will require you to embrace Mode 1 skills to maintain reliability and consistent user experience as demand grows unpredictably. Ideally, find someone with a large enterprise background that has experience delivering reliability for new, web-scale applications.

    1. Don’t force new methods. DevOps, a technique for infrastructure management in support of rapid delivery of applications services that is generally considered to be well-suited for Mode 2 applications, may not retrofit to every situation. For example, one can write code to manage infrastructure systems that expand and contract with the proliferation of application containers. While well-suited for the container-based application model, many of the coding concepts associated can be too complex for scripting the deployment of a multi-tier Mode 1 application. The layers and complexities of the scripting don’t provide enough return on the time invested to justify the upfront efforts. Leveraging a purpose-built automation engine or simply deploying manually likely makes more sense today. Choose the technique that best serves the initiative, not the one that seems the newest and coolest.

    Rather than getting hung up on how to reorganize IT departments, a better use of time is to determine how to blend the best of the old and the new. IT organizations today are frequently in a state of transition, given the pace of new technological developments. By merging tried-and-true tools and practices that deliver stability with the latest innovations for web-scale business models, companies can move quickly in their respective markets without sacrificing business longevity.

    About the Author/Steve McDonald

    Steve McDonald StrataCloudSteve McDonald is Vice President of Product at StrataCloud, developer of a platform for software-defining enterprise data centers. Over the past 15-plus years, McDonald has led cross-functional teams in the delivery of innovative business initiatives, most recently at Softchoice, where he a managed a team of business development and pre-sales professionals in the United States and Canada focused on the profitable growth of the entire Cisco portfolio as well the networking category overall.

  • Our Sprint to Agile Success

    Our Sprint to Agile Success

    Adoption of the agile methodology is essential to the success of a DevOps culture. This is not revolutionary, but is an important foundation.

    We view agile as the tool for developers to achieve DevOps. Our team, which is developer-centric, is focusing on the agile piece of the equation moving forward.

    But what happens when you think you have a grasp on the agile methodology but it turns out you were completely wrong?

    A change is needed.

    Getting back to the Agile Manifesto is a great starting point. This is our story of DevOps failure to success by implementing the correct agile methodology.

    Our Perception Was Wrong

    When thinking about the agile methodology, and, to a greater extent, DevOps, open communication is at the core. However, it is not the only thing agile and DevOps is.

    At the beginning, we thought as long as there was open communication we were agile. Seeing as we sat in the same room, this was pretty simple. But we quickly learned that this was not agile, and the revelation was painful.

    As we experienced development bottlenecks and difficulty in defining responsibilities, we knew there needed to be an adjustment in how we viewed the agile process. Also, we had begun adopting projects in areas where we did not have a high level of expertise.

    This is what brought us back to the drawing board.

    Getting back to the basics meant looking at the reason for implementing agile in the first place. For us, it was releasing better software, more often, with fewer updates. In detail, it was looking at how long it took the team to identify and define the need. Then, it was looking at how long it took from problem definition to software release. We consider this one software cycle.

    The reason for implementing agile is to decrease the time it takes to move through one of these cycles, as well as to decrease the number of cycles on any one project. Defining this process to the team is how we brought our software development back to the basics.

    Renewed Focus

    Once there was a renewed focus, it was time to implement a set of tools and processes. The concepts we focused on incorporating are the following:

    • Adoption of sprints
    • Open communication
    • Version tracking
    • Environment of continuous testing
    • Responsibility definition

    None of these are particularly revolutionary, but when implemented effectively, it made a world of difference. Once we defined these five areas of focus, we adopted the daily sprint meeting. This implementation was the core of our transformation into a truly agile environment.

    The Daily Sprint Meeting

    In the developer environment, meetings can be against the team culture, especially in a startup. This is why a meeting needs to be strategic. The daily sprint meeting should have both a question constraint and a time constraint. The result is no dragging meetings.

    The two metrics for the daily sprint meeting are: 1) each team member gets two minutes to speak, and 2) four questions need to be answered. Those are:

    1. What did I accomplish yesterday?
    2. What will I achieve today?
    3. What obstacles do I face to accomplish my projects?
    4. How am I feeling today?

    With a team of five people, this meeting should take 10 minutes at the beginning of each day. The adoption of the daily sprint has helped us achieve a level of focus not possible without it. This focus has produced increased productivity, as well as adopting an effective agile environment.

    The daily sprint meeting is how we successfully implemented a DevOps culture. This has made all the difference within our team.

    About the Author/Logan Rivenes

    LRivenes PictureLogan Rivenes is a Marketing Manager with Datapath.io, specializing in decreasing latency through network traffic optimization for DevOps.
    Twitter: @loganrivenes

    LinkedIn: https://www.linkedin.com/in/logan-rivenes-01a8964a

  • Evolving to Continuous Testing

    Evolving to Continuous Testing

    As agile development practices mature and DevOps principles infiltrate our corporate cultures, organizations are realizing the distinct opportunity to accelerate software delivery. However, when you speed up any process, immature practice areas such as testing and roadblocks become much more pronounced. It’s the difference between driving over a speed bump at 5 mph vs. 50 mph … at 50 mph, that speed bump is going to be quite jarring.

    Accelerating any business process will expose systemic constraints that shackle the entire organization to its slowest moving component. In the case of the accelerated software development life cycle (SDLC), testing has become the most significant barrier to taking full advantage of more iterative approaches to software development. For organizations to leverage these transformative development strategies, they must shift from test automation to continuous testing.

    Drawing a distinction between test automation and continuous testing may seem like an exercise in semantics, but the gap between automating functional tests and executing a continuous testing process is substantial. This gap will be bridged over time as the process of delivering software matures. Both internal and external influences will drive the evolution of continuous testing. Internally, agile, DevOps and lean process initiatives will be the main drivers that generate the demand for change. Externally, the expense and overhead of auditing government and industry-based compliance programs will be the primary impetus for change.

    A Roadmap for Testing

    Any true change initiative requires the alignment of people, process and technology—with technology being an enabler and not the silver bullet. Yet there are some basic technology themes we must explore as we migrate to a true quality assurance process. In general, we must shift from a sole focus on test automation to automating the process of measuring risk. To begin this journey, we must consider the following:

    Driven by business objectives, organizations must shift to more automated methods of quality assurance and away from the tactical task of testing software from the bottom up.
    graphic

    From Causal Observations to Probabilistic Risk Assessment

    With quality assurance (QA) traditionally executing manual or automated tests, the feedback from the testing effort is focused on the event of a test passing or failing—this is not enough. Tests are causal, meaning that tests are constructed to validate a very specific scope of functionality and are evaluated as isolated data points. Although these standalone data points are critical, we must also use them as inputs to an expanded equation for statistically identifying application hot spots.

    The SDLC produces a significant amount of data that is rather simple to correlate. Monitoring process patterns can produce very actionable results. For example, a code review should be triggered if an application component experiences all of the following issues in a given continuous integration build:

    • Regression failures greater than the average
    • Static analysis defect density greater than the average
    • Cyclomatic complexity greater than a prescribed threshold

    From Defect Documentation to Simulated Replay

    The ping-pong between testers and developers over the reproducibility of a reported defect has become legendary. It’s harder to return a defect to development than it is to send back an entrée from a world-renowned chef. Given the aggressive goal to accelerate software release cycles, most organizations will save a significant amount of time by just eliminating this back and forth.

    By leveraging Service Virtualization for simulating a test environment and/or virtual machine record and playback technologies for observing how a program executed, testers should be able to ship development a very specific test and environment instance in a simple containerized package. This package should isolate a defect by encapsulating it with a test, as well as give developers the framework required to verify the fix.

    From Structured Data to Structured and Unstructured

    The current tools and infrastructure systems used to manage the SDLC have made significant improvements in the generation and integration of structured data (e.g., how CI engines import and present test results). This data is valuable and must be leveraged much more effectively (as we stated above in the “From Causal Observations to Probabilistic” section.

    The wealth of unstructured quality data scattered across both internal and publicly-accessible applications often holds the secrets that make the difference between happy end users and unhappy prospects using a competitor’s product. For example, developers of a mobile application would want constant feedback on trends from end user comments on:

    • iTunes app store
    • Android app store
    • Stackoverflow
    • Twitter
    • Facebook
    • The company’s release announcements
    • Competitors’ release announcements

    This data is considered unstructured since the critical findings are not presented in a canonical format: parsing and secondary analysis are required to extract the valuable information. Although these inputs might be monitored by product marketers or managers, providing these data points directly to development and testing teams—in terms that practitioners can take action on—is imperative.

    From Dashboards to Business Policies

    In a Continuous Everything world, quality gates will enable a release candidate to be promoted through the delivery pipeline. Anything that requires human validation clogs the pipeline. Dashboards require human interpretation—delaying the process.

    Dashboards are very convenient for aggregating data, providing historical perspectives on repetitive data, and visualizing information. However, they are too cumbersome for real-time decision making because they do not offer actionable intelligence.

    Business policies help organizations evolve from dashboards to automated decision making. By defining and automatically monitoring policies that determine whether the release candidate is satisfying business expectations, quality gates will stop high-risk candidates from reaching the end user. This is key for mitigating the risks inherent in rapid and fully-automated delivery processes such as Continuous Delivery.

    From Tool Dependent to SDLC Sensors

    Let’s face it—it’s cheap to run tools. And with the availability of process intelligence engines, the more data observations we can collect across the SDLC, the more opportunities will emerge to discover defect prevention patterns.

    Given the benefit of a large and diverse tool set, we need to shift focus from depending on a single “suite” of tools from a specific vendor (with a specific set of strengths and weaknesses) to having a broad array of SDLC sensors scattered across the software development life cycle. And to optimize both the accuracy and value of these sensors, it’s critical to stop allowing tools to be applied in the ad hoc manner that is still extremely common today. Rather, we need to ensure they are applied consistently and that their observations are funneled into a process intelligence engine, where they can be correlated with other observations across tools, across test runs and over time. This will not only increase the likelihood of identifying application hot spots, but will also decrease the risk of false negatives.

    About the Author/Wayne Ariola

    Wayne Ariola (1)Wayne Ariola, Chief Strategy Officer, leads the development and execution of Parasoft’s long-term strategy. He leverages customer input and fosters partnerships with industry leaders to ensure that Parasoft solutions continuously evolve to support the ever-changing complexities of real-world business processes and systems. Ariola has contributed to the design of core Parasoft technologies and has been awarded several patents for his inventions. A recognized leader on topics such as service virtualization, SOA and API quality, quality policy governance, and application security, Ariola is a frequent contributor to publications including software test & performance, SOA World, and ebizQ—as well as a sought-after speaker at key industry events. Ariola brings more than 20 years strategic consulting experience within the technology and software development industries.

  • Puppet Labs Launches Annual State of DevOps Survey

    Puppet Labs Launches Annual State of DevOps Survey

    Puppet Labs has announced its 5th annual State of DevOps Survey. In the past five years, we’ve surveyed more than 20,000 technical professionals around the world, spanning all industries and companies of all sizes. We’ve captured a tremendous amount of data about how IT performance, culture, technical practices and organizational performance intersect.

    What sets our survey apart from the many other surveys out there is that it’s science-based. Yes, there is a science to creating surveys and analyzing data, and there’s also an art to translating all of that amazing data into something that’s useful to the industry at large.

    This year, we’ve partnered with DevOps Research and Assessment (DORA), founded by our friends Gene Kim, Jez Humble and Nicole Forsgren. If you’ve been following the DevOps conversation for a while, their names should be familiar. Together, our goal is to help advance the DevOps community and help technology organizations improve their practices through rigorous scientific research.

    Through our analysis, we’ve been able to quantify IT performance. We know that high-performing IT teams deploy code 30 times more frequently, with 60 times fewer failures, and they recover 168 times faster. We also know the factors that predict IT performance—technical practices such as continuous delivery, cultural norms and lean management—which in turn predict organizational performance.

    This year’s survey seeks to dive deeper into each of these areas, while also shedding light on new areas of research, including:

    • ROI of IT performance. What can you expect from your investment in DevOps? Our goal is to understand how throughput, stability and quality affect the bottom line.

    • Security and compliance. What role do security and compliance play in a DevOps environment? Some people see security as a roadblock to DevOps, but we want to investigate if it has to be that way.

    • Quality. So you’re deploying code faster than ever. What’s the quality of that code?

    • Containers. How do containers affect IT performance? Are they making IT’s job easier?

    • Lean management. Last year we found that lean management practices such as limiting work in process and creating and maintaining visual displays showing key quality and productivity metrics predict IT performance. This year’s survey looks at additional lean management practices to help us better understand what it really means for a technology organization to go lean.

    The survey seeks answers to questions we get all the time and we believe they reflect the broader concerns of the DevOps community. Your experience matters and we hope you’ll share it by taking the 2016 DevOps Survey. It should only take about 20 minutes, and when you complete the survey, you’ll be entered to win some great prizes (see the official rules), including :

    Please take the survey and share it with your friends and peers. Together, we can make IT better for everyone.

    About the Author/Alanna Brown

    unnamedAlanna Brown heads up DevOps research and go-to-marketing strategies at Puppet Labs. She also works closely with Puppet Labs product owners and engineers to develop a roadmap and support for Puppet on Windows.

  • The Forgotten Fourth Question

    The Forgotten Fourth Question

    A very well-written paragraph about DevOps appears in Mike Loukides’ book, “What is DevOps”:

    … Modern applications, running in the cloud, still need to be resilient and fault tolerant, still need monitoring, still need to adapt to huge swings in load, etc. But those features, formerly provided by the IT/operations infrastructures, now need to be part of the application, particularly in “platform as a service” environments. Operations doesn’t go away, a good part of it becomes part of the development. And rather than envision some sort of Uber developer, who understands big data, web performance optimization, application middleware, and fault tolerance in a massively distributed environment, we need operations specialists on the development teams. The infrastructure doesn’t go away – it moves into the code; and the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as DevOps.

    These days, recruiters to managers, engineers to analysts and, of course, CXOs all are interested in DevOps. They have questions such as, “What is DevOps?” “What are the DevOps requirements?” “What are DevOps implementations challenges?” But the key question is, “Why does DevOps remain difficult to implement?”

    Adopting DevOps does not simply mean adopting new processes or toolsets. “Why DevOps” can be understood better by focusing on the benefits it will give you. So let’s dive deeper into one of the key best practices we discovered in our journey into DevOps.

    Agile to DevOps

    Business challenges, complexities and competition pushed companies to innovate and solve their existing business problems in a better way, adding more features and integrated solutions. Ways of implementing solutions vary from organization to organization, adoption of tools and technologies also differ by small and large organizations based on complexity of problems, but it’s clear that many have adopted agile practices in the past two decades. Agile was made clear by a few well-defined processes such as iteration planning, daily scrum meetings, scrum of scrums (in larger enterprises), iteration demos, retrospective meetings and small, empowered teams.

    One of the key mindset changes most of the IT world went through while transforming themselves into agile execution was to have more verbal communications and daily scrum meetings. Daily scrum meetings required the scrum master to ask three questions:

    • What was completed yesterday?
    • What will be completed by end of today?
    • Any blockers?

    These three simple questions kept things simple and quick.

    As agility is extended to Ops now, there is a need to revisit whether these three questions are enough. There is a need to revisit the attendees in scrum meetings too. There is a need to add some more responsibility to the role of the scrum masters’ communication radius.

    Before we look at the fourth question, lets let look at the key reasons to adopt DevOps implementations in organizations:

    • Achieve higher speed of time to market without compromising Ops stability
    • Better resource utilization across Dev, Test and Ops
    • Be more responsive to customers

    Why would speed of delivery hamper stability in Ops? In our firsthand experience, the communication between Dev and Ops is not that rich in most of the organizations today. If one studies the root cause analysis of problems faced by Ops in trying to keep the environment stable and healthy, one will find some if not all the following issues:

    • Developers are not deployment-aware
    • Developers do not think of exposing or exporting the right controls for allowing Ops to configure app dynamically (Unintentionally. They simply don’t know.)
    • Many configurations are embedded deep inside the app
    • Adding specific third parties, changing their versions is sometimes missed in Ops communications
    • Ops is unable to clearly articulate what they require from Dev, even when everyone is co-located
    • Continuous firefighting in Ops results in fast fixes, better debugging, but not proactive processes
    • Even if weekly meetings between Dev and Ops happen, they do not have a clear agenda or metrics

    While there are many more symptoms and their causes, and while there are multiple solutions to fix processes and problems, we have found particularly one solution that seems effective.

    We added a fourth question to daily scrum meeting. That fourth question is: “Are you blocking Ops?”

    This question is a direct question to each developer in daily scrum meetings. This question essentially means to ask:

    • Have you written in any code that requires a new configuration?
    • Have you written any code that requires change in existing configuration?
    • Have you written any code that is creating a new binary or file that needs to be installed in production?
    • Have you recompiled existing code with new third party libraries because older ones are unsupported, even though there may be no other change in functionality?
    • Have you hard coded any IP address or other configurations into the code which cannot be changed without rebuilding?
    • And so on…

    Ask the Fourth Question

    The above list of questions is developed based on the root cause analysis of app stability in Ops. This list will be different for different developers/teams. The scrum master communicates the appropriate actions to developers based on the answers to these questions. The scrum master also alerts the Ops team and gives them a heads up on what’s coming their way, and provides timely feedback to the developers.

    Is this question important enough to be the fourth question in scrum meetings?

    Or is this question covered as part of the “Any blockers?” already being asked? One can debate either way. The blocker question in scrum meetings is thought of in a limited Dev/QA scope, and that scope has not included the Ops team until now. Given that Ops team faces customers, given that the DevOps movement is about improving synchronization between teams, this Ops question needs to be a first-class citizen in daily scrum meetings.

    Lastly, it’s critical to to look at root cause analysis-related Ops problem as early as possible. The scrum master becomes more mature as he asks this question to his team while interacting with Ops on hearing them out. If teams are funded enough to have someone from Ops into the scrum meetings, then he/she can be the primary representative for Ops and can steer the delivery to be Ops-friendly.

    Irrespective of how one achieves it, taking care of configuration issues proactively in daily meetings, and thinking about Ops on a daily basis in Dev meetings is key to successful DevOps adoption. Configuration issues are not the only focus, but they do form a large chunk of Ops issues.

    From our metrics, customers have seen following benefits after adding the fourth question their scrum meetings:

    • Shipping code 7x more frequently
    • 45 percent fewer failures
    • 12x faster ability to recover earlier in the tool chain

    Please feel free to share your findings with us @ info@opexsoftware.com.

    Happy DevOps!

     

    About the Author/Sanju Burkule

    sanjuSanju Burkule, a pioneer, visionary and creator of Products in the DevOps Space @OpexSoftware. He writes about automation and strong, connected, integrated IT and tweets often about these topics.

     

     

  • DevOps Days returns to London

    DevOps Days returns to London

    On April 19, after a break of nearly two and a half years, the DevOps Days conference is returning to London. Expect great things: All DevOps Days events are extremely interactive, making use of the Open Space format, and this year’s event includes a world-class set of presenters ready to share their experiences and guidance.

    The emphasis of the conference is on DevOps in the Enterprise, with specific reference to the financial services industry. That said, the event is open to any delegate, and participation is encouraged for enterprises that may be finding DevOps to be a struggle.

    The conference kicks off with a talk from Joanne Molesky a global expert in improving IT at large enterprises and co-author of, “Lean Enterprise: How High Performance Organizations Innovated at Scale.” Molesky’s talk, “We Are Great at DevOps but the Enterprise is Failing,” will include legacy management practices in finance, IT governance and procurement, and how they inhibit our ability to extend the benefits. She will offer up many real-world examples challenge us to apply Lean thinking and principles to break down these management barricades and deliver even more value to our customers.

    Kris Saxton, organizer of the London Infracoders meetup group, is slated to present a discussion with the provocative title, “Bimodal IT and other Snake Oil.” Saxton will draw on experience from five projects (four within large retail or investment banks and one with a large re-insurer) to challenge the idea that reforming legacy estates while continuing to innovate shouldn’t be attempted. Saxton hopes to convince you that this thinking is a flawed oversimplification which, when adopted, results in lost opportunities, delays crucial decisions and ultimately cripples innovation.

    Expert in everything from platform-as-a-service to people and culture to Perl—with the proud claim that modern Macs still ship with some of his Perl code, Casey West plans to discuss platform applications. He will play close attention to the operations, and, in particular, the operability end of DevOps. In fact, he won’t just be talking about it: Instead using 100 percent open source software, he will be performing a demo on stage in what he promises to be an “interactive live explosion” of a modern platform that will highlight quite how accessible in 2016 they are now.

    Day two kicks off with Gene Kim, award-winning CTO, researcher and author of, “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.” With all his immense dedication to DevOps operations and IT security, when Gene offers to share, “My Top Five Lessons Learned: DevOps In Large, Complex Organizations,” you know it’s going to be extremely valuable. In Gene’s own words: “I can’t wait to share with the DevOpsDays community what I’ve learned, share the problem road map that’s been verbalized, and some of the things we’ve been working on to help people overcome those problems!”

    Gareth Rushgrove is perhaps most well-known for writing the Devops Weekly newsletter, which is now more than 5 years old, but his talents don’t stop there. He is also a senior software engineer at Puppet Labs; a former infrastructure, operations and information security specialist for the UK government; and an established conference speaker. In his talk, “Rate of Change, (Un)opinionated Platforms and Devops Coevolution,” he will share insights on how the adoption of practices such as DevOps, microservices and tools such as platform-as-a-service are interconnected. He will explore the power of co-evolution, which makes cause and effect bi-directional, making it possible to leverage what you do and how you do it to improve your organization as a whole. Be prepared!

    Philippe Guenet is an expert in DevOps, in particular transforming banks toward continuous delivery. With his talk, “From Lean in Automative to Lean IT,” Guenet plans to draw heavily from what other industries learned in the 20th century dating back to Henry Ford and, of course, Toyota. He will revisit fundamental Lean concepts and principles applicable to IT and explore how they can be applied to improve organizations. The topics will include Total Quality Management, organization optimization, simplification and improved time-to-market.

    This is of course all just a taster. Slated also are talks from Thiago Almeida (Microsoft), Michael Coté (Pivotal), Jeromy Carriere (Google), Clair Agutter, Benjamin Wooton, Oliver Wood and John Clapham. In addition a panel is scheduled that will include at least one chief operations and technology officer. Last but not least, on top of all of the great interaction in breaks and Open Spaces and great presenters, we promise a great social event the evening of April 19, including a few surprises.

    The last few tickets are available here, so get one before they are gone!

    See you there!

    About the Author/Mark Rendell

    me_profileMark is a DevOps and continuous delivery specialist at Accenture with 11+ years of experience in development, configuration management, infrastructure as code, continuous delivery, environment management, build, deployment and testing automation as well as tooling. Currently, he runs a team specializing in implementing continuous delivery for large-scale, transformation deliveries across multiple industries.  He is also a proud contributor to the DevOps Platform.

    Blog: https://markosrendell.wordpress.com/

    Twitter: @markosrendell

     

  • 3 Reasons Why Automation is Critical

    3 Reasons Why Automation is Critical

    We’re hearing a lot about the “outcome economy”—how businesses must be results-oriented to meet evolving customer demand and gain greater market share. Today’s marketplace is connected, always on and increasingly competitive. Companies are adopting what we call an “as-a-service” approach to achieve better outcomes fast, consuming and leveraging leading-edge technologies such as cloud and automation.

    As IT systems grow exponentially, and cloud solutions proliferate, non-automated, manual systems increasingly are becoming a major business liability. Today’s systems are simply becoming too big and complex to run completely manually, and working without automation is largely unsustainable for many enterprises across all industries.

    Automation involves a set of tools, processes and insights that allows IT environments to self-modify and adjust, and some enterprises have started using intelligent automation to drive a new, more productive relationship between people and machines.

    For example, IT automation is often used to auto-scale and load-balance large fleets of servers, manage global content distribution based on geographic demand, enable self-healing of IT systems and manage security mostly with limited ongoing manual intervention.

    Moreover, automation enables the ability to adapt and improve the service experience without manual intervention. However, while these tools offer new strengths and capabilities, they are meant to complement and enhance human skills.

    Effective automation depends on adequate insights collected from all the systems relevant to the service experience and business outcome you’re trying to augment. Insights from data is necessary to create opens paths to automated predictions and ultimately using machine learning, or artificial intelligence, as part of a full scope the as-a-service construct.

    Specific insights known as telemetry allows signals to be harvested and interpreted so automation can better adjust production systems to maintain a healthy business. The insight gathered from such analytics allows automation to validate and compose modification rules. For example, sensors that detect a supply chain issue could automatically reroute or fine-tune related functions, such as dispatch or logistics, to solve or generate a workaround for the issue. The business flow can adapt and realign automatically with the ultimate goal of improving the customer experience.

    Automation Creates High Resiliency

    Two common business outcomes that depend on efficient automation are highly resilient systems and experimentation platforms.

    Highly resilient systems include automation that can detect, avoid, heal and remediate any deviations from normal, healthy business function. To detect deviations, automation capabilities need to understand what the “steady state” of the system is and what constitutes the “health” of the system under varying conditions. For each detected deviation from an established steady state, a specific automation is triggered that attempts to return the system back to the steady state.

    The best way to determine if resiliency automation works effectively is through a process known as “fault injection.” Highly resilient systems run under constant fire drills in which operations insert faults into the system while developers continuously build responding resiliency automation.

    Automation also can provide a higher degree of experimentation and increase agility, two key attributes of as-a-service economy. Automatically provisioning a component such as a virtual machine, for example, is only a piece of the puzzle since automation is most valuable when it contributes to improving a customer experience or delivering a business outcome.

    A platform that’s constantly testing, experimenting and developing allows companies to try new ideas in production quickly without fear of failure or outage. When confidence in system resiliency is high, it allows businesses to test new things directly in production (A/B testing). If an experiment fails, there is no harm done as automation returns the system to steady state. If an experiment succeeds, it is quickly absorbed into the production itself.

    A fast, efficient experimentation platform enables businesses to react faster to failures and successes—and pivot accordingly without excess wasted resources. For example, a retail company might change a shopping basket feature for 1 percent of its customers. With constant measurement and instrumentation, the company can automatically derive insights, determine if the change is effective and create a chain of automated reactions. If, say, the demand spikes for a new offering based on a limited customer pilot, the system can reset stocking levels ahead of geographic or further customer segment rollout. This ability increases a company’s agility and adaptability, improving the customer experience and delivering on the most important factors determining success in today’s as-a-service business environment.

    Moving forward

    In this fast-paced marketplace, it is becoming clear that automation is the next critical step in IT maturity—building trust into IT systems and enabling innovation of new capabilities.

    However exciting, impactful and resourceful automation is, it is important to note that automation will not replace people. Machines and artificial intelligence will be the newest recruits to the workforce, bringing new skills to help people do new jobs, reinventing possibilities across the business spectrum. The companies that succeed with automation take a “people-first” approach, adapting their enterprise’s organization, culture, skill and experience to use automated technology.

    Although automation becomes critical to stability when systems grow to global scale, it also provides great benefits to smaller systems. Every modern enterprise should start thinking about an automation strategy. Companies that aren’t experimenting with automation are going to be outpaced quickly by the competitors that are quick to analyzing data, yielding insights that make their processes more agile and unchains their systems and infrastructure from undue age-old complexities.

    About the Authors

    Marshall Wells_PhotoMarshall Wells, Managing Director, Hybrid Cloud

    Marshall Wells is a managing director at Accenture, focusing on Accenture’s Hybrid Cloud platform. He holds an MBA in Finance from theUniversity of California, Berkeley and a BS in Chemical Engineering from Colorado School of Mines.

     

     

    Miha_PhotoMiha Kralj, Managing Director, IT Strategy and Cloud Computing Transformation

    Miha Kralj is managing director at Accenture, where he is responsible for Accenture’s IT Strategy and Cloud Computing Transformation platforms. In this role, Kralj helps to define core cloud strategies that help clients transform traditional IT, creates and delivers IT transformation programs, and identifies the right cloud disposition for various workloads.

    Prior to assuming his current position in 2015, Kralj served as principal architect at Amazon Web Services, leading the domain of IT Transformation and modern IT delivery. Before that, he was senior technology director at Microsoft, where he designed Enterprise Architecture offerings through assessments, planning and value realization.

  • 5 Things DevOps is Not

    5 Things DevOps is Not

    For those who have been embracing and championing DevOps for years, the growing popularity of DevOps is as exciting as landing your first job out of college! Okay, maybe not that exciting, but still really cool. More and more companies of all sizes are embracing DevOps by including the adoption of DevOps practices directly into their fundamental strategies.

    On one side, this is giving teams the leverage they have needed all along to either begin their DevOps journey or to increase the maturity of existing DevOps adoptions. On the other side, when DevOps becomes a mandate, some of that grassroots passion can become watered down, as the use of the word becomes increasingly overused or incorrectly used.

    DevOps incorporates a new collaborative culture that embraces numerous practices combined together for a continuous software development methodology that places significant emphasis on feedback loops, collaboration and continuous improvement. DevOps requires fundamental cultural changes and includes so many practices that can be overwhelming to those just starting their journey.

    Instead of highlighting everything that DevOps is, I thought it would be good to take a step back and highlight what DevOps is not instead.

    1. DevOps is not simply combining Development & Operations teams

    We’ve all seen this one when the term DevOps comes up. “Let’s combine the Development & Operations team and, voilà!, we now have DevOps.” DevOps combines a set of processes and practices to be adopted throughout the entire delivery pipeline and spans multiple stakeholders. A couple of the key practices within DevOps adoptions include continuous integration (CI) and continuous delivery (CD). Simply combining two teams and calling it DevOps cannot accomplish those practices.

    2. DevOps is not a separate team

    Setting up a separate DevOps team is another trap many organizations fall into when beginning their DevOps journey. In general, I’m not a fan of the DevOps team as I believe it leads to more silos in the end. I’ve also found the creation of these teams can lead to further confusion when the mission is not clearly defined.

    There are some cases where a temporary DevOps team may make sense to help enable the processes and potential tooling that may be needed for adoption, but the key is making it temporary—which is often better in theory than in practice. There are several great blogs out there discussing DevOps teams such as Matthew Skelton’s blog, “What Team Structure is Right for DevOps to Flourish?”

    3. DevOps is not a tool

    Let me be the first to say I actually love the growing number of tools that enable us to continue maturing our DevOps adoptions, but I’ve noticed the use of one or two tools starts to lead to the perception that DevOps is a tool. How many times have you heard?

    “We’re already doing DevOps. We have Chef.”

    “We do DevOps. We automatically deploy through Jenkins.”

    Keep in mind, I’m a big fan of both Chef and Jenkins, but I think the power of DevOps is drastically underutilized if you’re equating the utilization of a single automation tool to DevOps success. Adopting automation and tooling is, of course, a part of DevOps, but only when combined with end-to-end practices of increased collaboration with continuous integration/continuous delivery, amplified feedback loops and continuous improvement (to name a few)! DevOps is a journey and that journey may start with a tool, but the goal should be to first identify your DevOps strategy and then find a tool or tool chain that meets those goals.

    4. DevOps is not a one-size-fits-all strategy

    Because there are so many different business drivers and technologies to consider when setting up an overall DevOps adoption strategy as well as identifying your DevOps tool chain, it’s important to apply the same tenets of DevOps to your DevOps strategy. Embrace change, gather metrics, understand feedback, fail fast and correct your course quickly. As an example, if you initially identify a tool that no longer works for your technology or environment, abandon it and move on. Just because you used it on the last project doesn’t make it a silver-bullet fix for the next one. We need to first understand our current strategy and environment, then react accordingly.

    5. DevOps is not automation

    That one may have caught the eye of a few people, so I’ll clarify: DevOps is not solely automation. Automation is absolutely a huge part of DevOps; however, it is not the only part, and deploying some degree of automation is often used interchangeably with DevOps. I think understanding the key DevOps practices is a great precursor to ensuring DevOps is viewed as more than just automation. Understanding the core DevOps principles is key to understanding the true benefits of DevOps adoption.

    There are a lot of things that DevOps is and I think I share a widely spread passion for DevOps. There are also a few things that DevOps isn’t—or isn’t solely. If you’re just starting your DevOps journey or still maturing your existing model, making sure everyone on your team has some basic DevOps education and is aware of the DevOps strategy for your project is key. It will go a long way in helping everyone understand that DevOps is about a lot of things. It’s also not about a lot of things.

    The list above isn’t exhaustive and I’m sure you all have a few you’d like to see on the list. I’d love to hear you thoughts and suggestions at @Shelbee_SE.

    You also can download and browse through the DevOps for dummies e-book.

    About the author/Shelbee Smith-Eigenbrode

    Shelbee

    Shelbee Smith-Eigenbrode is a Senior Software Engineer/IT Architect at IBM Cloud Infrastructure Center of Competency. She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.

  • Git: One Giant Leap Toward DevOps

    Git: One Giant Leap Toward DevOps

    If you work in an organization that has not yet embraced DevOps, then you might be wondering where to begin. Fortunately, there are many good answers. But I want to introduce one simple starting point that you probably haven’t heard: introducing Git to operations. By itself, Git might not seem like a meaningful way to overcome the barriers between dev and ops. Yet, Git provides some capabilities that mark the difference between the lowest performing IT organizations and the highest. And the difference in IT performance can translate into substantial business benefits. The highest performing IT organizations have noticed the following benefits:

    • They are about twice as likely to exceed profitability, market share and productivity goals.
    • Their employees reported far higher levels of job satisfaction.
    • They realize 50 percent higher market capitalization growth over a three-year period.

    To be clear, no amount of data will ever prove that use of Git leads directly to growth, profit, productivity and job satisfaction. What the Puppet Labs’ “State of DevOps Survey” does show is the incredible range between low and high performance in IT organizations. The rate of deployment has hovered at 30 times faster for high-performing organizations over the lowest. The 2014 survey showed 50 percent fewer deployment failures, while 2015 showed 60 percent fewer deployment failures, when comparing highest to lowest. The survey also indicates which practices separate the highest performers from the lowest. According to the State of DevOps Survey, the top two indicators of high performance are:

    • Version control of all production artifacts (surprisingly, a far greater predictor of performance than version control of source code); and
    • Peer review of production changes (in contrast to external change approval).

    It’s not that these two practices magically yield business benefits. Indeed, ITIL has long recognized management of production artifacts and review of production changes as best practices. But too many organizations still believe faster deployment and higher reliability are trade-offs. What is “magical” in high-performing organizations is they realize they can have both faster deployment and higher reliability by collaborating across organizational boundaries and automating intelligently. That means dev and ops sharing goals, measurements and tools. So one way in which these practices differ from typical ITIL practices is how dev and ops perform them collaboratively. More specifically, when dev and ops use the same tool for version control, they can better share techniques and workflows. For example, the peer review of changes can include both dev and ops. Thus, Git is a gateway to DevOps.

    Git has long provided those two capabilities for software developers: Developers use Git to version source code and developers use pull requests to perform peer review of source code. With a few tips about how to apply Git to configuration files, operations can use pull requests to perform peer review of configuration changes. Now with git-lfs, operations can also version production artifacts, which often are large, binary files that historically have not worked well with Git. More advanced concepts such as infrastructure as code and dedicated binary repositories, for example, build on version control, so even if the role of Git changes over time, the skills and collaborations remain valuable.

    In summary, the business case of Git for Ops is simple. The Puppet Labs survey shows meaningful upside for low performing IT organizations to become high performing. The survey shows high performing organizations are characterized by both rapid deployment and high reliability, not picking one over the other. Two practices that characterize high performing IT organizations are version control of production artifacts and peer review of changes. Git is now well-positioned to provide both capabilities. If you’re ready to start introducing operations to Git, don’t forget that Bitbucket has no limits to the number of private repositories.

     

    About the Author/Ian Buchanan

    ianWhile Ian Buchanan has broad and deep experience with both Java and .NET, he is best known as a champion of agile methods in large enterprises. He is currently the Developer Partisan for Developer Tools at Atlassian, where he focuses on the emerging DevOps culture and the application of Bitbucket and Bamboo for better continuous integration and continuous delivery. During his career, he has successfully managed enterprise software development tools in all phases of their life cycle, from cradle to grave. He has driven organization-wide process improvement with results of greater productivity, higher quality and improved customer satisfaction. He has built multinational agile teams that value self-direction and self-organization. When not speaking or coding, you are likely to find Ian indulging his passions in parsers, meta-programming and domain-specific languages.

  • InterConnect 2016: Culture Matters

    InterConnect 2016: Culture Matters

    The recent IBM InterConnect 2016 focused on plenty of tools and technologies, from cloud/SaaS solutions to containers and automation, but there was another popular topic of conversation heard in the halls—the culture of organizations. The basic premise of these conversations was that unless you get the culture right, all the technology in the world won’t get an organization to where it needs to be to compete in the ongoing digital transformation.

    At Nationwide, we have developed a foundational DevOps model that has two main pillars built on top of Gene Kim’s “The Three Ways” and lean and agile principles.

    While there are initiatives to implement the DevOps-related practices such as continuous integration using Jenkins, continuous delivery using TaskTop and UrbanCode and version control everything using GIT, how does one influence culture? Because clearly if the culture is not correct, technology solutions will not be enough to reach the goals of DevOps in terms of reducing lead time and enabling the business areas to be more responsive to market needs.

    Dev Cul 22

    Trust: The Foundation of Culture

    A key component of what underpins culture is trust. This was emphasized in a blog written by Lee Reid last year titled, “The Simple Math of DevOps.”

    So how does one build trust? Here are 13 behaviors that build trust from Steven Covey:

    Dev Cul 33

    Colin Powell, in a video on the Essence of Leadership, talks in a powerful way about this, saying that one way to build trust is to “Do what you say and say what you do.” He also stresses that successful leaders are those who provide selfless service to their teams.

    I don’t claim to have any magical formula to build trust, but clearly an organization’s transformational success must include a focus on culture and trust. Without this, the true promise of DevOps won’t be realized.

    You can read more about my session, “Achieving continuous visibility across the DevOps Lifecycle” at InterConnect 2016.

    About the Author| Carmen DeArdo

    Carmen-DeArdo-sq
    Carmen DeArdo is technology director at Nationwide Insurance. An ardent advocate of DevOps and a leading speaker in the DevOps and technology related events, Carmen is responsible for driving continuous delivery utilizing DevOps, lean and agile techniques across mobile, distributed and mainframe and other technologies.