GP - Fotolia
Natasha Litt was happy to take a break from her management position with New Relic Inc. to do some hands-on software engineering, her real love. This welcome change-up came with a price, however. Litt had to bone up on a new-to-her technology, Docker containerization -- and do it quickly.
Litt reflected on the potholes -- such as handling dependencies and legacy errors -- she ran into on her drive around the Docker containerization learning curve. Litt is a software engineer, internal business intelligence and analytics for New Relic, a software analytics and application performance monitoring software provider based in San Francisco. She came to SearchSOA's attention as a panelist on the session, "The Cloud, Containers and Microservices," at the 2016 Lesbians Who Tech Summit in San Francisco.
Recently, you moved back to hands-on software engineering with Docker after a term in IT management. What surprised you?
Natasha Litt: Ramping up quickly on Docker containerization, I was a bit surprised by the new world of how code gets from your laptop into a useful lifetime in production. The days when you got your app up and available by getting 40 pizza boxes and racking them are long gone. I had to get a better handle on how to take code from something that works on your laptop to something that's actually out there in the world, in the cloud and elsewhere, serving people. Oh, and doing that in an automatable, repeatable, reliable way.
What is the allure of Docker containerization?
Litt: I asked that myself when I was first introduced to it. Until I got elbow-deep in it, it was hard to discern. Now, I know that Docker containers are just so lightweight. Containerization is just so fast. I can do it in minutes, instead of hours or days, like it used to be. So, that's really nice.
Could you explain why you can build and provision apps on Docker containers faster than you could in the past?
Litt: Back when I was a sys admin and racking pizza boxes, and that sort of thing, one of the things I also did was build base images for those servers. Provisioning a server might take a week. I had to use Altiris, a deployment system, and install the [operating system] from scratch. Then, I'd make an Altiris backup, which took hours. Next, I'd install applications on top of that and take another Altiris backup, etc., etc. The process just took days to unfold.
With Docker containers, I can easily build on top of what other people have already made. It's very easy to go in where somebody's already installed Python, and install Ruby on top of that. And then, it's easy to take the Ruby-Python combo image, and install your own app on top of that. And then, it's easy to take that app and install your own plug-in on top of that. Also, I can go back farther down in the stack to something that didn't work out and change it.
What was the hardest part of boning up on Docker's container software?
Litt: The tricky part? Well, once your application is running in a container, there are all these things that you take for granted in your own environment that don't exist in a container. It's different if you're writing an application from scratch for Docker. I haven't done that yet, so much. I've taken things that are already working and helped them pour it over to Docker containers. So, I have to get around the learning curve to writing from scratch.
What challenges have you encountered when moving an app to Docker containerization?
Litt: If you have something that's working and start to move it into Docker, you discover all the things that you've taken for granted. Maybe you took it for granted that you could write it to the temp directory. But you can't do that necessarily anymore.
You take it for granted that the environmental variables have this and that already set up, but they don't. And so, you have to go through and discover each dependency that you didn't really know you had. Also, it will throw some error, and you may have to, say, debug the app in the container. It is tricky to figure out how to capture the output of a Docker container, in a way that you could make sense of the error. You have to follow the iterative cycle as you take your application, start it up and run into an error. You have to figure what the error is, and why it's happening. Then, you fix it. And then, lather, rinse, repeat. I probably did that 20 times on my first Docker app. After that, I ramped up enough to be able to bypass those gotchas, but that was a challenge to begin with.
Virtual machines already do the job, so why use Docker?
Troubleshooting and debugging Java apps within a container
How CI efforts are affected by container technology