I love to comment that this picture illustrates the conference just perfectly (for those who want something better, remember the dates: 2nd-4th of October), not to mention that diversity of this conference was almost the same as Saudi Arabia’s Women’s conference, but there still were quite a few good things to take away. What is interesting is that this conference had a lot of technical talks, at the same time, the added value for them was slim to none- some shameless self-promotion, some presentations that could easily be condensed in two or three slides, or just copied from the respected technologies “best practices” page.

As it is usual for DevOps conferences, many presentations also dealt with DevOps as cultural change and a lot of times it was possible to hear acronym CALMS (framework), with it’s five pillars: Culture, Automation, Lean, Measurement and Sharing, however, I cannot say that this conference covered all of these things in-depth, but in terms of Lean, one of the presentations that really stood out was by Howard Deiner: Synchronous vs Asynchronous Digital Circuits as an Analogy to Organizational Dysfunction Applied to DevOps Practices.

Due to really heavy title, it was not the most populated presentations, but it was probably the most useful in terms of understanding Lean principles, and it was just great to hear wisdom from someone, who has been around for quite some time and has been one of the first Agile/Scrum coaches.

TL;DR version for this would be “Forget about Scrum, use Lean, use Kanban- meetings create only more meetings and it is not where the magic happens”.

I understand that this is a rather radical shift, especially since a lot of organisations only now are starting to properly adopt Scrum, however, this needs to be looked in context- a small or medium team will work great using only the Lean principles- it has no need for Scrum ceremonies, as these ceremonies, speaking in terms of Lean, only provide “waste”. It usually starts great, everyone is motivated, but during time, the enthusiasm for such meetings gradually decreases- if at first everyone talked at retrospective, in few months, this is reduced only to few people. You don’t need to wait for retrospective to share something cool or your mistakes with the team, you can do it right away, or have impromptu retrospectives if you wish- the main thing to consider is to not limit yourself to “clocks”.

You can find the slides for this presentation on SlideShare, and I’m really hoping that video will be posted soon.

From slightly more technology focused speeches, need to mention Matthew Simons keynote about Monitoring, Alerting, and Paging: A Three-Part Guide to Incurring Human Costs In Engineering. There were a lot of good things coming from there, for example, “everything is a hammer”, meaning that any tool can be used as a hammer, however, even amongst hammers, some hammers are better suited for specific tasks.

The second really important though came from analogy to the story about a boy who cried wolf (or Aitu gans un vilks), where, instead of a boy, a system kept alerting people about the possible problems in production. Yes, there needs to be monitoring and alerting solution, but you need to focus and identify, which parts or things are important enough, that you would be willing to be woken-up at 3 am, or to put simply, create an alert only when it effects the clients experience, for anything else- create a ticket, do something simpler, but don’t mix these things together, and expect that people will pay a lot of attention to alerts.

I’m pretty sure I will be tarred-and-fathered, if I really don’t mention at least somewhat technical, and in this sense, presentation by Peter Souter from HashiCorp (yes, yes, the company we DevOps people actually love) about Security in DevOps world really stood out. Yes, there was some shameful self-promotion of HashiCorp Vault (but hey, we still love that product, and everyone wants to actually use it), but there were a lot more things that everyone should know:

• Treat security like fire safety- it is something that everyone should know about. It does not mean that we no longer need security people, or that non-Sec people should do the security, but everyone should know at least the basics;
• Automate security testing, e.g. using Trufflehog (https://github.com/dxa4481/truffleHog), that automatically scans your Git repositories for potentially leaked passwords/credentials;
• Use Vault;
• Remember, the best security is the one, where credentials cannot be leaked because there aren’t any- this might seem like far-fetched dream, but such solutions are possible on AWS for example, using IAM roles;
• And use Vault;

There was also an interesting presentation about Jenkins, or, how to make the jobs more portable, to be easier to migrate to other CI/CD solutions.

TL;DR– instead of writing sh steps in Jenkinsfile, put these commands in plain Shell files, and call them in Jenkinsfile, e.g. instead of sh echo “this worked”, put it in a script.sh file, and create a step sh scripts/script.sh.

This was mainly interesting, as I’ve had similar experience in different company, where the end goal (or where the manager wanted) was to have as vendor independent solution as possible, which ultimately lead to very messy scripts, no clear way of deploying the product, and, of course, no proper testing, beyond unit tests. And I’m not saying that it is a bad approach- or that you should not use it, but, the key element here is to actually understand, if you need this- if your pipeline is simple enough for this work, or, maybe you’d be better off to locking yourself to specific technology, or specific CI/CD solution and stop worrying.

Can I say that this was a bad conference? No, not really, but again, what I missed the most, was some mojo, that would make this something more than just your average DevOps conference. It was great to have a chat with a few speakers, it was great to meet-up with people, whom I’ve have not seen in quite a while and it was great to hear a few thoughts from others, so in this sense, this conference accomplishes this. What I really hated was to sit trough some self-promotion presentations, or to hear presentations that were technical, yet the takeaway could be easily expressed in a tweet. Lets see if Riga can do better, so wait until the 2nd of October, for the Untitled DevOps Conference #1 😉