Desktop Support Engineer to DevOps Professional

Photo by SOULSANA on Unsplash

Desktop Support Engineer to DevOps Professional

Table of contents

No heading

No headings in the article.

Hello Everyone! This is my first blog. It's not like a roadmap to make a transition into any specific role or stream but I thought of sharing this to let readers know that if I can make a transition from one stream to another then anyone else can too make it.

Disclaimer: This blog could be a long one.

So, let's get started.

1. The Beginning :

In 2014 I completed my post-graduation. Throughout my college education, I did not realize that DSA will be so an important part of being a software professional and also I did not have that inclination towards programming or coding. However, I enjoyed solving problems of statistics at graduation.

In my last semester of post-graduation when I was having an internship, I gave a walk-in interview at one of well known IT organizations. The interview had questions on basic troubleshooting of hardware, software and network-related issues. Later I received a call from HR about expectations regarding salary and other details. The interview was not that good and I believed that the probability of my selection was almost zero. A few days later, I received an offer letter but the name on the offer letter was different and that is how I learned about "Third-party employment". Due to personal reasons, I decided to accept the offer letter and start my professional journey.

To be honest, the first 2-3 months were full of turbulences. I was not at all good with hardware & network troubleshooting and also adjusting to 24*6 rotational shifts. But with the help of a few colleagues, I started gaining knowledge and slowly confidence. Post 12-14 months, I received a certificate of appreciation from management for my work.

Because of my work and handling of end-users issues, I was offered to take another senior role within the organization but at a different client location within the same city. Management informed me about this to me stating there will be an increment in your compensation and I happily agreed to take it. After one month of taking up this new role, I realized nothing much was happening from the management and HR side even after discussions and follow-ups. I then decided to quit the organization without having any other offer and after serving a notice period I was jobless. I started in 2014 with a 1.2 LPA and at the end of 2015 when I quit my job my salary was the same.

Things I learned:

  • You need to give time to yourself to adjust to a new environment.

  • You can learn new things (technical as well as non-technical) every day from people around you like colleagues, managers and even your clients.

  • There are no bad experiences, either they are good experiences or learning experiences.

  • No job role/profile is bad. Respect every job role and responsibility.

2. The Job Hunt :

Like any other job aspirant, I started to search for jobs rigorously but due to my prior experience, I was getting a similar profile job with almost a 10-20% hike. I realized Desktop support engineer role is not the one I would like to take as a full-time role in the long run. I started preparing for interviews by learning Java and SQL. Through one of my friend's references, I was able to get one job where I was supposed to teach programming to college students. As this private coaching centre was new, we tried circulation printed advertisements on roads of nearby areas. However, things did not go according to plan for the owner of the coaching centre due to his health and personal issues and I had to quit my job because the centre was closed.

Around one month later I joined one start-up organization where I was working as Assistant Software Engineer. Here, I worked specifically on Java and SQL. The salary was never on time and along with the development work I need to assist interns by providing them with sessions on Java. Due to a financial crunch and other unknown reasons, the start-up was closed and I was told to not continue my role. Post this, I applied to many companies but hardly use to receive any response. I realized this could be because of my previous work experience, skill sets and/or my resume. As I was running out of time I again started applying for support roles. During the same period, one of my friends referred me to his organization for the role of Technical Support Engineer which he recently joined as a Software Developer. I applied and a few days later I received a call for an interview. Post two rounds of interviews on programming, problem-solving, Linux and networking I received an offer from them. The friend who referred me is one of my best friends and I will be forever indebted to him for referring me.

It was the beginning of 2016 and my salary was still at 1.2 LPA.

Things I learned:

  • Always try to find out more about the organization before applying for a job so that you can make appropriate decisions.

  • Job search is not always a cakewalk and every failure will only add to your learnings.

  • Always have an Attitude of Gratitude.

3. The Turning Point

As a Technical Support Engineer, my main responsibilities included monitoring the deployed application in environments like PROD, PRE-PROD and UAT, deployment of the application and L1 troubleshooting any issues reported by users. At the time of joining I received approximately a 300% hike from my previous salary. But rotational shifts with 24*6 were still with me.

Along with primary responsibilities, my manager started assigning additional tasks to our team. Because of these assignments, I felt challenged and that increased my willingness to deliver more than expected. Each individual was assigned different assignments and individuals can collaborate to complete those tasks. I was assigned to create automation that will fetch issues from SonarQube and create a JIRA issue & assign that issue to the respective developer.

As our team was working in rotational shifts I found that on the night shift I was the only one whole office. The night shifts gave me that room to do research and google stuff that I was not aware of. With the help of JAX libraries in Java, I created an application that used to consume RESTful web services of SonarQube and JIRA. So, basically what I did was retrieve issues/errors reported from SonarQube using the GET method of RESTful web services, processing retrieved JSON format to support POST / PUT requests to create JIRA issues. This may sound like small automation but for me, it proved to be a great confidence booster. It took around 2-3 months to complete this automation. My manager's technical expertise also helped a lot in this.

After this, I was also assigned to dockerize Java-based web applications. We had limited options for on-premises servers and the cloud was not in the picture at that time. There was a requirement to have a separate instance of the application deployed other than Dev and QA environment and we decided why not try dockerizing the application and try it out. In this process, I learned a lot about docker, virtualization and Linux. Writing docker files, mounting persistent volumes to avoid data loss, port mapping and so many other things.

Along with these tasks, I was actively involved in deployments of the application, performing automation using shell scripts for the client's specific requirements.

I worked in this organization for 1 year starting from 2016 to 2017 without taking a single leave! It may seem to be just one year but I was very much satisfied with the knowledge and experience I gained from the said tenure. My only bad memory is that one of my teammates lost his life due to heart failure.

Things I learned:

  • You learn more by doing hands-on than only watching tutorials or reading tech blogs.

  • Along with technical proficiency other skills like communication plays an important role mostly when you are working as a team.

  1. Beginning of the transition

In April 2017, I moved to another organization as a Senior Engineer. I was part of a telecom domain project which was completely new for me. We were supposed to perform audits on Femto devices deployed in 3G and 4G networks and many of these audits were done manually with the help of spreadsheets.

There was automation using Java pre-build by existing developers but still, most of the audits had manual steps doing that every day was not adding to our actual productivity. We as a team decided to come up with automation and use Python scripting for the same. We almost automated manual tasks to 80% using python scripts, like retrieving data from the Oracle database and other network elements and generating results post-comparison or generating health reports of application servers and sending them to all stakeholders in a fixed interval using email and so on.

Post automation of these audits in the remaining time of my working hours with a few more hours I started doing POCs about the cloud specifically in AWS. Along with AWS, I started using Jenkins for CI/CD and terraform for creating AWS resources and deploying the application on EC2 instances.

I created a complete CI/CD pipeline for developers to deploy the dockerized application on AWS EC2 instances. Below were the steps of the Jenkins pipeline for deploying the application which also includes creating and destroying the AWS resource using terraform.

I have the template on GitHub for your reference - swapnil-shrishrimal/jenkinsPipelineProject (github.com)

  1. Source code checkout from the repository.

  2. Build the nodejs application.

  3. Static Code Analysis using SonarQube. The pipeline was configured in such a way that if quality gates fail pipeline will exit and not execute the next steps. The webhook in SonarQube was used for this.

  4. Building a docker image for the nodejs application using the Dockerfile and then pushing it to the repository.

  5. Initializing terraform with

terraform init
  1. Saving the plan of the terraform to a file with
terraform plan -out=terraform_plan.txt
  1. Executing terraform to create an underlying AWS EC2 instance.
terraform apply --auto-approve
  1. These instances were to be destroyed once the developer do small testing and so I used the user_data option in AWS EC2 instance creation which had all the information to install prerequisites like docker and pulling the docker image from the repository and running the container.

  2. Developers had 15 mins once the deployment is completed to test the application. Through the pipeline, an email was triggered to the team stating to initiate their testing and the pipeline was paused for the next 15 mins.

stage('Pipeline paused for 15 minutes'){
            steps {
                sleep time: 15, unit: 'MINUTES' // This was project specific, where pipeline has been paused for 15 mins.
            }
  1. Post 15 mins, the newly created EC2 instances were destroyed using terraform destroy
terraform destroy --auto-approve
  1. Email notification was triggered with logs and pipeline status.

Similar to this POC, I also tried to get some hands-on with configuration management tools like Ansible, container orchestration tools like Kubernetes and log monitoring tools like ELK stack. With these POCs, I was enjoying my exposure to DevOps.

Things I learned

  • I took time to understand more about DevOps and understood that it's more than the tools. DevOps is a culture in SDLC and all the key stakeholder's contributions & involvement at each stage of SDLC can make DevOps way successful. However, DevOps also make sure you are improving with the help of feedback you get at every stage of SDLC. So, DevOps is a kind of journey towards better deployments (a less or negligible manual process), time-to-market, how quickly you can fix bugs and many more.

  • You have to keep learning tools and technologies which are currently used in the industry. For DevOps specifically, this can be very overwhelming but the focus should be on understanding basics and building upon them. You cannot learn all tools and you are not supposed to do that anyway.

I still believe I have so much to learn & explore more on DevOps and that is what keeps me motivated to learn more and more!

I have failed many times whether it is in automation scripts or POC exercises or interviews and more you fail more you learn is what I have realized. There were times I thought I will be not able to survive in IT, but I only tried to learn from the opportunities I got and I will be always grateful for that.

That's all from my transition journey! If you have any suggestions or questions feel free to drop them in the comment section.