I was in Rome attending the DevOps days conferences and IMO it was an awesome success.
Apart from the conferences, there were a bunch of open spaces really really useful. Thanks to everyone for being so collaborative in these small talks.
I love how this DevOps movement is growing and how its foundations are being formed.
We talked about testing, code quality, scripting, monitoring, continuous integration, continuous delivery, how to introduce DevOps in a company, how to start doing DevOps, how to deal with Devs and Ops,… this is the great thing of DevOps, it covers lots of things.
Some stuff said in Rome that i really liked:
- Talking about monitoring and metrics:
- Do you know how many people clicks this awesome button?
- Then, why do you have this button?
- What happen if your most important server dies? can you make it run in 10 minutes? ( Chaos Monkey )
- How DevOps should be? centralized or decentralized?
Let’s explain DevOps at http://www.tuenti.com
Here, at http://www.tuenti.com we are doing DevOps since the beginning of 2012 with a 3 people separated team. The idea of having a single team, therefore, centralizing DevOps, is a single central point to manage the full development workflow within the company being the team that handles other teams requests, complains or suggestions easing the coordination between Dev, Ops and QA. The continuous integration/delivery, DCVS management, monitoring, development environment, releases and tooling also fall into Tuenti DevOps.
But, why centralize? In my opinion, the goal is decentralization, but, to achieve this, firstly we must centralize and drive the company to a position where the decentralization is possible, and here at http://www.tuenti.com a company with almost 200 engineers and many legacy practices, currently, is not possible.
So, we are centralizing to decentralize (what a paradox ehh!!)