I started my tech career like most others with an engineering background. It was in early 2018 when cloud was not all that prevalent and MS Azure was still new, that I started working on cloud. It was an infrastructure development project where we completely migrated an on-premise system into the cloud. I knew then that this would be the direction my career is headed in – with DevOps.
An Introduction to DevOps
DevOps as the name suggests is a combination of development and operations. For me, the beauty of DevOps lies in the fact that you get to see the entire SDLC in action. Once a developer checks in his code into a DevOps program, be it Jenkins or Azure, it is the DevOps architect who decides what different tasks to put into the program that correspond to the technology or version of the code checked in. You’re basically facilitating the developers’ needs — whether it is creating multiple environments, evaluating opportunities to enhance how a developer creates code, identifying alternatives to a developer’s idea, logic or look at scope of automation.
As you can see, the scope of DevOps is vast. With a simple automation you can save hours of manual work. All it needs is a thorough understanding of the backend. There’s a whole lot of research involved, getting to know your way around the system, and then figuring out what parts of it can and should be automated, and which kind of automation delivers the most impact for the client. This curiosity about the solutioning of automations got me to the architecture side of DevOps.
Scope of DevOps within a project context
Any DevOps setup is intended to do 3 main things.
- It protects the environment with application security solutions.
- It enables developers to maintain their source code and its versioning.
- It ensures that the hosting is done right for the client environment irrespective of the various programs running on a developer’s backend system.
While setting up the CI/CD pipeline, hosting environment accounts for 60% of a DevOps’ time, the remaining 40% that involves taking care of the environment — creating security solutions, providing enhancement ideas, identifying scope for automation and research on latest cloud offerings. This is also how you can differentiate yourself as an architect.
Rewards and Challenges of being a DevOps Architect
My favourite part of DevOps is the challenge of researching the right piece of code to automate, that also gives the maximum optimization. And of course, I feel good saving all the manual effort and time for my development team and my clients.
The toughest part of it all is in convincing yourself and others that it can be done. For instance, when you’re looking at the setup of a huge system, there are always various solutions floating around, including your own. At the end of the day, the scientific process through which you explain your automation choices and technology decisions that benefits everyone is critical. And therein lies the core value of a DevOps architect.
DevOps Teams at TVS Next
As a DevOps Architect, I can talk to the client directly — no restrictions. This client-facing role is something that I’ve learnt to handle here at TVS Next.
What I love most about my team here is how everyone feels ownership. It’s like the kind of exceptional teamwork you see on the USS Enterprise. If you’ve watched Star Trek, you’d know how the crew steps in to manage the ship whenever Captain Kirk is needed elsewhere. That’s how my team at TVS Next operates, seamlessly, even when we’ve all been working remotely.
Interesting future ahead
I’d say DevOps is still pretty nascent. There’s a lot of scope, so much more to explore.
I recently got this idea to develop a new cloud service after getting to know about Disaster Recovery as a service (DRaas). I think it has ample potential. I have also developed a Powershell script that monitors a project environment end to end. It can identify if a site goes down, can automatically fix it and even send me a report on it. What started out as a minor automation can now become a product of its own.