There has been a lot of talk about "DevOps" and [insert fancy acronym here]-Ops lately and it can seem difficult for us poor developers to keep up with which term should be on our resumés. But let's face it: in the end as, an engineering community, we have gotten to "You build it, you run it!" and that's fine. We are engineers after all and we love solving problems. So we just won over another set of super interesting engineering problems to solve!
In this talk we will look at which skills we bring to the table as software developers that help us in this increasingly complex and agile world. Of course we can run this. We will see that in the end we will basically be writing code for more things.
- But how will that affect the time we can invest into our actual codebase?
- And should we rethink how we write code?
- Do we suddenly need to care about architecture?
- Do all of us finally have to understand linux now?
- And who the hell will we blame for failures when the operations service desk is gone?
Relax. It's all going to be fine. We are good at this and we will build even better and more stable software once we have come to terms with this. And of course our Ops friends and their expertise will not be sent off, we will just be working much more closely with them and maybe even get some PRs coming in from them as full team-members!
Note that I am trying to address developers who are moving into DevOps or are curious about it.
If you are already experienced with DevOps and are looking for ways to smoothen the transition and raise acceptance, be my guest.
And of course you come from the mysterious "Ops" side of things you are welcome to join in, too.
This will be about principles and mindset mostly, but be prepared to see some advanced technical concepts that I take from my personal experience.