a16z Podcast - a16z Podcast: Containing the Monolith -- From Microservices to DevOps

Episode Date: March 8, 2018

What happens when monolithic architectures are broken down into containers and microservices (or when things are broken down into smaller units, not just in infrastructure but perhaps even in company structure too)? From building more dynamic websites to monitoring the enterprise cloud to elastically scaling applications, where are developers in the enterprise going now and next? This episode of the a16z Podcast, based on a panel by and for developers recorded at the a16z Summit in November 2017 and moderated by general partner Martin Casado, features Matt Billmann, CEO and co-founder of Netlify; Florian Leibert, CEO and co-founder of Mesophere; and Karthik Rau, CEO and co-founder of SignalFX. The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments and certain publicly traded cryptocurrencies/ digital assets for which the issuer has not provided permission for a16z to disclose publicly) is available at https://a16z.com/investments/. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

The content here is for informational purposes only, should not be taken as legal business tax or investment advice or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Hi and welcome to the A16Z podcast. Today's episode, based on a panel by and four developers at our recent summit event, dives into the details of what happens when software eats development and how the entire development life cycle is adapting, from how you design your software, how you build it, how you release it, how you configure it, to how you monitor it. Moderated by Martine Casado, the conversation includes, in the order in which she'll hear their

voices, Florian Libert, CEO and co-founder of Mesosphere, Matt Billman, CEO and co-founder of Netlify, and Karthik Rao, co-founder and CEO of Signal FX. This is, for me, one of the most interesting questions and trends in all of IT buying, which it used to be the case. If you sold something, that was a piece of infrastructure, you sell it to the ops person or core IT or whatever. More and more developers are involved in this purchasing. And so this kind of three days, you can think of it. You can be like, okay, there's core IT that's buying. There's this new group, maybe that's kind of like a devopathy group. Or basically in the end, it's the developers that do all the buying and have all the control. Flo, I'd love for you to talk a little bit about how you've seen this evolution. I mean, with Mezzo, you guys have been in the thick of this.

Is it core IT? Is it developers? Is it something in between? So our software is, the end users of the software actually operators and also data scientists. So those are the folks that actually use our product day to day. But then, of course, they install these platform services. And platform services are, for example, distributed databases, message cues, and many other things that you find on Amazon, that you find on Google Cloud. And what are these things used for? Well, they're for basic pillars, basically.

And one is transporting data. The other one is processing data. the next one is storing data, and then the other one is serving data back up. And you have basically many implementations within each of these pillars. And of course, again, the developers are the end users that take some of these components in order to assemble the applications. But of course, also data scientists will install notebooks, they'll install Spark, they'll install Hadoop, and then use it.

And the operator of the entire platform is usually the operator or the DevOps person. So I want to make sure I understand the layered cake. So you're basically saying, okay, there was Core IT, that's kind of antiquated. DevOps is eating Core IT. Developers are eating DevOps. And now you're just said that data scientists are eating developers. Is that the full stack of power? Actually, I think, right, in the future, hopefully we'll be able to click together applications. You'll have more and more building blocks, more and more applications. And frankly, it's more joyful to write Visual Basic than it is to write Go. Right. You actually achieve business results.

I mean, seriously, right? Like, writing a spark job, you see the output right away. Whereas if you write a large Go application, I mean, it's a lot of work. and you're just dealing with plumbing. So today when you build a mobile app, you build everything in the mobile app and you run it on your phone, and then for like core services, it'll call up to APIs or microservices on the back end,

like Twilio or Striper or whatever. So Netlify is doing this for the web. So basically you create a web page that's a thick front end and then you call microservices on the back end. So you can follow the general model of that. So this is kind of like developers eat web development. So how do you view the evolution of this?

Is the buyer changing? Is the influencer changing? How is that ecosystem evolving? So one of the things is, again, like the developer themselves changing. We used to have this very clear distinction between the back-end developers and then front-end developers

that worked with the web were barely really developers. They would mostly take some design file and then cut it up and hand it over to a back-end developer that would integrate that into some big monolithic application. And now we're seeing more of that

almost visual basically in the form of JavaScript where we didn't have this whole new world of front-ed developers that become the actual web developers And to a large degree, start just gluing together a lot of different microservices that are already ready on the back end instead of, like, building these latch monoliths. Okay, I want to make sure that I understand this, deck. So front-end developers, are they obviating designers, or are there still, is it just basically

now you have designers, you've got front-end developers, then you've got people doing microservice, and the back-end developers are becoming microservice. Is that how you view the industry? Yeah, and in many of these cases, the need for back-in developers is sort of shrinking. It's kind of going away, right? I mean, I can use PubNub or I can use Twilio. We talked to one agency that's really been a pioneer of adopting this model you talked about of building sites that used to have like 55 developers in staff where 35 of those were back-end developers.

And now they have around 33 developers and two of them are back-end developers and all the rest just works in this front-end layer. So that's where the big shift has happened. That now, just like we suddenly had a whole world of app developers emerging with the iPhone, Now we have this whole new world of front-end developers that have become just the web developer. Karthik, so you and I have very similar backgrounds. We both work to VMware, we're kind of core ops.

And then you're very much focused on ops for what you're doing, but it seems to me like the abstractions have evolved, like what's important to highlight. I mean, is that the case? As developers become more in the picture, as APIs make sure it's come more in the picture, is the type of information you service to the ops team evolving, or is it still a kind of IP addresses and low-level stuff?

No, I think it's higher level. You know, developers are more and more, involved, and in fact, in new applications are making the technology decisions for the core runtime. But, you know, if you look at organizations kind of at maturity, it doesn't make sense to have 10 or 20 different teams all kind of running isolated Kafka clusters and relearning best practices around how to scale and make it resilient. And so at a lot of these organizations, you do find a centralized team that will develop best practices around some of these core infrastructure services. You know, if you're running in a cloud, you can maybe just use an API to

leverage some of these core services from an Amazon or a Google. But within an enterprise oftentimes, you'll still find these functions. It's just they're focusing on a different kind of technology than, you know, the traditional enterprise applications. And particularly on this area, what do you think is the core bit of insight people look for in this kind of new era of microservices? Well, I think the big thing that's changed is the velocity of application development is just at an altogether different level, right? Instead of doing two or three updates a year, you could be doing thousands or tens of thousands of updates a year. And so, you know, the entire development life cycle, deployment life cycle, the entire tool set is evolving to support

velocity. So how you design your software, how you build it, how you release it, how you configure it, how you monitor, it's all adapting. So in our world, what people are looking for is to get insight into what's changing in the environment because there's so much change happening. You want to be a lot more proactive in identifying a destructive change so you can roll it back very quickly. And so having the analytics around all of your telemetry data to proactively identify and surface those trends becomes absolutely critical. So that's the key insight that our customers are typically looking for. So I'm glad you brought up to developer lifecycle.

So something that's actually unique across all of these companies is they integrate with the developer lifecycle. So just to set that up very quickly, then I'd love for you guys to comment about how this has kind of changed the way you think about business. Developers now follow a pretty common recipe for developing. It's called the CICD pipeline, you know, continuous integration, continuous development. And they use kind of pretty standard set of tools. And more and more, we see startups coming in that are traditional infrastructure

startups, which 10 years ago they'd sell a box, like they'd sell a router or something like that, or a piece of software. And these days, they integrate in the CIDC pipeline, and they're talking to developers. It's a massive, massive shift of enterprise buying. And it's also interesting because developers, if you're part of the code or you're close to the code, you have a lot more information than semantics. So I know your component is directly into Git. So how do you think about the CICD pipeline, A, and how you build Netlify, but also, like, how this is going to influence infrastructure companies going forward. So Git has been such a massive trend that's been adopted by developers universally and

it's become not just their version control system, but their main workflow engine and their main way of collaboration and communication even in issues around Git and so on. So what we're doing is really taking the way they work there and then extrapolating it all the way out through the deployment and infrastructure to really mean that developers working with Netlify essentially just work in Git. When they make a new pushing pull request to get, we create a new staging environment for them and give them a new URL where they can view that, right? When they merge that into master, we deploy that version of the site and it goes live.

When they change settings for caching, they do it just by writing a file in the Git repository and push it. When they work with content management, they do it just by putting a UI on top of the Git repository and essentially and giving normal people a way to edit the content and contribute to the same like workflow. So we're really just thinking about how can we take that really efficient workflow that developers are working with and then just make everything happen from there. So in Netlify, if somebody is editing, like a developer is making a website, they make the website, as soon as they push it into Git, he gets slurped up by Netlify, thrown in a CDN distributed

across the world, and that does the actual operations and deployment. Do you think the separation between developers and deployment operations goes away? Do you think like this is how things go in the future, or is there still another team? that's doing to operate. I mean, it kind of sounds dangerous to me on it. So the trick is to figure out ways to make it really safe. You can see every pull request in a brand so you know what's going live before you take it live. And Netlify everything is a mutable deployer. You can roll back in an instant and we sort of build a whole UI around that management of the deployment. And that in a certain

degree replaces all the existing like release engineers and so on for that whole part of the stack. And I think we'll see that more and more, this whole notion that if you're at a certain workflow, then a system can kick in and automate the whole process around it. So developers are now eating kind of deployment engineers and operators. I mean, again, you've actually seen the full evolution of this over the last decade. Like, how do you view the CICD affecting how you do business or people run things or ships in the industry? It's an interesting question. So I used to work at Airbnb, and Airbnb search was actually really difficult.

Search for Twitter is really easy. You always show everybody pretty much the same results. But for Airbnb, if you do that, then if the first person, sees a result for San Francisco, clicks on the booking, the second person does the same, then the booking might be gone. So if this happens multiple times,

the users actually will disappear. So what we had to do with Airbnb, every time we rolled out a new version of search, we had to do A-B testing, and we had to make sure that actually, that's a big part, actually, of CICD. So you can push out automatically a new version, and then you redirect 5% of the traffic

towards this new version. And then you actually scale that version up to 10%, scale the other one back, and so forth. And when you're running tens or hundreds of experiments like that a day, automation is really key. It's really key to actually automate every part. It's really key to actually have the metrics in place that if something goes wrong, that you can use tools like yours in order to do automatic rollback. But in general, you want to automate as much as possible because humans are the biggest sorts of errors. And then just back to this kind of this theme I've been

pushing on, which is I just kind of get so curious what the future looks like. Is it literally just devs of different flavors, like this is a dev that does front end, this is a dev that does automation, but they're all software developers and part of the same CICD pipeline, or is it still going to be your operations, your expertise is running somebody else's software versus developing the

software? I mean, I think the whole operator is going to go away over time, like with cloud, with tools like... Do you think so? You think operations are going to go Yeah, I think it's going to... I think we're going to go towards a world where a lot of that stuff is autonomous. Okay, that's a trillion-dollar business, you know, just I mean, I actually agree with you. I just

want, you know, like to actually take a moment and understand. So, I mean, I give you one example. I mean, in the past, when you were set up a sharded, well, yeah, sharded database structure, we had DBAs actually making sure that when one of them goes down, you actually do certain procedures and restore it somewhere else. So it was a lot of manual work. And usually, whenever you had humans involved, the Twitter things went wrong. That's where you all saw the fail oil a lot.

There were too many people involved. But now, when you think about it, when you have things like RDS or you have Cassandra that runs on DCOS, sorry for the Shamus plug, but if you have systems where a lot of the recovery of failures is actually built in, and the level of automation is really high, you actually don't need these DBAs anymore, sitting around and screwing stuff up. I still think there's an element of operations around these workloads, though, right? It's just the skill set and the type of people who are doing it are different. It's not your classic DBA sysadmin. It's going to be someone more of an engineering skill set. Is this somebody that understands code and APIs and whatever

is it someone that understands running application? For me, the line is, do you write your own application? Is your expertise primarily writing an application or running somebody else's application? I mean, let's take Cassandra as an example. Internally, we've got a large Cassandra cluster, and the developer who designed it for our particular workload is one of our most senior best engineers. I don't want him doing operations on our Cassandra cluster,

so we've got a different skill set. They're not quite the same level of seniority as a Paul, but... Right, yeah, yeah. So you should use ours offer. Then you can reassign that developer to do more important stuff. Are you taking advantage standardization of the CICD pipeline for signal effects? It seems like a very obvious way to kind of get access to signals. Yes, CICD and containers have completely changed the entire downstream systems management process.

You know, you think about with containers, a developer can now deploy directly into a production environment. So you have a high rate of change, direct deployment, especially with the mutable infrastructure. You're seeing people effectively replace an entire application with a new set. of containers and then, you know, decommissioning the all set. So there's a massive amount of change and there's a massive amount of churn in the environment. And so being able to collect the signals so that you can more, you know, proactively identify what's different. So a lot of our customers are doing, not quite A-B testing, but Canary deployments, blue-green deployments, where they're looking at metrics for the new set of infrastructure, the new application

version versus the old, identifying outliers, anomalies, and then rolling back very quickly. And do you require code instrumentation to do that? the higher level application metrics, the custom application metrics, yes, most of the customers are doing that. And it seems to me, like, another line that's bifurcating the industry here is the old model, the interface was like IP, or like the process, or the file system, or the database. But now, because CICD is becoming standardized, the interface is actually the programming language, which is so powerful. It used to be the case of I was going to provide something for signaling, for example. I couldn't be part of the code, so I'd either sit on the wire and I'd use network signals, or maybe I'd

use the file system or maybe some process performance characteristics, but you can actually integrate in the code because CICD and languages are becoming standards. I would assume allow you to provide better visibility than you can before. So playing this out, does every box become basically a library in somebody's code? Is it basically like the all set of vendors that were providing boxes and this and that? Do they just basically become software libraries? Yes, the richness of data that we can collect now is substantially better, just given that the developer does have an incentive to instrument his or her own code because if something goes wrong, they're the ones that are going to get paged. So, Matt, do you see that you're appealing to a subset of the community that's

growing, or is it more it's everybody and they're just learning? Are we seeing an emergence of a new kind of user, new buyer that understands development, that understands programming, or is everybody slowly moving towards it? Is it going to be old and a new, or is everybody going to become the new? I think it's very much moving in concentric circles from a group of early adopters, typically in the Bay Area around open source projects and so on, that's been some of our huge adopters at Netlify, right, and then sort of spreads out deeper and deeper into the whole ecosystem where, of course, like, you always have these curves of, like, adoptions that takes very, very long to trail off. So at this point, 28% of all websites are still built with WordPress.

And everybody kind of knows it's a bad idea, but it's even still slowly growing. And I think we're about to see a pretty massive sea change where the architecture of that will shift. And that, I think, will affect, like, basically all web developers over. the next 10 years. Okay, so for those that are running large companies that are moving towards containers into microservices, they understand that CICD is evolving and the entire infrastructure is evolving to support that. Like, is there any guidance where you would provide to someone running a business, especially a legacy business and how they get ready for this and how they adopt it, what to experiment, what to look into? Yeah, so I don't think there's going to

be this rip and replaced. So we're dealing with a lot of financial services companies. And if you lock onto your bank account or if you do an ATM transaction, that still runs on a mainframe. And that's probably not going to go away because I think a lot of the tools that have emerged, they don't have the same level of consistency that a mainframe has. But I think what's going to happen over time is, as a bank, for example, rolls out new applications and those applications are client-facing and they have more traffic, you can introduce caching layers that actually do a read from the mainframe, and then they can serve many, many more clients.

So I think we're not going to see a rip and replace. I think we're going to see more and more systems built around the old systems. And for some of the core infrastructure, I think even in 20 or 30 years, we'll still have mainframes. I agree. A lot of this will happen as gradual transitions, right? And part of the whole advantage of this microservice world is that you can actually split things into smaller services. And that also means you can start building out some kind of client layer that now consumes your old mainframe stuff wrapped in a couple of smaller services. So I think we'll see a lot of those gradual transition paths.

And old stuff sticks around for a very long time. One piece of feedback I would have based on everything we've seen with enterprises is this whole model of CICD, microservices containers, it's all around optimizing for speed and, you know, high velocity and speed. And what a lot of people don't realize is the entire tool set has to evolve to enable you to catch issues more quickly and to roll them back as quickly as possible. So that's the fundamental philosophical change in the tool set. And, you know, from the very beginning and how you develop your code all the way through how you support and manage it, We're seeing a lot of interesting new technologies that are supporting this very different model of software delivery. So I urge everyone to look at the entire spectrum from build all the way to release, manage, and support and how that's going to change in this new world.

Great. Please help me thank the panelists.