Meet Justin Kulesza: generalist, hardcore cross-country skier, and Operations Engineer at Atomic Object. I recently sat down with Justin Kulesza to learn about his job building the invisible infrastructure of a software company.
This is the fifth in a series of interviews with Atomic makers.
You’re an Operations Engineer; what does that mean at Atomic?
It means a lot of different things. For our clients, I plan and set up the infrastructure where we deploy and host their software. If the client doesn’t have an internal IT team, we pick a cloud hosting provider, set up servers, etc. For larger companies, we help their internal team do that; we facilitate getting what Atomic has built onto their infrastructure.
When projects are under active development, I set up continuous integration. We’re very big on testing at Atomic, and everybody creates automated tests for their own code. Since multiple people are working on the same project at once, we need to integrate changes and run tests on all of the code together. Automated systems help us do this continuously to detect problems whenever code is added or changed.
Another one of my responsibilities is managing source control during projects; this helps us coordinate all of the changes that different team members are making to the same project code base. It lets us track the history of these changes in an orderly fashion and brings the code together in a central location.
I also do the more traditional IT functions like computer troubleshooting, managing software licenses, ordering computers and other hardware, and managing our phone system, local network, WiFi access points, email system, internally-hosted applications, printers, and the cloud infrastructure for our website and blog. Sometimes there are specific bugs or configuration issues during development where I’ll assist with troubleshooting.
How did you come to be an Operations Engineer?
It was in 7th or 8th grade when I got interested in how computers worked and how to troubleshoot them. In high school, they switched from traditional desktops to a Linux terminal server, which was a very new and interesting thing that no one else was doing. I wanted to understand what was happening and how it worked, so I started learning.
When I began researching colleges, I was looking for something that would prepare me for a System Administrator role, but there’s no particular degree for that. Computer Science degrees are about the theory of computing and seem to focus on building software. Information Systems is about running systems and using tools to meet complex business needs, so I chose that. GVSU’s IS program also included a business minor, which has been very useful.
After graduating, I learned a lot as I went. My jobs before Atomic were either doing software development, fixing computers, or doing IT coordination and administration. All of that was very related to what I’m doing now, but nowhere near the scale of responsibility.
Since coming to Atomic, my role has evolved organically. When I first started, the only thing I worked on for the first year was the World Bank (SME Toolkit) project, fulfilling their support needs. After I’d been here for about a year, the guy who had been supporting Atomic’s internal systems left, so I started taking on responsibility for those systems as well.
I looked around and saw a lot of things that were being missed from an IT operations perspective–situations where I could more easily handle the work than project teams could, so I started asking if I could help and began giving advice on frameworks and processes that I understood. Over time, I built a reputation for having IT operations expertise. It was less of me having to advertise than people coming and asking me for assistance.
What skills does someone need to do what you do?
It’s a mix of information synthesis, problem solving, and critical thinking. A lot of: “I want to do this, and I don’t know exactly how, but I know a tool exists which can help me achieve what I want. So I’ll look at examples of how other people have used it, and mold that solution to this situation.”
Having excellent communication skills and attention to detail are also important.
What do you like about being an Operations Engineer at Atomic?
The thing I like the most is how many activities I get to do—it never gets boring. I’m always learning tons of things about so many aspects of tech: databases, cloud hosting, networking, WiFi access points, etc. Often in a larger company, people have very specific roles and responsibilities; they focus on one of those and become an expert there. My job means a breadth of knowledge and getting to do a variety of things.
It’s also really satisfying when you can build a system to host an application that’s essentially self-sufficient–when we build it well enough that we don’t need to touch it unless it needs a major upgrade. For example, we set up the servers for Atomic Spin years ago, and they’ve been running and running well ever since. We haven’t had to alter them to, for example, handle the higher amounts of traffic we’ve been getting.
What do you find frustrating about it?
A lot of times, the new and exciting tech we’re working with is still in development. The technology may only fulfill part of what we want to achieve. So we have to cobble together a solution using several different tools to make the system work or meet the need. We call this using duct tape. (e.g. Everything is being held together with duct tape.)
It can get really frustrating when one of the pieces of a system has a bug that keeps you from making progress, but you can’t choose something else because of other requirements. Or when you have to build off an older system, using old software that hasn’t been updated in years to support and extend an old product.
Where do you think software is going?
Things are moving toward containerization and micro services. The idea used to be that you’d build out a single virtual server with all the components required to run an application, and it would all be on a physical server, which sat in the basement. Things then moved out to the cloud, but it was very similar–only using a server in the cloud.
Now we’re starting to break up those components and defining sets of micro services; rather than putting everything together in a single server, you’re relying on external providers and containers to provide services for you.
I think more things will be going this way, and at a larger and larger scale. It gives you more consistent building blocks to construct systems. Before, you had these low-level components you had to manage and configure individually. Now, you have a more abstract way of thinking about the service components.
Containerization also allows you to have a higher density of services on a set of resources. You might be able to do more with your physical server capacity because you can use the available resources more efficiently. You’re only allocating what you actually need.
We’re experimenting with this internally so we can understand how it works. Right now, the technology isn’t ready to be used for production, but we want to be ready for when it is.
What do you like to do outside work? Why?
I like to cross-country ski. There’s a race in northern Wisconsin called the North American Birkebeiner, which is 55 kilometers long. I do the shorter version called the Kortelopet (“Korte”), which is 24 kilometers and takes about two hours. Someday I’ll do the longer one. Last year, I did the 27K North American Vasa in Traverse City; the wind chill was -20 degrees that day.
I also like to hike, especially in the Canadian Rockies in Banff National Park. I like outdoor physical activities because they give me a break from the intensive mental work that I normally do.