DevOps is a great way for many organizations to optimize software design and delivery. Yet, like every other technological innovation in history, DevOps is not perfect. Here are some examples of drawbacks associated with DevOps.
By no means do I think DevOps is a bad idea in general. I want to be very clear about that.
However, organizations considering making the move to DevOps—and those that are already doin’ DevOps, as we say here on devopsy.kinsta.cloud—can gain useful perspective by recognizing the difficulties that DevOps can present. Those include …
Narrower Team Member Roles
Traditionally, software engineers were expected to bring “full-stack” skills to the table. That meant they should understand the ins and outs of all layers of an application stack.
Under the DevOps model, each member of the software delivery team has a more rigidly defined role. Coders code, QA engineers test, IT Ops admins administer and so on. These people all talk to each other, but they do not share in the same tasks.
In many cases, this approach is better because it allows each professional to focus on what he or she does best. But this can be a drawback for full-stack developers. Their broad skill sets are no longer valuable. This is why people such as Jeff Knupp complain that DevOps is “killing” developers.
There’s a potential downside here for organizations, too. Under DevOps, they have to hire and manage more personnel to make sure there is a specialist who can cover each stage of the software delivery pipeline, rather than investing in a smaller number of full-stack developers.
Software Feature Bloat
One of the key advantages of DevOps is that it promotes continuous software delivery. That means new features can be rolled out faster.
But the ability to add features more easily also raises the risk that software delivery teams will add functionality to software just because they can, not because it’s needed. More features are not always better, even if they can be implemented efficiently.
Infrastructure Changes
To make the most of DevOps, most organizations will have to upgrade at least part of their infrastructure to optimize software delivery. Many will need to migrate apps running on virtual servers to containers, for example.
There is nothing inherently wrong with such infrastructure upgrades. But they are potentially expensive and complicated endeavors, and if you don’t complete them properly, you might not actually get very much out of the other DevOps processes that you implement. Organizations considering DevOps should keep this in mind.
Half-Baked DevOps
The final major risk of a DevOps migration is not actually a downside of DevOps, per se. It’s a risk that results from the chance that organizations will implement DevOps imperfectly.
This can be easy to do, because organizations can mistakenly believe that doing DevOps means simply running a continuous integration (CI) server or changing job titles. In practice, DevOps also requires significant cultural changes and new methods of communication. If you implement a half-baked DevOps environment that includes the tools but not the culture, you’ll likely be worse off than you would without having attempted DevOps at all.
Conclusion
Again, I want to be clear that there are lots of good reasons to do DevOps. I’m not trying to go on record as the guy who hates DevOps, because I absolutely don’t. Almost all organizations have much more to gain than to lose by adopting DevOps, if they have not already.
Still, being aware of the imperfections and risks associated with DevOps is important. DevOps is not a magic pill that will solve all of your software delivery problems with no side effects. If you want to avoid mistakes or unrealistic expectations when doing DevOps, you need to appreciate the drawbacks you may face.
Without good design practices, a DevOps implementation has no hope of delivering on its promise of accelerating innovation with high quality and scale.
Anyone who has been a designer knows that good design for DevOps is easier said than done. My blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps. One of the seven pillars is Design for DevOps. The blog explains that the pillars are not silos, but rather foundations that need to be kept in balance. It also can be said that a good design goes a long way to make up for shortcomings in the other pillars.
This is true for any number of designs, including designs for legacy, greenfield or brownfield products. It is true for platform projects, feature enhancements or repairs. It is true for enterprise three-tier applications or multilayer products. And it is true whether the developers are using Agile, Waterfall or ITIL processes.
In every case, a designer faces tough challenges and is expected to balance conflicting goals. Designers are expected to rapidly drive down the work backlog, yet produce quality products that avoid costly rejections and rollbacks. In addition, there is pressure to increase the percentage of effort spent on creative content over corrective content and do so with limited time and resources. These conflicting goals constitute tall responsibilities. If not supported with best practices, the overall design experience is a cauldron of stress and fast route to burnout.
The following best practices improve the design experience and products of design in a way that is streamlined for the DevOps pipeline:
Designers must thoroughly understand customer use cases
Usability, reliability, scaling, availability, testability and supportability are more important than individual features! Quality over quantity is recommended. Designs that anticipate actual customer usage are the most successful.
The culture needs to support designers
Leaders must support the designers with motivation, mentoring and training. No designer can be expected to know everything. It’s OK for designers to make some mistakes if lessons are learned and improvement quickly follows. Good DevOps practices including continuous monitoring and quick remediation are examples of practices which help minimize the impact of any mistakes.
Design coding practices are critical:
Products are architected to support modular independent packaging, testing and releases. In other words, the product itself is partitioned into modules with minimal dependencies between modules. In this way the modules can be built, tested and released without requiring the entire product to be built, tested and released all at once.
Where possible, applications are architected as modular, immutable microservices ready for deployment in cloud infrastructures, in accordance with the tenets of 12-factor immutable non-monolithic apps, rather than monolithic mutable architectures.
Software code changes are pre-checked using peer code reviews prior to commit to the integration/trunk branch.
Software changes are integrated in a private environment together with the most recent integration branch version and tested using functional testing prior to committing the software changes to the integration/trunk branch.
Developers commit their code changes regularly, at least once per day.
Good DevOps design practices support QA:
Understand the QA process.
Software code changes are pre-checked with unit tests prior to commit to the integration/trunk branch.
Software source code changes are pre-checked with Static Analysis tools prior to commit to the integration branch. Static analysis tools are used to ensure the modified source code does not introduce critical software faults such as memory leaks, uninitialized variables, and array-boundary problems.
Software code changes are pre-checked with dynamic analysis and regression tests prior to commit to the integration/trunk branch to ensure the software performance has not degraded.
Good DevOps design practices support Ops:
Understand delivery and deployment pipeline processes.
Software features are tagged with software switches (i.e. feature tags or toggles) during check-in to enable selective feature level testing, promotion and reverts.
Automated test cases are checked-in to the integration branch at the same time code changes are checked-in. Evidence that the tests passed are included with the check-in.
Tests are conducted in a pre-flight test environment that is a close facsimile of the production environment.
Supporting tools are needed to realize Design for DevOps practices:
Elastic infrastructures that can be easily orchestrated, created and released as needed to support designers tasks on-demand with minimal delay.
Design, code management, monitoring and test tools readily available and scalable with minimal delay.
Monitoring tools that track application process performance and report the results to designers in easily consumable formats without delay.
Design for DevOps Summary
What do you think? Do you agree the above are important best practices for DevOps design? Are there others you recommend?
While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to choose tool-agnostic IT partners that can provide solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all of their IT systems.
Regardless of whether an organization subscribes to a bimodal IT approach, one thing is clear: It’s more important, and more difficult, than ever to fight the agility-stability paradox. Today’s businesses must build on a delicate balance of being compliant, plan-driven and keeping the lights on while also seeking ways to become more fluid and agile with high customer touch. The barriers standing between these two key initiatives are numerous and complex; whether it’s mismatched technology or a lack of mutual understanding, the agility-stability paradox remains.
In a lot of ways, this paradox comes down to a difference between traditional and new forms of IT. Traditional IT can be described as predictable–it’s compliant and plan-driven, with conventional processes and long-term cycles. But as the next generation of IT starts to take hold, today’s businesses must find ways to also fold in a new IT that’s dynamic, fluid, agile and continuous, with short cycles and high customer touchpoints. In this way, traditional IT and new IT are polar opposites, and many companies struggle to find a balance between the two. Competing attitudes, too much change at once and tooling challenges all stand in the way of harmony between the reliability of the traditional approach and the need for agility in the new way of doing things.
Balance is Possible
While there is no magic tool or wand that can solve for the incongruities so many organizations face, balance is possible. Enterprises don’t have to choose reliability, customer experience, uptime and performance over agility, release velocity, new markets and competitive response. The real secret to overcoming the agility/stability paradox lies in establishing who, what and how. What this means is that with the right people, processes and tools in place, any company can achieve the balance between agility and stability needed for success.
Who? People
People serve as the “who” of finding balance between reliability and agility. This is the chance to integrate your culture into solving the agility/stability paradox. Start by identifying how each member of the team needs to adapt and shift to accommodate changes. The real trick to getting the people aspect of things right is communication. Define a communication path and be really clear about why your organization needs to transform, how it will be transformed and when everyone can start expecting to see some real adjustments take shape. Orchestrate a response mechanism across your teams and enable social operations collaboration to facilitate execution. Be sure to provide ongoing updates and encourage feedback.
What? Process
Now that you’ve established who needs to play a role in overcoming the agility/stability paradox, it’s time to talk about what exactly needs to change. Process is absolutely crucial here. There are a few keys to establishing the right process for balancing traditional and new IT models. The first is to identify, and not dictate. Dictating change from the top down is never going to be effective. Instead, work together to determine areas of weakness and highlight them. Use your observations as a guide, not a mandate.
From a more tactical perspective, be sure to streamline workflows wherever you can. Define instead of inheriting urgencies and alerts. Don’t be afraid to rely on automation wherever possible, either. By automating processes that help out on the people side of things, you can free up your team to spend less time on tedious, manual tasks and focus more on innovation.
How? Tools
Tools are your best friend when it comes down to actually making all this change happen. Considering the vast number of tools in the market, choosing a toolset may appear daunting at first. But if you start with strong integration across the operational modes already in place, then you’re already in good shape. In particular, to bring new, agile IT into the fold, you’ll want to incorporate IT service management (ITSM) solutions and establish a DevOps tool chain.
Don’t Boil the Ocean
The most important thing to remember is to start small—you don’t have to boil the ocean. Build a culture where traditional and new IT environments are encouraged to work closely together, where you can build and run software that addresses both agility and reliability to respond to the pressures on the business. Start by defining what is is right for your team and organization and acknowledge the existing culture and people. Don’t be afraid to experiment and create isolated learning environments, either. Just make sure to maintain a clear connection to customer value and use this as your North Star. Finally, don’t forget to celebrate. Celebrate your failures and learn quickly from them.
About the Author / Manish Kalra
Manish Kalra is director of Product Marketing at PagerDuty. He is responsible for driving product marketing strategy, product positioning, launches and collateral development for the PagerDuty incident management platform. Prior to PagerDuty, he served as Director of Product Marketing at companies like Sumo Logic and Splunk.
When building DevOps or continuous delivery (CD) practices relying on Docker, you can learn a great deal from others. Reference architectures reveal what choices people made, what practices they put in place and how they connected the dots.
We at Sonatype pulled together a set of 21 reference architectures for folks building CD and DevOps practices using Docker. Why? DevOps professionals numbering 3,500 recently attended our webinar on, “Continuous Integration using Docker,” discussing just one reference architecture example. We recognized then there was a strong interest in the community to learn more. That’s why we assembled 20 more reference architectures into this collection.
A picture speaks a thousand words. Beyond the images, we also share the details of each DevOps/CD Docker reference architecture. In the bottom right corner of each slide, we share the original blog or presentation source for the image. When one of the images piques your interest, you can then dive deep into the source. Cool, huh?
Think of this set of reference architectures as open source. The slides are free to view, download and distribute. Share with others if you find them helpful.
Help Others
Oh, and if you have a Docker reference architecture we should add to the deck, please let us know. We would love to add it to our deck for others to learn from. Just like the others we included, you will be sure to get full attribution for your work.
For those of you not using Docker, we did publish a set of DevOps and continuous delivery reference architectures last year on devopsy.kinsta.cloud. With more than 86,000 views and 3,300 downloads, many people in the community have found it helpful.
Under pressure to innovate and deliver rapid updates to their applications, developers often place monitoring as an after-thought. In today’s world, where a slowdown can translate to customer attrition and an outage can lead to millions of dollars in losses and negative press, ensuring satisfactory response time has evolved to be one of the most critical needs in the early stages of development and is a common goal to ensure DevOps success.
The Shift-Left of Monitoring: To study emerging patterns of how and when DevOps teams start monitoring, we interviewed several DevOps squads. Almost unanimously the responses were:
They care most about knowing, Is the application up and loading quickly? Are all critical user interactions with the application responding within acceptable standards?
They would like to get this information proactively throughout the development life cycle so they can determine if any code check-in impacted the performance/
They would like to monitor with minimum setup and configuration and don’t have the time to learn complex tools/
To satisfy these needs, synthetic monitoring becomes the starting point for monitoring.
With synthetic monitoring, DevOps teams can simulate user behavior and proactively detect performance problems from around the world and around the clock, before they impact their users. They can maximize uptime and ensure good response by pinging the application URLs and APIs and running simulations to check if the most common paths traversed by users are responding fine.
Some of the key capabilities of synthetic monitoring that are important to DevOps squads:
Reports availability, response time and user satisfaction score (such as Apdex) for all web pages, URLs and critical user interactions from around the world, 24X7
Runs synthetic tests as often as once per minute or even less than that, to test:
Webpage loads
REST API calls
Runs simulated user interactions through scripts once every few minutes
Requires minimum setup and maintenance with preferably a SaaS solution with globally hosted probes. Private probes are required for monitoring internal applications.
Incorporated into the DevOps life cycle as part of the delivery pipeline such that synthetic tests can be run in dev/test, staging and then in production.
Provides granular controls on what tests to run, how often, from where and what to validate in the HTTP response code.
Easy-to-use scripting tools that do not have a learning curve and preferably open-source. Often, automated regression test scripts used in development can be reused to run synthetic simulations in production.
Alerts users of issues through not only their preferred channel of notification, such as email or SMS but also through their primary collaboration channel.
Provides relevant alerts and avoids alert noise by appropriate alert filtering and retries on failure.
Identifies whether an issue was caused by an application deployment or change by presenting an auto-correlated view of alerts, metrics and deployment activities.
Isolate quickly whether the problem is in the application code or one of its dependencies such as a network latency issue or a third-party service slow down.
Diagnoses the exact step of failure by providing waterfall analysis of all page assets, pinpointing slow requests, broken links, large images, slow external API calls and more.
Accelerates diagnosis with an automated browser screenshot of the failure.
Compares two versions of applications to enable A/B testing.
Provides daily, weekly and monthly scores and reports to ensure that target SLAs for uptime and user satisfaction are being met.
Stay tuned for the next blog on DevOps and log analytics in this five-part blog series and don’t forget to register for an upcoming interactive webcast, “Learn Why We Must Shift APM Left in the DevOps Lifecycle.”
About the Author / Payal Chakravarty
Payal Chakravarty is offering leader for the Application Performance Management portfolio at IBM. She has nine years of experience in enterprise technology in various roles including product management, strategy, DevOps and engineering management and software development. She defined and delivered software as a service (SaaS) and on-premises software for Application Performance Management, Hybrid Cloud Monitoring, Data Center Management, and Operational Analytics. Payal has an MBA from Duke University and a MS in Computer Science from North Carolina State University. You can find her on Twitter, where she tweets about all things DevOps and cloud. Connect with Payal on LinkedIn / Twitter
Recently, Tasktop surveyed 120 global IT professionals on their software delivery processes. The results were based on analysis obtained from its licensed Forrester Modern Application Assessment Tool, which helps organizations evaluate where they fall on the spectrum of modern software delivery and offers insight into what needs to happen next.
The survey covered topics such as customer needs, application development and delivery objectives and strategies, business value, metrics, tools and more.
Key Findings
In spite of the increasing adoption of agile and DevOps initiatives, the survey identified the need for stronger alignment with customer and business needs and tools that increase coordination in the software delivery process.
Developers, tech leads, project managers, chief technology officers and other IT titles surveyed reported the following:
Only 6 percent strongly agreed they could trace the contents of a software release back to business needs or customer satisfaction.
Just 9 percent strongly agreed their application development and delivery strategies were aligned with business strategies.
And, strikingly, a scant 15 percent strongly agreed their work management tools assist in coordinating the work of the software delivery team satisfaction.
It seems that in spite of a strong industry drive toward being more responsive to the the needs of the business, there remain large gaps in how organizations realize the benefits of the tools they use to support these initiatives.
Any parties interested in taking the survey and receiving an assessment can do so here.
About the Author / Betty Zakheim
Betty Zakheim is vice president of Industry Strategy at Tasktop and is the vertex between Tasktop’s customers, the company’s product team and marketing team. She has an extensive background in software development, software integration technologies and software development tools. As a software development manager, she was an early adaptor of “iterative development,” the precursor to Agile. As the VP of product management and marketing at InConcert (acquired by TIBCO), she pioneered the use of Business Process Management (then called “workflow) as the semantic framework for enterprise application integration. Connect with her on LinkedIn and Twitter.
The global audience for DevOps is expanding faster than any one person or company can keep up with. While DevOps Days and other regional events provide invaluable support to their local communities, we wanted to create a global event, offering the very best lineup of speakers across North America, Europe and Asia.
We also wanted to make sure that anyone, anywhere can attend. So, we set a high bar for our organizing team, and they delivered: $0 registration.
By creating All Day DevOps as an online event, we are able to get many people to attend and present—many of whom ordinarily would not be available because of time or travel restrictions. We expect well over 1,000 people to attend throughout the day.
15 Time Zones, 15 Hours, 3 Keynotes, 54 Sessions
Nov. 15 will see the first truly global, online DevOps Conference: All Day DevOps. Starting at 9 a.m. Greenwich Mean Time/5 a.m. Eastern Standard Time and continuing through midnight GMT/8 p.m. EST, there will be three simultaneous tracks, each track containing 18, 30-minute presentations, for a total of 27 hours of presentations.
Call for Papers
We are inviting speakers from around the world to participate in this first-of-its-kind event covering 15 time zones. Timing for the conference is set for the EMEA sessions to begin at 9 a.m. GMT, then, at 9:30 a.m. EST, move the concentration of presentations to the east coast of the United States and ending with presentations on the west coast of the United States starting at 11 a.m. PST. All sessions will be recorded, but you will need to register for the event to have access to the recordings.
The Call for Papers is now live. Please submit your paper soon. The deadline for submissions is Sept. 21.
Conference Tracks
The conference will host three tracks: Modern Infrastructure, Automated Security and CI/CD. We’ll have 54 sessions plus three keynotes on three tracks, running continuously for 15 hours.
Track One: Modern Infrastructure
Modern Infrastructure Track Hosts and Moderators: James Wickett, Signal Sciences, joined by Ernest Mueller, AlienVault and Karthik Gaekwad, Oracle
In this track, we will be discussing novel architectures, approaches and tools for building out software and services. We are not looking for the standard approaches, but the way Infrastructure will be in the next three to five years.
Track Two: DevSecOps & Automated Security — Living the Dream
Automated Security Track Hosts and Moderators: Milton Smith, Oracle, and Shannon Lietz, Intuit
You have a well-tuned development and delivery environment or you’re in the process of building one. AppSec is a top business concern. You moved DevSecOps from Big Foot and UFOs to reality, you sold the dream to staff, and now it’s beginning to pay off. This track explores DevSecOps tools and techniques to build a successful automated security program.
Track Three: CI/CD — Continuous Everything
CI/CD Track Hosts and Moderators: Derek Weeks, Sonatype, and Andi Mann, Splunk
Continuous delivery is not magic, but it does take the right effort. The most successful practitioners have taken pragmatic steps to reduce cycle times, improve collaboration and build quality in without burning people out. This track asks you to share your frontline experiences of building CI/CD pipelines, aligning key stakeholders and measuring the results. Remember, what’s now an everyday experience for you is awesome to another pursuing that path.
Conference FAQs
How to I register to attend?
Registration is open now at AllDaydevopsy.kinsta.cloud. The site will be constantly updated, sometimes multiple times per day, with the latest information. You can also follow us on Twitter under the handle @AllDayDevOps and using #AllDayDevOps.
How will the sessions be delivered?
The sessions are delivered over Google Hangouts, allowing us to have an unlimited number of attendees on each of the three channels. All you need to deliver a presentation is a reliable internet connection.
We are also arranging Slack channels for all sessions to host interactive Q&A sessions for everyone.
If my talk is selected, can I post a notice or an article about the conference on my site?
Not only is it OK, we would thank you profusely if you did. You’re welcome to use the banner and the conference icon if you need graphics for the article. Let us know when it goes up and we’ll give you a shout-out.
Who is organizing All Day DevOps?
The All Day DevOps Conference is organized by advocates in the DevOps community. We are working together to deliver a diversity of vendor-neutral sessions and speakers from around the globe to show practical usage and technical solutions of DevOps in small and large enterprises.
I went seeking honesty at a DevOps conference and met Diogenes.
Diogenes of Sinope was a controversial figure in ancient Athens who was known for walking around the famed ancient city—some say in the nude— during daytime with a lamp in his hand. He parried inquisitors who questioned his strange habit of using a lamp by day by insisting that he was looking for an honest man. At the recent DevOpsDays Boston, I actually met Diogenes. True story. See picture below. (Thankfully, he was wearing clothes.) But, as you probably guessed, this was not the man with the lamp, but rather one of the many conference organizers looking to help less-acquainted individuals find their way around the many meetings and speakers that filled the two-day conclave. Indeed, my Diogenes was instrumental in organizing the conversations and lectures that proved both honest and helpful. Rather than a self-congratulatory summit, the two-day meeting was an honest conversation highlighting the advantages as well as many of the stresses befalling organizations that have adopted DevOps.
I found the most honest discussions were a floor up and a bit removed from the topics discussed in the main ballroom. These discussions were given the informal title of “Open Spaces” and were run in a typical un-conference format. These conversations were the real opportunities to learn about the stresses of implementing the modern portmanteau of DevOps.
Tensions Between Dev and Ops: Why Can’t We All Get Along?
One of the most interesting discussions in the Open Spaces looked at the dynamics between Devs and Ops. Like with any two groups that need to work together to accomplish larger organizational goals (think Sales and Marketing or Design and Engineering), there are inherent tensions that need to be overcome. The tensions between Dev and Ops are based on the different mission each pursues. Dev is striving to get software out the door as quickly as possible and push software updates forward. Ops is guided by the need to keep the ship as steady as possible, which often means limiting updates, as every update opens the door to potential bugs and deployment challenges. Starting with this premise of conflicting motivations, issues of trust and respect further complicate the relationship as each sees the other as trying to control the process.
Yet, participants in this Open Spaces discussion were hopeful that tensions could be dissolved if management played an active role in creating cross-functional teams and managing workloads better. It was suggested that by essentially seeding Ops with Devs and vice versa, a greater community of understanding could be created. By promoting this cross-pollination, there would be greater understanding on both sides the implications (from the Dev side) of pushing software over the wall to Ops too quickly. From the Ops side, there would be greater understanding that 100 percent uptime is incompatible with dynamic product cycles that encourage innovation. A common and acceptable level of uptime needs to be agreed upon by both sides.
For example, creating demos and code walk-throughs so both Dev and Ops can comment on potential problems and issues allows both Dev and Ops to see issues at the beginning rather than at the time of deployment.
Blameless Post-Mortems in DevOps: Can They Exist?
Another fascinating discussion in the Open Spaces focused on blameless post-mortems. Postmortems first and foremost suffer from an image problem. I believe it starts with the root word “mort” and it doesn’t get much better. To be clear, there was a lot of back and forth during this Open Space about the difference between a “postmortem” and a “retrospective.” Retrospectives are usually a weekly or bi-weekly event that bring to light the multiple root causes that are leading to defects or causing success through a review of RCA. In typical DevOps, one-week sprints are followed by a retrospective. Usually, the more data you can bring to a retrospective, the better. Post-mortems, on the other hand, result from an incendiary incident that was unexpected and undesired.
Since post-mortems inevitably occur due to human oversight or lack of planning, there is no amount of thinking or planning that can prevent a crisis and thus prevent a post-mortem. As such, effective management will make post-mortems as painless as possible. The goal is to have blameless post-mortems balanced with accountability. According to one participant,
“No one wants central casting to send in a screaming manager in a time of crisis who is only interested in assigning blame. That doesn’t help anything.”
Importantly, you cannot fire yourself out of a post-mortem. Post-mortems are a necessary instrument to get at the root causes of issues. And while several different events can cause one issue, the post-mortem will at least begin to look at the process which caused the chaos. By not making the goal of post-mortems to find a scapegoat, the participants in one of these sessions can actually work on effective problem-solving.
The goal of post-mortems needs to be effective problem-solving with the intent of committing the lessons learned to an actual document. It is not enough to let the lessons learned remain as an informal corpus that lives only in the heads of the engineers involved. Instead, documentation is required and it has to be in accessible place. Furthermore, it needs to be summarized and presented to management in either a lunch-and-learn or seminar so that the lessons learned then become actionable.
Furthermore—and this was perhaps the most interesting part of the discussion on post-mortems—effective post-mortems are about getting Dev and Ops out of silos. There is no automation tool that will make Dev and Ops work together. Dev and Ops cannot just be about finding another automation tool. Instead, management needs to step in to help the process. Management needs to take engineers out of their silos and get them to work together if post-mortems are going to be really effective.
Are You Feeling the Burnout Yet?
After so many hours of interesting discussion in the DevOpsDays Open Spaces, I too was beginning to tire a bit. So perhaps it was well-planned to move on to a discussion on avoiding burnout.
The artifacts of burnout are seen throughout the DevOps world as engineers constantly change jobs. This might be the phenomena of the “shiny orb,” where engineers always feel that there is a better, higher-paying job on the other side of the fence. However, as much as that might be true, it is equally the case that engineers are trying to escape burnout.
According to the kanban methodology, which is woven into DevOps, you only pick up work as you can process it. Yet, DevOps practitioners often pick up work because they want to feel like they are team players or invincible or because they underestimate the work’s demands. They also fear the “imposter syndrome,” whereby colleagues seem less genuine if they don’t accept a piece of work offered to them. Inevitably, because the work is more than the engineer can handle, he or she becomes overwhelmed and is too proud to reach out for help.
In a well-managed workplace, admitting overwork would not be an admission of failure. Instead, there would be a supportive culture to help the engineer or better mentoring on how to get through a challenging issue. “One-on-ones,” where the manager and individual contributor sit down together, would effectively solve the issue.
But given the idiosyncrasies of workplaces, good management is not a given and engineers are often left to find their own coping techniques to help avoid burnout. The participants in this particular Open Space came up with the following gems:
Brain dumping. Empty your brain by putting all the thoughts and tasks that remain on your list and in your brain at the end of the day onto post-it notes. This helps avoid burnout because you are able to clear your brain prior to leaving work.
Create a Slack-based or bullet journal as a way to write yourself notes and create a list of priorities.
Follow the Pomodoro technique. Take a five-minute break every 25 minutes and a 15-minute break every two hours to better monitor how much time you are devoting to an issue and also to ensure you don’t forget to get a bit of movement into your day.
Learn how to say ‘no’ to requests. It’s a very simple word, but uttering ‘no’ once in a while will ensure that you mark boundaries and don’t take on more responsibility than you can handle.
Enlist management to make them aware of time you are spending beyond the normal working day and try to figure out ways to better manage the schedule and avoid burnout.
The participants of this Open Space left with some new techniques to consider in avoiding engineer burnout. Hopefully, they will be implemented to practical advantage.
Conclusion
My first DevOpsDays conference was a true eye-opener. I was lucky to get my education among such thoughtful and well-spoken individuals. I look forward to future opportunities to learn at the foot of Diogenes.
About the Author / Orlee Berlove
Orlee Berlove is the Marketing director at OnPage Corporation located in Waltham, Massachusetts. OnPage is a cloud base incident alert and management system that elevates notifications so they continue to “ALERT-UNTIL-READ” so it’s not confused with email, SMS or phone calls. Incidents can be programmed to arrive to the person On-Call and can be escalated if they are not attended to promptly. Follow OnPage on Twitter and LinkedIn.
To remain competitive in today’s software-driven economy, organizations of all sizes are investing in DevOps to become better at releasing software. Although the ROI is evident in the IT and business performance of organizations that have successfully implemented DevOps practices, the journey still can be challenging.
There are troves of resources available to help companies begin or continuously improve along their DevOps journey. However, oftentimes it’s the practitioners—experts from the community who live and breathe DevOps every single day—who can offer the most insightful tips.
To that end, Electric Cloud hosts a community video podcast series titled, “Continuous Discussions” (#c9d9, for short). Each episode focuses on a different topic and brings together a group of expert panelists to discuss all things DevOps, Agile and continuous delivery (CD).
Why? Because we all understand DevOps is a team sport. It’s all about collaboration: bringing people together and continuously improving through shared learning and experimentation. Community is at the core of any DevOps initiative, and connecting with peers and sharing experiences is the best way to accelerate our mutual success—so we can all get better at delivering software, together.
These casual #c9d9 chats are often funny, entertaining, thought-provoking and—always—educational! These are a great way for the IT community to pinpoint emerging patterns, discuss challenges and highlight tips and best practices for modern software delivery, in topics including continuous improvement (CI), deployment patterns, security, DevOps culture, microservices, containers and more.
Out of the 50 episodes that have aired to date, featuring more than 150 guest speakers, below are 10 of our favorite recent discussions:
“In the microservices world, individual features might end up being their own services that are completely well understood”
– Daniel Rolnick, Yodle
Microservices are all the rage right now, and the industry is still learning, experimenting and developing patterns, for successfully designing, deploying and managing microservices in the real world. Are you considering jumping on the microservices wagon? Learn from experts at Kik, Yodle and Semaphore, as they share their journey and learnings from decomposing their monolithic application into microservices. Featured Panelists:
Daniel Rolnick
Daniel is the CTO of Yodle, a SaaS platform for small businesses, where continuous delivery is a way of life. @YodleTech | www.yodletechblog.com
Darko Fabijan
Darko is co-founder of Semaphore CI, helping teams deliver software faster. He currently is focusing on scaling Semaphore team and architecture. @darkofabijan | semaphoreci.com/blog/
Usman Ismail
Usman is a server and infrastructure engineer, with experience in building large-scale distributed services on top of various cloud platforms. @usman_ismail | techtraits.com
“When you treat configuration like first-class citizens, only then can you have your deployment product succeed because your product depends on the deployment configuration being right.”
– Juni Mukherjee, author of “Continuous Delivery Pipeline – Where Does It Choke?”
To enable fast, reliable releases, deployment automation is a must. This episode discusses the prerequisites and best practices for automating your deployments and ensuring zero downtime and fast mean time to recovery (MTTR) when deploying large-scale mission-critical apps. We also talked about the key differences between the first-generation of deployment automation and deployment automation 2.0, and riffed on what we have to look forward to for the next iteration of deployment automation 3.0.
Robert Firek
Software craftsman at Codurance. Devops engineer. Java programmer. Agile practitioner. He strives to create software according to the rule, “Simplicity is the final achievement.” @robertfirek | codurance.com/blog/author/robert-firek/
Paul Reed
Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec, and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity and human factors. @jpaulreed| jpaulreed.com
Taco Bakker
Taco previously worked as a Team Lead for a large international bank, spending most of his time bridging Dev and Ops. Today he’s a LEAN Six Sigma black belt focusing on CD. @tsbakker65 | www.tsbakker.nl/taco.html
Continuous Discussions (#c9d9) Podcast: Episode 43 – DevOps and CD for Non-Web Applications
“Firmware is updatable and I think the whole notion of being responsive to change is ultimately a very powerful characteristic of firmware and one that ultimately, along with the performance you get from it, is going to be an important part of solutions as we go forward.”
– Stephen Hendrick, ESG
If you think that DevOps is only for web apps, think again! Some of the largest organizations in the world focused on hardware manufacturing, embedded systems and IoT are proving the value of DevOps for the delivery of complex physical products that are integrated with software components. Watch the podcast to explore the differences between continuous delivery for webware and firmware, and listen to panelists discuss the challenges and patterns for successfully implementing DevOps for non-web apps.
Featured Panelists: J. Paul Reed
J. Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec, and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity, and human factors. @jpaulreed | jpaulreed.com
Continuous Discussions (#c9d9): Episodes 29 and 45 – Security & Compliance as Part of Your DevOps Processes
“In order for you to audit and trust the system, you need to make sure the system hasn’t changed over a period of time. Have a test that shows whatever you put in, the results that come out are predictable.”
– James DeLuccia, PwC
Listen to expert panelists explain how to bake-in security and compliance to your DevOps processes. Find out how DevOps and automation can help you pass your next audit. Key focus points include what it takes to get everyone on board with DevOps; how automation equals auditing, with some discussion on industry-specific regulations and compliance requirements; and how to enforce security for the code and for your environments and configuration.
Jonathan McAllister
Jonathan has been creating automation software since he was a child. Professionally he leverages 10+ years of experience in software development, test and delivery practices. He is an author, automator and business consultant. @jmcallister80 | www.masteringjenkins.com/
“The safest environment is the one you don’t let humans muck around in.”
– Martin Cron, WiserCare
Featured Panelists:
Andreas Wittig Cloud Specialist. Author of “Amazon Web Services in Action.” Software engineer, speaker, teacher and consultant. @andreaswittig | cloudonaut.io
Dave Bechberger
Senior architect and developer with a passion for delivering solutions to challenging problems in difficult domains from concept to delivery. @bechbd | experoinc.com/author/dave.bechberger/
J. Paul Reed J. Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity and human factors. @jpaulreed | jpaulreed.com
Sukhbir Dhillon
When Sukhbir isn’t coding, dreaming of automation or being the founder of Addteq, he is at home playing with his 2-year-old daughter. @addteqsukhbir | nebula.addteq.com/blog
Continuous Discussions (#c9d9): Episode 21 – Implementing a DevOps Culture
“One expectation I like to lead the conversation with is, if you are a non-trivial software business, then guess what? You are in competition with every other software business in the world. So, you have two choices: evolve or die.”
– Aaron Lee, Pythian
This podcast offers tips, best practices and real-world examples of how organizations can navigate the cultural shift to Agile, DevOps and continuous delivery—from the leadership’s perspective, as well as at the teams’ level. Hear expert advice on how to facilitate silo-busting and system-level thinking and how to encourage experimentation, support a blameless culture, constantly practice for game day and more.
Featured Panelists:
Aaron Lee
VP of Transformation Services at Pythian. DevOps practitioner committed to creating successful business outcomes for clients. @observator | www.pythian.com/blog
Alon Becker
DevOps architect at AOL. Alon is involved in DevOps transformation at several companies, both startups and enterprises. @alonbecker
Mike Kavis
VP/principaI architect @ CloudTP Analyst at Forbes and The Virtualization Practice. Author of, “Architecting the Cloud.” No hype, just lessons learned. @madgreek65 | www.cloudtp.com/insights
Randy Bias
Randy Bias, VP Technology, EMC former founder of Cloudscaling (acquired by EMC) and director at the OpenStack Foundation. @randybias
Robert Kalweit
Certified ScrumMaster with 7 years’ experience and an Agile mindset that helps to execute tasks efficiently, on time and with personal heartiness. www.kalle-online.net/blog/agile
“While there are multiple approaches for implementing an internal Dev/Test cloud, you need to make sure that you pick a solution that is adaptive.”
– Kelly Looney, Skytap
The need to speed up feedback loops, simplify dev/test processes and collaboration and also save on infrastructure costs has led many organizations to create a private Dev/Test cloud to standardize their processes, tooling and environments across teams. This podcast takes a deeper dive into some of the challenges and prerequisites for enabling a self-service shared platform for the software delivery pipeline across dev and test, and some tips and best practices for getting started.
Phil Dougherty
Phil has over 10 years of experience building the backbone of the internet, from multi-continent private cloud environments to fully automated public cloud infrastructure powering mobile commerce APIs. @phildougherty | blog.containership.io
Continuous Discussions (#c9d9) Podcast: Episode 36 – ITIL and DevOps
“Take a user-centered design approach to everything you do.”
– Jeff Sussna, DevOps writer and speaker
During this discussion, we uncovered the similarities and differences between ITIL and DevOps, and discussed tips for how to align the two methodologies in an organization.
Featured Panelists:
Jan-Joost Bouwman
Jan-Joost works at ING as ITSM process owner, adapting ITIL to an Agile Way of Work. Previously he worked in various roles in systems development. @JanJoostBouwman
Kaimar Karu
Head of ITSM at AXELOS – custodians of ITIL & PRINCE2 / President at #itSMFEstonia / Service Management enthusiast / Beer sommelier / Food writer @kaimarkaru | www.axelos.com/news/blogs/
“The way we build software when it’s always releasable is fundamentally different than when we build to a release. The flexibility and agility comes from building it iteratively—where you’re always able to go in and change it. That, I think, is the main advantage of CI and CD.”
– David Bernstein, To Be Agile
Panelists review some of the metrics that matter for the different stakeholders throughout the software delivery pipeline. Learn best practices for some of the metrics that you should be monitoring to track your DevOps efforts, and—equally important—some of the metrics you should abandon.
David Scott Bernstein
David helps teams adopt practices such as test-first development and refactoring at hundreds of companies around the world. David is also the author of, “Beyond Legacy Code.” @ToBeAgile | tobeagile.com/blog/
Ketil Jensen
Ketil is a passionate learner and practitioner, always looking for better ways to work. Loves to help organizations continually improve. @ketilj | ketiljensen.wordpress.com
Continuous Discussions (#c9d9) Podcast: Episode 32 – Orchestrating Your Testing Suite
“If you can test it underneath the UI, you probably really should be testing it under the UI”
– Chris Kent, BTI360
Get an in-depth review of best practices for orchestrating enterprise software testing. Panelists discuss some of the challenges and proven patterns used to test critical software quickly and efficiently: What does your test matrix look like? How do you define the pathway through your test cycle? How do you use automation and service virtualization? How do you manage test environments and data? And more.
Featured Panelists:
Alex Cowan Alex has been an entrepreneur (5x) and intrapreneur (1x). Currently helping create digital innovators @DardenMBA & advising companies. He talks too much. @cowanSF | alexandercowan.com/blog/
Chris Kent
Chris loves crafting enterprise apps with ATDD, TDD and clean coding. You’ll also find him reading, outdoors or at a local brewery/winery. @thirstydev | www.bti360.com/author/chris-k/
Hugo Hendriks
Hugo is a freelance integration consultant based in the Netherlands with the focus on Oracle Fusion Middleware, Java, open source and Scrum. @R3DR0CK | www.redrock-it.nl
Kate Abrosimova
Director of content at Yalantis and tech journalist, who likes to create things, write about technology with a focus on mobile and collaborate with tech teams. @kateabrosimova | yalantis.com/blog/
“The pipeline is not so much about ushering code out to production, it’s finding ever opportunity to reject a harmful change prior to letting it get into production. So, the pipeline is an essential part of risk management.”
– Michael Nygard
To get to CD, applications and delivery pipelines must be architected in a way that supports the more frequent pace of smaller, incremental releases. On this episode, we discussed some recommendations for constructing a flexible, versionable, reviewable, test-able, revertable and resilient application architecture and CD pipeline.
Featured Panelists:
Aater Suleman CEO of Flux7, helping companies use AWS infrastructure to improve business agility and continuity. Flux7 deploys web apps across various technology stacks. @FutureChips | blog.flux7.com
Graham Smith
Dr. Graham Smith is head of software engineering at the UK Hydrographic Office, championing continuous delivery by day and blogging about it at night. @GrahamDSmith | pleasereleaseme.net
Marcus Rehm
Software engineer and business intelligence developer for Odebrecht Ambiental. Agile and Automation enthusiastic that always is looking for ways to improve products and process. @marcusrehm | marcusrehm.github.io
Melvin Laguren
QA automation lead at Wrap Media. Melvin has worked at various start up and enterprise companies developing automated tests and working on CI/CD pipelines. He spends his “free” time speaking at meetups/conferences, teaching QA workshops and working on a weekly comic strip, www.melvinisms.com. @mlaguren | www.laguren.net
Michael Nygard
Michael works for Cognitect. Has written and co-authored several books, including, “97 Things Every Software Architect Should Know,” and “Release It!” @mtnygard | blog.cognitect.com/
With such great conversations, it’s certainly hard to choose…
Continuous Discussions (#c9d9) airs every other Tuesday at 10 a.m. PST. You can watch all previous episodes of the podcast and also subscribe on iTunes here.
About the Author / Anders Wallgren
Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings more than 25 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.
While there’s no fundamental conflict between IT service management (ITSM) and DevOps, DevOps does bring new and different techniques for getting work done and interacting with the rest of the organization.
ITSM people who are used to frameworks such as ITIL and COBIT tend to regard the IT department as a “service provider” and the rest of the organization as “the customer.” But DevOps has come from web-scale organizations “where IT is the business,” and that means the prevailing view is more like the Toyota Production System mentality, wherein the aim is to move things along a production line with maximum speed and maximum quality, says Matt Hooper, product evangelist at LANDESK.
DevOps thus has already broken down some of the barriers between “IT” and “business”—practitioners realize they have to determine what the business needs, and then provide it. But Agile or Agile-like practices also are part of this approach, so there’s lots of experimentation, learning and redeployment in “lots of tiny little steps,” and, consequently, there’s not much risk of going very far wrong with any of them.
An issue is that this conflicts with ITSM’s view of life cycles, partly because the whole idea is to merge development and operations—for instance, by automatically spinning up software-defined infrastructure as needed.
What’s needed, Hooper suggests, is “service management with a digital mindset” rather than ITIL’s “human mindset.” It’s all about feedback, he says, but for ITSM and DevOps to sit comfortably together there must be a realization that feedback can come from humans or systems.
And even though the command and control mindset tried to avoid failures, systems still failed. So a better approach is to accept that “stuff breaks” and make small changes at a time, respond to issues as they arise and keep learning. In the longer term, this will lead to more durable systems, he says.
It’s a myth that you’ll be able to stop bad things happening, because people and systems aren’t perfect. DevOps, in contrast, accepts that things will go wrong but aims to respond quickly—for example, by keeping developers close to operations so they can see problems occurring, realize what mistakes they made, and put them right.
“That’s challenging to a traditional ITSM person,” Hooper says. It is important to accept that failure is an option, even though massive failure isn’t.
(Before you ask, he accepts that certain systems need to be extremely reliable. But others provide room for a somewhat experimental approach, in which case DevOps helps avoid overengineering.)
While some ITIL practitioners see value in DevOps’ continuous deployment approach, their premise is still that IT is a “service provider” rather than a “partner,” but the business side of the organization wants the latter. You don’t get home from a business trip and tell your spouse you were 99.98 percent faithful while you were away, he observes, and that sort of SLA-based thinking works against becoming a learning organization, achieving good demand management and so on.
ITIL v2 served a good purpose, but ITIL v3 arrived too late, Hooper suggests. The growing influence of the Lean movement means systems are going through rapid change cycles, and too much “process” leads to waste and lower performance. DevOps and software-defined technologies provide ways to better handle rapid change—infrastructure can be spun up and back down in seconds, providing opportunities for self-healing systems with better scalability and reliability.
Where ITIL focuses on meetings and human processes, DevOps prefers to use analytics to determine the right time to release and then whether then release was successful. “The feedback loop is an essential part of DevOps strategy,” just as it is with ITIL, but ITIL has a more human-centric idea of feedback.
“ITSMers tend to hide in the back closet” waiting for the business to tell them what to do, but DevOps takes a more active approach, he suggests.
Manish Kalra is director of Product Marketing at 
Payal Chakravarty is offering leader for the Application Performance Management portfolio at IBM. She has nine years of experience in enterprise technology in various roles including product management, strategy, DevOps and engineering management and software development. She defined and delivered software as a service (SaaS) and on-premises software for Application Performance Management, Hybrid Cloud Monitoring, Data Center Management, and Operational Analytics. Payal has an MBA from Duke University and a MS in Computer Science from North Carolina State University. You can find her on Twitter, where she tweets about all things DevOps and cloud. Connect with Payal on 
Betty Zakheim is vice president of Industry Strategy at Tasktop and is the vertex between Tasktop’s customers, the company’s product team and marketing team. She has an extensive background in software development, software integration technologies and software development tools. As a software development manager, she was an early adaptor of “iterative development,” the precursor to Agile. As the VP of product management and marketing at InConcert (acquired by TIBCO), she pioneered the use of Business Process Management (then called “workflow) as the semantic framework for enterprise application integration. Connect with her on 
I found the most honest discussions were a floor up and a bit removed from the topics discussed in the main ballroom. These discussions were given the informal title of “Open Spaces” and were run in a typical un-conference format. These conversations were the real opportunities to learn about the stresses of implementing the modern portmanteau of DevOps.
Orlee Berlove is the Marketing director at 
Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings more than 25 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.