#scalesf twitter legends

[bythebayio]

Marius Eriksen at Scale

1. When did you start at Twitter, and what part of the stack were you responsible for initially?

I worked at Twitter from the end of 2009 until 2016. I joined Twitter as part of their acquisition of Mixer Labs. For the first 6 months, I worked on Twitter’s geolocation stack and search engine; every since then I worked on all manner of infrastructure problems, particularly those that were relevant to ours moving off of the monorail.

2. How did this responsibility evolve, and what is the one main thing you learned to do best? What was the worst thing that happened to teach you that best thing? What was the best thing that followed your own mastery of your own best thing?

For better or worse, I managed to operate somewhat asynchronously (hah) with the various products and project teams. I took on a number of very concrete projects, but also stayed involved in everything from architecture to engineering governance. Part of that is the nature of doing infrastructure work, part of it was just following where the hard problems led me.

What did I learn to do best? I would say that over time, I learned pretty well how to “sell” a project or technology to the larger organization, to not just convince others to join what I believed were important efforts, but also convincing various customers to sign up for dependencies to new and unproven technologies that they may otherwise have hesitated to do.

3. How did this thing lead you to starting your own company, or doing what you’re doing now?

I realized that health and biotech are underserved by “modern” engineering, and that computing is key to the field. What’s more, you get to apply yourself and what you’re learned elsewhere in industry to challenging and interesting problems that at the end of the day help improve or even save lives. That is ultimately a very gratifying way of working.

4. How does your link in the chain relate to others’ on the panel, whom do you need the most, who needs you the most, today and in the wonderful world of tomorrow? If you don’t need anybody and can power a whole Twitter by yourself, it’s OK to say so!

At Twitter we set out to transform a very, very large service from a more traditional LAMP stack to something more scalable and cost efficient. While we weren’t the first to do so, we more or less started with a clean slate: mature open source infrastructure was far behind at the time. We all played different roles in bringing to life (and ultimately open sourcing!) the infrastructure required to make this happen. In hindsight, what was required was quite astounding. The different pieces more or less fell in place at the time—it felt obvious (at least in hindsight), but engineering is about 1% about the idea, and 99% the hard work required to make it into reality. Five or six years later, we’re in a much better place, but there’s still a lot to do. I view what William and Evan is doing in a way as refining and simplifying what we’ve learned so far: in general, complexity trickles down the stack, this way we can concentrate our limited capacity of complexity in fewer places, and leverage it more fully—that is what companies like Buoyant and Fauna are doing.

5. We all know without a doubt that you create the best tools for building and running large-scale distributed systems. But the world is full of hype around software sales. How do we cut through all that with our technical excellence, strong communities, and pithy tweets? What do we need to do to achieve greatness, adoption, and acceptance of the lessons encapsulated in our systems?

Well, these are leading questions. Are you sure these are the best tools? I’m not. But I see your point about enterprise software.

One big issue is that the problems that are solved by infrastructure for large-scale systems usually only show up in … large-scale systems. It’s not always evident why you’d need something big and complicated like Aurora or Finagle when there are alternatives that are deceivingly simpler (or more trendy, or whatever). However, when you are faced with scaling or reliability problems, you’ll wish you had them.

So how do we evangelize it? First by acknowledging that we shouldn’t advocate using the wrong tool for the wrong job. Second, by really emphasizing the hard-won production lessons that are embodies by these systems and stacks. Ultimately, that’s about education—blog posts, talks, conferences. We should work to emphasize and celebrate how software works, and conversely to de-emphasize snazzy demos and manifestos.

6. If a smart, well funded CTO comes to you and asks you to put together a SMACK-like stack from the systems you provide, how would you structure that architecting process – elicitation of needs, assessment of scale, SLA needed, development process, etc.? What does this process of aligning with customers look like now? Would you partner with other folks from this group on arhitecting it?

Ultimately it depends on the needs of the organization. I think that, generally speaking, such a request (“put together a SMACK stack”) is much too prescriptive—it’s always important to understand what problem is being solved, and within which constraints: what is important, what isn’t?

I think that a useful maxim is: try to spend as much of your engineering budget (cost, complexity, resources) focused on solving the problem that your business is about: i.e., what does the organization have to be uniquely good at in order succeed? The rest is less important, and should be outsourced as much as possible. That’s not always possible, of course, but it’s a good rule of thumb.

7. What is the best thing you give the community, and where do you need the most help?

For the last year or so, I’ve been busy working on new approaches for large-scale cloud data processing. We’ll be open sourcing some of our work very soon, and I’m looking forward to re-engage with the open source community.

8. What is the best thing you love about SBTB, and what are you looking for the most going there? Which talks on the program do you want to see most of all?

I love how interdisciplinary SBTB is. It’s nice to see deep work across a number of different fields, discussing everything from compilers to machine learning. I’m particularly looking forward to the talks about cloud data processing, data science, and machine learning, to see how others in the industry are approaching the kinds of problems I am now involved with daily.