Framing Microservices

Link to Slides.

Richard: Great. Can everyone hear me? Is this thing on? Okay. All right, this is weird because I can see it on my peripheral vision. Anyway, thank you everyone for coming. Welcome. We’re super excited for the Microservices Practitioner’s Summit. And just a show of hands, how many of you guys have actually adopted microservices? Okay, so a good chunk, maybe half. And then how many of you are just learning about microservices and trying to figure out what you’re doing? Okay, so everyone thinks they’re an expert. That’s awesome.

Okay, so everyone, let’s have the expert conversation here. Okay. So just a little bit about why we’re actually organizing this. So at DataWire, we spent the past year talking to a whole bunch of companies that have adopted microservices or SOA for cloud-native applications is sort of some people don’t like the term microservices. They think there’s a marketing pejorative context to it. And one of the things that we’ve learned that was actually remarkable to us is that there’s a whole bunch of common engineering patterns across organizations.

And we thought it was remarkable because people have actually converged on solutions to problems organically without actually talking to each other. And so we thought that was really interesting. And what we also found was interesting is that people were really excited to actually share and learn more about how to do microservices. And so, and I used to, for those of you who don’t know me, I spent my past five years doing IT security type stuff. And in IT security, if you talk to some sort of practitioners, they don’t like to talk about anything.

So it’s actually kind of fun to actually talk to people who want to share about what they’ve learned the hard way. And so hopefully, by being able to put this together, was are actually able to share some of that knowledge directly from all these people that we’ve been talking to. So the agenda, I’m going to just talk for a little bit. Then Ben Christensen, he’s going to talk about why you shouldn’t build a distributed monolith. And then Nic Bender from New Relic will be talking about designing APIs with customers in mind.

And then Randy will be talking about building microservices ecosystem at scale based on his experience at Google and eBay. We’re going to have lunch back here for a little bit. And then after lunch, John and Joseph from Yelp will be talking about some of the organizational aspects of SOA. Yelp, for those of you, for the record, they don’t do microservices. They have a service-oriented architecture. And then Tom Petr from HubSpot will be talking about how they maximize developer productivity.

Kolton from Netflix will be talking about how they have evolved their views around introducing failures into their development process. And then finally, very excited that Matt Ranney from Uber will be talking about how they’ve actually scaled from a single microservice to hundreds of services. And then we’ll wrap up around 4:00, and then we will have beer. And then slides and videos will be published. If you want to be notified when this happens you can register online at microservices.com. So feel free to register and we will send you an email.

And then, as Austin mentioned, if you want to tweet about any sort of pithy or not so pithy statements made by anyone we’re using the hashtag microservices. And speaking of Twitter, I was actually at a presentation a couple weeks ago by Alex Roetter. He used to run engineering at Twitter. And he actually pointed us to a tweet about microservices, which I thought was sort of apropos given sort of this area and hype around microservices. So this is an engineer at Twitter. And then I thought this was kind of funny.

And then I thought, actually, Alex Lambert’s response back to him was actually even funnier. Anyway so I think we’ve actually identified that you shouldn’t use Console or ZooKeeper or any of these fancy, strongly consistent systems which are really hard to engineer, and you should just use PagerDuty. So anyway, so I want to just talk a little bit about microservices and how we’ve actually learned and thought about microservices. There are lots of different, fancy definitions around microservices, but I think at its core, from a technical perspective, you’re basically building a continuously available distributed system.

And I think the approaches and practices around how you build distributed system with continuous availability are reasonably well understood, where you need to introduce sort of asynchronous type behavior, you need to think about failover, you need to think about back pressure, you need to think about sharding, all sorts of things. Not to say that this is easy. There’s hard engineering, but it’s actually well understood engineering.

The other thing about, the other sort of piece we’ve seen in microservices is it’s really around distributed development. You’re not actually having one development team working on one thing. You’re actually splitting your development team into lots of smaller development teams that are coordinated. And again, we, as sort of an industry, have a good understanding of what distributed development looks like and how you do it. Linux is a great example of distributed development at scale around the world.

And you have collaboration tools like Git and some sort of bug tracking system or some mailing list or all three. You create APIs so you have strong abstraction between each of your different components. You have unit testing and integration testing and CI systems, and all sorts of stuff to actually build, for example in Linux, a pretty sophisticated, pretty reliable piece of software. But I think in microservices, what’s actually interesting is what you’re actually trying to do is you’re actually trying to apply distributed development principles to building a continuously available, continuous uptime distributed system.

And that’s actually what’s newly hard, because if you think about how you’re collaboration tools, your APIs, you’re testing all these practices that you use for distributed development. They change when you’re starting to build a distributed system. For example, you can’t actually just think about local API semantics. You have to think about network API semantics. Testing on your laptop, you can’t just run a full integration test because your microservice might depend on 20 other microservices that aren’t running on your laptop.

If you think about your tools, you might use Javadoc to see all the APIs in your big, monolithic app, but if you’re using 50 microservices that are independently deployed and half of them are in Node and half of them are in Java, there’s no canonical set of APIs. So how you think about this, I think, is actually really evolving. And I think really, for us, what we’ve learned about microservices is that this is actually what the newly hard stuff actually is. A lot of the other stuff is, “Hey, let’s think about distributed systems and make sure that we’re actually thinking about asynchronicity.” And there’s lots of things around how do you add layer 7 back pressure and things like that. And those are all problems that require real engineering and thought. But the general principles are actually the same.

And so there’s a lot more learning, I think, around how do you converge distributed development for a distributed system. That’s a lot of distributed. And so we think of microservices as an architecture for building continuous uptime distributed systems with a distributed development model. And so I’m just going to make a couple points around how it impacts organizations or what we’ve seen, because in microservices it’s about decentralizing your decision-making to increase your velocity.

You’re trying to push as many decisions as possible to your leaf nodes, to your developers. And so if you think about your traditional model, you’ve got your pointy-hair boss, whether it’s your VP of Engineering, your Chief Architect, your CTO, whomever, saying, “This is how things are going to be done,” and then your developer is responsible for writing some code. And she doesn’t do anything else other than write some code. I think that when we talk to companies that are just starting to adopt microservices, the first responsibility or decision that the pointy-hair boss relinquishes to that developer is actually the ship date.

Because the developer is suddenly empowered to actually make the decision when the code is ready and when she ships. And so there’s a question around how do you safely do this. But that’s fundamentally, what you’re doing is you’re transferring responsibility from your pointy-hair boss to your actual developer. And then over time, it’s not just about ship dates. You’re actually giving the developer, or her team responsibility, or decision-making authority, maybe, around testing standards or the tools that they’re using or how they do code reviews or maybe ultimately how they think about persistence or what programming languages they use.

And maybe you don’t delegate all this responsibility to the developer, but fundamentally we think about microservices as a shift in responsibility, and we think about when we look at organizational maturity around adopting microservices, it’s about how you’ve actually moved and adopted the decision-making from the pointy-hair boss to the developer. And so we think it’s interesting. And so if that’s the case, then what’s the role of the pointy-hair boss, because the pointy-hair boss can’t just sit there anymore and say, “That’s not how it works,” because they’re not supposed to do that anymore.

And so just a few sort of observations around how to become an enlightened pointy-hair boss, if there are any pointy-hair bosses here. Are there any pointy-hair bosses here? Oh, there’s a few. Okay. So here’s some advice for pointy-hair bosses. A grumpy pointy-hair boss thinks about architecture and coding standards. They stick it into a confluence wiki, because everyone loves confluence. Just kidding. But an enlightened pointy-hair boss, they actually focus a lot around the developer experience.

They recognize that developers are actually lazy. And so instead of saying, “Every time you open an [inaudible] request, you need to put in a timeout,” what you do is you put someone in charge of creating an [inaudible] library that puts in a timeout and tell everyone to use this API call. And it magically puts in the right semantics for you. And so we found that companies that have adopted microservices successfully, like all the ones who are speaking, have actually invested in the developer experience.

And that’s how they drive standards. They don’t say, “Everyone, you need to put in a timeout.” The grumpy, pointy-hair boss thinks about architecture decisions and creates an architecture review board. The enlightened pointy-hair boss delegates the technical decisions. The grumpy, pointy-hair boss, they think about engineering velocity in terms of throughput. So they say, “I’ve got 50 story points of velocity this week. I want to get to 75 and I need to hire 5 more engineers to get to 75,” and that’s how they think about it.

I think the enlightened pointy-hair boss actually doesn’t think about throughput. They think about latency, and think about how fast you get stuff out. So it’s about how many deploys you do a day. And there’s not a lot of good metrics around how you measure latency, so I think that’s an interesting question, but close approximation maybe is how frequently you can actually deploy. And then the grumpy, pointy-hair boss actually thinks about mean time between failure, when the enlightened person actually thinks about mean time to recovery.

And so this is really how we’ve thought about the evolution from the grumpy, pointy-hair boss to the enlightened pointy-hair boss. And so, just sort of to summarize, I think that the new hard parts around microservices around building distributed developments is hard, building distributed systems is hard, but the new hard part is actually how you actually manage the intersection of the two. And I think that the role of the developer and the pointy-hair boss actually really evolves in this world.

And that’s a good starting point to think about it. And I think there’s a lot more that we are excited to learn about. This is obviously a semi-opinionated view. I would love to talk more about it. And so at DataWire, we’re all about experimenting so this sort of summit was a little bit of an experiment. And so we’re also thinking that it might be kind of fun to actually start a mailing list to actually discuss architectural patterns. So we have no subscribers on the mailing list. It’s a public mailing list.

But if people want to actually try to create a forum, because we looked at Stack Overflow but it’s a discussion, not a question and answer, because there are no clear answers. You can send an email to architecture+subscribe@microservices.com and see if we can get a discussion going. So with that, I…oh, and I should actually say, I think I forgot to say this. The format of the talks, we’re doing about 30-minute talks followed by a 10-minute Q&A. And so really encourage people to do questions and answers or questions for the speaker to answer.

And if you’re on the live stream, you can tweet and we will try to actually put some of those questions out there. So with that, I’m going to turn it over to Ben.