staging-devopsy.kinsta.cloud

Tag: devops

  • Adding Accountability with ‘You Build It, You Run It’

    Adding Accountability with ‘You Build It, You Run It’

    Let’s see if this scenario resonates with anyone: Your department, organization, company, etc. is beginning to embrace DevOps practices, which is, of course, an amazing step in the right direction! One of those key practices is the “You Build It, You Run It” (YBI/YRI) mantra that helps facilitate a higher level of quality and accountability. This common practice also solves the mentality of throwing your solution/code over the fence for some other team to fix.

    I’m a huge proponent of YBI/YRI. However, in the case of existing brownfield solutions, there are several things you need to consider when transforming into the YBI/YRI model, including:

    • What if you have an existing solution where the collective “Y(ou)” in ‘You Build It’ does not include any or many of the original team that built it? This would be anyone who was part of the end-to-end creation of the solution and was empowered to make decisions impacting the design, development and delivery of a solution. In this case, it becomes, “Someone else built this mess, now you run it,” [SEBTM/NURI] which not only makes for a horrible acronym but is also a very realistic scenario that requires special consideration we’ll discuss below.
    • What if you are still heavily siloed and have a squad spread across multiple organizations, each with different goals and objectives? If you are still running outside of a true squad model, it can be difficult to ensure everyone’s priorities and goals are aligned to produce quality solutions with the right functions customers want.
    • What if you have varying definitions of “You” within your organization? Often in the YBI/YRI model, the interpretation makes some roles or key decision makers exempt from the glory of pager duty or answering to an angry customer. This can be especially true when you’re still trying to get to a point of having fully cross-functional, empowered squads.

    I think it’s fair to say that most DevOps transformations don’t necessarily happen on greenfield solutions, which means, especially at the enterprise level, the reality can end up being a beast of a monolithic solution(s) built by others who may or may not still be around.

    How do you fix it? My suggestion is that every person who was empowered to make a decision that contributed to the “B” (Build), becomes a “Y”(You). Of course, this doesn’t work if “Y” is no longer with the group or company, in which case I think it becomes a different issue of ensuring the new “Y” is 100 percent empowered with the ability to make decisions that enables that team to successfully run it.

    One more complication that adds to the mix of a YBI/YRI strategy is putting that strategy in place without a solid foundation of agile practices. Ideally when you are adopting DevOps practices, you already have a solid agile foundation with empowered cross-functional squads; however, in practice we often see the agile foundation still being built and/or refined at the same time as incorporating DevOps practices. As a result, there still exists a lot of hand-offs while two transformations are trying to run in parallel. If you have hand-offs combined with team’s with separate business objectives, those blurry lines of accountability will become an issue sooner than later.

    During transformations, if you find yourself in that in-between state of not having fully empowered accountable teams and are working with solutions your team may not have actually built, below are a few suggestions to get through those initial challenges:

    1. Ensure you allow for enough time to address technical debt during your sprint planning. Continuing to add features and functions on a poorly designed and/or broken solution will only cause further issues and likely increase the level of frustration on the team.
    2. Ensure that EVERY person who contributes to key decisions on a solution is included in the pager rotation in some way. Until you are in a state of fully empowered cross-functional squads, it’s important to drive the importance of accountability. As an example, if you have an architect in one organization who is working with a development team in another organization, that architect needs to be included on the pager as well to be aware of any problems resulting from a key architecture decision.
    3. Get in the habit of operational retrospectives. Begin (or continue) the habit of operational retrospectives that bring together the end-to-end squad into a cross-functional review of the operational incidents, root cause assessment and stories/tasks that need to get added to the backlog and prioritized.

    Although the transition into YBI/YRI for brownfield solutions can be muddy, empathizing with the mountains of technical debt and fully empowering solution teams can go a long way in truly helping your team’s succeed through the beginning phases of your DevOps transformation.

    About the Author / Shelbee Smith-Eigenbrode

    Shelbee

    Shelbee Smith-Eigenbrode is a senior software engineer/IT architect at IBM and has been in IT for 19 years.  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.

  • Continuous Testing: Solving the Biggest DevOps Bottleneck

    Continuous Testing: Solving the Biggest DevOps Bottleneck

    It’s time to start implementing the practices of Continuous Testing

    Earlier this year, Computing Magazine conducted a fascinating study around the adoption and benefits of DevOps in its DevOps Review 2017 publication. The findings that stood out most fascinating to me where around quality assurance and testing.

    In this survey, the question was asked, “Where are the main holdups in the software production process?” Of all the self-proclaimed DevOps practitioners, a whopping 63 percent said the biggest delays occurring in the QA/Test phase. In fact, this cited bottleneck was more than 2 times greater than the next proclaimed bottleneck, which they felt was in planning (29 percent).  In this same survey, another question asked, “What tends to lose out more in DevOps environments?” While 43 percent said, “Nothing,” nearly 30 percent of these DevOps practitioners said that quality was being sacrificed. When asked which area they wanted to focus on improving in the next year, over 40 percent opted for quality.

    Why is it that quality has taken such a hit?  The study cited two issues: 1) Testing and QA is often siloed from the other parts of the organization, and 2) Testing tools haven’t matured much in the past five years.

    Testing must become a cross-functional operation across the software development lifecycle (SDLC) spectrum, one that involves all teams. Agile developers and testing teams don’t have weeks to test, but hours. Testing hasn’t kept up because it hasn’t applied the methods and concepts of agile development have not been applied to testing and QA processes. By removing the constraints that force testing to the end of a development cycle, developers and QA teams can achieve accurate, automated testing from day one. They can create an integrated pipeline, capable of taking an idea from design to deployment, at speed, without compromising quality.

    Open-source, cloud-based solutions can be the catalyst that brings the speed of agile to testing.  Here are a few examples.

    Better In-Sprint API Testing: Since APIs have become the major component of applications, organizations are shifting their approach from starting testing when the user interface is complete to shifting the focus of testing at the API level.  But the hard thing is finding enough time in a development sprint to test them sufficiently.

    Today’s applications are a collection of microservices and API calls. UI testing alone just won’t cut it. UI testing is very brittle, and whenever it changes, testing breaks. Testing needs to shift left into the development cycle—into sprints. But if you shift testing left to be a focus of the sprints, what kind of API testing can you really do? How comprehensive can they really be?  Creating those API tests has to be quick, and simple.

    Dev and Test teams must utilize automated tools that not only generate API tests, but create an exhaustive set of test cases from the API, then execute those tests. These tools also need to support the most popular open-source testing frameworks allowing developers to run functional API tests as performance tests without any proprietary conversion issues. And, vice versa, developers must be able to take open-source performance tests and be able to run them as functional API tests.

    Orchestrating Testing: A Continuous Delivery Pipeline Manager: “Faster” is becoming table stakes with automation.  The facts show that companies who have widespread agile adoption and are deploying more frequently with significantly reduced lead times. But, this too often leads to release failures, quality issues and disorder with multiple—if not hundreds—of applications rolling through the SDLC. Plus, things slow down significantly with time-consuming handoffs and rework in the release process. DevOps teams, who release features and fixes frequently while significantly reducing errors and manual processes, need toolchain-agnostic pipeline planning, orchestration and optimization solutions that enable them to eliminate spreadsheets, automate test processes and feedback, and continually improve the delivery of revenue-generating features to end-customers. New CD SaaS tools help make this orchestration process easy.

    Performance and Functional Testing Using Open Source Frameworks: More and more organizations are trying to move from legacy testing tools. It’s not so much that these don’t adequately test, but they were never designed to meet the needs of agile development approaches. Rather, they were designed for releases that occurred two to three times per year. But that won’t cut it anymore.

    And as developers begin to incorporate testing activities in the coding process, they need simple-to-use, open-source tools. Luckily, there are such tools like JMeter, Selenium, Gatling, Locust and others. There are even tools that help you convert from legacy platforms to open source technology with ease, and guides to transform existing functional tests created with other tools over to load tests.

    These are just a few examples of how continuous testing eliminates the testing hurdle. With continuous testing, organizations can:

    • Automatically convert user stories from requirements management tools like CA Agile Central or Atlassian JIRA into the minimum number of test cases required for complete code coverage, and being able to adapt automatically to changing business requirements.
    • Reduce test cycle prep time by requesting test data from within requirements.
    • Request, reserve, and create test data at any time, even from requirements phase.
    • Virtualize APIs for better testing, while managing API access to developers.
    • Institute easy API testing that can generate comprehensive test cases (positive, negative, edge case, and SQL injection) and execute those tests automatically.
    • Democratize testing with SaaS-based testing tools so that developers can test early and test often.
    • Speed testing by feeding test data directly and securely to virtual services.
    • Use open-source testing tools such as JMeter, Selenium, Jenkins, Jenkins, Appium, Taurus, Gatling, Locust and more.
    • Orchestrate the application delivery pipeline to promote releases from one environment to the next as soon as all the tests pass and enable faster feedback loops.

    This is testing unleashed, going hand in hand with agile development to accelerate quality into production.

    By adopting next-generation testing practices, DevOps teams have the ability to test early, often, automatically and continuously. To learn more about continuous testing and why it is critical to DevOps and Continuous Delivery initiatives, visit this Continuous Testing informational page.

    — Aruna Ravichandran

  • 7 Steps to DevOps Hiring Success

    7 Steps to DevOps Hiring Success

    As many of us in the DevOps scene know, most companies are hiring, or, at least, trying to do so. The required skills and job descriptions can change entirely from company to company. As a broad overview, most teams are looking for a candidate from either an operations and infrastructure background or someone from a software engineering and development background, then combined with key skills relating to continuous integration, configuration management, continuous delivery/deployment and cloud infrastructure. Currently in high-demand is knowledge of container orchestration.

    In the ideal world, the two backgrounds will meet somewhere in the middle to form Dev and Ops, but in most cases, there is a lean toward one side or the other while maintaining sufficient skills to understand the needs and demands of their counterparts to work collaboratively and achieve the end goal of continuous delivery/deployment. Every company is different and there isn’t necessarily a right or wrong here. It all depends on your infrastructure, tech stack, other team members’ skills and the individual goals you hope to achieve by hiring this individual.

    Focus Your Hiring

    Now, given the various routes to becoming a DevOps practitioner, how do hiring managers focus their search and selection process to ensure that they’re hitting the mark?

    Decide on the Background

    Assess the strengths of your existing team. Do you already have some amazing software engineers but you’re lacking the infrastructure knowledge? Aim to close these gaps in skills. You may have been given the budget to hire for DevOps, but you don’t have to spend weeks/months searching for the best software engineer who happens to use Docker and Kubernetes because they are the current hot trends in this space. Find the person who will provide the most value in your environment and go from there.

    Contractor or Permanent Employee? 

    Many hiring managers will automatically start searching for a full-time permanent employee when their needs may suggest that they have other options. Sometimes a contractor is your best bet or maybe contract-hire. If you’re aiming to design, implement and build a new DevOps environment, why not find a senior person who has done this a number of times already? Try hiring a senior contractor and bring on a junior full-time hire in parallel; this way, you’ll be able to retain the external contractor knowledge by having them work alongside the junior hire. Contractors can be expensive, but the knowledge they bring can be invaluable, especially if the work can be completed over a shorter time frame. Again, this is just another point of view and you might be best off with a full-time hire to grow the team.

    CTRL F is not the Solution

    Focus on their understanding of DevOps and CI/CD-related processes over specific tools. I believe the best approach is to focus on finding someone who understands the methodologies over the tools. Does your candidate understand the concept of continuous integration or the concept of continuous delivery? That’s more important than asking whether your candidate uses Jenkins versus Bamboo versus TeamCity and so on. Try not to get caught up in the exact tool chain. The focus should be on the candidates’ ability to solve problems. Are they obsessed with increasing efficiency, saving time, automating manual processes and constantly searching for flaws in the system? They might be the person you were looking for, but you missed them because you didn’t see the word “Puppet” on the resume.

    Work Closely with your Internal Talent Acquisition Team and/or an External Recruiter

    Be clear and precise with what you’re looking for and have an ongoing, open communication with recruiters. They can and will help you if used effectively. The job of these recruiters is to save you time by sourcing candidates while you’re focusing on your day-to-day role. Work closely with them and deliver in the same way that you would expect them to deliver for you. If you say you will review a candidate by X time, do it. If they say they’ll have a candidate in your inbox by Y time, make sure they do it, too. Start by setting up an initial call to talk through your requirement, lay out a timeline in which you expect candidates by a specific time and explain your process in terms of when you will interview, how many interview rounds and how soon after you will be able to make a final decision on whether to offer or reject the candidates. If you can get this relationship working well, you’ll save lots of time. And make sure your internal teams are focused on supporting your process, not blocking it.

    $$$

    Decide how much you want to pay. It’s not all about the money, but you can waste a lot of your and other people’s time if you don’t lock down the ballpark salary or hourly rate that you can afford. If your budget doesn’t stretch as far as your competitors’, you need to consider what else can help sell the opportunity. Flexible working hours and remote working options are some great ways to do this. Most companies have snacks, beer and cool offices nowadays, so focus on the real value such as the innovative work your team is doing and how awesome your game-changing product might be.

    Drop the Ego

    You may have an amazing company and/or product, but you also have some hot competition. Everyone is hiring in this space and candidates have a lot of the buying power. It is no longer as simple as saying, “We are hiring” and the awesome candidates come flowing in. You need to sell your opportunities. Maintaining a reputation as a great place to work is also important. A poor hiring process, such as interviewing without giving feedback, can contribute to bad rumors being spread across the industry. It only takes a few minutes to leave a sour review on Glassdoor.

    A Smooth Process is a Successful One

    “Let’s get every single person within the company to do a one-hour interview with the new DevOps person we are hiring!” No, let’s not do that. Two or three stages should be sufficient. You have managers and directors for a reason. Trust your instinct and use your experience to make decisions on who will fit into your organization. Some of the most successful companies can do one phone screen followed by an in-person meeting. During the in-person interview, spend a morning or afternoon allowing the candidate to meet the relevant leaders and senior members of their direct team, then take them for lunch, dinner or drinks where you can see how they are on a social level. If you can’t have a simple conversation with them, then you probably won’t enjoy working with them. If the thumbs are up, make the hire and don’t wait around. A good candidate will usually have numerous offers on the table at the same time.

    If all goes well, you should be inviting your shiny new employee or contractor into the office in the next few weeks and hopefully many more throughout the year.

    About the Author / Conor Delanbanque

    conordelanbanque

    Conor Delanbanque has been recruiting and leading recruitment teams in the DevOps space for the past few years. As well as being exclusively responsible for growing some of the most innovative DevOps & SRE teams in the US and Europe as an external consultant and recruiting partner, Conor also founded the Future of DevOps Thought Leaders Debate, sponsors DockerNYC Meetup on a regular basis and co-hosts ServerlessNYC. You can tweet him at @ConorDevOps, find him on LinkedIn or at events, expos and writing articles on staging-devopsy.kinsta.cloud.

     

  • Continuous Testing vs. Test Automation: 3 Key Differences

    Continuous Testing vs. Test Automation: 3 Key Differences

    Testers have been wrestling with test automation for years, yet most teams are not satisfied with their current level of test automation or the overhead required to maintain it. Additionally, the past few years have brought a sea change in the way that applications are architected, developed and consumed—increasing both the complexity of testing and the business impact of software failures.

    How can software testing professionals help the business control risk in light of the increased complexity and pace of modern application delivery? Enter continuous testing.

    What is Continuous Testing?

    Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain feedback on the business risks associated with a software release candidate as rapidly as possible.

    Test automation is designed to produce a set of pass/fail data points correlated to user stories or application requirements. Continuous testing, on the other hand, focuses on business risk and provides insight on whether the software can be released. To achieve this shift, we need to stop asking, “Are we done testing?” and instead concentrate on, “Does the release candidate have an acceptable level of business risk?”

    Why Do We Need Continuous Testing?

    Today, changes across the industry are demanding more from testing while making test automation more difficult to achieve (with traditional tools and methods, at least):

    • Application architectures are increasingly more distributed and complex, embracing cloud, APIs, microservices, etc., and creating virtually endless combinations of different protocols and technologies within a single business transaction.
    • Thanks to Agile, DevOps and continuous delivery, many applications are now released anywhere from every two weeks to thousands of time a day. As a result, the time available for test design, maintenance and especially execution decreases dramatically.
    • Now that software is the primary interface to the business, an application failure is a business failure—and even a seemingly minor glitch can have severe repercussions if it impacts the user experience. As a result, application-related risks have become a primary concern for even non-technical business leaders.

    How Is Continuous Testing Different From Test Automation?

    The main differences between continuous testing and test automation can be grouped into three broad categories: risk, breadth and time.

    Risk

    Businesses today have not only exposed many of their internal applications to the end user, they also have developed vast amounts of additional software that extends and complements those applications. For example, airlines have gone far beyond exposing their once-internal booking systems. They now let customers plan and book complete vacations, including hotels, rental cars and activities. Exposing more and more innovative functionality to the user is now a competitive differentiator—but it also increases the number, variety and complexity of potential failure points.

    Large-scale “software fails” have such severe business repercussions that application-related risks are now prominent components of a business’ public financial filing. Given that notable software failures resulted in an average -4.06 percent decline in stock price (which equates to an average of negative $2.55 billion loss of market capitalization), it’s not surprising that business leaders are taking note—and expecting IT leaders to take action.

    If your test cases weren’t built with business risk in mind, your test results won’t provide the insight needed to assess risks. Most tests are designed to provide low-level details on whether user stories are correctly implementing the requirements—not high-level assessments of whether a release candidate is too risky to release. Would you instantly stop a release based on test results? If not, your tests aren’t properly aligned with business risks.

    To be clear: We’re not suggesting that low-granularity tests aren’t valuable; we’re stating that more is needed to stop high-risk candidates from going out into the wild.

    Breadth

    Even if a business manages to steer clear of large-scale software fails that make the headlines, even seemingly minor glitches can still cause trouble these days. If any part of the user’s experience fails to meet his expectations, you not only risk losing that customer to a competitor—you also risk brand damage if that user decides to take his issues to social media.

    Just knowing that a unit test failed or a UI test passed doesn’t tell you whether the overall user experience is impacted by recent application changes. To protect the end user experience, you need tests that are broad enough to detect when an application change inadvertently impacts functionality which users have come to rely on.

    Time

    Now that the speed at which organizations ship software has become a competitive differentiator, the vast majority of organizations are turning to Agile and DevOps to accelerate their delivery processes.

    When automated testing emerged, it focused on testing internal systems that were built and updated according to waterfall development processes. Systems were all under the organization’s control, and everything was completed and ready for testing by the time the testing phase was ready to start.  Now that Agile processes are becoming the norm, testing must begin in parallel with development; otherwise, the user story is unlikely to be tested and deemed “done done” within the extremely compressed iteration time frame (often two weeks).

    If your organization has adopted DevOps and is performing continuous delivery, software may be released hourly—or even more frequently. In this case, feedback at each stage of the process can’t just be “fast”; it must be nearly instantaneous. If quality is not a top concern for your application (e.g., if there are minimal repercussions to doing a rollback when defects are discovered in production), running some quick unit tests and smoke tests on each release might suffice. However, if the business wants to minimize the risk of faulty software reaching an end user, you need some way to achieve the necessary level of risk coverage and testing breadth—fast.

    For testing, there are several significant impacts:

    • Testing must become integral to the development process (rather than a “hygiene” task tacked on when development is complete)
    • Tests must be ready to run almost as soon as the related functionality is implemented
    • The organization must have a way to determine the right tests to execute at different stages of the delivery pipeline (smoke testing upon check-in, API/message layer testing after integration, end-to-end testing at the system level, …)
    • Each set of tests must execute fast enough that it does not create a bottleneck at the associated stage of the software delivery pipeline
    • A way to stabilize the test environment is needed to prevent frequent changes from causing an overwhelming number of false positives

    Continuous Testing> Test Automation

    If you only take one idea away from this article, we hope that it’s this:

    Test automation ≠ continuous testing

    Continuous testing > test automation

    Even the teams that have achieved fair levels of success with traditional test automation tools hit critical roadblocks when their organizations adopt modern architectures and delivery methods:

    • They can’t create and execute realistic tests fast enough or frequently enough
    • The constant application change results in overwhelming amounts of false positives and requires a seemingly never-ending amount of test maintenance
    • They can’t provide instant insight on whether the release candidate is too risky to proceed through the delivery pipeline

    It’s important to recognize that no tool or technology can instantly “give” you continuous testing. Like Agile and DevOps, continuous testing requires changes throughout people, processes and technology. However, trying to initiate the associated change in people and processes when your technology is not up to the task will be an uphill battle from the start … and ultimately a losing one.

    If your organization is starting or scaling your continuous testing automation efforts, we encourage you to review two new pieces of research by Forrester and Gartner. Both reports provide insight into continuous testing and test automation trends as well as how the top continuous testing tools compare.

    About the Author/Wayne Ariola

    Wayne Ariola (1)Wayne Ariola, CMO of Tricentis, is a recognized thought leader on software testing topics such as continuous testing, risk-based testing, service virtualization, and API testing. Wayne has created and marketed products that support the dynamic software development, test, and delivery landscape. He has driven the design of many innovative technologies and received several patents for his inventions. He has been a contributor to the software testing space for fifteen years and in the software industry for more than 20 years. Connect with him on LinkedIn.

  • Spurring the DevOps Adoption Journey

    Spurring the DevOps Adoption Journey

    Every few years, the IT canvas is splashed with a new initiative that sparks enthusiasm among businesses and technologists alike. DevOps is one such philosophy gaining significant momentum in today’s digital transformation landscape. At the same time, the concept remains misunderstood and adoption is slow.

    DevOps embodies Development plus Operations within software development. Traditionally, these two parts of an organization have operated siloed from one another with marked differences in both ethos and approach. The result: delays in launching products and releases to the market. The fundamental principles of DevOps are to reduce barriers between Development and Operations; increase Development autonomy; and to automate Development and Operations activities to reduce wait time (and waste from a customer’s perspective), thus enabling faster time to market—all while keeping the end customer at the center.

    Planning the Adoption Journey

    Here are four different aspects an organization should consider before starting the DevOps adoption journey:

    Conduct an as-is continuous delivery assessment on product development practices and processes within the organization

    This will best determine an organization’s current maturity level across several different parameters, including:

    • Culture and organization
    • Build management and continuous integration
    • Environments and deployments
    • Release management
    • Testing and verification
    • Data management
    • Design and architecture
    • Information and reporting

    This process also includes identifying current automation levels and opportunities to automate, inclusiveness of tools and environments supporting continuous delivery, and an assessment of existing product design to determine if it lends itself to frequent and fast deployments.

    Map the journey of a piece of code from a developer’s desk all the way to when the consumers use it

    Utilizing a development pipeline assessment to study the life cycle of a piece of code through its journey from a developer’s desk to production will best identify “waste” during the life cycle. This assessment should bring out critical information, including the number of environment hops, test pyramid maturity and level of continuous testing, level of provisioning and deployment autonomy and its automation.

    Establish a culture of inclusiveness, autonomy and a sense of a ‘common goal’ within the organization

    Product management, development and operations teams should have a common mission and goal for the product, sprint or release they are working on. The definition here should be the value delivered to the customer as opposed to the value of code, test results, or individual deployment steps. Including operations roles within a close-working scrum team benefits this cause by:

    • Bringing in common views on what a product, release or sprint is intended to deliver.
    • Creating an opportunity to bring forward and address operations needs during the development cycle.
    • Creating a better understanding of mutual expectations and empathy for delivering outcomes that meet customer expectations.

    Measure and track

    Finally, determine parameters the organization would like to establish to track progress towards a successful adoption. The key here is to have a few, simple metrics that truly reflect “value to the end customer.” Here are a few commonly considered metrics:

    • Production deployment frequency: The number of product releases within a specified time.
    • Average lead time for a production change: The typical amount of time it takes for a piece of code to traverse from a developer’s desk through production.
    • Average production recover time: The time taken to bring back production systems after an incident involving a release, release rollback or system outage.
    • Change failure rate in production: The number of releases that did not stick in the live environment and needed either a rollback or an immediate emergency fix.

    The goal and a true measure of successful adoption would be an improvement of all these parameters over time. Internally, they would require strong engineering rigor and cultural realignment to be able to improve these customer-facing metrics.

    Navigating DevOps adoption successfully is neither easy nor fast for a number of reasons. DevOps encompasses different parts of the organization, which historically may have operated in silos and with different ethos. DevOps also questions the status quo regarding engineering roles and practices, and focuses on automation and reskilling, all of which need both upfront time and effort investment. Finally, DevOps believes in and propagates continuous learning and improvement, whereas many organizations may have more stepwise-based programs in place.

    For a midsized IT organization, it could take anywhere from 18 to 24 months or more to be able to reach a reasonable steady state. That’s why it is important to carefully craft a charter that encompasses the above parameters before embarking on this DevOps adoption journey.

    About the Author / Amit Gupta

    Amit Gupta is leader of Ness Digital Engineering’s DevOps practice. He has several years of software delivery background. He has keen interest and has developed deep expertise in establishing practical software development processes especially for globally distributed teams. Amit currently leads Ness Digital Engineering’s DevOps practice, and engages with several customers on such areas as improving engineering effectiveness, engineering tools and process transformation. Connect with him on LinkedIn.

  • Improving DevOps Success with Well-Defined Metrics

    Improving DevOps Success with Well-Defined Metrics

    Collaboration within diverse project teams is often more difficult to achieve when there is no clearly visible aim, the planning is haphazard and the information shared is inadequate. However, these are crucial hurdles to overcome in any organization—and more so in product companies with globally distributed teams working on different parts of the product pipeline.

    Successful product development requires effective and constant communication between various teams through well-defined metrics, not only to reduce the engineering operations overhead but also to improve on the overall engineering deliverables.  These metrics, including  ROI or profitability, mean time to recover and deployment frequency provide a clearer picture to an engineering or business owner on how the Dev and Ops teams are working, their adherence to processes and guidelines and the technology they’re using.

    Every engineering owner likes to know if the technology investment they make is going to yield a significant ROI. It is no different with DevOps. It is important to identify the exact metrics by which the positive impact of DevOps can be measured.  The most effective way to illustrate these metrics in a way that would make sense to senior management is revenue impact.  Here are a few of them which have had proven success on internet of things (IoT) projects.

    Business metrics such as cycle time impacts incremental sales and customer satisfaction. Whereas other business metrics such as product investment and running costs impact profitability, DevOps implementation effectiveness can be measured by both. Cycle time is, in turn, derived from a number of product features delivered, sprint velocity and release planning metrics. The lower the cycle time, the more features get pushed and impacts the go-to-market. It also results in potential incremental revenue in terms of the value brought by reducing the cycle time.

    Another dimension to measure DevOps impact is engineering metrics. Companies today are worried about the cost of downtime in the operational phase as much as they worry about time it takes to bring the product to market. DevOps metrics are valid throughout the end-to-end implementation of a project.

    Build automation and code quality analysis, for example, can provide significant savings in build cycle time and build rollout time. Automating deployment process improves time to deploy and sprint velocity. Continuous testing improves mean time to resolve, and CloudOps monitoring tools can help reduce mean time to recover and uptime of any application. Further collaboration in automation through ChatOps tools can help improve mean time to respond. Once set in motion, all these matrices start improving the product quality, which leads to less rework. Intelligent automation also incurs direct productivity benefits.

    Organizations now measure these codes to release the metrics at the end of the day to get maximum ROI. A lot of these metrics also depend on the DevOps capability maturity. Organizations at the higher end of the maturity spectrum would tend to measure all of these metrics and try to optimize them. Also, the emphasis of these metrics vary with the domain and stage of the product life cycle being worked on. Home automation companies developing their IoT platform, for example, would emphasize build and deployment metrics, whereas companies in industrial automation with large infrastructure deployment would look at CloudOps monitoring metrics more closely. For telematics companies, test automation metrics become important when there is limited time and bandwidth to capture the data.

    DevOps is a cultural transformation and most of the time businesses measure the effectiveness in a very obvious way. However, a change in the way the organization operates should be looked in such a way that the metrics can generate long-term value. Thus, continuous measurement of the DevOps practice should also become one of the major focus areas of DevOps teams.

    About the Author / Urvashi Babaria

    Urvashi Babaria is a Product manager at eInfochips working in new age areas like IoT, DevOps and CloudOps. She is a techno commercial marketer with nine years of experience in product and project management, business analysis and transformation. She has keen interest in areas of data science including visualization, analytics and modeling. You can start a conversation with her at urvashi.babaria@einfochips.com

  • SRE vs. DevOps — a False Distinction?

    SRE vs. DevOps — a False Distinction?

    Just a few days before he died at the beginning of the 1990s, a wise man taught us that “the show must go on.” Freddie Mercury’s parting words have long provided the guiding light for many, if not all, ops teams. In their eyes, the production environment should be exposed to minimum risk, even at the expense of new features and problem resolution.

    About 10 years ago, Google decided to change its approach to production management. It took the company only a few years to realize that while R&D focused on creating new features and pushing them to production, the Operations group was trying to keep production as stable as possible—the two teams were pulling in opposite directions. This tension arose due to the groups’ different backgrounds, skill sets, incentives and metrics by which they were measured.

    Trying to bridge this gap between the two groups, one of Google’s ops leaders, Ben Treynor, thought of an innovative solution. Instead of having an Ops team built solely from system administrators, software engineers—with an R&D background and mentality—could enrich the way the team worked with the development group, change its goals and help with automating solutions.

    Site Reliability Engineering, or SRE

    And so, the Site Reliability Engineering position was created. According to Google, SRE engineers are responsible for the stability of the production environment, but at the same time are committed to new features and operational improvement. Google decided its SRE teams should be composed of 50 percent software engineers and 50 percent system administrators. The engineers were driven to use software as a way of solving problems and perfecting what had historically been solved by hand. They integrated easily with the development team, and encouraged code quality improvements and automation testing.

    Understanding the value of SRE, several organizations of various sizes decided to embrace its principles. Some, such as Dropbox, Netflix and Github, are well-known for being at the forefront of technology leadership.

    Wait, Isn’t That DevOps?

    DevOps is a more recent movement, designed to help organizations’ IT department move in agile and performant ways. It builds a healthy working relationship between the Operations staff and Dev team, allowing each to see how their work influences and affects the other. By combining knowledge and effort, DevOps should produce a more robust, reliable, agile product.

    Both SRE and DevOps are methodologies addressing organizations’ needs for production operation management. But the differences between the two doctrines are quite significant: While DevOps raise problems and dispatch them to Dev to solve, the SRE approach is to find problems and solve some of them themselves. While DevOps teams would usually choose the more conservative approach, leaving the production environment untouched unless absolutely necessary, SREs are more confident in their ability to maintain a stable production environment and push for rapid changes and software updates. Not unlike the DevOps team, SREs also thrive on a stable production environment, but one of the SRE team’s goals is to improve performance and operational efficiency.

    Google tried a few approaches to implementing the SRE process before finding the one that suited them best. One of these approaches attempted to tie the number of permitted releases to the product’s stability. The principle underlying this process is that new releases are green-lighted based on current product performance.

    For each service, the SRE team sets a service-level agreement (SLA) that defines how reliable the system needs to be to end users. If the team agrees on a 99.9 percent SLA, that gives them an error budget of 0.1 percent. An error budget is exactly what the name suggests: the maximum allowable threshold for errors and outages. Here’s the interesting thing: the development team can “spend” this error budget in any way they like. If the product is currently running flawlessly, with few or no errors, they can launch whatever they want, whenever they want. Conversely, if they have met or exceeded the error budget, and are operating at or below the defined SLA, all new releases are frozen until they reduce the number of errors to a level that allows the launch to proceed. This process ensures that both the SREs and developers have a strong incentive to minimize the number of errors in production.

    Another interesting approach recommended by Treynor, which is more related to SRE professionalism and efficiency, is allowing SREs to move between projects. Moreover, he suggests allowing SRE engineers to move to development, and even the other way around. As the work done by both teams is similar, these transitions help the Ops team gain better and deeper knowledge of the product and code, and bring the Dev teams into the production space to help them understand its challenges. This strongly promotes a team atmosphere, rather than one in which an individual feels that “I’m on the SRE team for this product.” As part of this approach, Treynor had Dev teams handle 5 percent of the operations workload. This, according to many organizations, adds to the SRE team’s motivation and effectiveness.

    Riddles in the Dark

    Well, SRE seems perfect. As already stated, several large-scale organizations have chosen to move some of their production operations from old Ops to SRE. However, there are still a few questions that need to be asked:

    Is the position of SysAdmin (production/ops) no longer relevant for SysAdmins?

    Historically, almost all system administrators have come into their roles through tech support and similar work, or even just running Linux on their desktops and then transitioning into server work. It should be pretty clear that the same path is not available into SRE. To retain their positions, SysAdmins should now be more code-oriented, have better technological knowledge and be receptive to new methods of conducting the work they already do.

    Can an SRE team prevent production incidents?

    One of the strengths of a professional site reliability engineer is the ability to handle the growth of production load and traffic in-house. Monitoring and analyzing processes and logs with platforms such as the ELK Stack is part of the day-to-day workload, and the team should be able to identify problems as they occur, and even foresee risks to software stability. The power of this position—based on the skill set it requires—lies in developing solutions for these problems and risks. As Ciara, a software engineer in Google’s cloud storage SRE team, described it in a “Life in Google” post, “We solve cooler problems in cooler ways.”

    Are we doing DevOps or are we doing SRE?

    This question is usually asked by people trying to position themselves in the Operations world. According to many companies that implemented SRE in a slightly different way than Google, you don’t have to decide. At Reddit, ops engineers work on reducing toil, improving deployment and scaling processes, but they are referred to as “DevOps.”

    At Logz.io, we bridge the gap between developers and production through the use of automated monitoring and performance stress-testing. And we personally refer to it as “DevOps” rather than “SRE.”

    So, is it Just a Question of Context?

    In her blog, Charity Majors talks about SRE and DevOps being two different operational approaches that any organization can choose to work by, but insists on emphasizing that there is no “correct” approach. Although Google and Dropbox have decided on SRE, this does not mean the rest of the world should do so as well. What fits Google’s needs and organizational philosophy does not necessarily work for other orgs—at any scale. Moreover, Charity believes that DevOps, having grown and evolved within a broader variety of software organizations, is the more flexible, collaborative and adaptable approach, and will work better for most software organizations at all stages of development.

    On the other hand, SoundCloud senior engineer, Matthias Rampke issued a series of tweets on how SRE and DevOps were basically the same, with only one difference—high management support. Though in contradiction to her blog, Charity lent weight to this opinion during an AskMeAnything event that revolved around DevOps and SRE. She shared a story about a friend who was hiring for a startup, which, as an experiment, posted the exact same job description twice, the only difference being that one listing was titled “DevOps engineer,” and the other “SRE.” At the time of relating the story, DevOps was winning by 10 percent or 20 percent. However, all this means is that the job title is irrelevant, and naming an SRE team does not magically bestow qualities upon it. Rather than focusing on the title, organizations must focus on the work being done.

    To summarize, we can quote Matt Simmons, a technologist with many insights into this topic, who says, “Not every infrastructure needs an SRE, but every infrastructure could use an administrator who acted more like one.”

    — Asaf Yigal

  • Get Ready to Become a Full-Spectrum Engineer

    Get Ready to Become a Full-Spectrum Engineer

    The more things change, the more they stay the same. In software development, change has been a constant. I’ve been a software engineer for more than 25 years and have had to morph, pivot and learn new things to remain current and in demand. Plus, the industry swings like a pendulum between the need for specialists and generalists and that cannot be ignored: The advent of new architectures, methodologies and disciplines drives the need for specialists. Once assimilated, the market drifts back toward generalists.

    Back in the day, it was not uncommon to have 50+-person teams building applications using the Waterfall methodology. From a technology perspective, development was kept in silos for each specialty. It was uncommon for a developer to straddle specialties such as GUI, business logic, database and quality assurance.

    The swing back to generalists was driven by the shift to Agile. When the Agile methodology became prevalent, we saw the teams of 50 reduced to teams of six to 12. The reduced team size also reduced the number of specialist you could have on a team. Developers needed to know more and do more. Today, most companies are looking for generalists who can do it all—otherwise known as the full-stack engineer. These developers work on web applications and can operate in any vertical tier of the application. They write HTML, CSS and JavaScript for high-performing and functional UI for the front end. They can also work from the server side to develop the business logic to support the UI. Behind that are the database schema and queries they write to move data in and out of the application.

    Enter the Full-Spectrum Engineer

    DevOps has ushered in a new trend. Teams are moving from batched releases of functionality to single-piece flow. In other words, we no longer think about collecting the work of multiple engineers over multiple sprints into a release. Our ability to bring value to the customer as soon as possible and out-innovate the competition will be driven by releasing the work of a single engineer as soon as it is ready. This typically is accomplished through a continuous integration/continuous delivery (CI/CD) pipeline directly from the source repository through automated testing and finally deployment into production, preferably without any human intervention.

    What does this mean for developers? Plenty. Here’s a look at the major capabilities needed by software engineers who want to thrive as full-spectrum engineers (FSEs.)

    1. Be a good software engineer. That means keeping up with the latest trends in design and implementation. You need to assimilate new frameworks and open-source libraries into your first party code to build software quickly. Furthermore, you must understand scale and performance of the system under load. Creating services that scale out and back based on demand will enhance the user experience.
    2. Have an eye toward quality. This means testing both the functional and non-functional aspects of the application. Well-written unit tests are just the beginning. An FSE must think about how to create automated regression tests that can run in a staging environment to assure that the entire system will not be negatively impacted by their deployment. Testing for non-functional aspects such as performance are a must as well.
    3. Understand the complexities of deployment. Whether that be containers, cloud or infrastructure as code, you need to know where and how the software runs and be able to create those environments from scratch. Using stable, version controlled configurations for the running environment will ensure that Dev, QA, Staging and Production all look and behave the same. That makes testing repeatable and operations more straightforward.
    4. Don’t forget about operating the software. As part of a DevOps team, you will be expected to take part in pager duty. When writing new functionality, consider how to debug it remotely and whether your teammates will be able to do the same. That means logging and other telemetry are critical but insufficient. Turn that data into information that can be consumed by both people and machines. Can the software detect that it is not running properly? Can it heal itself? Can it call for help?
    5. Make security a priority. The fast pace of software development means that there is no longer time to wait for a security analysis or pen test when your release candidate is ready to deploy. Security standards should be part of the acceptance criteria and security scanning must be added to your definition of done. Use tools that can provide quick feedback and diagnosis of security vulnerabilities while writing code as well as identify vulnerabilities in your open-source components. This preventative scanning will not only train you to write secure code, but it will also allow the software to run successfully through the assurance scans that are part of any good CI/CD pipeline.

    DevOps is turning the concept of a full-stack engineer on its side. Now the vertical tiers of technology and architecture are secondary to the horizontal disciplines that must be mastered to create software at the speed of DevOps. While I am eager to tell you that the future of software development is generalist, it does not mean that we should get rid of our specialists. What it does mean is that we will need fewer of them—the skills and capabilities of a full-spectrum engineer are the future of software development. DevOps has smashed the velocity barrier but to reach the full potential will require a new breed of multi-disciplined generalists—Full-Spectrum Engineers.

    About the Author / Peter Chestna

    As Director of Developer Engagement at Veracode, Pete provides customers with practical advice on how to successfully roll out developer-centric application security programs. Relying on more than 10 years of direct AppSec experience as both a developer and development leader, Pete provides information on best practices amassed from working with Veracode’s 1,000+ customers. Pete joined Veracode in 2006 as a platform developer and was instrumental in delivering the first version of Veracode’s service to customers. Later, as Director of Platform Engineering, Pete managed the Agile teams responsible for delivering Veracode’s SaaS platform and built the first DevOps team. Follow him on Twitter @PeteChestna.

  • Advancing DevOps with Diagrams

    Advancing DevOps with Diagrams

    The Application model can be incredibly useful to map out application features, planned changes and current flaws, and even for roadmapping. The model takes organizational time and effort, and can only be created and maintained when a universal language has been developed by a modeling team. The effort is well worth the cost, however, since it can lay the foundation for a better DevOps environment.

    The modeling team will represent various organizational backgrounds and must bridge gaps of understanding that are common between technical and non-technical personnel. The team also will include operations and development professionals so that collaborations produce not just deeper understandings, but also lay framework that meets, corporate, Dev and Ops needs from the beginning.

    Diagrams can be used by the modeling team to foster the understanding and creation of a universal language by adding more context to ideas and processes. Diagrams serve as a drill-down exercise and can be drawn on a whiteboard, sketched on a notepad or formalized with a UML tool.

    Diagrams become more technically correct as they are iterated on, and can be easily retained for future discussions. Further, the base of some diagrams often enable other types of diagrams that can be helpful to the development team (such as Class or ERD) and provide a level of technical documentation. They also provide a base of discussion for the modeling team to relay discussions back to their organizational units for feedback and improvement.

    Last, and perhaps most importantly, diagrams help to remove ambiguity that is inherent to narrative descriptions and discussions. Removing ambiguity is at the heart of the universal language and enables clear communication, a key tenant of DevOps.

    We can show this drill-down in diagramming by focusing on a small and simple operation: describing what happens when a new customer enters a banking system for a business loan.

    UseCase Diagram

    A common place to start is a UseCase Diagram like the one below.

    The diagram shows a few key points of data:

    • There are two types of employees (actors) that are involved: a Loan Officer and an Underwriter
    • The Loan Officer and the Underwriter interact with three business elements: Client Files, Credit Requests, Requested Information

    This diagram might not seem very useful to those outside of the discussion, but it is the first step to creating more in-depth and useful diagrams.

    Activity Diagram

    A logical and easy step from a UseCase Diagram is an Activity Diagram. It takes many of the same concepts and expands them to a step-by-step order of procedures, which are established by discussion of current procedures as well as compliance and regulatory needs.

    By partitioning procedures into vertical “swim lanes” we now have an order to the processes as well as who or what is responsible for it.

    The first partition, labeled Loan Officer, shows three processes (Create a Client File, Create a Credit Request, and Upload Financial Statements) that they are responsible for before the system can do anything. All three pieces must be present before moving beyond this first position.

    Once those items are taken care of, the system then notifies the second Actor, the Underwriter, that there is a credit review for him or her to perform as well as where to locate the needed data.

    The Underwriter then decides whether the loan is approved. Whether this is a semi-automated process or done entirely by humans is beyond the scope of this diagram; all we need to know is that a decision happens next. What we can see is that the Underwriter has two options. He or she can:

    1. Decide on the loan (approve or deny—again, beyond the scope), at which case the system takes over from there.
    2. Request more information from the Loan Officer (perhaps the wrong files were uploaded or more data from the client is needed). The system would then notify the Loan Officer and the process starts over.

    Activity Diagrams are useful for documentation because they start to add structure to the overall business process. They also start to define which processes are:

    • Managed by humans
    • Managed by the application being developed
    • Represent a system that the application will interact with, and operations will need to secure

    Even if not 100 percent technically correct (as our sample isn’t entirely correct), they still represent information in a meaningful way that anyone with little or no guidance can understand.

    Data Flow Diagram

    With Data Flow Diagrams (DFD) the diagrams start to map out the system and procedures that happen and the flow of data. DFDs, which are more involved than the other diagrams so far, become keenly useful in showing how different processes interact. Even though DFDs become more detailed as more layers are added, they are still understandable and explainable to any member of the modeling team no matter the background.

    Operations teams often find them helpful since they map out when sensitive data may be accessed or stored. In our example, things such as corporate tax returns will be stored and accessed; there obviously would need to be some security measures implemented to ensure only those with clearance can see them.

    Discussions are key when creating Data Flow Diagrams because it would be very rare for an individual to have all of the knowledge needed to create one without questions and answers. Based on our current diagrams and a few questions such as:

    • Are Client IDs manually created, or is it part of a system?
    • Do requests go to specific people or are they delivered via queue?
    • Is the credit decision part of the original application or saved as a separate file?

    A DFD can be drawn up:

    The DFD may look complex at first, but when taken piece by piece it is quite simple and understandable with very little (if any) explanation. It also can be helpful to the Dev team because it isolates specific processes at a granular level.

    For example, the Dev team may see the process “Get ID,” know that it’s a system process (non-manual) and realize that they already have a module like that in an existing application that they can use for this application.

    Of course, this would be one of many DFDs created during an Application Model, which is another key advantage of using DFDs. Data Flow Diagrams can be layered, starting with a context diagram and working down granularly to the smallest process needed. This layering also naturally helps to break down the application to discreet parts, helping both in creating different parts of the Application Model as well as having natural starting and stopping points for conversations.

    With the idea that there can be many diagrams used during these discussions, it can be useful to use a modeling tool to easily create, edit, layer and store the diagrams for future use.

    Other Diagrams

    Of course, these are only a few diagrams, but they demonstrate how a process of diagramming can be useful to help a modeling team communicate. While a team could start with a Data Flow Diagram, it would be a much more difficult process. However, by walking through a UseCase and an Activity, it becomes easier since it breaks a system down into digestible parts.

    It also provides the modeling team easy-to-understand diagrams when they go back to their business units. They can explain the Application Model and get quality feedback, as well as suggestions to be added into the Model.

    These diagrams also can be helpful for teams as a starting point for documentation. The DFD is a good starting point for:

    • The Development team to create a detailed class and component diagrams that outlines the application architecture.
    • A deployment diagram for Operations to note which data to isolate behind a firewall with limited access.

    While no process of diagramming can create a universal language by itself, diagrams are supremely helpful to create team clarity. They also serve as a memory of Application Model discussion so that human error and memory can be reduced. Last, by helping to eliminate ambiguity among the modeling team, they help drive better communication that is part of the essence of DevOps.

    Note diagrams were created in Astah Professional and used with permission. To learn more about Astah and modeling please visit the company’s website.

    About the Author / Scott Reece

    ReeceScott Reece is a huge fan of the greater visibility and communication enabled by DevOps. As a Friend of Astah Scott has been successfully closing project communication gaps by using models and team building. With more than 10 years of project management experience, Scott currently serves as a Partner Director at Inedo.

  • The State of DevOps Adoption and Trends in 2017

    The State of DevOps Adoption and Trends in 2017

    DevOps has come a long way, and we see a tremendous increase in adoption in the recent years. To outrank your competition and be ahead in the growth curve, it has become an essential element for software-powered organizations. DevOps has taken a center stage in the software development field with no signs of leaving.

    Below is an infographic of DevOps and some of the trends we see happening this year in DevOps:

    DevOps trends in 2017

    Sources:

    http://www.rightscale.com/blog/cloud-industry-insights/new-devops-trends-2016-state-cloud-survey

    https://www.storybase.com

    slideshare.net

    https://en.wikipedia.org/wiki/DevOps

    Google.com

    7 DevOps Trends

    1. DevOps will be the mainstream and garner a lot of attention; hence, 2017 is going to be the “Year of DevOps.”
    2. Along with DevOps, the three C’s—Continuous Integration, Continuous Deployment, and Continuous Delivery—are going to gain a huge momentum.
    3. A number of new DevOps automation tools will be released that change the way we do software development.
    4. “Containerization” also will be in the limelight.
    5. Many software firms will move to a microservices architecture.
    6. Automation and continuous testing will become more popular—and more important.
    7. Must-have tools and platforms including Docker, AWS, GitHub and JIRA will become even more popular within developer zones.

    The Names to Know

    Below are the names of the top DevOps experts you need to follow:

    Name Twitter Profile Who is He/She Klout Score Website
    patrickdebois https://twitter.com/patrickdebois bridging the gap between creativity and technology with a #devops mindset; eternal researcher and pragmatic implementor; cto @townheroes; started @devopsdays 50 http://www.jedi.be/blog/
    Avi Cavale https://twitter.com/avinci ceo @beshippable, wildlife photographer, scotch lover 50 https://app.shippable.com/
    Kris Buytaert https://twitter.com/krisbuytaert Everything is a Freaky #Devops Needs Sushi Problem, Open Source, Infrastructure as Code, Consultant, Speaker, Author, Organiser of #devopsdays, #cfgmgmtcamp 53 https://about.me/krisbuytaert
    Gene Kim https://twitter.com/realgenekim DevOps enthusiast, The Phoenix Project co-author, Tripwire founder, Visible Ops co-author, IT Ops/Security Researcher, Theory of Constraints Jonah, rabid UX fan 64 http://www.realgenekim.me/
    Jez Humble https://twitter.com/jezhumble Co-author of Continuous Delivery, Lean Enterprise, DevOps Handbook; CTO devops-research.com, lecturer @BerkeleyISchool. PGP: https://keybase.io/jezhumble 63 https://continuousdelivery.com/
    Gareth Rushgrove https://twitter.com/garethr Software developer, occasional sysadmin, general web, programming and technology geek and curator of Devops Weekly. Engineer at @puppetize. @gdsteam alumnus 56 https://www.morethanseven.net/
    Denise Dubie https://twitter.com/ddubie Strategic Content Creator @CAInc, editor/writer/techie focused on App Economy, DevOps, Mobility, ITSec.& Mgmt., Cloud; former Network World/IDG tech journo. 50 https://www.ca.com/us/rewrite.html
    Sanjeev Sharma https://twitter.com/sd_architect #DevOps #Agile #Cloud #TechSales #CTO #Architect #Author – #DevOpsForDummies #Blogger #Inventor #Disruptor #IBM #DistinguishedEngineer. 52 https://sdarchitect.blog/
    Donnie Berkholz https://twitter.com/dberkholz Research director for development, DevOps & IT ops @451Research. PhD biophysicist. Open-source OG. Emerging tech, craft beer, and zeroth-world problems 59 https://451research.com/analyst-team/analyst/Donnie+Berkholz
    Nathen Harvey https://twitter.com/nathenharvey VP, Community Development at Chef 57 http://nathenharvey.com/
    Damon Edwards https://twitter.com/damonedwards DevOps, IT operations, and improving how businesses operate is my thing. Rundeck is where I work. 49 https://www.rundeck.com/

    We hope DevOps will be a rock star in 2017 and continue to rule the software industry.

    — TeamShippable