Takeaways from Devops Pro Vilnius

On the 26th of May, some of us took a day off from our everyday work and went to learn new things at Devops Pro Vilnius. Here are some things we found interesting.

Walking skeleton

This term kept popping up recently and the conference was no exception - which made us curious enough to look up the definition. After reading up about it, we realized that we do it when we develop new services at Vinted. In our opinion, it’s a very good practice. It forces you to tackle problems gradually, instead of facing “alright… so how do we deploy this complicated full-featured app to production”.

Theory of Constrains

Ian stressed several times that focusing on constraints is the best way to address problems. The basic premise is simple - if you aren’t focusing on the bottleneck:

  • optimizing anything before the bottleneck simply overloads the bottleneck more
  • optimizing anything after the bottleneck just makes those parts in the pipeline more idle

Trust level in an organization

Ian (yeah, Ian was good) mentioned trust in a way that got our attention. Situation - your colleague gets into some sort of trouble at work.

In a low trust environment you go “Why did we hire this guy? He’s a jerk”. In a medium trust environment you go “Well, that was a bit weird”.

In a high trust environment you go to help them.

What’s the trust level in your company 😏?

Some quotes that we found relevant

If things are painful, do them often - meaning that you will eventually make them less painful and automated.

If something is easy to do, it will be done more often - one thing that came to mind were some of the MySQL issues we were having. Our backend developers did not notice them quickly enough. We believe the main culprits are the lack of visibility and knowledge where to start. Simply by making these problems more visible and giving backend developers more tools to dig deeper we should be able to facilitate prompt resolution of these issues.

Develop without a debugger, imagine you can't ssh anywhere - forces you to think about what the real side-effects of your software is (i.e: where do I put logs?).

Be careful not to set your KPI's as your goals or targets - because that drives bad behaviour (i.e: 99.99% site reliability is a KPI, not a goal. If you set that as your Operations team goal - why should operations ever allow a new deployment? Deploying something new is always at least a little uncertain, thus can hurt reliability).

Thanks to Tomas Varneckas who helped me write this article.