Serhat Can on Managing incidents in microservices

07-08-2018 Antonio Goncalves 0 all

Hi Serhat, tell us who you are and what lead you into microservices?

I’m a technical evangelist working for OpsGenie based in İstanbul. I’ve been involved in various parts of software development ranging from mobile to frontend to backend to operations, going all the way down to the dark side! Prior to working as an evangelist, I worked in different development teams at OpsGenie and experienced on-call from first hand. Additional to DevOps, Serverless is one of my passion. I’m an occasional speaker in DevOps and Serverless area and help organize Serverless and DevOps meetups as well as a DevOpsDays in İstanbul.

While working as a developer and helping our customers, I saw how monitoring, on-call and incident response become a real challenge. We also at OpsGenie have experienced this change going from 3 developers to 60 developers within 2 years. Microservices are the necessary evil as you grow. They require proper tooling and practices if you want them to rock!

What will you be talking about at Voxxed Days Microservices?

Microservices solve a lot of problems, especially once the company scales. But this change doesn’t just require a change in how we build software, it also requires a change in how we operate the software. Once we talk about operations, we must be ready to take the on-call and solve critical problems affecting our systems and essentially our users. With multiple services with dependencies and stakeholders, challenges like finding out the right team to handle the incidents, creating actionable alerts, and managing the incident response process arise. In this talk, I’ll talk about these challenges by giving the reasoning behind and propose some solutions to these real-world problems. I’m also going to make a demo!

Today I think we all agree that microservices have to be monitored. But monitoring really seats in between Devs and Ops. What is your experience in getting efficient monitoring between these 2 communities ?

The key is to making developers in charge of what they build. DevOps aims to bring both ops to dev and dev to ops closer. In this case, we need more devs in the ops side. Yet, we can’t just expect them to do everything themselves while still building all those complex business logic. We need to empower developers to take the responsibility for the services they build. They shouldn’t reinvent the wheel. There should be services and tools for reliability which they can easily integrate without relying on other teams. Those self service tools should help teams proactively solve any problems arise in the system.

Based on our own and our customers’ experiences, putting developers in the on-call schedules and giving them access and responsibility to operate their services have extraordinary benefits for both developers and the company. And there is always a but. This requires a shift in mindset and proper tooling.