On November 6th, 2019, the annual All Day DevOps conference (ADDO) was held for the 4th time. Being a fully online event, the aim is to bring the conference to the participants instead of the other way around. This is both very convenient for people working at companies with tight travel budgets and is better for our global environment. The conference ran for 24 hours straight with 150 speakers, 6 keynotes and 5 different tracks. Attendees were spread across an impressive 152 countries and 38 timezones.
At our Devoteam office in Amsterdam, we hosted 1 of the 181+ viewing parties showing 4 of the 5 tracks in separate rooms for about 4 hours, starting at 4 pm.
Throughout the day I watched several talks and keynotes from different tracks. In this article, I would like to share my main takeaways.
Paying attention to Patrick Debois’ keynote
All Day DevOps Takeaways
Applying Site Reliability Engineering (SRE)
With the current focus on SRE, it is understandable that organizations are tempted to apply this practice to every production workload. Everybody wants to be as successful as Google at running systems at scale and in the cloud. However, it is easy to fall into the pitfall of copying what somebody else is doing. The secret of success depends both on methodology and organizational culture. A methodology that has been applied successfully in one organization might not work in another organization, due to differences in culture. To learn more about this, read our blog-post “High Performing IT Organizations: Please stop implementing the Spotify model“. Hiring a few SRE engineers and introducing Service Level Indicators (SLIs), Service Level Objectives (SLOs) and error budgets and applying this to every production workload will most likely not provide the expected positive results.
As with everything in our industry, the answer to the question which technology or methodology to use is, “it depends”. Applying SRE to any workload requires an investment of time and resources and needs to be considered carefully to determine whether there is a use case for this for any particular workload. Setting up SRE for a business-critical customer-facing system would most likely justify the required investment while applying it to a small intranet portal might not. The main question to ask for each workload is, which impact a major outage or disturbance would have for the overall business. SRE can certainly create a lot of additional value, but only when an organization is ready to make the related organizational changes. It requires cultural changes like for example, introducing blameless reviews and celebrating failure as a means to learn and improve. The challenge in applying methodologies lies not in applying the actual methodology, but in making the required cultural changes across all layers of the organization.
Devoteam NL CTO Gert Jan van Halem kicking off the All Day DevOps Viewing Party
The Imposter Syndrome
The first time I heard about the imposter syndrome was at the DevOpsDays Amsterdam in June 2019 during a very entertaining talk by Joep Piscaer with the title “Come listen to me, I’m a fraud!”. During the ADDO conference, there was a talk called “Imposter Syndrome Ain’t Just a River in Egypt” from Jesse Butler about the same topic. Even though we all consciously know that we are not the only ones with any particular problem, many of us are surprisingly good at fooling ourselves into thinking this. How many of us have not had a question which they did not trust themselves to ask, only to be grateful for somebody else in the audience asking the exact same question? This syndrome can have a big personal impact as it can generate a constant feeling of being under pressure to prove your worth and value.
Fortunately, DevOps offers many things that can help to overcome this syndrome. It promotes open and safe communities in which people can grow and learn together. In the end, we are all human, and much stronger together than we are alone. People should always be at the center of everything we do. Within Devoteam for me, this is reflected by the fact that we focus on “Technology for People”. Through using technology like for example the “as code” pattern and automation, technology is used to bring about cultural changes.
What’s a Viewing Party without some fun
The “as code” pattern
The most well-known variety of this pattern is infrastructure as code where the required infrastructure is defined in machine-readable files, and the creation of the actual infrastructure is handled by tools. These definitions files are then stored in a version control system like GIT together with the source code. This concept can be extended to other areas like configuration as code and documentation as code. The 2 main benefits of this general pattern are that it allows, especially developers, to use the tools they are used to when developing code (IDE and GIT). This allows for tracking changes and reverting to previous versions in case of issues.
What if we could also extend this pattern to compliance? Compliance is an important topic for every organization as it is in general directly related to regulation and certification. Compliance is verified through audits that involve an auditor coming onsite to review whether all required processes and procedures are being followed. Many of us will have been asked to perform a lot of manual preparation work just before an audit to verify that everything is indeed compliant. In case this sounds tedious and stressful, that is because it actually is. Often it needs to be done under high time pressure. As one of the main aims of DevOps is to automate toil (in this context manual and often tedious work) wherever possible and compliance involves many repetitive tasks, many of these processes and procedures can be automated. Capturing compliance rules in definition files, which are executed automatically, would show regularly and early on when there is an issue with compliance which can then be fixed. This would greatly reduce the need for preparations shortly before an audit and it would also automate much of the audit itself. The compliance definition files can then be stored using version control providing the expected as code benefits. One potential framework for implementing compliance as code is in-toto.
Pizza, beer and knowledge sharing
Do you want to be part of fun community events?
At Devoteam we believe in TechforPeople. Above all, our own people. We believe that technical communities are the core of innovation. Do you want to be part of that?
All Day DevOps: What’s next?
For those who missed ADDO this year and for those interested in more, the conference will return on November 18th, 2020 for another 24 hours full of interesting talks. Stay tuned! You can, however, already register for our All Day DevOps 2020 Viewing Party. Details will be sent to you when they are known (somewhere during the summer of 2020).