Hey everybody, so I'm Marc Imbriaco, and I hope you like my clickbait title. They asked me for a title for my keynote,

and I tried to come up with the most sort of obnoxious and annoying thing I could think of to say at a RailsConf. And it's funny, but it's also, well here, let me introduce myself. I gotta say thank you to Pivotal first. So I work at Pivotal, I've got this stupid title, Field CTO DevOps and Transformation. What that really means though is,

and I'll be talking about kind of the things I've learned over the past decade or so, since I got involved with Rails. And what I do is I go and talk to big companies and tell them how exactly the same things we were doing at 37signals and Basecamp and Heroku and others can work for them. So I get this fancy title so they'll actually listen to me.

And just to manage expectations about this talk. It's roughly half self-indulgent nostalgia for me. Another half-ish of thought leadering and then maybe accidentally an insight or two. We'll see, you can tell me afterwards if I was insightful at all.

So scalability, let's talk about scalability. Since my talk was theoretically about scalability, let's define that for a second. And I think this is actually, it's interesting because this is a term that often is not well understood. The difference between performance and scalability. Performance is sort of how fast you can go, right?

How fast can you go? Can you meet a response time for a specific number of users? And scalability is, if I'm adding more users and I've got more throughput requirement, can I just add more stuff to make it go faster? Can I add another server? Can I add another Heroku dyno? Can I add another Docker container? Can I make the thing handle more users

by adding another resource? So this is interesting because it applies to a lot of things. And we could talk a lot about kind of the details here. We could talk about universal scalability law. This is actually really interesting but we're not gonna talk about it right now. We will talk about the equal bang for the buck model here

which is linear scalability. So linear scalability is sort of what we're talking about usually. When people said Rails doesn't scale, they were talking about this. They were saying that you couldn't just add another server and get double the throughput. Linear scalability is sort of the utopian model, right? If one server gets saturated, I add another one

and things are, I can handle twice as much throughput now. Plot twist, Rails actually scales, it turns out. So I lied but I hope it'll stick around anyway. But the thing that we're gonna explore in the rest of this time I think is

the fact that linear scalability of technology is actually kind of boring, right? It's an architectural concern. Anything can scale. It's all about how you design your system and Rails doesn't preclude that in any way and it never has. Even when Twitter said Rails doesn't scale, they were wrong. We used to fight this all the time but the reality is linear scalability of technology

is actually boring. I'm way more interested in what are the resources, right? So if on the left we've got linear scalability of technology and I'm adding resources, I'm adding servers and I continue to scale linearly, are there things that I can add that'll let me scale sort of hyperlinearly, right? Can I scale disproportionately by adding resources?

And I think the answer is yes and we're gonna talk about that. And here's the reason why I think the sort of linear scalability in technical systems is not super interesting. It's because scalability is a characteristic of the system as a whole.

When we look at the systems, the systems that we run, there's a technical system, there's that Rails app that we built, but that's only part of the story. In fact, it's probably the least interesting part of the story. There's a whole additional social system that's attached to that technical system, right? This is your users, this is your system administrators,

hello, this is your developers, this is all of the social parts that sort of live around and with your technical systems. And when you put these things together, you get this thing called a socio-technical system and this is what is the most important thing to scale. I think for me personally, in fact,

I strongly believe that scaling on the social side is far more important and interesting than the technical side. So story time, I'm gonna kind of spend the rest of my time giving you a hopefully interesting, long-winded historical presentation of my life, I guess.

Especially my sort of work life and kind of the things I've learned along the way. I'll try to be remotely interesting. So 92, 92 is the date that I picked as the start because that's the year I graduated from high school and went to college. And it's interesting because it's sort of when I really got involved in systems.

My first job in college was in the fall of my freshman year in the CS department as a system administrator. So I've been doing this for, you know, David said 20 years, he was actually lying, he's not quite old enough for it to be 20 years. I say 25 and I'm underselling it, but we'll split the difference. And my story, like other historically great stories,

starts with a camel. In 1992, in fact, I was all about camels. I was about this camel, in fact. Pearl was sort of the first language that, it wasn't the first language I learned, but it was the first language I fell in love with. There were a lot of things I loved about Pearl.

The same things I see in Ruby today are what I loved about Pearl. Pearl gave me this power to be expressive. It let me do things in a way that felt natural. And it was sort of the natural language of the web at the time, right? If you're doing anything on the web, well if you're doing anything on the web in 92, congratulations, because we didn't have inline images yet until 93.

I looked this up earlier, I thought I was right. Mosaic 0.3 came out in sort of the middle of 93 and that's when we got inline images. And I loved Pearl because, there were a lot of things I loved about Pearl. It was this ethos around Pearl, right? Larry Wall is incredible. And he had this Tim Tody thing,

there's more than one way to do it. And that was the ethos of Pearl. And there was this pound Pearl channel on Fnet, which was sort of the manifestation of community at the time. It was a relatively toxic and neckbeardy community, but it was a community. It was not at all as friendly as what we have today, which is interesting, but I still loved it

because I felt back in 1992, 1993, you sort of felt like a magician, right? When you're working on the computer, there's very limited documentation. You can't just go get books everywhere. Hell, just getting on the internet was an accomplishment. So here I am bending the computer to my will. I'm the CS major and I'm writing this horrible code

that nobody else can read and it's full of regular expressions and I'm loving every second of it. And I got involved in the Pearl community for a long time. And Mod Pearl was my sort of first foray here. I dropped out of college in 1994 and started a company. And it was a web company, so we spent more time,

this was in 94, we spent more time telling people what the web is than we did actually earning money. But so it goes. And I got involved in this Mod Pearl community and this was the first community online that really felt like a community to me. I ran the mailing list for this and I was heavily involved in this community for a long time. I went to the Pearl conference, I spoke.

I went to the first two actually, or the first three. And it was a ton of fun and it was a great time in my life. But this startup, eventually when you spend too much time explaining what the web is and not making money, life comes at you fast and you have a couple kids. And suddenly you have to figure out

how to balance these things that are fun and interesting to you with feeding your children, right? Having a good life. So I left the startup that I founded, I went to work for a bank. Don't recommend that. In fact, I've turned down another offer at a bank since then, so I don't recommend it.

But I learned a lot. And the thing I learned here was that you have to care about what you do, right? Just making that paycheck's not enough. So I didn't last very long there. And I had some other jobs along the way. I worked at America Online for a couple of years, which sounds crazy, but it was actually awesome because I was running the largest websites on the planet.

And we were carpet bombing the world in CDs and making cool sculptures out of them. So that was cool, right? That was fun. We had an unlimited budget and more internet that we could use. I had a 100 megabit connection to my desk in 1994, or 1998, right? It was unbelievable.

And then I left AOL. And I left AOL because my family was more important to me than living in, Ernie talked about this a lot just before me, and Ernie kind of stole my thunder a little bit, which was great, because I'm hearing recurring themes and I like it. AOL had this culture that had to be in the office,

and the office was in Northern Virginia, and for anybody that lives in Northern Virginia, I'm sorry. It's not much fun, right? It wasn't for me, it wasn't for me. I know people that love it there, but I don't know how. So we lived there for a couple years, and we just decided that we wanted to be with our family again, and we wanted to move back.

And life came even faster, right? So Facebook move fast and break things. Well, I had four kids now. I had to move fast with stable infrastructure. So I had to have a real job, and this sort of led to what I call the Java years.

So this is the real application that I built, and honestly, we laugh about the Java years, right? But I'm incredibly grateful for them, because this was a time, think about sort of 2000, 2001, the dot-com crash. I spent all that time in the dot-com downturn

employed at a startup writing Java, so I got the right, and I worked remotely. Now, I was building software to do estimating repairs on heavy trucks, but hey, you take what you can get. So I was grateful for those years, but there's a downside.

So the Java years were great. It let me move fast with stable infrastructure. Actually, it let me move slow with stable infrastructure, but it was valuable, except for the fact that I grew to not love coding anymore, and this was a huge bummer, right? Because this was a big part of my life.

I knew the entire time I was growing up that I was gonna work with computers, right? When I was a kid, you didn't really know what that meant, but I knew that I wanted to write code, and I knew that I wanted to work with computers in some way, and here I was. I don't know, it was 2005, so I was 30 years old, 31 years old, and I just didn't love coding anymore,

and it sucked. My whole life was around coding, my whole professional life, and I didn't wanna do it anymore. So I started looking for outlets, and I went to this conference called No Fluff Just Stuff, and this was sort of kind of an elitist, right?

It was a weekend conference, and their pitch was, you know, you only go to this thing if you really care about getting better, but it was for sort of the dark corners and the nerdy bits of Java when I first started going, so it was sort of the right way to think about it. And I went to this thing for a couple years, and it helped, but one time I went to this talk

by Dave Thomas. Dave was a regular on the No Fluff Just Stuff circuit. He was talking about Ruby, and I went and sat down because I'd been to this thing several times. I'd seen most of the other tracks already, so I went to Dave's talk, and Dave started talking about Ruby, and I was sitting in the, I remember it like it was yesterday, I was sitting in the front row and watching,

and I just, my jaw hit the floor, right, because I was looking at Ruby, and I was seeing Perl, and it brought back all the same feelings that I had when I first fell in love with coding with Perl, but it brought objects and these other things that I had grown to actually think were valuable along the way as well.

And I'd been, you know, you'd seen lots of conversation about Rails at the time. This was 2005, so we were at the very beginning. David was being antagonistic towards everyone in the universe about Rails, which was great. And we were all skeptical, which was great.

And then I went to this thing, this talk from Dave, and it just blew my mind. So I went back to my hotel room that night, and I wrote my first Rails app. And this is what I loved about Ruby when I first saw it. I'm not even kidding, right, when I watched Dave talk about Ruby, and he started doing this crazy

opening of class and adding methods and shit, I was like, what is happening? This looks like Perl. This is amazing. I can do all kinds of horrible crap that no one can ever understand. Yes, these are my people. And I got a little obsessed.

And I started reading the 37 Signals blog. And I started learning more about Rails. And I somehow, I still don't know how, convinced my boss to let me, we had a new project that we had to start working on. And I guess I was sort of the lead developer at the time and I convinced him to let me build it in Rails, which I had known for like two weeks.

And it was amazing, and it went shockingly well. In fact, it went so well that I convinced him after we did that for about a month to let me rebuild the thing that we'd been building for four years in Rails. And we did it in four months. And it was way better.

That company was called Decisive, and I specifically want to shout them out because the faith that the CTO there, Satish Joshi, had in me to let me do that changed my life, because that's what led to me working at 37 Signals, and it sort of set the stage for the rest of my career. They're still using Rails. In fact, someone from our community, I don't know if it's public, yes, I won't say his name,

but someone from this community that many of us know just started there as their VP of Engineering yesterday, literally. So this is awesome. They're still in Rails. I felt a little bad because we finished build and transitioning this big app to Rails. But along the way, things sort of escalated kind of quickly.

We were finishing this thing up, and we had deployed this new version of the app like two or three weeks before 37 Signals posted this. And they escalated really fast

because I was really excitable. And anybody who knows me knows I tend to be, especially when I write, very long-winded, I have to struggle to write things briefly. Anybody who's ever read one of my post-mortem's knows this. So 37 Signals is looking to hire a system man, and I read this job posting, and I should have posted it here, and I was like, oh my God,

this job posting was written for me. And I was on a vacation with my wife. We were in New Jersey watching my sister-in-law finish post-guard basic training. So we were there for a graduation. And I saw this post, and I looked at my wife, and I was like, I gotta go for this. So I pulled my laptop out.

I wasn't looking for a job. In fact, I was happy for the first time in a couple of years because I was doing the Rails stuff. It was super fun. But then I saw this, and I just knew that it was what I wanted to do. So I wrote this email to David that basically said, hey, you should hire me because I know all these things you asked for, plus I know Rails. And I don't have a resume because I wasn't looking

for a job, but here's 1,300 words about why you might like me. Oops. Sorry, David. I read it. I read this, my email to him again when I was working on this, and I cringed. But I guess that's the way it goes. 1,300 words on the fly from a hotel room sitting in bed on my laptop. It was insane.

I'm shocked that I made it to this. So let's look at the dates again because it's interesting. So I sent this email August 17th, and a month later, I was at 37signals.

And it changed my life, and that's not an exaggeration. Almost everything since then in my career I sort of owe to my time there, and to David and Jason and the team at 37signals. And it's not just technical things. It's not that Ruby on Rails was the remarkable

part of all this. It was the people, and it was the people in the Rails community, and it was the ethos that David had and that everyone in the Rails community had this desire to enable everyone. David, his talk this morning really touched me because it's exactly what I care about.

This idea of broadening the base, bringing people in, making people feel empowered to develop things, the lessons that 37signals shared stick with me. But the reality is we had no idea what we were doing.

2006, and we had the first part. We had this whole, you could build a blog in 15 minutes, and you could maybe get it running on some hosting provider in three or four days. So we still had some ground to cover, and we didn't really have much idea what we were doing.

The way that I describe myself technically is I'm a mediocre developer, and I'm really good at troubleshooting. So I think I'm probably, I don't know, I'm very good at troubleshooting and solving problems and breaking things too. So I guess those things go together. So we were figuring things out on the fly, and it was fun, but it took a village.

It took a bunch of people working together. The Engine Yard thing choked me up a little bit because I saw Ezra's name. And Ezra, one of the founders of Engine Yard was, you know, he and I were, I guess, the two people who were sharing the most about how to deploy and manage Rails apps

of any size at the time. And I learned a ton from Ezra, and I like to think that I helped spread knowledge as well. But the reality is it took all of us working together to compress, do this conceptual compression, right? We needed to simplify what it meant to run a Rails app. We needed to make this knowledge accessible to everybody.

Now, we didn't really know how to automate that stuff yet. We didn't really know, we didn't have Heroku yet. We'll get to that in a minute. But we knew we needed to make it simpler and we needed to enable people to be able to run this code, right? So we spent a lot of time writing blog posts, and we spent a lot of time sharing, and I wrote postmortems and blog posts

about HAProxy and experiments and Erlang and tons of other topics. And I spoke at conferences, although, hilariously, I joined 37 Singles 12 years ago, and this was my first Rails Conf that I've spoken at. So this is really exciting for me. So sharing is the thing that enabled the community

to move forward. And we spent a lot of time dealing with the sort of flip side, right? It's, okay, great, we've got this Rails app built, but why is Twitter fail-wailing all the time? Rails can't scale. Rails is too hard to deploy. That'll never work in the real world. You know, we got this at 37 Singles all the time

because we were very unapologetic about giving advice. And we didn't use weasel words to surround that and say this depends because we assume adults recognize that it depends. And you have to deal with this. And the way that we deal with this in the Ruby world is, I think this has been lost a little bit along the way

and I wanted to bring this up specifically because this ethos we had in Ruby at the time was MOTS is nice so we are nice. And this picture is my son from the Life Comes At You Fast when he was, I guess, 11 or 12 years old at RubyConf in Orlando and he had just learned Ruby.

And I said, hey, let's go take a picture with MOTS. And we walked over and MOTS was gracious enough to take a photo with him. And this sort of ethos of being nice and of sharing and of community, I think is what makes Rails special. So I talked about technology and scaling not being super interesting but the reality is

if you want to look at some of these resources that if you add, you get a disproportionate return. Community is one of those, right? If you share something in the community, you're not helping one person. You're not getting a linear 1x lift on that curve. You're getting a multiplicative effect. So by contributing and participating in the community, like all of you are here, by the way, thank you.

When you share with the community, when you make connections with one another, when you help one another, you are making that scale become this hyperlinear growth that we're looking for. So community scales. So I spent four years at 37signals and it was amazing.

And I ultimately decided for a bunch of reasons that it was time for me to move on and do something else. And the thing that I had discovered about myself that I was passionate about and what's really driven my career since then was this idea of enabling people. In particular, enabling developers. I was excited when David did his software is eating the world Pac-Man thing because I trot that line out all the time.

Andreessen was right. It's kind of a meme at this point almost, this whole software is eating the world thing, but it's really true, right? If you want to have an impact on the world, you want to have the best return on your investment. If you want to have disproportionate impact, software is the place to go, whether it's positive or negative impact. So to me, this idea that I can enable other people

and I can help shift that scale better than linear is what's driven me. So in 2010, I joined Heroku. Yikes, I don't know what I just did. Hang on. We'll get back. Oh well, we lost the slide, I think.

Sorry, we'll figure it out. I'll just skip. So I joined 37signals, I mean, I joined Heroku. And these two slides that you see here are talks that I've been giving

to pivotal audiences lately. In fact, this was from a keynote that I gave at DevOps Enterprise Summit to, I don't know, a couple of thousand people that worked at Fortune 500 and Global 2000 companies who are doing the DevOps, right? And what's interesting to me is that all of the lessons I've learned here, these were lessons I've learned at places that I've worked since 2010.

So I've been really fortunate. I worked at Heroku. Heroku sort of hit me right in the fields with this enablement story, right? Heroku solved that, it takes three or four days to run your Rails app problem, incredibly beautifully. And I spent a couple years at Heroku. And I learned a bunch of things. And then I went to LivingSocial.

Yep. I went to LivingSocial because Chad Fowler is an evil genius and he somehow convinced me to go to a daily deal site. I still don't know how he did it. I think it was all the people there. There was a bunch of amazing people there. So I wanted to go hang out with my friends

and get paid for it. And that's actually kind of cool. Then I had the chance to go work at GitHub. And again, this story of enablement and community sort of rings through. And then DigitalOcean. And the thing that's interesting and what I like about this talk that I gave at that event was that these lessons are things that are very familiar to you if you read Getting Real.

And if you've sort of read any of the blog posts in our community. And what I love about this is that in 2006 and seven, eight, and nine, we were being told all the time, that won't work in the real world. That won't work at my company. And now we've got people paying a lot of money for us to tell them the same thing we've been telling them for a decade. And they believe us now.

So it turns out that these lessons that we've learned in the Rails community and in the various communities we've been a part of and have learned the hard way and we've been told over and over again aren't relevant to the real world. They're all very relevant. And then I left DigitalOcean.

I'll tell a quick story here. This one, apologies if I get emotional here. Operable is a startup that I founded in 2000 and I guess 2014 maybe, whatever. Three years ago, whatever that was. 15 I guess, so 15 and 16 I did it.

And the reason I did it was because of someone in our community. And this is the part where I make it emotional. So I've been working at DigitalOcean and DigitalOcean was in New York. And I spent my first six months at DigitalOcean I spent 30 days in a hotel in New York. So I was spending a lot of time in New York.

And I had a friend who had recently moved to New York, James Gollick. And James and I had sort of known each other in the community for a long time. James was very active in our community. For those who have been around for a while I'm sure you know who he is. And James was very active in sort of the system side and the scaling side and the operability side

of Rails much like I was. And we became closer friends. But the thing that happened that sort of led to me finally taking a chance on my startup was over the holidays in 2014 James passed away unexpectedly. He was in a car accident and in a taxi and he and his fiance unexpectedly died.

And it was interesting, I had a response to this personally that was disproportionate to how close we were as friends, I felt, right? Like we hung out when I was visiting New York but we weren't super close friends. But what really struck me was sort of the fragility

of life and the thing that really struck me was that James was, his sort of ethos was give a damn about what you're doing, right? And care and contribute the way that you think you can deliver the most value to the world. So I spent a lot of time thinking about this over the holiday break and the first day back

from the holidays I quit my job. Because I was convinced that the place where I could have more impact was by delivering something that I cared more about. So I founded a startup beginning of 2015 and life came at me really fast and I raised a bunch of money and tried

to build some things that I believed in. We built a product and long story short, when I give this talk at other events, that last bullet I close the doors fills in later. But the long story short part is we failed. And that's okay, right? I say this when people get mad at me sometimes

when I say we failed. But I'm very reflective about successes and failures and I try to be honest with myself about them and learn from them. So when I say we failed it doesn't mean that I'm a horrible person or that I didn't get anything valuable for that time. It just means that we didn't do what we set out to do. But I wouldn't trade that time for anything

because I learned a ton. And interestingly, some of the things I learned were some of the things that I already knew. So those who don't learn history are doomed to repeat it in their next conference presentation and knowing is only half the battle as we all know. The other half is red lasers and blue lasers.

So it's like these things that I learned, this whole make tiny decisions and sort of fighting hero culture. I learned these things with all the 37 signals. But suddenly I'm doing my own startup and it's like yeah, well that's like your opinion, man. Like I can be a hero if I want. I can work 100 hours in a week.

You're not my real dad. You know, I can have a nervous breakdown. And these things I learned at Digital Ocean, these lessons, you know, sort of around MVPs and feedback loops. And I'm like well, you know, this thing we're building is really complicated though. I can't just start with a piece. I gotta build the whole thing.

It turns out not so much. So these things, just because you sort of have learned the lessons before doesn't mean that you're gonna remember them when you need them. But for me, the best way to, I don't have my next slide, beautiful, yes. I love it when a plan comes together. The best way to remember these things

is to teach them to other people. Which is why I've been repeating these lessons to people every chance I get. Because the more I tell other people the things that I've screwed up, the less likely I am to do it again. And the last thing I want is for someone else to have the experience that I had where I didn't listen to myself about hero culture. Because I grinded as hard as I could

on this startup for two years. And I can tell you the exact moment I hit rock bottom. There's a conference called Monitorama. It's one of my favorite events every year. And we were sponsoring and we'd been working on a demo. And I worked 110 hours the week leading up to that. My flight was Sunday morning at like 7 a.m.

to the West Coast. And it was 2 a.m. the Saturday night before that. And I was still awake because I was working. And I finally got to the point where I knew that I wasn't gonna be done. There was no universe in which the demo that I wanted to give, I could give. I had to do something else. And I finally sort of threw in the towel,

walked downstairs to my bedroom, and I'm standing in my room in the dark knowing that I need to go to bed. And I just stood there and I started crying. Because I was just done. I was so exhausted and emotionally drained from this experience of this abuse that I'd put myself through that I just didn't have anything else in me.

I was numb for days afterwards. It was the low point in that experience. And the worst part of it was, it wasn't so much that I put in the effort and failed. Like I said, failures, it happens, right? I don't like it, but I wanna learn from it. If it's gonna happen, at least I wanna learn from it. The thing that really upsets me though is that I already knew that lesson.

And I did it again anyway. So sharing these lessons with one another not only helps other people, it helps you too. So teaching scales, just like participating in the community, scales. If you can teach one person and they teach someone else, or if I can teach a room full of people these lessons, maybe I can have a real impact.

So we started with this, how do we go from linear to hyperlinear? What's that piece, what's that question mark? What's the resource that we can add that helps us scale in a fundamentally better way? And to me, and I've heard this throughout the day from other folks and I'm super happy to hear it.

To me, you are that question mark. Everyone in this room is that question mark. Everyone in this room is the resource that helps us scale. Whether it's the community, whether it's the technology, our socio-technical system as a whole, you are what makes it scale. You're what makes it recover when it fails. You're what makes us learn so we don't have to repeat the same mistakes.

You are the thing that helps us as a community as a world scale. So people are what scales systems. Not rails, not technology, people. That's it, thanks.