Some Activities Carried Out By The Infrastructure Engineer at Moka
Continuing from the article of How Moka Infrastructure Team Handle One Million User Requests, we want to dig in more about what Infrastructure Engineers in Moka do.
From my experience as an Infrastructure Engineer, the important process to manage Infrastructure Team at Moka is divided into 3 Main Categories.
Besides the operational and research, we don’t leave the fun behind! Being an infrastructure engineer sometimes can be very stressful. But well, stress is common in whatever job you’re in, right?
When you want to be an Infrastructure Engineer, you must have the ability like an owl — the ability to be available and responsible to take care of all the infrastructure in your company. You must be the front layer if the service is down. Therefore, you need to be available 24/7. And also, you need to always bring your laptop anywhere and make sure you have good internet connection. Why? Because if something goes wrong with the server, our Pagerduty will call you anytime and anywhere!
Now, let’s start to peel this one by one.
Operational
1. Serving Pods
The operational area goes along with any request from the engineering team, such as requests related to the server, database, performance test, etc. Currently, we’re working in multiple Pods with one PIC from Infrastructure Team at each Pod. The number of infrastructure team members assigned to each pod depends on how big the Pods are and how many services that the Pods have.
Anyway, the term Infrastructure Team is kinda too long. Let’s just call it Infra Team, shall we?
So, how do engineers send their requests to the Infra Team? Mainly, we use Slack for central communication inside the company. And then, we have one specific channel where all developers can request anything to Infra Team through JIRA ticket.
In the next article, I will define how exactly an Infrastructure Engineer serves each Pods from the first day they join until they are assigned as the PICs for each Pods.
2. Legacy On Call
What is Legacy? Legacy is when the old code was built using monolithic methodology. We are now using Ruby on Rails for our core services.
Does Moka still have Legacy code? The answer is yes we do. We still have 50% functions that are still running on Legacy services. But now Moka is starting to standardize every new service to microservices methodology. Our Tech Team is working on progress to move the Legacy to microservices. However, requests keep on coming in and we have limited time to refactor the Legacy code. That’s why we still have a portion of Legacy services to be managed.
The most important thing is that we need to be careful and standardize everything, before doing the deployment. Three common parameters that are very closely monitored by the Infra Team as a reference to do some changes on those services are as follows;
Query changed?
In the Legacy services, we have a complicated query from the application to the database. It could be some factors that have not been optimized and will become boomerang if the query changes cause trouble to our server, especially to our database.
That’s why we put query changed to be an important parameter as a checklist prior to the release. If the developer does some changes to the query, they must ‘explain analyze’ their query first to record how long the query will take before and after.
Migration changed?
We’re using Active Record for managing our database core structure. The active record will help you in doing a database data structure and in managing your database schema version. For a startup that Moves Fast in building products, Ruby on Rails is a good option — it’s a lot easier and faster. And then, using ‘active record’ must be monitored extra carefully as it makes your root prone to problems.
There are some common problems caused by creating a non-optimal migration logic. Hence, we need to create some simulations to verify it.
Logic changed?
Logic changed is very common in a codebase. As an Infra Team, we always push the developers to do ‘profiling code’ if the logic has changed a lot. After getting the profiling result data from them, our job is to review it.
Research
Instead of just doing operational tasks, we are also doing research to make sure our operational works efficiently. Not only that, but through research, we can also find out about some methodology limitations, develop our technical depth and so on.
What triggers us to do research? If we are stuck in fixing problems, we will list down all our limitations and research for alternative solutions.
Fun and grow together!
To balance things up, don’t forget to be happy! Because working as an infrastructure engineer means that you need to balance out your stress. You must find the fun in any way. Therefore, we have some refreshment activities.
1. Team bonding
We gather on a quarterly basis to bond with each other such as dinner together, watch movies, etc.
2. Sharing Session
To ensure the growth of every team member, we conduct internal Infra Talk every 2 weeks. It’s an open sharing session for all to learn from each other, to be #EmpoweredToGrow
So, what do you think? Are you dreaming to be an Infra Engineer? Make your dream comes true here.
