When you hear the term “DevOps Engineer”, who do you imagine?
Some geeky fellow who helps set up servers and optimize your delivery pipelines, perhaps?
Maybe it’s the team that’s always stopping you from releasing your code because of bugs that break the build system.
Maybe it’s a combination of both – a team of people whose role is to ensure that code gets from your laptop into production as fast as possible without compromising the integrity of the platform.
At United Cloud, we decided that these typical approaches to DevOps Engineering were not right for us – and instead challenged the status quo for DevOps Engineering roles in our industry.
Don’t get me wrong, we still want to make sure that your code doesn’t compromise the stability of our systems – but rather than bear that burden alone, we have opted to develop tools and procedures that you can use to create and deploy apps without ever needing to open a support request.
This self-service model allows us to focus on the more exciting and true nature of the goal we share – building a stable yet complex infrastructure and the tools needed to maintain it.
Although I came from a programming background myself, I honestly had no idea what a DevOps Engineer really did before joining the United Cloud Team. I had interacted with DevOps Engineers in the past, but only as a developer. I never fully understood what it was they did or why.
Joining the team
Then one day I joined the United Cloud DevOps Engineering team and found that I was a DevOps Engineer myself. That’s when I learned about a whole world of hidden technology that I had known nothing about.
It amazed me to see what resources were applied to running code from the development team with zero downtime for end-users: everything from physical servers maintaining over 600,000 (yes, 600,000!) persistent connections per server to the retrieval, encoding, and streaming of nearly 1,000 channels of around-the-clock content to user TVs.
To make streaming for millions of our users work seamlessly, thousands of geographically distributed servers worldwide push nearly a terabyte of data per second during primetime through content delivery networks we developed. That’s why infrastructure development and management require substantial know-how and ingenuity.
We apply an “automate everything” mindset at every opportunity. And if we need some tool or functionality that does not yet exist, we build it ourselves. In fact, a large portion of our tools and products were developed by United Cloud DevOps Engineers – in a wide variety of programming languages and frameworks, including Python, Golang, and Java.
One of the secrets to our success is that we develop and maintain everything according to community and industry standards. This lets us accomplish a lot with a modestly sized team.
Of course, this kinds of tools and frameworks is of no value if no one knows how to use them. That’s why we devote a lot of time and effort to educating colleagues with regular workshops.
Because the discipline of DevOps spans a wide range of technologies and expertise, it’s not uncommon to have different people on the team be experts in specific topics. Each subject-matter expert is encouraged to share knowledge with colleagues, so everyone has an opportunity to develop great solutions as speedily and well as possible. That’s the goal behind the “tech evangelism” culture that we nurture at United Cloud.
One of the things I love about UC DevOps is the way innovation is encouraged. There is the freedom to explore and experiment, to try new things, to tinker. As the innovation center of United Group, the parent organization for telco providers, TV stations, news portals, ad agencies, and content owners around the world, we enjoy unique opportunities to shape our industry. Today we’re building a highly optimized storage solution for video on demand. Tomorrow we’ll research ways to integrate completely new technology into our existing stack. The playing field is constantly evolving.
Being a DevOps Engineer at United Cloud is a unique and challenging job. There’s much more to it than clicking buttons on a cloud provider’s fancy dashboard. The role requires different skills and know-how. But if I’m being honest, these demands are the reason this is one of the best jobs I’ve ever held. I can feel my competencies growing day by day.
A day in the life
Let’s take a look behind the scenes at the way I spend a typical day in UC DevOps.
9:00-10:00: Post
I typically start my day at about 9 a.m. If I’m coming to the office, I usually start at the restaurant downstairs to have breakfast with colleagues. This is a special time for me because the conversation is not planned. A lot of interesting project ideas start over these informal breakfast meetings.
If I’m not coming to the office, I usually spend this time researching my next project, replying to support requests in Slack, or resuming work on a previous project.
10:00-10:30: Kernel-Init
This is when we usually have our daily meeting. This is a short meeting of 10 or 15 minutes to update everyone on the status of current projects. We also use this time to catch up and offer help to anyone who may need it. These meetings can last longer if we are talking about a new feature implementation or trying to solve a particular problem. It's very dynamic, as we are not a particularly large team. We tend to bend the Agile rulebook every now and then.
10:30-13:00: RunLevel 5
From here on, it's off to our various duties and tasks. Depending on the assignment, we may be helping other colleagues with support requests, clearing out tasks from our Jira board, or coding a fancy new automation. This time is spent grinding, chipping away at a project. We can work on anything from a multicast monitoring solution, to researching how to have a single database server maintain 600,000 persistent connections. It all depends on what we have going on at the moment.
13:00-14:00: Fork()
This is the most holy and sacred time for DevOps Engineers: lunch time. The morning’s hard work has depleted our brains of their wisdom and knowledge, and we require refueling. So we make our way to the kitchen and fill our bellies. It’s a nice time to recharge and chat with colleagues.
14:00-16:00: Socket.Connect()
After lunch we tend to schedule workshops and other team-related meetings.
16:00-17:00: Shutdown
Toward the end of the afternoon, the day gets pretty quiet. People who started work early are beginning to head home, and the office gradually becomes less populated. I am usually at my most productive at this time (maybe it was lunch finally reaching my brain?), and I like to use the afternoon to focus on my project. Because I have a software engineering background, I find this a good time to open up my terminal and pump out some juicy lines of code. (Okay, maybe not juicy – but good. I hope.)
The bottom line
From building hand-crafted tools to utilizing existing open-source APIs, from managing complex elements of a high-performance infrastructure to teaching teams to leverage our in-house tools, being a United Cloud DevOps Engineer is a unique and worthwhile experience.
Technology is constantly evolving, which means that our techniques and tools must evolve too. That leads to the DevOps team’s “always learning” attitude, which is one of the things I enjoy most about my job.
Our team is small (for now), but we are always on the lookout for outstanding individuals who have a willingness to learn, a strong drive to tinker, and a habit of thinking outside the box. DevOps is a bridge between our developers and our users, and we aim to deliver the best possible products – both internally and externally.
Every day offers something new and exciting to work on, to develop, and to learn. So what are you waiting for? Come take a peek behind the curtain and see the awesome world that keeps our most powerful and load-intensive apps running smoothly.