Attending DevOpsDays India 2022
4 min read

Attending DevOpsDays India 2022

Attending DevOpsDays India 2022
Image credits to Abhinav Dubey

Thank god the pandemic is over. I have been attending conferences virtually. But I have been missing the in-person interactions, open spaces and BoF sessions, and being able to meet old friends - all things that make attending an IRL conference a different feeling altogether. I finally broke my streak of not attending IRL conferences by making it to DevOps Days India 2022 which happened in Bengaluru. It was a 2 day event. This post is about my experience of attending the conference.

The conference

I want to appreciate the efforts that the volunteers put to organise the conference which I am sure must not have been an easy task after so many years. Having organised smaller events myself, I know it is not easy to put together a conference.

For me, the highlight of the event was meeting the DevOps community and old friends in-person after many years. I personally spent most of the time hanging out in the corridors of the venue meeting friends and other attendees - talking shop, learning about all the cool stuff they have been working on and exploring opportunities to work together. Just this part in itself was valuable enough for me to make the trip from Gurgaon to Bangalore.

However, I expected more from the conference in terms of content. I hoped to have learn more from the talks than I did. I felt that either the topics were not relevant enough or fresh, and the speakers did not focus enough on the business value failing to communicate their ideas. For example, topics like Google SRE practices have been covered so many times. Other topics were introductory in nature.

The talks in themselves were not as bad. But they probably don't cater to an audience of different experience levels. An event like DevOps Days should cater to a wider range of audience. It would be nice to see multiple tracks like beginner, intermediate and expert in subsequent events so that beginners as well as practitioners at all levels get to learn something.

What was everyone talking about

Like I said, the most valuable part for me was the conversations I got to have with people across discussing a range topics from DevOps and cloud-native technologies to pricing of SaaS dev tools like Github and Gitlab. Some of the conversations I would like to highlight are:

  • Difficulty of adopting Kubernetes as a common theme - Kubernetes is great. But it's also hard. The time to value can be extremely high and is often not considered enough by engineering leadership and platform engineering teams, so much so that it might not even be the right solution for many teams. There can be other viable solutions for different businesses at different times - HashiCorp Nomad, ECS or not doing containers at all.
  • The best of teams have technical debt in their platforms - we assume that the best of businesses have the best of tech but that might not necessarily be true. While working for a client, I made the mistake of assuming that a certain really large (unicorn) fintech company in India will have all their infrastructure problems solved. After speaking to engineers on their team, I learned that's not the case. The experience of deploying and operating applications on their internal Kubernetes platform was far from ideal, fairly complex and often broken. I had a similar experience when I spoke to an engineer working at a really large global HR tech company. I assumed that they would have a rock solid Kubernetes platform already deployed whereas the reality is that they have been struggling to break their monolith into microservices and migrate to Kubernetes. The best of businesses have interesting technical challenges but also an equal amount of technical debt, and sometimes fairly basic in nature.
  • Challenges of testing changes in microservices - microservices are great as long as you know what you are doing, and most of us don't know what we are doing. I have spoken several times on this topic and my belief just keeps getting stronger as I talk to more people on this topic. In a conversation with some of friends at other companies, the topic of automitically came up while discussing Kubernetes and microservices. Engineers experienced in working with microservices often bring up the topic of doing microservices the "right way" and how most teams struggle with testing changes in microservices. Theoretically, a change in a microservice should be independently deployable but the reality is usually different. In reality, changes in a microservice can break the application if not tested properly, which defeats the purpose of microservices. Testing methodologies like contract testing (using tools like Pact.io) can be helpful in theory but are hard to understand by most developers in reality. Small teams built by carefully hiring experienced and smart developers can deal with complexities of microservices. But microservices are often deployed in large environments with large teams working on them - and their experiences of adopting microservices are different from "ideal teams". In such situations, testing all microservices as a whole using business facing end-to-end API tests is one of the best bets for continuous delivery. But here we are - treating our microservices backend as a Distributed Monolith.
  • DevRel is an upcoming role - it was great to see so many folks who are now devrels at companies building something in the space of devtools, cloud-native technologies and infrastructure. The role is still fairly new and the folks in the role are fairly young as well. They have great energy and charisma to engage with the beginner community and seem to be using it fairly well to their advantage. But at the same time, they need more technical experience to engage with the larger community and connect with more experienced audiences as well. In a conversation with a friend active in this space, we discussed how to help accelerate growth of devrels. The idea that I found most valuable was to have young devrels do a lot of customer focussed work like demos, solution engineering, webinars and customer support. The customer facing exposure can accelerate the learning and getting the relevant experience to connect with more mature audiences.

Conclusion

It was great to be attending conferences IRL again - what a fresh change from regular work and an amazing opportunity to meet new people. Attending DevOps Days has pumped me up to get more active in the community again. Looking forward to attending more community events in the near future.