I believe I have already mentioned in my previous posts about the journey I started as a Software Engineer back in 2011. When I was still early in my bachelor’s degree, I was asked to join a young team as their iOS developer. It was a great opportunity for me to start my career, and I am very thankful for that. I have learned a lot from that team, and I have always been grateful for the chance they gave me. Years passed and I enjoyed my life as I saw myself growing in the industry. Until almost 2 years ago on April 2022, when I joined WithSecure as a Senior Developer. The new role was different, a macOS developer.
Quickly after I joined the team, I found myself in a new world with new challenges, yet it felt like I am still in the same Apple world. I felt like an iOS developer who meets new challenges and a much greater audiences now. Even though the team was very supportive and I had the chance to learn a lot from them, deep down I felt that I want more. I wanted to go beyond software development. I wanted to design them, deploy them, and maintain them. I wanted to be challenged by their scale, by the costs they can make for us. I wanted to be a DevOps/Cloud Engineer.
And now here I am. A DevOps Engineer who still has a lot more to learn, but enjoys every second of his career. I am involved in projects that are used by hundreds of thousands of users each month. They are scaled all over the globe and cost ten of thousands of dollar for the company. I am responsible for their uptime, their security, and their performance. I am responsible for their deployment, their monitoring, and their maintenance. I am responsible for their design, their architecture, and their scalability. I am responsible for their success.
But here I want to talk about things I have learned in this path. Things can vary widely when going from a Mobile Engineer where you face end-users with no middle layer, to a DevOps Engineer who is responsible for things that are used by others to provide values to our customers. I want here to talk about things I learned, things I wish I knew before, and things I am still learning.
You are working in a totally different world now. Every piece of code you write when dealing with end-users (either for Mobile or Front-End) may impact on users’ experiences and touch the company’s profit by some margins. You see the result almost pretty fast. You get feedback directly from customers, and you can use the data to determine if you have to turn-back or continue. When coding, you should always remember that these changes may be revised not long from now, as products evolve by the time. Additionally, you may also have the chance to test your changes right from your machine, and ensure that the changes are working as expected.
Here in the DevOps world, you may bankrupt the company in a blinking. If you don’t care of security, you can destroy the company’s reputation. If you neglect regulations, your company may be fined for its fortune. Each project can stay alive for decades. A bug (regardless of its importance) may lurk somewhere hidden for long, until it is too late to take any steps to cure. At the same time, you may be forgotten when it comes to visible changes. People may not see your work, or understand its importance. You may not be rewarded or appreciated as others.
Your changes may not be visible to end customers, but you are the one who is responsible for the company’s success, its failure, or its reputation. You are the one who is responsible for the company’s future. So if you want to join this path, you should be ready to do things not for them to be seen, but for them to build a foundation for others to provide services to customers.
I know! After reading above section, you may be frightened to take such responsibilities. It may seem too scary to many, and you know what? IT IS SCARY. But the point is to remember that you are a human, and we human make mistakes. No one likes to do wrong things intentionally, so when something breaks, it is broken. You can’t change the past, but you can learn from it. You can take steps to prevent it from happening again.
But don’t be afraid of breaking things. A good DevOps team understands this matter, and provide enough room for mistakes. That is why many companies adopt the idea of CI->STG->PRD environments. You can test your changes in a safe environment, and ensure that they are working as expected. You can monitor the changes, and see if they are causing any issues. You can rollback the changes, and fix the issues. A good DevOps team knows the value of automated tests, End-To-End tests, and the importance of keeping them updated. A good DevOps team appreciates and uses monitoring tools to avoid facing surprises when it is too late. And more importantly, a good DevOps team has a supportive atmosphere, where you can ask for help, learn from others, and being brave enough to make mistakes.
One of the issues I faced when I started my journey as a DevOps Engineer was that I was too focused on the technical details. I was too focused on the tools, the technologies, the languages, and the frameworks. While these are very valuable when developing, sometimes you need to step back and try to understand the big picture. As a DevOps Engineer, you are constantly building complex structures that are coupled with internal and external dependencies. While it is very valuable to know how to do thing, it is always better to understand what you are trying to build first. You should always remember that you are not building a software, you are building a system. A system that is used by others to provide values to customers, and systems are complex.
This matter is very important when you start dealing with Cloud platforms like AWS. You may be asked to deploy a new service, but you need to decide how to do it. Do you use EC2, Fargate, or ECS? What engine do you use for your databases? How do you manage secrets? And so many similar questions to answer, before even you have the chance to open your editor or IDE.
A good DevOps Engineer is always looking into the big picture. Making significant architectural decisions is a daily routine in this world.
Do you like to be called on a weekend when you are enjoying your time in the middle of nowhere? Or do you like to be called at 3 AM when you are sleeping, to rollback a problematic deployment that happened yesterday? If your answer to these questions is No, then you should start automating everything. A good DevOps Engineer is always looking for ways to automate things. They are always looking for ways to make their life easier, and their systems more reliable.
While this may not be a case for some stacks (for example in a Mobile world when deployments are approved by Apple or Google), the automation is in the heart of every steps in the DevOps world. You always look to automate things, not just because it is easier, but because they are more reliable and less error-prone. All steps, from git checkout until you run smoke tests against a live environment must be automated and repeatable. This would give confidence to you and your team, and ensure that anyone with correct permissions can do the same steps without any issues.
I remember a very good colleague once said: My goal is to automate everything in a level that the company feels that they don’t need me anymore. This is a very good point, and I assure you that no company would fire/lay off a person with this mindset :)
Last but not least, you need to communicate more than any other team in your company. Your communications usually go beyond your internal team, as now your users are other teams in the company. But regardless of whom you are communicating, you need to be clear, concise, and informative. You need to be able to explain complex technical details in a way that is understandable and relevant to the audience. You need to be able to listen to others, and understand their needs and concerns. You need to be able to ask for help, and provide help when needed. You documentations should be clear, up-to-date, and easy to follow. You should always remember that you are not the only one who is responsible for the system, and you should always be ready to share your knowledge with others.
I am very new in this world myself. I am constantly learning new things, and I am constantly making mistakes that make me a better Engineer day-by-day. I will share more about this journey in the upcoming months. Stay tuned!