Category: DevOps Culture

  • DOES London 2019: Give Repos the Respect They Deserve

    DOES London 2019: Give Repos the Respect They Deserve

    Think about it. could we have a DevOps or even agile without code repositories (repos)? Repos allow for version control, team collaboration, testing on check in and more. So much of what we do today around software development and DevOps is based on the repo.

    For a long time and even today, the repo was sort of the Rodney Dangerfield of software tools. In spite of how important it is, it didn’t get the respect it deserved. Of course that changed a bit when Microsoft laid out all those billions of dollars for GitHub. But even then, the narrative was Microsoft paid that much to reach all those millions of developers that used GitHub. Not for all of the great features and functionality GitHub delivered to its million users.

    Also, in the case of GitHub, they had done a masterful job of weaving together a fantastic free, open source tool with enterprise features and SaaS delivery models to build a legitimate business for everyone from single developers to small groups and all the way up to large enterprises.

    Nigel Abbott, GitHub

    In this interview from the Digital Anarchist news room at DevOps Enterprise Summit London, 2019 we spoke with Nigel Abbott, director at GitHub for EMEA. After leading GitHub’s efforts for the enterprise in the UK, Nigel is now leading enterprise efforts for all of Northern Europe.

    This was a great interview with Nigel and hope you will enjoy it, too.

    Nigel Abbott, GitHub | DOES London 2019

    Don’t forget! DevOps Enterprise Summit Las Vegas 2019 is happening from October 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already and join us for a premier event for the technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

    — Alan Shimel

  • Why Modernizing Security is Like Visiting a Fast-Food Restaurant

    Why Modernizing Security is Like Visiting a Fast-Food Restaurant

    Fast casual restaurants are taking over the food industry. Today’s consumers want quality and speed, and the brick-and-mortar model offering immediate service paired with quality ingredients perfectly fits the bill. It’s the new, modernized dining experience. You can also argue that the same modernization taking the food industry by storm is happening in the security sector.

    Simply put, fast-food restaurants know what their customers want: food that’s served hot, fresh and quickly–all while being made to order. And while the needs of a fast-food customer may seem far from the security needs of an organization, it isn’t too far off. Just like a fast-food customer, DevOps teams are hungry for a streamlined process. However, in their case, this doesn’t come in the form of a fried chicken sandwich; rather, an app infrastructure that is low-latency, secure and brings visibility.

    According to the 2018 Verizon Data Breach Investigations Report, web application attacks are the leading source of data breaches. This suggests security procedures are not keeping up with modern systems and vice versa, which means they’re not keeping up with the modern customer, who has increased security needs due to demands for fast, interactive, web-based experiences with vendors. From food service to security, many industries are learning that, to succeed today, you’ve got to combine the old with the new.

    As technology evolves, systems must as well. When it comes to security, it does not make sense to continue using a legacy WAF built for a decades-old line of defense. Today’s technology and applications require next-gen WAF systems that can keep up with the changing infrastructures and the evolving threat landscape. The risk is too great to sit back and do nothing.

    Security teams today often find themselves either supporting new infrastructure initiatives or inheriting legacy applications and systems. Determining where an application is running can be a challenge. Rather than simply pointing to a rack of servers to locate an app, security professionals now must look to the cloud. However, this presents another obstacle: container orchestration. Kubernetes or otherwise, the options are not always clear-cut.

    A modern infrastructure mix is made up of many parts (much like a layered chicken sandwich): cloud, containers, hardware, platforms—and sometimes serverless. Flexibility and deployment options are essential to defending applications and APIs across multiple components and delivery stacks. Typically, security teams end up in a balancing act of supporting new infrastructure plans while taking over existing legacy systems and applications.

    To be adequately protected, security teams must evaluate defensive tools, open source or commercial, for use in:

    • Major cloud providers (e.g. AWS, Azure, IBM, GCE)
    • Container platforms (e.g. Kubernetes, Docker)
    • Hardware and web servers (e.g. load balancers, NGINX+)
    • Serverless options (e.g. API gateways)
    • Platform services (e.g. Heroku, language plugins)
    • Cloud-based deployment models (e.g. hosted cloud WAF)

    The modern world is ever-evolving and the definition of “modern” changes as new technology is introduced. Fast-food chains have evolved over the years and, in turn, moved the food industry forward with the introduction of fast, casual and reliable options. The companies continue to evolve to meet the customers’ demands by introducing delivery services, unique rewards programs and leading mobile apps.

    The security world can learn a thing or two from the fast-food chains’ commitment to continued business evolution. Much like the way fast-food customers are quick to jump ship if they don’t see the selection they want, legacy WAF customers are learning they can make a change to other security solutions if features and infrastructure aren’t evolving.

    The simple truth is legacy WAF solutions can’t accommodate today’s technology and applications, exactly how traditional fast-food can’t keep up with customers’ growing demand for tasty yet quick meal options. This leaves proprietary data exposed and vulnerable to attacks. It’s time for security leaders to take action and upgrade their systems while getting their teams up to speed without sacrificing security of their vital assets.

    — Jonathan DiVincenzo

  • Embracing the Product Development Cycle

    Embracing the Product Development Cycle

    Nowadays, a truly successful product calls for purposeful investment in the people that will ultimately use it in their specific environments.

    We all know technological development is hyperactive and unpredictable. Ultimately, we want to be able to create cutting-edge tech, deploy it wherever it’s needed and have it operated by skilled staff that understand all the nuances. We need to be able to move fast, adapt on the fly and do so with security mechanisms that fire on all cylinders–irrespective of environment.

    The best way ahead is to actively engender a more informed user base that can apply experience and context. There are big benefits to be had by doing this. With the right investment and infrastructure, the aim is for informed and confident end users to form symbiotic relationships with the vendor, helping to guide product and solution development on an ongoing basis. Operational challenges are not static, so the technology in place to meet them certainly shouldn’t be.

    Vendors need to embrace the mindset that a product’s lifecycle needn’t be clunky, disrupted by diversions or constrained by boundaries. It is all about continually engaging and listening to every contributor to a product’s existence: customers, partners, engineers, support staff–the whole ecosystem. Collaborate, innovate, feedback, improve and repeat. The future is a dynamic continuum of constant innovation and improvement.

    As part of F5’s transformation to a multi-cloud application services company, we had to train hundreds of engineers around the world with a new set of foundational skills in cloud, automation, orchestration and DevOps methodologies. Essentially, the process entails developing training content to test with a selection of key users. Areas of improvement are identified, and these are then built into the product. The cycle is repeated.

    It may sound simple but you’re not going to get the substantive, actionable feedback you need without instilling the right culture. For this, you need a lot of training and documentation. You need to guide the way with strategic credibility and maintain confidence. Above all, you need to be patient and listen.

    At F5, we’re constantly building out the mechanisms for how we train in conjunction with our development efforts. A big part of that is integrating adequate feedback loops—both on the training and products front. If a customer hits a wall, what did we learn? How can we contribute via open source? How do we leverage what we learned to make our products and people better?

    We’re not just building automation and orchestration solutions. We’re aligning to the methodology around DevOps and the software process. We’re designing as if it were a giant distributed software project that happens to run on and integrate with the F5 platform. All of this gives us the means to start a new conversation with customers, one that is entirely based on how to achieve successful outcomes. Sometimes we may assent to, for example, the introduction of a new feature. Sometimes, we’ll push back. We will always be agile, adaptable and collaborative. It is never anything less than an eye-opening journey. It needs to be. We have no interest in directionless wheel-spinning, nor do our customers.

    Another major benefit of our approach is it explicitly and effectively helps NetOps become a true partner of DevOps. This means projects are no longer bounced around in silos, bottlenecks are eliminated and the results speak for themselves. Going through this process and making these shifts have fundamentally changed F5’s ethos and identity. We had to change in order to fully engage with the bleeding edge, with the way container ecosystems are built, the way microservices are built or the way software is developed in the modern age.

    — Hitesh Patel

  • A Culture-Driven Approach to DevOps Transformation

    A Culture-Driven Approach to DevOps Transformation

    One of the most challenging aspects of a DevOps transformation isn’t automating and overhauling technology. The biggest challenge of DevOps is changing an organization’s culture and purpose. You can’t “buy a DevOps.” DevOps demands the involvement of people, process and tools working together.

    Unfortunately, I’ve seen too many companies get carried away with the latest shiny object and neglect the people aspect. So, the end results they were expecting do not come to fruition. Research from Google Cloud and Harvard Business Review supports the importance of a people-first DevOps strategy. This research confirms DevOps transformation projects are worthless without addressing the people aspect.

    Of course, such large-scale transitions are difficult. People have to put their reputations on the line to sell the transformation. Employees may become stressed or resist the cultural changes that come with a DevOps transformation. Therefore, communication throughout the entire transformation must be your primary goal. Communication includes measuring the effectiveness of the transformation vision and goals and sharing that information with your team. Keeping them informed ensures they understand the critical role they play in this vision, as well as the value of their work. These measurements need to also show how participation in change translates to value for the business.

    Here are some best practices for prioritizing people and process when working through your DevOps transformation.

    Communicate Every Step of the Way

    It’s important to establish a level of empathy for your employees and understand exactly how changes will affect them. Employees’ professional identities develop over many years, and you can’t expect them to change overnight. Here are some questions your employees are wondering about:

    • What happens to my job when we have to start adhering to this new process?
    • Will I lose my job when all this automation is implemented?
    • How am I going to learn the skills to be effective and contribute to this new way of working?

    Expect their questions and listen for more areas of concern. Be proactive about sharing both the questions and the answers with everyone.

    It’s critical that you keep an open channel of communication with your employees to help them through this change. Don’t view this as an add-on exercise–it should be the cornerstone. Focus on communication, and devote time to your staff, so they are completely integrated into the new DevOps process.

    Your communication strategy needs to include all the teams involved with application delivery. Hold regular meetings across all departments, not only development and operations teams. Think about how the DevOps transformation impacts departments such as marketing, human resources and finance. What challenges have they run into? Have there been any negative impacts thus far? Listening and addressing each issue in real time will ensure the transformation is moving in the right direction.

    Measure What Matters

    When it comes to measuring your success, don’t worry about what other companies may be doing. The metrics that matter are the ones that support your ultimate business goal, which in this case is a better software delivery process.

    Identifying metrics for your business demands you understand how your company’s process drives behavior. Ask questions such as: What corners were cut to get from development to production on time? Did meeting this deadline impact the timelines and performance of other teams and the quality of other applications?

    Meaningful metrics allow you better insight into your processes in the real world. And meaningful metrics help determine whether your pipeline is moving in the right direction to deliver high-quality, high-value software.

    Remember those regular meetings I mentioned earlier? These are also a great time to focus on metrics so employees understand how their work impacts the business. It’s also an opportunity to hear what’s happening on the ground in the delivery pipeline. This real-world information can determine progress, as well as test if the right metrics are being tracked.

    Conclusion

    A DevOps transformation requires changes to staffing, organizational structure, performance and culture. As a result, the success of your transformation involves moving the entire organization forward—building a strong culture ensures all people at all levels are invested in it. Measuring and communicating results must be the standard for every release you do.

    DevOps can fundamentally change any organization for the good. By continually communicating a clear vision of the goals and expectations of your transformation, people will feel confident they are on a winning track.

    — Tj Randall

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

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

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

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

    Principles and IT Excellence

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

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

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

    Consider the Lean principles pyramid from a DevOps perspective:

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

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

    Systems and IT Excellence

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

    The Insights

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

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

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

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

    — Mike Orzen

  • The SRE Pressure Cooker: Balancing Velocity Against Risk

    The SRE Pressure Cooker: Balancing Velocity Against Risk

    Delivering fast, reliable digital services today is a lot like Olympian alpine skiing. These services must deftly maneuver a series of perilous passages en route to end users, all while maintaining the astounding speed we now take for granted.

    In an SRE’s world, those passages are today’s increasingly complex and interconnected internet infrastructure through which they must deliver and support cutting-edge application functionality–all while rolling out updates at a relentless pace. It may appear easy to end users, but SREs are working incredibly hard behind the scenes, and as the internet grows more intertwined and treacherous, the risk for catastrophe increases.

    Judging from the results of our second annual SRE survey, striking this critical balance between supporting development velocity while maintaining site reliability is an onerous and stressful task. Here’s a look at some of the key findings, and takeaways for organizations increasingly reliant on this emerging role.

    The SRE Role Is Relatively New

    Even though Google coined the term in 2003, 64% of respondents noted their SRE disciplines have only been in existence for three years or less. This means many SREs and SRE teams—those professionals dually knowledgeable in software development and adapting IT systems to meet the needs of particular software—are still adjusting to their roles and responsibility. Many SRE teams are also small relative to the size and scope of the infrastructure to be managed, and they remain a scarce resource, with many organizations highlighting skills shortages in this area.

    IT Incidents Are the “New Normal”

    Almost half (49%) of survey respondents reported they had worked on a service incident over the course of the past week. In the month of June alone, Google—which is known for having a very mature SRE practice—had two significant outages: One that hit YouTube, G Suite, and several popular third-party apps relying on Google Cloud for their back-ends (including Discord and Snapchat), and the Google Calendar outage just a few weeks later.

    Catchpoint has detected a significant uptick in outages in recent months, likely the result of growing internet complexity which naturally increases the potential for problems impacting digital service reliability. This is a challenge for all companies and their SRE teams, including the biggest and the strongest—the last few weeks have shown us no one is immune. Organizations can help their SREs maintain a healthy perspective by bearing this in mind.

    Many SREs Don’t Have Clearly Defined Service Level Objectives (SLOs)

    This is problematic, because without SLOs, it is nearly impossible to identify what is an incident in the first place. Twenty-seven percent of SREs reported they don’t have any SLOs, and when flags are raised on everything, this leads to more alerts, a greater number of false positives, and naturally, greater SRE fatigue and stress. Our own conversations with SREs have revealed that even among those with SLOs in place, these are often unrealistic or not correlated to end-user satisfaction and happiness—for example, targeted at 100% availability (impossible perfection) when 98% availability may suit end users just fine. If you’re striving for perfection, every little thing that goes wrong constitutes an emergency, even if customers don’t notice. Setting unrealistic targets and not letting customer satisfaction define SLAs is a recipe for SRE burnout.

    Many SREs Feel Burnt Out and Stressed

    According to our survey, 21% of respondents indicated they never experience post-incident stress. However, it was interesting to note the answers to the following question, where we asked what types of changes SREs notice after an incident—in concentration, ability to sleep, mood and more. One would suspect if an SRE never experienced post-incident stress, he/she would select “none” for the second question—but that wasn’t the case. Rather, one third of SREs said they have noticed such symptoms. Sixty-seven percent of SREs who reported feeling stress after each incident, indicated they don’t believe their company cares about their well-being.

    We are aware of other surveys showing SREs are quite happy, particularly given their impressive compensation. While we don’t believe being an SRE automatically makes someone stressed and unhappy, organizations should never assume these professionals know and understand how appreciated they are. There is often a reluctance to discuss topics such as job-related stress, as evidenced by the fact that 50% of the SREs we targeted opted not to complete our survey—perhaps a result of SREs’ predominant hero culture. In addition to compensation, organizations should consider other ways to show SREs—whether they vocalize their stress levels or not—they care about their well-being, such as offering an extra vacation day or other perks after a particularly trying incident.

    SREs Could Benefit from Automation, but Don’t Have Enough

    Another thing we consistently heard in our conversations with SREs is they feel so busy putting out fires today they don’t get a chance to create a better tomorrow—in other words, they lack the opportunity to be proactive and preemptive in their approaches. A key factor in this is the amount of toil SREs face daily—meaning manual, repetitive, automatable, tactical work. Our survey found 59% of SREs believe there is too much of it in their jobs, and too little automation. Nobody strongly agreed with the statement, “We have used automation to reduce toil,” while almost half disagreed or strongly disagreed.

    Considering SRE teams are often small and the talent pool tight, it becomes critical for organizations to automate as much work as possible, including areas such as application performance monitoring. The SRE team at Alaska Airlines recently automated performance monitoring and deep-dive diagnostics, and as a result has been able to reduce their alert noise by 92%. Ultimately, this has freed up the team to focus on real issues versus wasting time investigating false positives. This has helped them bring down the average mean time to detection for real issues from hours to less than 10 minutes.

    Conclusion

    The stage has been set for SREs to experience significant stress, at a time when organizations need their exceedingly rare skillsets the most. As internet complexity increases, it is critical for organizations to continually nurture, encourage and motivate these valuable team members. This means understanding and empathizing with the intense pressures they’re under; having SLOs well-defined, realistic and meaningful; leveraging soft skills to communicate effectively and non-monetary incentives to show appreciation; and providing them with needed automation so they can focus on proactive improvements that advance the business.

    — Mehdi Daoudi

  • Aim to Be a Top 12% Global Testing Team

    Aim to Be a Top 12% Global Testing Team

    We know that you’re thinking, “Really? Another fluff post about the top people in my profession and what I need to do to be just like them?” Listen, we hear you, but this is not some fluff piece with vague ideas of what might (or might not) work.

    In case you missed it, on May 27th, the 2019 State of Automated Visual Testing was released. Based on independent research sourced from over 350 testing teams around the world, we learned 12% of you are getting much better results than the other 88%. We’re talking four times more successful as measured by the things you (and your boss) really care about–test coverage, release velocity, application quality, overall R&D teamwork and cold hard cash. This is not our opinion. It’s not subjective. It’s objective data and information. Data and information that came from you and your peers.

    In other words, we’re not asking you to take our word for it; we’re asking you to take your word for it.

    What Separates the Top 12% from the Other 88%?

    Digital Transformation. Two words that have been baked into our world over the past 20 years. To such an extent it may be fair to call it fluff? Fluff or not, IDC forecasts worldwide spending on technologies and services that enable digital transformation will reach $1.97 trillion in 2022, per the (IDC) Worldwide Semiannual Digital Transformation Spending Guide.

    That’s a lot of fluff! When your bosses’ boss is spending that kind of cash, it’s always worth paying attention. It could be good for your career. As it turns out, 12% of the world’s testing teams did pay attention, and it’s their approach to managing the challenges of digital transformation that have set them apart.

    The Testing World’s Digital Divide – Digital Transformation Quantified.

    You can quantify it for yourself with some simple math and see how you compare to other R&D and testing teams around the world. Got that calculator ready? Here we go…

    How many applications do you have in production today? (Don’t forget those native mobile apps, they really add up).

    How many pages or screens do you have in production on average for each of these applications? (Single page applications can be tricky but give it your best guess).

    How many viewport breaks do you support? (The market average is six if you are not sure).

    How many human languages do you support? (We’re talking about localization here–English, German, Spanish, Chinese, Japanese–not coding languages in case you’re wondering).

    Now, multiply those four numbers together. Congrats! You have just quantified the digital footprint of your business. People can write about digital transformation all they want, but you’ve just transformed all that fluff into something quite real. It’s probably a big number. Over 90,000 for a typical company and over 624,000 for the largest 30% of companies in the world. Here’s the kicker. You and your R&D team are responsible for managing the visual and functional quality of every single one of those pages and screens.

    When functional test automation first emerged way back in 1989 with the launch of Mercury Interactive XRunner, it was a much different time. Browsers didn’t even exist. Since then, the browser wars have come and gone, and standards are now in place. Applications have grown far more complex with native mobile, dynamic content, single page applications (SPA) and responsive design now an everyday reality. Digital transformation for any size company is officially past tense. We’re not transforming, we’re transformed. And now you have to deal with it, but how?

    What Defines a Top 12% Global Testing Team?

    Top 12% teams have overcome the massive challenge posed by digital transformation. Like any technical challenge we have ever faced, it started with someone on the team who felt the pain and set out to solve for it. And when they did, good things happened:

    • Test coverage increased by 60%
    • Release velocity became 2.8x faster (even though coverage increased 60%)
    • Visual and functional quality improved 3x with far fewer escape bugs (even though they release 2.8x times faster)
    • R&D teams are 4x more satisfied with their visual and functional quality outcome

    All of this despite the 12% of testing teams were managing applications 2.2x larger than the other 88%. In all likelihood, they felt the pain before most of us, and have now led the way for the rest of us. We just need to follow.

    Today, successful continuous management of application visual quality creates competitive advantage. Business leaders know this and are paying attention. As a result, testers are in a better position than ever to be heroes respected by their R&D teams for driving huge value for the companies they work for.

    — James Lamberti

  • DOES 2019: Understanding the Effects of Burnout

    DOES 2019: Understanding the Effects of Burnout

    If you work in the IT field, cybersecurity, the startup world or any other high-pressure job, you or someone you know has probably suffered from burnout in one form or another. If so, you already know that burnout is a real condition with significant consequences. In fact, the World Health Organization (WHO) recently recognized burnout as an occupational phenomenon.

    The WHO describes burnout as follows:

    Burn-out (sic) is a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed. It is characterized by three dimensions:

      • feelings of energy depletion or exhaustion;
      • increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job; and
      • reduced professional efficacy.

    I have been on the road pretty much constantly for the last three or four months (no, I am not trying to say I suffer from burnout). We have covered lots of great conferences. One of the best, as usual, was Gene Kim’s DevOps Enterprise Summit in London. We have about 30 videos from the conference up on the Digital Anarchist site. Of those interviews, my favorite is the one in which I had a chance to sit down with three PhDs to discuss the issue of burnout. I say three PhDs not just to throw around titles—these are three recognized experts in their field.

    The trio of panelists are:

    Dr. Christina Maslach — Probably the foremost authority in the world on burnout.

    Dr. Steven Spear — Senior Lecturer at MIT Sloan School and the Engineering Systems Division at MIT.

    Dr. Nicole Forsgren — Founder of DevOps Research and Assessment, now part of Google.

    This interview is a little bit longer than most, slightly more than 30 minutes. But I think it is well worth your time to hear what these three experts have to say on the issue of burnout and workplace fatigue.

    In addition to our interview on the Digital Anarchist set, I am also happy to include the panel discussion these three folks had on the main stage of DOES London with Gene Kim.

    More importantly, if you or someone you know is suffering from burnout symptoms, please reach out for help and do something about it. You are not alone.

    Don’t forget! DevOps Enterprise Summit Las Vegas 2019 is happening Oct. 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already and join us for the premier event for technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

    — Alan Shimel

  • DevOps India Summit 2019 (DOIS19)

    DevOps India Summit 2019 (DOIS19)

    DevOps India Summit 2019 (DOIS19) is a platform provided by Xellentro in India to meet and learn from the top technology and business leaders from across the globe for two days of immersive learning.

    Experience the DevOps journey from these leaders who are helping to drive this transformation in organizations of various sizes at various geography.

    Share your own experience, insights, challenges and how you have overcome these as practitioners and SMEs in DevOps, and get to discuss and get tips from the leaders of DevOps from various parts of the world.

    DOIS19 is a place to meet up with the top leaders and practitioners, authors and founders of DevOps and hear about their transformation.

    Day One

    On the first day, Aug. 31, there will be various workshops on the following:

    • Full-day workshop on DevOps by Rosalind Radcliffe.
    • Full-day workshop on Microsoft Azure by Microsoft.
    • Half-day workshop on Value Stream Management by Phil Hombledal of Collabnet.
    • Half-day workshop on Microservices on Cloud by Shaun Norris and Ananda Bose of pivotal.io.
    • Half-day workshop on Cloud Native by Aymen El Amri.
    • Half-day workshop on CI/CD on Cloud by Marc Hornbeek.

    Day Two

    On day two of DOIS19, Sept. 1, speakers will have presentations all day. During the breaks you will be able to have interesting discussions while having your coffee or lunch at the Lightning Talk booths. There will also be a one-hour panel discussion with some of the eminent speakers you will be hearing throughout the day.

    Sponsors

    • Title Sponsor – Microsoft Azure
    • Platinum Sponsor – IBM
    • Gold Sponsor – Collabnet VersionOne
    • Gold Sponsor – Publicis Sapient
    • Gold Sponsor – Infosys
    • Gold Sponsor – Axelos

     Partners

    DOIS19 Speakers

    This year we have four keynotes from some of the most famous DevOps leaders and practitioners. You will be able to learn from DevOps experts, including:

    • Tapabrata Pal, senior director and senior engineering fellow at Capital One. His topic is “Cloud, Culture and Continuous Everything–Build your own DevOps.” Pal will share some of his key learnings along the journey. He will describe how cloud technologies and DevOps culture have played the most critical roles in the transformation. He will also make a case as to why he believes there is no prescribed way of doing DevOps and how one should think about Building Your Own DevOps (BYOD) focusing on continuous everything.
    • Sanjeev Sharma, vice president global practice director, data modernization at Delphix. His session, “Is Data Friction Putting a Crimp in Your CI/CD Flow?” will go into client-tested and proven methods and practices to address data friction in the CI/CD pipeline, and show how to bring secure, compliant data on demand to practitioners and achieve CI/CD flow.
    • Rosalind Radcliffe, chief architect for DevOps for enterprise systems at IBM. Her topic is “DevOps Best Practices for Enterprises.” Radcliffe will discuss best practices and the transition to a DevOps mindset, focused on reducing waste and delivering value.
    • Gary Gruver, president at Gruver Consulting LLC. His topic is “Engineering the Digital Transformation.” Businesses implement the latest Agile and DevOps practices from the software industry, hoping that simply doing so will provide the required improvements. Gary talks about his new book. This book focuses on high-level principles for engineering improvements, leveraging as much as possible from manufacturing, and modifies them to address the unique characteristics and capabilities of software.
    • Shaun Norris, field CIO, APJ, Pivotal.io. Will be talking about how a PaaS platform can remove a number of ops pain points.
    • Marc Hornbeek, principal consultant DevOps at Trace3 and DevOps Author. “DevOps in the Cloud from Chaos to Continuous Improvement…and Beyond.”
    • Matt Hogstrom, chief architect of IBM Z Systems Management. His session is “Service Management and DevOps in Cloud Environment.”
    • Daniel Oh, principal technical product marketing manager at Red Hat, South Korea. He will talk on “Quarkus brings Serverless to Java Developers.”
    • Aymen El Amri, founder of Eralabs and DevOpsLinks, tech author, Entrepreneur. His session will be “Designing Cloud Native Applications: The Best Practices.” Moving to the cloud without being cloud native is a waste of time and resources. In this talk we will discover the cloud native approach and the best practices to implement it.
    • Naresh Choudhary, vice president, Infosys. His session is “Platform Approach to DevSecOps.”
    • Dheeraj Nayal, ambassador, DevOps Institute. His session will be “Multi-Dimensional Professionals Powering Cloud and DevOps Adoption.”
    • Mohammad Wasim, Publicis Sapient. His session is “Headwind or Tailwind.”

    There are many other speakers from Paper Submissions:

    • Divya Vaishnavi, Microsoft – “Seven Habits of Effective DevOps.”
    • BMK Lakshminarayanan, Bank of New Zealand – “Cloud Confusion, DevOps Dilemma, Microservice Madness.”
    • Archana Joshi, L&T Infotech – “Harness the Power of 3 DevOps, Cloud and AI.”
    • Prabhakaran Sivaguru, Netfoundry – “Universal Service Fabrics Will Unleash Developer Innovation While Being Secure-by-Design.”
    • Sakina Shaikh, Digite – “Our Journey of Implementing DataOps Pipeline Using Apache Nifi, Kafka, Spark and ELK for Monitoring.”
    • Saurabh Gupta, DigitalOcean – The session will cover the best security practices to be followed while designing and implementing Kubernetes within an organization.
    • Mohammed Wasim Shahpuri, Infosys – “Implementing Collaborative Security Model Using DevSecOps.”
    • Ashwini Lakshmikantha, Oracle – “Culture of the Enterprise-Optimize your DevOps with AI and ML.”
    • Sarat Dara, Intellect Design – “Intellect Design on Cloud Native Application Development.”

    Finally, I will also have a session on “Service Management and DevOps in Cloud Environment.”

    We hope to see all the practitioners from India present both days for DOIS19 and immerse themselves in the knowledge and experience, sharing with speakers and participants from all over the world.

    — Niladri Choudhuri

  • DORA Again Adds to ‘State of DevOps Report’ Slate

    DORA Again Adds to ‘State of DevOps Report’ Slate

    I’m thrilled to announce that Dustin Smith has joined DORA as an author on this year’s “Accelerate State of DevOps Report.” I met Dustin last year, when he joined me in a brainstorming session to discuss research ideas and design considerations. (If you peek back at the 2018 report, you’ll see him in the acknowledgments!) This year, his research and statistics background made a huge impact to the rigor of the report, in addition to his insights as a top-notch researcher. I can’t wait for you to see it. Stay tuned—the report comes out late August! ~Nicole

    It’s a pleasure to introduce myself to the community! After contributing to the research design of last year’s report as a subject matter expert, it’s exciting to join forces with the DORA team and be a co-author of this year’s “Accelerate State of DevOps Report”! I’m a huge supporter of DORA’s data-driven approach and focus on factors such as culture, organizational policy and well-being, as opposed to metrics such as number of PRs and lines of code changed, which easily can be misunderstood or taken out of context.

    During my tenure at Google I’ve studied developer workflows and experiences to help inform product and design teams. My background is in psychology with an emphasis on considering the systematic factors that influence an individual’s or team’s judgment and decision-making. I believe that people are influenced by their environmental constraints, and to help them be most effective, we need to understand those constraints.

    This year’s report is packed with trends and new exciting findings. Be sure to check out the section on “What Really Works in Scaling Transformations” — it’s one of my favorites this year, and I led that analysis. It presents patterns we see among the highest performers, allowing teams and organizations to take an evidence-based approach to building and scaling their own DevOps transformation.

    I look forward to sharing the results with you all soon!

    — Dr. Dustin Smith