It's been almost 3 years since I have been exposed to infra-heavy teams and I wanted to share my learning and experiences around this.To give some context, I have been working as a regular developer from past 8 years in an agile environment. The maximum devops that I came across in my earlier teams was triggering/re-triggering builds and maybe write a few scripts here and there. Coming to land of devops, it is a whole a different ball game. Many teams are dependent on you and you need to make sure everything is up and looks pretty.And if something goes wrong, well you would still be fine, I think.
Given below are the few gotchas/heads-ups most developers would come across while getting their hands dirtied with devops:
Mapping business value and devops
Being mostly feature/functionality focused in my previous teams, it took me a while to understand the business value infrastructure teams can bring on the table. What I learnt in this time is, infrastructure teams are responsible for the developer experience and also the app performance which links to user experience. Whether it takes 300 ms to load your site or 30 seconds , it directly ties back to the infrastructure in place. If observed more acutely, these finer details are responsible for most of the end users to switch apps and opt for a newer-more performant one. So, to sum it up, infrastructure teams have a direct impact on the customer base.
Mastering at least one editor
If you are interested in infrastructure be prepared to run scripts. Your life would be much easier if you could master at least one editor, and there are two reasons for this. First, commands don't change, at least the underlying commands don't. And let us admit, instead of logging into console and searching for the accurate page where you would finally execute your task, it would be far more efficient to execute the same via command line. Second, you have more control over the arguments and the options. I am currently trying to learn emacs-doom(fingers crossed), but there are many other editors that can be tried out.
Getting firm grip on the tech stack
Remember the advice that its important to focus on concepts rather than tools/ide , well what I have experienced is for devops you would need both. It would help to a great extent if you are well verse with the tech stack. For example, if AWS is being used, it would be beneficial to know about various AWS services and which one to use when. It would also help to know at least one of the AWS supported languages as well.
Dashboards are your savior
Visualizations of the infrastructure is extremely important since it shows your entire system in a glance. And making them as intuitive as possible and highlighting only relevant information is the key here. Dashboards are usually the first instant visual indication that something is not right and it would be really annoying to look at a cumbersome report instead of looking at the stats which are of high stakes. So being as concise as possible is something to keep in mind while building them.
Well, that is pretty much I had to share. If you are an aspiring devops, hope the above nuances are helpful to make your journey an effortless one. I have been hearing this a lot- Devops is not just a role, its a mindset. And what I learnt in these 6 months is in order to adopt this mindset it is crucial to be open to it and to come out of the comfort zone.
Top comments (0)