Lisa Hagemann

“You should go into computers!”

Hi, my name is Lisa Hagemann. Back in high school, my mom always wanted me “to go into computers,” but since it was the early-mid 80s, we didn’t have one at home, and the internet (as we know it) was just a gleam in someone’s eye.

When I was in college, I was a Communications and Journalism major, but we were required to have science credits, and I realized that computer science could fulfill those credits. That’s where I picked up my first computer science classes, but Temple wasn’t exactly on the bleeding edge of the comp-sci world. My first classes were Fortran and we wrote all of our programs on punch cards, I loved it (even though I was always worried I was going to drop my cards—if you did, you were screwed).

By the time I graduated, I was only two credits shy of minoring in computer science and programming. I used all of the programming classes to fulfill all my electives, and as part of my journalism major, I got into desktop publishing in its infancy. It was like the first breaths of graphic design, computer-aided design, and layout, which naturally led me to web development. I started working for the New York State Division of the Budget building out web pages and sites, all of that front-end work, and then I discovered regexes and Perl. The rest is history, and my Perl knowledge would help me out when joining a small, bootstrapped company called Dyn. 

Joining Dyn (the first time)

When I joined Dyn, there were only eight of us on the engineering team, and if I’m remembering correctly, I was employee number 15. Dyn believed a lot in making everything consistent across the board. So everything was in Perl all the way down, down to our web app and ticketing system which were in Mason. All of our servers were also running FreeBSD, so that anyone could administer any server. It’s like with Southwest Airlines: if all the airplanes are the same, everyone can fly all of them. However, even though FreeBSD was the most efficient for Bind, it turns out it was not the most efficient for MySQL. 

I’ve seen building in one stack work for smaller environments and startups, but it didn’t work when we got bigger and started to scale. It didn’t pan out from a technical perspective because engineers and operations folks aren’t just cogs you can plop into a spot to fill it. People have expertise, different interests, different personalities, and different ways of thinking. Just because the whole stack is the same, doesn’t mean that there won’t be disparities between individuals working on different projects.

Dealing with incidents early on 

As a wannabe operations engineer, I quickly realized I was more of a developer when I would watch wide-eyed as our true systems engineers did their magic. What I learned in these beginning days at Dyn was many of the things that today are just table stakes around having good metrics and having a good way to visualize them. There are so many third-party tools and startups that are doing incredible things now that we had been trying to build out at Dyn on our own, which wasn’t our core competency. We used a program called Munin that delivered a static graph that was downright painful, so take advantage of the new tools available to you to have better tracking and visualization of metrics. We take for granted how easy it is now to have infrastructure as code by checking code into Git so people can see the history, review it, and approve it instead of needing to call someone that’s halfway around the world to go to a server and turn it off or on. 

Being a technical co-founder

In my hiatus from Dyn, I was the technical co-founder for two different startups, and it was tough. One of them wasn’t successful and was greenfield so I could do whatever I wanted, but it was only me doing all the technical work. We were less than bootstrapped, and if I didn’t personally do something, it would never get done. So a lot of stuff didn’t get done.

I was then the technical co-founder of Open Rounds at the same time I had returned to Dyn, it was my side hustle. It was much better funded, but I was still predominantly on my own. I was able to hire some contractors to do the true, hands-on-keyboard stuff and I could focus on the operations. What I found is that when I operated solo, I cut a lot more corners. I didn’t pontificate about what would be the best way to do things, I just decided what to do and did it even if it meant I had to run a script every day to get the backup shipped to s3 until I had time to automate it. When I was the one having to execute, I was willing to take on the tedious work to get it done instead of pushing to make the process better.

Open Rounds remained a side hustle for the entire time I was with them until it got to a point where it needed more of my time than I was able to give without receiving a paycheck. I had to make that call with my cofounder, so we found another person who was able to make time to do it right. Open Rounds is still chugging along leaning on the same things I built—I still get emails every month from a deadman switch that tells me the data backups are still getting shipped across the country! Leaving Open Rounds worked out well timing-wise, as Dyn was going through a period of extreme growth and then we were acquired by Oracle. 

Returning to Dyn and moving to Oracle

When I went back to Dyn in 2013, it was eye-popping to see how large the company had become and how fast everything was. There were still some operational growing pains as the company tried to balance legacy systems with new functionality. The difference between the two systems was quite jarring, and we started putting everything (even things that didn’t necessarily need to be) in Docker.

Then there was the huge, shocking announcement that we had been acquired by Oracle. Well, we had known there was some kind of acquisition going on because we had been  in a room doing licensing audits for 2.5 weeks; that should have been a good hint. More specifically, we had been acquired by a smaller venture within Oracle called Sparta that was looking to build a cloud within Oracle—all of our combined forces would then become OCI.

Coming in, there were more Dyn people than at Sparta, and we spent a year thinking that we were going to bring the Dyn culture and processes to Sparta. However, even though we outnumbered Sparta, we were only a third of the size of Oracle in Seattle. Overall, one of the biggest challenges we had was taking our build processes and the way we access our servers and making that fit into the prescribed tooling from Oracle, but being some of the first people on the ground at OCI was amazing. 

Joining up with OCI

It was fun as an engineer to be one of the first people at Dyn to deploy services onto the OCI Cloud and write Terraform against the OCI provider that was being developed as we were using it to deploy so many different things. I also deployed the entire infrastructure for the OCI email system within the first couple of months and that was the first Dyn service that had been moved to OCI. It was both a pleasure and very frustrating—not everything worked because all the API calls were not in the provider, and at the same time we were trying to deal with that we were trying to make the infrastructure as code reusable and followable for others. Most of what I did at Oracle was leading folks down the path to deploy into OCI. I always tried to leave a breadcrumb trail, but the birds kept eating it all so it was hard to establish pathways. 

Sticking with DNS at NS1

Ever since I started working with DNS, I got a thrill out of knowing that any time someone picks up their phone or opens their laptop, the first thing that has to happen is a DNS call that has to be resolved. I’ve had the absolute honor and pleasure of working at two companies where I know that the work we’re doing is being touched by every single person on the planet every single day.

NS1 reminds me a lot of Dyn right before it had its growth spurt. It’s not even DNS at this point, it’s connecting people to the things that they need to do and DNS is just the protocol by which we make that happen. It’s all about the excitement people get out of everything from seeing funny cat pictures to operating banking and medical equipment. At NS1, we’re on the verge of bringing forth some new cloud services that bring the internet edge closer to the end user, connecting applications and audiences to help make people’s lives delightful.

Lisa recommends

One of the authors I’ve been most excited about recently is Joe Hill. “Joe Hill” is his pen name, because he’s Stephen King’s son. I heard him speak on NPR’s “Writers on a New England Stage” and he was fabulous, so I started reading/listening to all of his work. The book I enjoyed the most is called The Fireman. Even though it was written several years ago, it’s a very timely story about an invisible plague, so you don’t quite know who has it, and how people band together to survive. It’s cool because the plague causes people to burst into flames. Definitely a little bit of Stephen King influence there, I think.