Screaming in the Cloud - Episode 40: Wave of Innovation Breaking Ahead of the Bow of the Ship that is Amazon

Episode Date: December 12, 2018

You can't make money selling to developers! The bottleneck of getting business requirements and creating business value used to mean waiting for the next waterfall release. That’s not the case anymore in the venture community. There’s programmatic access to infrastructure and DevOps/agile developments that offer super-fast cycle times. Now, the bottleneck is about how fast your developers can move and how much they can get done. Today, we’re talking to Joseph Ruscio, general partner at Heavybit Industries, which is an accelerator for seed-stage companies and focuses on developer-first products. Tools and products that get you more leverage out of your developers are incredibly valuable. Some of the highlights of the show include: Measuring maturity of startups’ engineering teams by looking at SaaS list - what products they have in place and how many are using out-of-house vendors Customers don’t care how curated or artisan a piece of your stack is, they only care that it works Not all claims (scales infinitely or never fails) are true when it comes to products on the market, so people are skeptical Heavybit focuses on helping businesses build a bottoms-up, grassroots community around its products and a disciplined inside/direct sales motion Build vs. Buy: Whatever people try to do themselves is a costly, pale imitation of something they can buy Advice for New Entrepreneurs: Never compete with AWS on hosting compute because it will obliterate and Amazon is great at plumbing, terrible at painting AWS’s version of your product won't be as sophisticated; continually work on it to deliver a more seamless product and customer success experience Measure downtime/outages in terms of dollars by using monitoring tools that deliver more holistic, integrated, comprehensive experience than CloudWatch Starting a company is easier; even if you're the 800-pound gorilla in the category you created, keep innovating and building or Amazon’s coming after you Azure, unlike GCP, has ability to meet customers where they are, rather than telling them where they should be Understand the problem your customer is trying to solve and understand how far out of their current comfort zone they're willing to go to solve that problem Software exists to create business value; it doesn't matter what it's written in or how it's hosted, so some systems will be around for a long time Links: Joseph Ruscio on Twitter High Leverage Podcast Heavybit Industries Heavybit Library Serverless Framework Pagerduty Stripe Circle Lightstep LaunchDarkly Treasure Data Replicated AWS Twilio Librato re:Invent MongoDB Kubernetes Rackspace New Relic SolarWinds CloudWatch GCP Azure SimpleBB Datadog Digital Ocean .

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as a managed service at

varying degrees of maturity. Others bias for, hey, we heard there's some money to be made in the cloud space. Can you give us some of it? DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they're using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access and IP addresses. DigitalOcean makes it all simple. In 60 seconds, you have root access to a Linux box with an IP. That's a direct quote, albeit with profanity about other providers taken out. DigitalOcean also offers fixed price offerings. You always know what you're going to wind up paying this month,

so you don't wind up having a minor heart issue when the bill comes in. Their services are also understandable without spending three months going to cloud school. You don't have to worry about going very deep to understand what you're doing. It's click button or make an API call and you receive a cloud resource. They also include very understandable monitoring and alerting. And lastly, they're not exactly what I would call small time. Over 150,000 businesses are using them today. So go ahead and give them a try. Visit do.co slash screaming, and they'll give you a free $100 credit to try it out.

That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Joe Ruscio, who's a general partner, is it, at Heavybit Industries? That's correct, yeah. Perfect. There are general partners, there are limited partners, and I don't understand why there isn't a third tier called unlimited partners, but that's probably one of those finance things I'll never fully understand.

Yeah, yeah. It's surprisingly complex for what is honestly a fairly simple thing when you get down to it. So Heavybit Industries is an accelerator for seed stage companies, as I understand it. I'm simple, and I think in terms of cartoons. So I'm going to more or less equate that to venture capitalist. Am I wrong? No, you're not. You're not wrong. No. So yes, so Heavybit is an accelerator. And I use that term, unfortunately, these terms are kind of thrown around without a lot of distinction. But unlike a lot of what I think of as incubators that start with basically brand new companies, I mean, Y Combinator being the canonical example, we focus on taking seed stage companies, that is, companies that have achieved some basic product market fit and have

raised some seed capital, which in this day and age means typically somewhere in the realm of one to even if it's what we call mango seed rounds, like $4 million. And are really starting to think about how they go to market more broadly than just having their friends that they get coffee with from other tech companies buy the product. If I take a look through the list of member companies that you've been involved with, it's sort of a who's who in some respects, with respect to various companies that you've been behind. Serverless Framework, PagerDuty, Stripe, Circle, Lightstep, LaunchDarkly, Heidi was on the first episode of this podcast, Treasure Data, Replicated, and the list continues onward. These are interesting companies. What ties them together? Yeah, that's a great question.

And so in addition to the stage focus, we have another very, very intentful focus on what we call developer-first products. And it's actually a fairly broad definition, but fundamentally, we founded the firm around this notion that a lot of the technological change of now the last, I'd say, almost 10 to 12 years. Actually, I guess, really more like 10 years if we look at AWS coming of age is a really big inflection point. But whereas historically in the venture community, there was always this now a canard of, you can't make money selling to developers. And that was because historically, the bottleneck of getting business requirements... Because fundamentally,

everything developers do at a good company is about creating business value. Everything's measured and should be measured through that lens. But historically, the bottleneck in creating business value by taking the new requirements of the business and getting them into running production code was not your development team. It was like procuring servers, procuring space and data centers,

racking and stacking. And then there's what's your quarterly release schedule. So you had to wait for the next waterfall release to go out. Fast forward 10 or 15 years, and this has now all been turned on its head. We have programmatic access to infrastructure. We have DevOps and agile development, breaking things down into super fast cycle times. And now, the bottleneck of implementing new business requirements into running code and production at a high-performing organization is literally just how fast can your developers move. And exacerbating this is that every company that's going to be an enduring company is becoming a software company at some level. And by that, I mean, not like online media or e-commerce or anything, but I mean, really like companies like

Coca-Cola and John Deere and Marsk Shipping are all fundamentally becoming software companies. And what that means is I don't think as much work is going into, which is great and we should continue, but as much work is going into broadening the pool of developers that are available, I don't think there will ever be enough. And that means not only is your success going to be limited by how fast your developers move,

but how much they can get done because you won't be able to hire as many as you want in almost all cases. And so if you believe all that, which I do, it follows that tools and products that allow you to get more leverage out of your developers are incredibly valuable now. And so we have a thesis and a focus on products that do and companies that do exactly that. The challenge, too, that I found as I've gone through my own business is that historically, when I'm talking about business-level concerns, like the AWS bill has grown to stratospheric proportions, I haven't found that developers for this market or many other markets are good

customers. First, it starts with, I guess, a healthy level of skepticism. From there, it turns very rapidly into a world where you're talking to people and their response is, oh, I can write a script that does that in the course of a weekend. And that's never true, but it does tend to be a somewhat enduring reality in that people underestimate how much work it is. To the point where you finally wind up winning a developer over to become a champion, it turns out that their signing authority for budgets rounds to zero. So it seems like an awful lot of work to convince a developer to necessarily buy something,

only to wind up discovering that they can't. And yes, I realize I'm speaking in very broad generalities and painting with an extraordinarily broad brush, but that's historically been the theme that I've seen tend to emerge. Instead, you fundamentally have taken an accelerator and built exclusively towards companies that cater to that exact market. How does that work? Yeah, that's a great question. And I guess there's a couple things. First of all, my background, before I came full-time into actually on the investor advisor mentor side earlier this year, I spent effectively 20 years as a technologist, a first engineer, and then an engineering leader,

and then an entrepreneur building actually a company in this space with these similar goals. And so I've seen all sides of that, both as a buyer and as a vendor and now as an investor. And you're absolutely right. This is something where there is fundamentally, I think, a maturity level for development teams and organizations. And I often tell people, when I come into a company, and not just the kind we invest in, but any company, whatever the hottest new startup is, I can generally measure the maturity of their engineering team just by taking a look at their SaaS list. What products do you have in place for starters? And how many of those are you using out-of-house vendors? Because going back again, if you believe, as I do,

and I've seen that you fundamentally can never hire as many developers as you want. One of our customers once referred to buying these kind of products as hiring by API. And what they meant by that is if you look at products like Twilio or Stripe, you're replacing what historically you would have needed a whole team of developers and a product manager and QA and some operations engineers with an API that you make programmatic calls to. Amazon AWS is a great example, right? I think it's one of those things that more senior engineers who have been through

a couple rodeos and have seen what happens when you spend all your times on things that Werner refers to it as undifferentiated heavy lifting, right? And I think that applies to all levels of the stack. So I think high-functioning teams look... And I know I tried to do this as an engineering leader. Look really, really aggressively at everything on their list and ask, which of these are competitive differentiators to us? Which of these increases the core value we deliver to our customers that no one else can?

And which of these are things that... I mean, I used to tell my team, obviously, the customer literally does not care how curated or artisan this piece of our stack is. They don't care. All they care is that it works. So why spend our time there? But yes, you're right. And so it's interesting because one of the things we do at Heavybit, and I think one of the things we help our member companies with specifically, is we do believe, and why we believe there's value in us focusing in this area, is that we do believe that there are a set of best practices to take these products to market.

And one of the reasons for that is because the... I won't even necessarily say the buyers because it varies, but many times, especially in smaller companies, developers are actually the buyers. But in larger organizations, they often aren't the final buyers, which you alluded to. But this initial set of champions or audience is extremely discerning. And as people with technical backgrounds, we understand that. Everybody is very skeptical of all the products with all the market texture,

claiming to do all kinds of crazy things. Scales infinitely, never fails. And we know that's all not true. And so we focus with our companies on exactly how do you do two things. You build bottoms-up grassroots community around your products. But then you also have to pair that with a very disciplined insider or direct sales motion, depending on the kind of go-to-market you have, that can capture that and knows how to identify and qualify which companies are going to spin their wheels for a while trying to build it themselves. Early in my career as a vendor, I used to get very upset when somebody would tell me, like you said, oh, we'll build that in a script in a weekend. And then

as I became more experienced, I stopped letting that bother me because I knew and inside my head, it was that those companies would be back in six months. Those projects would fail in almost all cases and they would be back and they would have learned their lessons and they would buy. Yeah. If you legitimately can solve a problem in a script over the course of a weekend, maybe that's not a particularly defensible position to build a product around. Yes. Yeah. I mean, you honestly, obviously, as an entrepreneur and a vendor, you have to be secure in knowing that whatever people try to do themselves is going to be a pale imitation of what you're doing. And also that the ongoing maintenance costs,

I mean, that's the other great thing about hiring by API is unlike most of your hires, you don't have to budget or account for turnover and loss of institutional knowledge and retraining and shifting priorities because those products and those APIs will always be there. Assuming obviously that the company's healthy, but we'll always be there and we'll always work the same way. And that just takes a big load off your

shoulders. There's all these hidden costs in internal. The build versus buy, there are absolutely cases where build makes sense, but it's usually much more expensive than I think your naive or more junior engineers often think. I would generally agree with that. So as you find yourself building companies that turn into, in some cases, runaway successes, do you find that there are certain tells early on that differentiate, I guess, winners from losers? I mean, first, I'm not asking for secret information on how you wind up evaluating companies. But I guess I'm wondering if you're starting to see a recurring theme that differentiates the companies that build something that can endure versus companies that build something that AWS releases a feature the week later that winds up effectively destroying their entire value proposition. Yeah. Yeah. And so it's interesting. There's actually a couple good questions in there. So just to focus on... There is particularly with developer-focused or IT or infrastructure-focused

products, which we cover all those, especially in the last, say, I don't know, I want to say like five to six years. Because my company, I found a company called Labrado, which was the first hosted telemetry company. There's a bunch of other great companies in the space now. And we started that in 2011. And I actually built a previous product started in 2009. And at the time, AWS was very

basic, right? Object storage, instance, a small number of EC2 instances, not the infinite alphabet soup that they have now. Load balancers, RDS was MySQL only. Oh, yeah. And even at the time, looking back, I still remember feeling like, this is a lot of services I need to learn. I'm never going to be able to wrap my head around all of that. I look back 10 years and laugh at myself. Yeah. Literally, there's like, man, there's 10 services. How can I remember all these? So yeah. So I mean, at the time, so then there was this Cambrian explosion of all these different... There were like five different companies that were doing hosted Redis at the time, right? Just as a ludicrous, absurd example, right?

A pathological case. But then as we all know now, AWS started moving up the stack and the other cloud providers have followed. And so now they're offering all kinds of managed services very sophisticated managed services in some cases and then basically any kind of

flavor of hosted open source that you would run on some server somewhere if it reaches a sufficient enough market size I fully expect reInvent I think will be done by the time this podcast is out.

But the information is reporting that they'll have a MongoDB-hosted service. So we'll see. Yeah, I've heard that rumor a lot myself. And frankly, let's be honest, Mongo is a terrific choice to store your data. Not my data, that stuff's valuable. But for your data, absolutely. Go nuts.

Yep. But Amazon, as you know, is quote-unquote customer-obsessed, and that's definitely a project that I think has passed the threshold. But it's a great example, yeah, that you can be guaranteed that Amazon will continue to roll out higher and higher level functionality. So a lot of times, we do spend a lot of time talking about and with our companies. Because again, okay, so the point of all that was seven or eight years ago, it was fairly easy, relatively speaking, to build a small business because you just provision some EC2

servers, ran something on top of it, and then charge people to manage the thing you're running on top of EC2 instances. That is effectively gone. I mean, I don't know. You might be able to run a lifestyle business with a particular niche flavor of something. Yeah. Click a marketplace button, receive configured and running WordPress or equivalent. There's always going to be a niche market for that. But it's not exactly the growth industry of the future either. Right. Right. And so then you have to look for, okay, what is your, what value are you going to bring? And so I generally tell new entrepreneurs at least two high-level things. One, it's kind of the equivalent of like, what's that line I think from the Princess Bride? Like, never start a land war in Asia, right?

Well, never compete with AWS on hosting compute. Like, just period. Whether it's some VPS service or, again, hosting whatever. Do not compete with AWS on hosting compute because they will just obliterate you. Azure, this does not apply to you. Yes, yeah. The main exception being

if you have a billion-dollar war chest and 30, 40 years history of software development. But outside of the two other companies that are already doing that, no one else should. The other thing, which is probably much more... a little more subtle, but I think probably much more important because not hosting compute is an easy one.

AWS, I've heard this saying, which stuck with me four or five years ago. Amazon is great at plumbing. They are terrible at painting. And so I think what that means is usually you talk about an 80-20 solution. I think Amazon and the way they develop software, they're very good at identifying basic needs of users. They're very good at putting out a serviceable, basic solution. They've historically not been great at supporting documentation, the UI, UX to drive it.

And so we tell all of our companies, there's this room, and there still is, and I kind of especially now believe there probably always will be for what we call premium solutions, right? So if you pick your niche and you go deep on it, then you can be certain that AWS will have a version of it at some point. But if you're doing your job and you're executing, it won't ever be as sophisticated as yours

because you're going to continue working on it. You're always going to be ahead. And you can deliver a just better, more seamless product UX and customer success experience. And so, again, taking LaunchDarkly as an example, I expect Amazon at some point will have a feature flagging service. I expect it will be basic. And if you're a tiny company with simple needs, it will be more than fine. I don't think LaunchDarkly will lose a lot of their enterprise customers to it. Absolutely. And I think that you'll see a basic version of everything. I mean,

you have Gremlin for advanced chaos engineering, or you can use the basic service and just run your stuff in US East 1. Yeah, exactly. I mean, that's like the original managed service, which by the way, I love the t-shirts. I got mine in the mail the other day. Well, thank you. I thought the subtle US East 1 on the side of the dumpster was a nice touch. It used to be much less subtle. And to be clear, I don't blame the t-shirt vendor for any of this, but they wanted to take the arrowhead off of the Amazon logo,

and they wanted to sort of fuzz the US East 1 in the interest of not getting sued. And I don't believe that AWS would ever sue something like that for a charity t-shirt that benefits kids with cancer. But by the same token, they said, cool, great, we're on board with that. Can you get Amazon to commit to that in writing? And yeah, you can imagine how that conversation went from there.

So I fuzzed the logo and called it a day. Yeah, I think that's a very pragmatic decision. We do what we must. So one thing that I find fascinating as you continue to look at the ecosystem, it's not just the relatively basic features that initial service launches wind up bringing along, but there seems to almost be a sense of, I don't want to say delight, because that's too strong, but inevitability, where there's a big keynote at reInvent, which, again, as of this recording is next week, where they announce a whole bunch of services.

And then my favorite macabre game that I play at reInvent is walking around the expo hall and look at who just had their business model Sherlocked out from under them. Yeah, yeah. Well, I mean, it was a good example going back, you know, I mean, last year when AWS announced not just one, but two flavors of managed Kubernetes, right? Like EKS and Fargate. And there were, I'm not going to name anybody, but there were, I think, at least two or three vendors

on the expo floor who were literally selling a managed Kubernetes service on Amazon. They provisioned EC2 instances, they ran Kubernetes on it for you, and you push in their containers. And so it's some form of a platform as a service. So I never had a chance to talk to those people before, but had I, prior to that,

I mean, that's exactly what I would have told them would happen at some point. Yeah, when you have a technology as hot as Kubernetes showing up in the New York Times or the Wall Street Journal, you can pretty much bet that all the big players are going to be there. And it's almost like the olden days of web hosting. When you talk about the small web hosting shops with the rise of things like Rackspace and later in time, Amazon and DigitalOcean,

the answer became very clear that, so how are you going to compete? And their answer was always the same, excellent customer service, which means we don't really know how we're going to compete, but that's an answer no one can argue with. Yeah, there's two answers that come up. That's one, and then the other one is multi-cloud, which is also not a real answer. And yeah, going back again, the answer has to be, it has to be something that through product and UI UX, you can significantly differentiate. And I think, for instance, taking another area, my background and probably just some bias there, but monitoring is a great example.

When we first launched our product, CloudWatch was extremely primitive. It was two weeks of retention at one or five-minute resolution, extremely basic UI, and not all the services had metrics. I didn't realize that you launched three weeks ago. Well, I've heard, at least, that it's made dramatic strides, especially in the last couple of years.

But then you compare that to, again, and they're doing a great job. And for, I think, basic entry-level people, that's fine. But then if you compare that to products like even New Relic or Datadog or the work SolarWinds has been doing, and it's night and day. And again, if you're measuring your downtime and outages in terms of dollars, it is well worth investing in good observability and monitoring tools that deliver a far more holistic, integrated, comprehensive experience

than CloudWatch does. I actually know some people on the CloudWatch team, and they're great, and they're doing a good job. As do I, after the article I wrote a couple of weeks back that more or less savaged them. Yeah, to be clear, I hope and trust that in the not very distant future, I'll get the opportunity to write a article or blog post or similar with the theme of, it's better now. I really do hope it is. There's always going to be a place for monitoring vendors. If for no other reason than you need to have something outside of the platform your production environment runs upon

in order to tell you when it's experiencing issues, there's just a philosophical story there. But yeah, right now, there's so much more that needs to happen that I'm not convinced that CloudWatch is ever going to provide a comprehensive story around. But there is, at least as of the date of this recording, a lot it could be doing that it isn't. Oh, yeah. Yeah. But again, it just all comes back down to, as an entrepreneur and a founder, you need to be obsessed with product. You need to be obsessed with user experience.

And you need to make sure that you're always delivering some value above and beyond what a basic three-letter service from Amazon does. And you have to make sure that for the majority of customer use cases, or at least customers with real purchasing power, what you're offering above and beyond is real value. Or the thing that you're building has the opportunity to provide that. Because again, going back to platform as a service or hosting compute or even databases, there's not really a lot. Like Amazon, if the primary interface to your product is a simple API and there's not really a lot of need

for any kind of management or orchestration layers, you're probably going to be in trouble. And that's really, I think, the lesson that we can take from a lot of this, where basic building blocks to weave into services have always been Amazon's strength. Now they're trying to move up the stack into higher level managed services that solve specific business problems. And on the one hand, that's really neat to see. On the other, it's not historically in their core DNA. And if you have sophisticated requirements, I don't see that there's necessarily going to be

something coming from AWS that takes the market by storm. If you need a basic thing that checks a box for some random higher-level service, yes, there's a great chance that AWS will release that. Will it wind up being a nuanced exploration of the space? Probably not on day one. And as a result, I feel like there's room for a wave of innovation, I guess. The wave's breaking ahead of the bow of the ship that is Amazon.

And there's always going to be, to some extent, a story for partners and vendors in that space. That said, I think that anyone who's taking what they're building today and effectively not iterating on that in any meaningful way will not have a business in five years. Do you think that's a fair characterization? Oh, I think so. Yeah, I mean, I think, honestly, if anything, what's happened is that it's just that the bar has been raised. So the two things have happened. One, it's become much, much much easier to start a company than it's ever been, particularly with things like Stripe Atlas, for example, where it's basically like AWS for starting companies. products, I think the bar has been raised for what you need to not only initially deliver, but also the continued execution on product and just continuously improving your product. And especially for consumers, that's fundamentally a good thing. I just think whereas historically, it was probably a little easier to rest on your laurels once you had created your category and established your leadership there. Now you know, even if you're the 800-pound gorilla in the category you

created, if you don't keep innovating and building, they are coming for you. And so I think as long as you're aware of that, that's not a bad thing. I feel like we spent a fair bit of time talking about AWS specifically, which I think is fair. But something that has been on my mind lately, since I just got back from a trip outside of the bubble of the Bay Area, which is a good thing because as of this recording, that bubble is full of smoke. I encountered something that sort of surprised me in that if you'd asked me a month ago to say, all right, what is the second cloud, if not Amazon, that's going to, I guess, continue to win

in the market, I would have opened with GCP. And having been outside of this, I guess, ridiculous technical echo chamber, I've completely done a 180 on that. At this point, I guess, ridiculous technical echo chamber. I've completely done a 180 on that. At this point, I firmly believe Azure is the second cloud, not necessarily from a story of technical capability, which is where I went wrong before. I fell into the engineering trap of believing that capabilities are going to define the future, but rather in the ability to meet customers where they are,

rather than telling them where they should be. Is that something that I guess has risen to your level of attention as far as you explore various multi-cloud stories as you go through the world and see, I guess, what real companies are using? Oh, yeah, absolutely. And I think, yeah, I mean, by the way, you're 100% correct. And I mean, there was actually literally just some earnings results where, yeah, it's not even close. I mean, I forget Microsoft is like four or five X, Azure is four or five X the size of GCP. GCP is quote unquote only, I think it was 1.6 billion. And yeah, it's interesting. I mean, when, you know,

and again, you know, we've been just, like you said, you say talking about AWS a lot, but I just kind of mentally substitute that for, you know, viable cloud computing, which I lump in absolutely Azure and also Google with.

And as, you know, someone who was a buyer from about 2008 until really the last 10 years, so for the whole ride up, I remember initially being very excited when GCP first started coming out and with the continuous load balancers, which could do crazy things at the time ELB couldn't do. And so there was a lot of promise on technical capabilities. But yeah, I think meet customers where they are. I saw someone retweeted something just recently, which

just really resonated where it said, there's a customer talking to GCP and says, we want X and GCP says, great, but we're going to sell you Y because that's a better way to do it. And then customer says, great, we're going to go buy X from Microsoft. And I think there's this concept called, I believe it's an Overton window, where I think what Google has always struggled with, and I'm becoming less and less, they had a very recent obvious executive shakeup, I think, trying to address this. Diane Greene is on her way out, and they've brought in someone from

literally Oracle, which is the least Google company you can think of. True. And their cloud is going super well. So that was absolutely a smart move. Oh, yeah. Spark and cynicism aside, it probably is the right direction. Yeah. But I think the problem is, and I mean, if you look historically, right? So when GCP launched, right? They launched with Google App Engine, right?

Which is a great example of something way ahead of its time. You know, it literally like a platform as a service, not only way ahead of its time. You know, it literally like a platform as a service, not only way ahead of its time in terms of saying, hey, you can just ship us your app code and we're going to run it in these things we call containers, which nobody knows about yet, and just abstract away all of the infrastructure, servers, instances, everything.

Also, it only runs in Python because we as Google have decided that's the best language. And I think there was some surprise when two years later, Amazon was roundly trouncing them just by selling hosted Linux servers. And yeah, I think they've gotten incrementally better. But I think it's very hard for an organization that large and that ingrained and being literally... And I'm not saying the snarky, they are the smartest people in the room. If you look at things like Spanner and again, the load balancer they have and these other pieces of technology, they have by far the best cloud tech, but they just don't grok fundamentally as an organization. And I know they're trying to get there as to how to sell the enterprise,

which is you have to understand the problem of the enterprise. There's two things. One is, which everybody knows, understand the problem your customer is trying to solve. That's number one. I don't want to say easy, but a lot of people get that. The second thing that's a little trickier is you have to understand, this goes back to the Overton window,

how far out of their current comfort zone they're willing to go to solve that problem. And I think that has been Google's Achilles heel. Because they've got the most crazy science fiction best way to do this that is decades ahead of what their customers have been thinking, they've tried to pull them from the huge legacy stacks directly, fast forward 20 years, and all the learning schools had into the new thing. And a lot of people just can't make that jump. And then on the flip side, you have Microsoft, not only that I think more deeply understands that,

but has just this massive enterprise sales channel with all the relationships in place that they've built up over decades with just the Windows and Office franchises. And then doing very... What Microsoft has done the last couple of years, I think is just incredible. The executive team there is... I mean, between things like.NET Core, acquiring GitHub, running Linux. I mean, there is literally a Microsoft Linux distribution for some of their IoT stuff, right? And I'm old. I was in Onslashdot and the FUD wars, right?

Like the great FUD wars of the late 90s. And I mean, if you had told me the kind of thing, the moves that Microsoft is making today, no one would have believed it, not in a million years. And so that's why I think the window is rapidly closing on Google being able to... I think they'll be fine. But in terms of being a massive cloud player, they need to figure it out quick. They do.

And I think you're right when you say that window is closing. There's also a certain lack of awareness that I'm picking up on from understanding how their customers view the world. Google historically has always been much more interested in what it's building than what it's shipping. And as a result, they tend to deprecate things relatively haphazardly from the outside world. That scares the crap out of enterprises who are in many cases running 30 or 40-year-old systems to solve certain things. No one is going to build something that has the potential of lasting that long on top of a cloud provider that has shown a willingness to change directions mid-course. And I don't think that there's fully an awareness culturally at Google at this point of how damaging that is to their reputation. There's also, of course, the whole separate argument of when you're trying to sell something to someone and you imply that they're incompetent because they don't see the world the same way that you do, that's sort of a really

crappy sales pitch. Yeah. Yeah. I mean, I think both of those things. In one way, it's kind of fascinating because Google, the consumer company, right? Because for instance, I don't think they've actually shut down or canceled any cloud services, really. But there have been a few. I have a list somewhere. I don't have them off the top of mind. But there have been, I think there are three or four so far yeah well i guess could actually just random question i mean so like it was a simple db still running yes you can still get it on new accounts even you have to request it i believe and they will do their damnedest to steer you away from it but you can get it okay well there's a good contrast right there i. But I think even more kind of interesting is I do suspect that now their proclivity,

which in isolation is probably the right thing, but to shut down consumer services, whether it's Google Plus or Wave or RSS feed, you can't help but have some of that just because of the way brands work in people's mind, right? You can't help but have some of that just because of the way brands work in people's mind. You can't help but have some of that carry over to the cloud side. Absolutely. Where people are like, regardless, at the highest level, this is a company that is super comfortable to just do things that are better for them and shut these things down rather than have a handful of engineers continue to work on RSS feeds.

And there's no way... And if there are already examples of them shutting down cloud services, that just even makes it worse. So yeah, I do think that's absolutely a problem that they're going to have to fix. And they're going to have to be real explicit with their customers. And yeah, I mean, treating your customers or implying that they're in some way incompetent is, yeah, absolutely the worst sales tactic. I think the best people,

the best salespeople, they understand the problem that's trying to be solved. They position the way their product solves that problem and they sell it. But they also, again, understand how far out of the current comfort zone they can pull the customer before it's just not tractable. Even if it's technically the best solution, if you require the entire human... There's just some basic lizard brain stuff here, right? For perpetuation of the species, we're only going to go so far out of our comfort zone at any one instance in time. The interesting thing being, though, is you can, and this is what I think the most successful companies do,

even if they know ultimately the customer needs to end up to that place they're not comfortable enough to move to now, you build your product and sell it in such a way that you get them in and then over time, you get them more comfortable and you move them in and then over time, you get them more comfortable and you move them over. And I think what AWS has with EC2 instances and then ECS and now EKS, and they can bring in lift and shift customers into EC2. And over time, any of the cloud providers can do this.

They all have the pieces, but you can bring them into instance compute with lift and shift and slowly get them dipping their toes into containers and Kubernetes. And before you know it, they'll be doing serverless stuff, right? And I think everybody wants to do the new things. It's just what they can do at any one point in time.

Throw away your 15-year-old billing system and rewrite the entire thing using this new paradigm. Yeah. You get that makes us money, right? It becomes a different story. Yeah. And you can never lose sight of the fact. And it's tough, especially like you said in the bubble. Because yeah, in Silicon Valley, which absolutely is a bubble, right? I mean, people are like, you're using tech that's 18 months old. And the vast majority

of the world, and I think this is the right way to look at it too, software exists to create business value. And if it's doing that, it really doesn't matter what it's written in or how it's hosted. If it's creating business value, I mean, switching costs is a real thing. And so yeah, I think you have to expect

that those systems will be around for a very long time. Last question for you. How do I get you folks to fund Twitter for Pets, the most innovative social network for four-legged animals? Yeah, I've heard you've been refining your pitch there. I mean, I guess, yeah, for us, like I said, Heavybit has a very developer, infrastructure-centric approach. So I guess we need to be API first. We need to understand the Twitter for Pets API and how it's going to glue every consumer app on the planet together.

And then probably need some kind of understanding about how we'd not take the same path Twitter did with their API. There's probably a very unfortunate story that's up in there somewhere. The fun part about a lot of this is that it also turns out being, I guess, an ongoing battle, not just to get noticed and discovered. So if people want to hear more of your sage thoughts, where can they find you? Yeah, that's great. So one of the things we do at Heavybit also, in addition to working with companies and accelerators,

we do a ton of work just around trying to level up the entire community on this, whether our companies or not. So if you go to heavybit.com, we have an incredible curated library. Basically, we are constantly having speakers come in and one-off events. We run targeted conferences. We call it Dev Guild on things like pricing or product marketing or enterprise readiness of products.

But all these, we do very high-fidelity recordings and transcripts. So you can come in and it's literally, I think at this point, hundreds of different things. So anybody who's building products in this space, you go check it out. It's completely free. We have a regular newsletter you can sign up for on the site called for both Heavybit and DevTools Digest, which we give weekly updates, just interesting things in the space. And then finally, I guess more personally, I've recently entered

the wonderful world of podcasting. And so I have a brand new podcast. We just launched the first episode a couple weeks ago. It's called High Leverage. And it's really just a series of conversations focused on the culture and processes and tooling

that the highest performing software teams use in this day and age. And if it can tempt any of your listeners, I was fortunate enough to record an episode with you recently that will be coming out very soon. Perfect. Well, I look forward to seeing that

come out. Thank you again for taking the time to speak with me today. I know that you're a busy person. Yeah, the pleasure is all mine. It's great, great, great, great chatting. So look forward to the next time. Likewise. This has been Joe Ruscio of Heavybit Industries. I'm Corey Quinn, and this is Screaming in the Cloud.

This has been this week's episode of Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com or wherever fine snark is sold.