Elaine Uy is a senior software engineer here at Tapjoy. Last week, Codeship did one of their "Inside Look" Interviews with her to talk about turning a monolith into an SOA, what “senior engineer” even means, and why programming classes as a high-school requirement are probably a good idea. The body of the interview is included below, or you can go read it on Codeship's blog here. Below are just a few excerpts from the excellent interview!
You're a senior software engineer at Tapjoy. Can you tell me a bit about what you're working on right now?
Sure. I am the tech lead for the Content Team, so I’m responsible for the technical architecture. Tapjoy is an advertising company, so very specifically, I am working on the actual ad content and delivering that.
I make sure that everyone has the right work and that we’re working on the right things to accomplish the greater team goal. My concern is specifically the technical architecture and the things that we are actually producing.
When you first joined Tapjoy, you were part of a team that moved your internal architecture from a monolith to an SOA. Can you talk about the challenges you ran into there?
The analogy that I like to give about doing this kind of work is imagine you have a very fast-moving racecar and you want to live-swap the engine out. That’s kind of like what that work is like. It’s actually really exciting and kind of terrifying — but really exciting.
We started out pretty conservatively, and of course we didn’t just live-swap code. That is always a bad idea, so we had tests in isolation. We had ways to run basically test tube tests, both the new code that’s going through a microservice versus staying in the monolith. There was a lot of isolation code work that had to be done and tests that had to be rewritten, and it was a process, that’s for sure.
But it was time for it, and it needed to happen. One of the things you’ll find when you are in a early-stage startup is you’re trying to iterate as fast as possible and trying to put out as many features as possible to sort of get into your Agile stride, right? You’re not doing anything at scale, you’re just trying to get users or whatever metric you’re judging your growth by. You usually do that all in one application, right?
Tapjoy had actually grown to the point where it was cumbersome to have everything that we were doing — and there were so many things that we were doing -- under one roof. It didn’t make sense anymore.
One of the most important lessons that we learned while we were breaking up into microservices was that you should only do it when the amount of work put in is worth the output that you get back. So, the first two or three that we did made sense, but as we started getting into the more nitty-gritty, integrated, hard-to-unwind bits of code, we actually realized that we needed to back off. That would be more effort than building on top of what existed. So, there was that interesting tradeoff we had to make.
If you'd like to hear more from Elaine, be sure to check out the full article here!