How to make your first DevOps project interview-ready
Let’s take a minute to think about our learning path during the years.
After you finished your studies and just before entering the workforce, you probably started your portfolio (or something similar), attempting to demonstrate your abilities in order to showcase your value. Your first personal project as a DevOps Engineer!
Because it’s only the start of your path in the High-Tech industry, and we don’t have much experience yet, we want to show as much professionalism as possible in only one project. Sometimes, we accidentally mess it up and don’t demonstrate our capabilities.
Usually, if it’s not the project you’ve been tasked with as the final step in your bootcamp, then maybe it’s a project you decided to build on your own, to show to employers or prospects in interviews. This ‘portfolio’ project has a significant impact on your future career as this is the first time you are going to show your capabilities.
When starting a project, most people wonder: Is it good enough? What are the problems in my project? How can I improve it?
Often, people want their projects to be better than their colleagues’, so they compete against each other by using newer technologies, applying more sophisticated logic, and even just showing off. It is a legitimate goal to be the best on your team, so I will try to help you improve your future and past portfolios with some insights I’ve gained from my experience.
What made me realize these insights?
My story starts during a recession in the hi-tech world, and as such, our team competition was extremely tight. We realized that most of the people in our roles and experience status couldn’t find work easily, so we better be good—very good.
As a result, our entire group started working on the project before the schedule started.
My project included many sections and a lot of knowledge. I can divide it into 3 major parts stored in 3 different Github repositories:
- The first part was the portfolio application source code and the CI/CD workflow (a Jenkins file).
My application was a Python Flask web application that served the user. However, the web application wasn’t the only thing that I’ve developed. My website lets you download one of my other projects, “CrossyRoad,” a game I developed in the Python programming language.
The Flask application integrates with a MySQL database where the users’ credentials are stored and also uses NGINX as a frontend and reverse-proxy and serves static content. The Jenkins file in the repo is used for CICD. I’ve configured a Jenkins server that runs on an AWS EC2 instance, so during the CICD process, according to the stages presented in the Jenkins file, a demo environment will build and test the application using docker-compose, and then will publish the artifacts (two Docker images) to AWS ECR, one for Frontend and the other for Backend. The last stage in the pipeline is deploying the images to a running Kubernetes cluster on AWS using ArgoCD and notifying about the process result via email.
- The second repository contained only the Kubernetes cluster Helm charts.
I’ve created Helm charts for my application and for other tools I used in the architecture:
- For the Flask application itself, I’m using Kubernetes deployments and services.
- To securely store secrets in the cluster, I am using the chart “External Secrets.”
- Logging with EFK stack and monitoring with Prometheus-Grafana.
The Helm charts get updated in the live Kubernetes cluster using ArgoCD technology that reads my git repository and creates/deletes resources from the cluster.
- My last part was, of course, creating all my infrastructure using Terraform and specifying all the resources that I wanted to create using Terraform code blocks. My project had two modules: one for networking by creating a VPC and the other for the AWS EKS cluster.
Together, all these repositories were presented as my personal project. So, you are probably wondering how I could improve my project? And if you are wondering why I have wanted to improve it let me tell you some breaking news: There is no one single project that we can define as perfect! There is always room for improvement! So let’s see three different ways, one for each repository, and as a result we will get some insights.
Ask A Friend
In the final steps for the application repository, I was so excited that I succeeded in serving my developed game through the website. I went to a good friend and my mentor at the time, Idan, and asked him to take a look at my game, and after a few rounds playing the game, he asked me in a tone of a joke: “But where is the leader board”? That was the moment I realized that I could actually develop a leaderboard without much effort. I only need to create a scoring logic in the game code, create an HTTP POST request at the end of the game, and serve the leaderboard from the website! No effort at all, but yet a big difference with more complex logic, and in the end, I’ve shown that I can connect all my project systems together.
So what is my advice to you?
Ask a friend – sometimes, a friend can take only one look and give us some suggestions of things we can add to the project. Moreover, he may notice some mistakes that we could have made along the way and correct us or simply give us his honest opinion, which is nice too.
Use better technology than expected (to impress)
For the second repository, the Kubernetes Helm repository, there is no “Inventing the wheel” mission or something like that. You only need to create Helm charts, and most of my colleagues used the same Helm charts. One of the tasks in the portfolio was to use a chart called “Sealed Secrets” that allows you to store secrets that you don’t want to publish to a GitHub repository as plain text, for example, the database password. Honestly, this technology was very complicated for me to use at the time because it involved much more configuration and adding external scripts to encrypt and decrypt the secrets. There must be an easier way to achieve this goal. And of course there is one: by using AWS Secrets Manager and Helm chart called “External Secrets,” you can achieve your goal in a much more secure way. By doing so, I’ve increased the project security, used AWS best practices, created something that no other team member has used, and learned something new on the way. As a result, I got compliments for my improvement.
My advice to you- Be creative as possible, use newer technologies than you’ve learned and don’t be afraid to follow your ideas if you see there is a better approach to achieving your goals.
Organize your project
My last note for you all is about how to organize your project. In the end, your project will be presented to someone who has never seen your work before, so you need to make sure that they will not have much trouble understanding your achievement.
In the last Github repository of my portfolio, I’ve stored the AWS infrastructure Terraform code. After creating and destroying the infrastructure several times, I gained some insights.
First, my friends who reviewed my project had trouble understanding a lot of my code and the logic that I used. So if they don’t understand it ‘here and now’ with me next to them, then how on earth will someone who has never seen the project before react to the first time they see my project? Moreover, will I understand what my intentions were a few years forward? I started adding more comments in my code, and every time someone asked me something that he didn’t understand in my project, I started writing comments so my logic would be clear.
Second, as my project got more complex, after every time my environment has been deployed, I needed to perform more and more actions: Decrypt Kubernetes secrets for demonstration purposes of services, changing Route53 routes, updating my computer to connect to the EKS cluster, etc’. So, instead of doing this manually every time, I decided to write a Bash script that performs all these actions for me. As a result, I didn’t need to remember to do all these actions every time. Imagine you arrive for an interview and then realize that you forgot to update the routes in Route53. Not so nice…
By making my project more organized, I saved a lot of time in the interviews to come, saved many configurations, questions and answers, and, of course, made my project more readable to others.
To conclude this article, I want to make it clear: I’m sure that all your projects are amazing and have unique value, but remember that every project can be improved, no matter how good it is. In the end, every DevOps engineer who returns to his first project after a few years is surprised by how bad it was, according to the things he does nowadays. You don’t believe me? Simply go and ‘ask a friend’ to see for yourself…