Interview with Vamsee

leena

May 8, 2017

Vamsee We have a change for the post in this week. I usually share guidelines or case studies about how software should be delivered. Instead, this week I am interviewing Vamsee Kanakala - who is a good friend of mine and a popular personality in both Ruby and DevOps communities, especially in India.

Q: A quick introduction about yourself i.e. your experience as Dev, Ops and then as a DevOps evangelist

I’ve been in the IT industry for nearly 14 years now - out of which I’ve been a web developer for close to 10 years. Though I have worked on multiple web technologies over the years, a large part of my experience is with Ruby on Rails and related technologies. I’m a big believer in Agile methodologies, and Rails had been an easy fit. Since I always had an entrepreneurial bent of mind, I chose to be a consultant working for startups, mostly remotely.

One of my earlier clients, an Australian startup asked me to be the Engineering Manager for their Indian office, I had the opportunity to look at some of the issues a small but dynamic team faces up close - like setting up proper developer workflows - processes around git usage, fixing deployment issues, having proper ci/build server setup, etc. That’s when I realized how important a good DevOps engineer is for startup teams.

Since I had some trouble hiring a good DevOps engineer for that team, after I left that job, I hit upon the idea of offering precisely this expertise as a service to startups. By that time, I was already playing with tools like Puppet, Chef, Docker, etc. So the transition to DevOps consultant was smooth, and I have been helping small teams setup DevOps processes and execute successfully on ambitious release goals for these past 4 years.

Q: Can you expand a little more on what you mean by DevOps processes?

When you look at the whole nine yards of the building and maintaining of software, a lot of questions arise such as:

And that is what is I meant by DevOps processes above i.e. looking at the whole nine yards and removing the impediments for smooth flow of software delivery.

Q: A related question to the above. In your opinion, what is your definition of Continuous Delivery? Why does Continuous Delivery matter?

I touched upon that above. My definition of Continuous Delivery would be a team being able to release software early and often, with as little friction as possible. Continuous Delivery matters immensely for any team which cares about shipping features on time. In my opinion, it’s also a state of mind, that’s shared by everyone on the team - the attitude of relentlessly removing the obstacles to getting to a place that would let them ship several times a day without any disruptions to regular development work. In other words, deployments should be as simple as a git commit, and any developer should be able to deploy to production, provided the commit passes the automated tests.

Q: I assume customers approach you when they have good traction in the market and want to improve the predictability and sustainability of delivery. But the challenge the team has is implementing Continuous Delivery Pipeline while continuing to deliver the product. How do you approach this to maintain the product delivery and improving the delivery pipeline?

Actually, my clients span the whole spectrum - some approach me because they’ve had a break-in on one of their servers and they realize that the current team doesn’t have the bandwidth to take care of the servers. Some, like you mentioned, need help in scaling up the speed of releases. I’ve also worked with startups who’ve had forward-thinking technical leadership and wanted to do things the "right way" from the get go.

But if it’s help with scaling release speed they want, I always tell them there’s no easy answer - first, I need to measure the velocity of the current team, understand their current bottlenecks, and make changes to the status quo - this might involve training the developers with the correct git workflows, helping them write better tests, etc. This might also involve rationalizing the deploy process so they could ship faster.

I always look for the low-hanging fruit first and then go about changing the hard things - like development culture. If it means that the releases have to take a break so I can fix some broken workflows, so be it. I don’t make any promises up front because each team is different when it comes to the challenges they face in shipping faster. However, usually the solutions are not inaccessible by any measure - it just takes instilling discipline in the team and educating them about the right way of doing things, and how a little faith in the process makes their lives easier.

Q: What do you think are the fundamentals that every team should be doing, to implement a smooth Continuous Delivery Pipeline? What needs to change in the team fundamentally for this?

What I hope for the most is a curious team - a team which realizes some things are broken and are eager to the fix them - it makes my job immensely easier. And equally frequently, I hope for humble technical leadership - people who are ready to admit things are broken and are ready to listen to an outside consultant - however hard it might be to have someone external point out weaknesses. This is perhaps the single most important reason whether I succeed or not - if the client doesn’t give me enough rope to change how things are currently being done, there’s very little I can do to fix those issues.

All change is hard, so it involves courage on all parties - on my part to push the team to change, the leadership to accept things are broken and to seek help and the team to be open to new ideas and be willing to try something new. Obviously, I go out of my way to help all parties get to this place as much as I can, but the fundamental requirement is for the team to be ready for the change. It’s not always easy, which is what makes my work very challenging and when it works, equally rewarding.

Thank you Vamsee for taking time and sharing your thoughts and opinions with us.
In the next part, we’ll talk more about your experiences while working with customers.