Podcasts about Google Cloud

Subbiah Sundaram, Sr. VP of Products at HYCU discusses several key announcements at re:Invent 2022, details about HYCU's free tier which provides zero-impact backups to one-click restores, and easy data mobility.

On this episode, Jake and Gino are with Wayne McCulloch, who is one of the world's leading customer service experts and a Top 100 Customer Success Strategist. Wayne shares his top tips for delivering amazing customer service, including the importance of always putting yourself in the customer's shoes. He talks about the right strategies that brands can adopt to create the customer success. He shares the insights from his book ‘The Seven Pillars of Customer Success' and explains step by step framework for creating the value-system for the customers. Wayne McCulloch works with Google Cloud's entire SaaS portfolio as the Customer Success Leader. He's a keynote speaker and the recipient of multiple industry awards with more than twenty-five years of experience in customer-focused roles. Watch this video to learn how to take your customer service skills to the next level! Key insights: 00:35 Introduction 02:55 Making customers successful 07:00 Guidelines to serve customers 11:54 Operationalizing: Doing the right thing for the customer at large scale 14:00 Onboarding process for customers 17:19 Values make people keep coming back 19:40 Adopting phase: Maximising the utility value 23:38 Retention: Value realization in present and future 28:06 80% of customers are motivated by privilege 34:02 Creating advocates for your brand 39:36 Best way to operationalize customer service component 41:44 Book recommendations 44:10 Wrap-up For more information about The Seven Pillars, including downloadable templates and training and certification materials, visit www.cspillars.com Check out the author's best-selling book ‘The Seven Pillars of Customer Success' on Amazon: https://rb.gy/q068a8 Brand New? Start Here: https://jakeandgino.mykajabi.com/free-wheelbarrowprofits Want To Get Into Multifamily Real Estate Or Scale Your Current Portfolio Faster? Apply to join our PREMIER MULTIFAMILY INVESTING COMMUNITY & MENTORSHIP PROGRAM. (*Note: Our community is not for beginner investors) https://jakeandgino.com/apply About Jake & Gino Jake & Gino are multifamily investors, operators, and mentors who have created a vertically integrated real estate company. They own over 1900 units totaling over $250M in assets under management. Their students have closed on more than 55,000 units totaling over $5B (billion) in assets. They have created the Jake & Gino Premier Multifamily Community to teach others a simple three-step framework for investing in multifamily real estate. Connect with Jake & Gino on the social media platform you are most active on: Jake & Gino Facebook: https://www.facebook.com/jakeandgino/ Jake & Gino Linkedin: https://www.linkedin.com/company/jake... Jake & Gino Instagram: https://www.instagram.com/jakeandgino/ #realestate #multifamilyrealestate #multifamilyinvesting #investing #apartmentinvesting #multifamily #realestateinvesting #commercialrealestate #loopnet #costart #biggerpockets #realestateinvest #multifamilyapartment #apartmentbuildings #multifamilydeals #multifamilyanalysis #analyzemultifamily #Multifamilyunderwriting #multifamilycommunity #multifamilyinvestors

Cloud N Clear is LIVE NOW!

About BrianBrian is an accomplished dealmaker with experience ranging from developer platforms to mobile services. Before InfluxData, Brian led business development at Twilio. Joining at just thirty-five employees, he built over 150 partnerships globally from the company's infancy through its IPO in 2016. He led the company's international expansion, hiring its first teams in Europe, Asia, and Latin America. Prior to Twilio Brian was VP of Business Development at Clearwire and held management roles at Amp'd Mobile, Kivera, and PlaceWare.Links Referenced:InfluxData: https://www.influxdata.com/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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.Corey: This episode is bought to you in part by our friends at Veeam. Do you care about backups? Of course you don't. Nobody cares about backups. Stop lying to yourselves! You care about restores, usually right after you didn't care enough about backups.  If you're tired of the vulnerabilities, costs and slow recoveries when using snapshots to restore your data, assuming you even have them at all living in AWS-land, there is an alternative for you. Check out Veeam, thats V-E-E-A-M for secure, zero-fuss AWS backup that won't leave you high and dry when it's time to restore. Stop taking chances with your data. Talk to Veeam. My thanks to them for sponsoring this ridiculous podcast.Corey: This episode is brought to us by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone vector database let your applications understand and act on what your users want… without making them spell it out.Make your search application find results by meaning instead of just keywords, your personalization system make picks based on relevance instead of just tags, and your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit Pinecone.io to understand more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. It's been a year, which means it's once again time to have a promoted guest episode brought to us by our friends at InfluxData. Joining me for a second time is Brian Mullen, CMO over at InfluxData. Brian, thank you for agreeing to do this a second time. You're braver than most.Brian: Thanks, Corey. I'm happy to be here. Second time is the charm.Corey: So, it's been an interesting year to put it mildly and I tend to have the attention span of a goldfish of most days, so for those who are similarly flighty, let's start at the very top. What is an InfluxDB slash InfluxData slash Influx—when you're not sure which one to use, just shorten it and call it good—and why might someone need it?Brian: Sure. So, InfluxDB is what most people understand our product as, a pretty popular open-source product, been out for quite a while. And then our company, InfluxData is the company behind InfluxDB. And InfluxDB is where developers build IoT real-time analytics and cloud applications, typically all based on time series. It's a time-series data platform specifically built to handle time-series data, which we think about is any type of data that is stamped in time in some way.It could be metrics, like, taken every one second, every two seconds, every three seconds, or some kind of event that occurs and is stamped in time in some way. So, our product and platform is really specialized to handle that technical problem.Corey: When last we spoke, I contextualized that in the realm of an IoT sensor that winds up reporting its device ID and its temperature at a given timestamp. That is sort of baseline stuff that I think aligns with what we're talking about. But over the past year, I started to see it in a bit of a different light, specifically viewing logs as time-series data, which hadn't occurred to me until relatively recently. And it makes perfect sense, on some level. It's weird to contextualize what Influx does as being a logging database, but there's absolutely no reason it couldn't be.Brian: Yeah, it certainly could. So typically, we see the world of time-series data in kind of two big realms. One is, as you mentioned the, you know, think of it as the hardware or, you know, physical realm: devices and sensors, these are things that are going to show up in a connected car, in a factory deployment, in renewable energy, you know, wind farm. And those are real devices and pieces of hardware that are out in the physical world, collecting data and emitting, you know, time-series every one second, or five seconds, or ten minutes, or whatever it might be.But it also, as you mentioned, applies to, call it the virtual world, which is really all of the software and infrastructure that is being stood up to run applications and services. And so, in that world, it could be the same—it's just a different type of source, but is really kind of the same technical problem. It's still time-series data being stamped, you know, data being stamped every, you know, one second, every five seconds, in some cases, every millisecond, but it is coming from a source that is actually in the infrastructure. Could be, you know, virtual machines, it could be containers, it could be microservices running within those containers. And so, all of those things together, both in the physical world and this infrastructure world are all emitting time-series data.Corey: When you take a look at the broader ecosystem, what is it that you see that has been the most misunderstood about time-series data as a whole? For example, when I saw AWS talking about a lot of things that they did in the realm of for your data lake, I talked to clients of mine about this and their response is, “Well, that'd be great genius, if we had a data lake.” It's, “What do you think those petabytes of nonsense in S3 are?” “Oh, those are the logs and the assets and a bunch of other nonsense.” “Yeah, that's what other people are calling a data lake.” “Oh.” Do you see similar lights-go-on moment when you talk to clients and prospective clients about what it is that they're doing that they just hadn't considered to be time-series data previously?Brian: Yeah. In fact, that's exactly what we see with many of our customers is they didn't realize that all of a sudden, they are now handling a pretty sizable time-series workload. And if you kind of take a step back and look at a couple of pretty obvious but sometimes unrecognized trends in technology, the first is cloud applications in general are expanding, they're both—horizontally and vertically. So, that means, like, the workloads that are being run in the Netflix's of the world, or all the different infrastructure that's being spun up in the cloud to run these various, you know, applications and services, those workloads are getting bigger and bigger, those companies and their subscriber bases, and the amount of data they're generating is getting bigger and bigger. They're also expanding horizontally by region and geography.So Netflix, for example, running not just in the US, but in every continent and probably every cloud region around the world. So, that's happening in the cloud world, and then also, in the IoT world, there's this massive growth of connected devices, both net-new devices that are being developed kind of, you know, the next Peloton or the next climate control unit that goes in an apartment or house, and also these longtime legacy devices that are been on the factory floor for a couple of decades, but now are being kind of modernized and coming online. So, if you look at all of that growth of the data sources now being built up in the cloud and you look at all that growth of these connected devices, both new and existing, that are kind of coming online, there's a huge now exponential growth in the sources of data. And all of these sources are emitting time-series data. You can just think about a connected car—not even a self-driving car, just a connected car, your everyday, kind of, 2022 model, and nearly every element of the car is emitting time-series data: its engine components, you know, your tires, like, what the climate inside of the car is, statuses of the engine itself, and it's all doing that in real-time, so every one second, every five seconds, whatever.So, I think in general, people just don't realize they're already dealing with a substantial workload of time series. And in most cases, unless they're using something like Influx, they're probably not, you know, especially tuned to handle it from a technology perspective.Corey: So, it's been a year. What has changed over on your side of the world since the last time we spoke? It seems that well, things continue and they're up and to the right. Well, sure, generally speaking, you're clearly still in business. Good job, always appreciative of your custom, as well as the fact that oh, good, even in a world where it seems like there's a macro recession in progress, that there are still companies out there that continue to persist and in some cases, dare I say, even thrive? What have you folks been up to?Brian: Yeah, it's been a big year. So first, we've seen quite a bit of expansion across the use cases. So, we've seen even further expansion in IoT, kind of expanding into consumer, industrial, and now sustainability and clean energy, and that pairs with what we've seen on FinTech and cryptocurrency, gaming and entertainment applications, network telemetry, including some of the biggest names in telecom, and then a little bit more on the cloud side with cloud services, infrastructure, and dev tools and APIs. So, quite a bit more broad set of use cases we're now seeing across the platform. And the second thing is—you might have seen it in the last month or so—is a pretty big announcement we had of our new storage engine.So, this was just announced earlier this month in November and was previously introduced to our community as what we call an IOx, which is how it was known in the open-source. And think of this really as a rebuilt and reimagined storage engine which is built on that open-source project, InfluxDB IOx that allows us to deliver faster queries, and now—pretty exciting for the first time—unlimited time-series, or cardinality as it's known in the space. And then also we introduced SQL for writing queries and BI tool support. And this is, for the first time we're introducing SQL, which is world's most popular data programming language to our platform, enabling developers to query via the API our language Flux, and InfluxQL in addition.Corey: A long time ago, it really seems that the cloud took a vote, for lack of a better term, and decided that when it comes to storage, object store is the way forward. It was a bit of a reimagining from how we all considered using storage previously, but the economics are at minimum of ten to one in favor of objects store, the latency is far better, the durability is off the charts better, you don't have to deal—at least in AWS-land—with the concept of availability zones and the rest, just from an economic and performance perspective, provided the use case embraces it, there's really no substitute.Brian: Yeah, I mean, the way we think about storage is, you know, obviously, it varies quite a bit from customer to customer with our use cases. Especially in IoT, we see some use cases where customers want to have data around for months and in some cases, years. So, it's a pretty substantial data set you're often looking at. And sometimes those customers want to downsample those, they don't necessarily need every single piece of minutia that they may need in real-time, but not in summary, looking backward. So, you really—we're in this kind of world where we're dealing with both hive fidelity—usually in the moment—data and lower fidelity, when people can downsample and have a little bit more of a summarized view of what happened.So, pretty unique for us and we have to kind of design the product in a way that is able to balance both of those because that's what, you know, the customer use cases demand. It's a super hard problem to solve. One of the reasons that you have a product like InfluxDB, which is specialized to handle this kind of thing, is so that you can actually manage that balance in your application service and setting your retention policy, et cetera.Corey: That's always been something that seemed a little on the odd side to me when I'm looking at a variety of different observability tools, where it seems that one of the key dimensions that they all tend to, I guess, operate on and price on is retention period. And I get it; you might not necessarily want to have your load balancer logs from 2012 readily available and paying for the privilege, but it does seem that given the dramatic fall of archival storage pricing, on some level, people do want to be able to retain that data just on the off chance that will be useful. Maybe that's my internal digital packrat chiming in at this point, but I do believe strongly that there is a correlation between how recent the data is and how useful it is, for a variety of different use cases. But that's also not a global truth. How do you view the divide? And what do you actually see people saying they want versus what they're actually using?Brian: It's a really good question and not a simple problem to solve. So, first of all, I would say it probably really depends on the use case and the extent to which that use case is touching real world applications and services. So, in a pure observability setting where you're looking at, perhaps more of a, kind of, operational view of infrastructure monitoring, you want to understand kind of what happened and when those tend to be a little bit more focused on real-time and recent. So, for example, you of course, want to know exactly what's happening in the moment, zero in on whatever anomaly and kind of surrounding data there is, perhaps that means you're digging into something that happened in you know, fairly recent time. So, those do tend to be, not all of them, but they do tend to be a little bit more real-time and recent-oriented.I think it's a little bit different when we look at IoT. Those generally tend to be longer timeframes that people are dealing with. Their physical out-in-the-field devices, you know, many times those devices are kind of coming online and offline, depending on the connectivity, depending on the environment, you can imagine a connected smart agriculture setup, I mean, those are a pretty wide array of devices out and in, you know, who knows what kind of climate and environment, so they tend to be a little bit longer in retention policy, kind of, being able to dig into the data, what's happening. The time frame that people are dealing with is just, in general, much longer in some of those situations.Corey: One story that I've heard a fair bit about observability data and event data is that they inevitably compose down into metrics rather than events or traces or logs, and I have a hard time getting there because I can definitely see a bunch of log entries showing the web servers return codes, okay, here's the number of 500 errors and number of different types of successes that we wind up seeing in the app. Yeah, all right, how many per minute, per second, per hour, whatever it is that makes sense that you can look at aberrations there. But in the development process at least, I find that having detailed log messages tell me about things I didn't see and need to understand or to continue building the dumb thing that I'm in the process of putting out. It feels like once something is productionalized and running, that its behavior is a lot more well understood, and at that point, metrics really seem to take over. How do you see it, given that you fundamentally live at that intersection where one can become the other?Brian: Yeah, we are right at that intersection and our answer probably would be both. Metrics are super important to understand and have that regular cadence and be kind of measuring that state over time, but you can miss things depending on how frequent those metrics are coming in. And increasingly, when you have the amount of data that you're dealing with coming from these various sources, the measurement is getting smaller and smaller. So, unless you have, you know, perfect metrics coming in every half-second, or you know, in some sub-partition of that, in milliseconds, you're likely to miss something. And so, events are really key to understand those things that pop up and then maybe come back down and in a pure metric setting, in your regular interval, you would have just completely missed. So, we see most of our use cases that are showing a balance of the two is kind of the most effective. And from a product perspective, that's how we think about solving the problem, addressing both.Corey: One of the things that I struggled with is it seems that—again, my approach to this is relatively outmoded. I was a systems administrator back when that title was not considered disparaging by a good portion of the technical community the way that it is today. Even though the job is the same, we call them something different now. Great. Okay, whatever smile, nod, and accept the larger paycheck.But my way of thinking about things are okay, you have the logs, they live on the server itself. And maybe if you want to be fancy, you wind up putting them to a centralized rsyslog cluster or whatnot. Yes, you might send them as well to some other processing system for visibility or a third-party monitoring system, but the canonical truth slash source of logs tends to live locally. That said, I got out of running production infrastructure before this idea of ephemeral containers or serverless functions really became a thing. Do you find that these days you are the source of truth slash custodian of record for these log entries, or do you find that you are more of a secondary source for better visibility and analysis, but not what they're going to bust out when the auditor comes calling in three years?Brian: I think, again, it—[laugh] I feel like I'm answering the same way [crosstalk 00:15:53]Corey: Yeah, oh, and of course, let's be clear, use cases are going to vary wildly. This is not advice on anyone's approach to compliance and the rest [laugh]. I don't want to get myself in trouble here.Brian: Exactly. Well, you know, we kind of think about it in terms of profiles. And we see a couple of different profiles of customers using InfluxDB. So, the first is, and this was kind of what we saw most often early on, still see quite a bit of them is kind of more of that operator profile. And these are folks who are going to—they're building some sort of monitor, kind of, source of truth for—that's internally facing to monitor applications or services, perhaps that other teams within their company built.And so that's, kind of like, a little bit more of your kind of pure operator. Yes, they're building up in the stack themselves, but it's to pay attention to essentially something that another team built. And then what we've seen more recently, especially as we've moved more prominently into the cloud and offered a usage-based service with a, you know, APIs and endpoint people can hit, as we see more people come into it from a builder's perspective. And similar in some ways, except that they're still building kind of a, you know, a source of truth for handling this kind of data. But they're also building the applications and services themselves are taken out to market that are in the hands of customers.And so, it's a little bit different mindset. Typically, there's, you know, a little bit more comfort with using one of many services to kind of, you know, be part of the thing that they're building. And so, we've seen a little bit more comfort from that type of profile, using our service running in the cloud, using the API, and not worrying too much about the kind of, you know, underlying setup of the implementation.Corey: Love how serverless helps you scale big and ship fast, but hate debugging your serverless apps? With Lumigo's serverless observability, it's fast and easy (and maybe a little fun, too). End-to-end distributed tracing gives developers full clarity into their most complex serverless and containerized applications, connecting every service from AWS Lambda and Amazon ECS to DynamoDB, API Gateways, Step Functions and more. Try Lumigo free and debug 3x faster, reduce error rate and speed up development. Visit snark.cloud/lumigo That's snark.cloud/L-U-M-I-G-OCorey: So, I've been on record a lot saying that the best database is TXT records stuffed into Route 53, which works super well as a gag, let's be clear, don't actually build something on top of this, that's a disaster waiting to happen. I don't want to destroy anyone's career as I do this. But you do have a much more viable competitive threat on the landscape. And that is quite simply using the open-source version of InfluxDB. What is the tipping point where, “Huh, I can run this myself,” turns into, “But I shouldn't. I should instead give money to other people to run it for me.”Because having been an engineer, where I believe I'm the world's greatest everything, when it comes to my environment—a fact provably untrue, but that hubris never quite goes away entirely—at what point am I basically being negligent not to start dealing with you in a more formalized business context?Brian: First of all, let me say that we have many customers, many developers out there who are running open-source and it works perfectly for them. The workload is just right, the deployment makes sense. And so, there are many production workloads we're using open-source. But typically, the kind of big turning point for people is on scale, scale, and overall performance related to that. And so, that's typically when they come and look at one of the two commercial offers.So, to start, open-source is a great place to, you know, kind of begin the journey, check it out, do that level of experimentation and kind of proof of concept. We also have 60,000-plus developers using our introductory cloud service, which is a free service. You simply sign up and can begin immediately putting data into the platform and building queries, and you don't have to worry about any of the setup and running servers to deploy software. So, both of those, the open-source and our cloud product are excellent ways to get started. And then when it comes time to really think about building in production and moving up in scale, we have our two commercial offers.And the first of those is InfluxDB Cloud, which is our cloud-native fully managed by InfluxData offering. We run this not only in AWS but also in Google Cloud and Microsoft Azure. It's a usage-based service, which means you pay exactly for what you use, and the three components that people pay for our data in, number of queries, and the amount of data you store in storage. We also for those who are interested in actually managing it themselves, we have InfluxDB Enterprise, which is a software subscription-base model, and it is self-managed by the customer in their environment. Now, that environment could be their own private cloud, it also could be on-premises in their own data center.And so, lots of fun people who are a little bit more oriented to kind of manage software themselves rather than using a service gear toward that. But both those commercial offers InfluxDB Cloud and InfluxDB Enterprise are really designed for, you know, massive scale. In the case of Cloud, I mentioned earlier with the new storage engine, you can hit unlimited cardinality, which means you have no limit on the number of time series you can put into the platform, which is a pretty big game-changing concept. And so, that means however many time-series sources you have and however many series they're emitting, you can run that without a problem without any sort of upper limit in our cloud product. Over on the enterprise side with our self-managed product, that means you can deploy a cluster of whatever size you want. It could be a two-by-four, it could be a four-by-eight, or something even larger. And so, it gives people that are managing in their own private cloud or in a data center environment, really their own options to kind of construct exactly what they need for their particular use case.Corey: Does your object storage layer make it easier to dynamically change clusters on the fly? I mean, historically, running things in a pre-provisioned cluster with EBS volumes or local disk was, “Oh, great. You want to resize something? Well, we're going to be either taking an outage or we're going to be building up something, migrating data live, and there's going to be a knife-switch cutover at some point that makes things relatively unfortunate.” It seems that once you abstract the storage layer away from anything resembling an instance that you would be able to get away from some of those architectural constraints.Brian: Yeah, that's really the promise, and what is delivered in our cloud product is that you no longer, as a developer, have to think about that if you're using that product. You don't have to think about how big the cluster is going to be, you don't have to think about these kind of disaster scenarios. It is all kind of pre-architected in the service. And so, the things that we really want to deliver to people, in addition to the elimination of that concern for what the underlying infrastructure looks like and how its operating. And so, with infrastructure concerns kind of out of the way, what we want to deliver on are kind of the things that people care most about: real-time query speed.So, now with this new storage engine, you can query data across any time series within milliseconds, 100 times faster queries against high cardinality data that was previously impossible. And we also have unlimited time-series volume. Again, any total number of time series you have, which is known as cardinality, is now able to run without a problem in the platform. And then we also have kind of opening up, we're opening up the aperture a bit for developers with SQL language support. And so, this is just a whole new world of flexibility for developers to begin building on the platform. And again, this is all in the way that people are using the product without having to worry about the underlying infrastructure.Corey: For most companies—and this does not apply to you—their core competency is not running time-series databases and the infrastructure attendant thereof, so it seems like it is absolutely a great candidate for, “You know, we really could make this someone else's problem and let us instead focus on the differentiated thing that we are doing or building or complaining about.”Brian: Yeah, that's a true statement. Typically what happens with time-series data is that people first of all, don't realize they have it, and then when they realize they have time-series data, you know, the first thing they'll do is look around and say, “Well, what do I have here?” You know, I have this relational database over here or this document database over here, maybe even this, kind of, search database over here, maybe that thing can handle time series. And in a light manner, it probably does the job. But like I said, the sources of data and just the volume of time series is expanding, really across all these different use cases, exponentially.And so, pretty quickly, people realize that thing that may be able to handle time series in some minor manner, is quickly no longer able to do it. They're just not purpose-built for it. And so, that's where really they come to a product like Influx to really handle this specific problem. We're built specifically for this purpose and so as the time-series workload expands when it kind of hits that tipping point, you really need a specialized tool.Corey: Last question, before I turn you loose to prepare for re:Invent, of course—well, I guess we'll ask you a little bit about that afterwards, but first, we can talk a lot theoretically about what your product could or might theoretically do. What are you actually seeing? What are the use cases that other than the stereotypical ones we've talked about, what have you seen people using it for that surprised you?Brian: Yeah, some of it is—it's just really interesting how it connects to, you know, things you see every day and/or use every day. I mean, chances are, many people listening have probably use InfluxDB and, you know, perhaps didn't know it. You know, if anyone has been to a home that has Tesla Powerwalls—Tesla is a customer of ours—then they've seen InfluxDB in action. Tesla's pulling time-series data from these connected Powerwalls that are in solar-powered homes, and they monitor things like health and availability and performance of those solar panels and the battery setup, et cetera. And they're collecting this at the edge and then sending that back into the hub where InfluxDB is running on their back end.So, if you've ever seen this deployed like that's InfluxDB running behind the scenes. Same goes, I'm sure many people have a Nest thermostat in their house. Nest monitors the infrastructure, actually the powers that collection of IoT data collection. So, you think of this as InfluxDB running behind the scenes to monitor what infrastructure is standing up that back-end Nest service. And this includes their use of Kubernetes and other software infrastructure that's run in their platform for collection, managing, transforming, and analyzing all of this aggregate device data that's out there.Another one, especially for those of us that streamed our minds out during the pandemic, Disney+ entertainment, streaming, and delivery of that to applications and to devices in the home. And so, you know, this hugely popular Disney+ streaming service is essentially a global content delivery network for distributing all these, you know, movies and video series to all the users worldwide. And they monitor the movement and performance of that video content through this global CDN using InfluxDB. So, those are a few where you probably walk by something like this multiple times a week, or in our case of Disney+ probably watching it once a day. And it's great to see InfluxDB kind of working behind the scenes there.Corey: It's one of those things where it's, I guess we'll call it plumbing, for lack of a better term. It's not the sort of thing that people are going to put front-and-center into any product or service that they wind up providing, you know, except for you folks. Instead, it's the thing that empowers a capability behind that product or service that is often taken for granted, just because until you understand the dizzying complexity, particularly at scale, of what these things have to do under the hood, it just—well yeah, of course, it works that way. Why shouldn't it? That's an expectation I have of the product because it's always had that. Yeah, but this is how it gets there.Brian: Our thesis really is that data is best understood through the lens of time. And as this data is expanding exponentially, time becomes increasingly the, kind of, common element, the common component that you're using to kind of view what happened. That could be what's running through a telecom network, what's happening with the devices that are connected that network, the movement of data through that network, and when, what's happening with subscribers and content pushing through a CDN on a streaming service, what's happening with climate and home data in hundreds of thousands, if not millions of homes through common device like a Nest thermostat. All of these things they attach to some real-world collection of data, and as long as that's happening, there's going to be a place for time-series data and tools that are optimized to handle it.Corey: So, my last question—for real this time—we are recording this the week before re:Invent 2022. What do you hope to see, what do you expect to see, what do you fear to see?Brian: No fears. Even though it's Vegas, no fears.Corey: I do have the super-spreader event fear, but that's a separate—Brian: [laugh].Corey: That's a separate issue. Neither one of us are deep into the epidemiology weeds, to my understanding. But yeah, let's just bound this to tech, let's be clear.Brian: Yeah, so first of all, we're really excited to go there. We'll have a pretty big presence. We have a few different locations where you can meet us. We'll have a booth on the main show floor, we'll be in the marketplace pavilion, as I mentioned, InfluxDB Cloud is offered across the marketplaces of each of the clouds, AWS, obviously in this case, but also in Azure and Google. But we'll be there in the AWS Marketplace pavilion, showcasing the new engine and a lot of the pretty exciting new use cases that we've been seeing.And we'll have our full team there, so if you're looking to kind of learn more about InfluxDB, or you've checked it out recently and want to understand kind of what the new capability is, we'll have many folks from our technical teams there, from our development team, some our field folks like the SEs and some of the product managers will be there as well. So, we'll have a pretty great collection of experts on InfluxDB to answer any questions and walk people through, you know, demonstrations and use cases.Corey: I look forward to it. I will be doing my traditional Wednesday afternoon tour through the expo halls and nature walk, so if you're listening to this and it's before Wednesday afternoon, come and find me. I am kicking off and ending at the [unintelligible 00:29:15] booth, but I will make it a point to come by the Influx booth and give you folks a hard time because that's what I do.Brian: We love it. Please. You know, being on the tour is—on the walking tour is excellent. We'll be mentally prepared. We'll have some comebacks ready for you.Corey: Therapists are standing by on both sides.Brian: Yes, exactly. Anyway, we're really looking forward to it. This will be my third year on your walking tour. So, the nature walk is one of my favorite parts of AWS re:Invent.Corey: Well, I appreciate that. Thank you. And thank you for your time today. I will let you get back to your no doubt frenzied preparations. At least they are on my side.Brian: We will. Thanks so much for having me and really excited to do it.Corey: Brian Mullen, CMO at InfluxData, I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that you naively believe will be stored as a TXT record in a DNS server somewhere rather than what is almost certainly a time-series database.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Louis Bailleul is a Chief Enterprise Architect at PGS. After years of running highly-ranked super computers to process PGS' seismic data, Louis's team at PGS has lead a transition to Google Cloud. Listen in to learn about HPC in Google Cloud with GKE, and to explore using Kubernetes to do processing on vessels at sea! Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod Chatter of the week Listen to the KubeCon NA 2022 recap episode News of the week Docker + Wasm Istio control plane vulnerability CVE-2022-39278 KubeFlow joins CNCF as an Incubating Project CNCF Backstage course CNCF Istio intro course Links from the interview PGS A picture of a PGS vessel PGS post from 2021 about their supercomputing rankings and transition to Google Cloud Top500 List Kubernetes Custom Resources (CRDs) Scaling Kubernetes to Thousands of CRDs Google Cloud Spot Instances Google Cloud Preemptible VM Instances Google Cloud - Manage capacity and quota KubeCon NA 2019: How the Department of Defense Moved to Kubernetes and Istio - Nicolas Chaillan Bare Metal K8s Clustering at Chick-fil-A Scale by Brian Chambers, Caleb Hurd, and Alex Crane

About AndiAndi Gutmans is the General Manager and Vice President for Databases at Google. Andi's focus is on building, managing and scaling the most innovative database services to deliver the industry's leading data platform for businesses. Before joining Google, Andi was VP Analytics at AWS running services such as Amazon Redshift. Before his tenure at AWS, Andi served as CEO and co-founder of Zend Technologies, the commercial backer of open-source PHP.Andi has over 20 years of experience as an open source contributor and leader. He co-authored open source PHP. He is an emeritus member of the Apache Software Foundation and served on the Eclipse Foundation's board of directors. He holds a bachelor's degree in Computer Science from the Technion, Israel Institute of Technology.Links Referenced: LinkedIn: https://www.linkedin.com/in/andigutmans/ Twitter: https://twitter.com/andigutmans TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you wanna learn more about how they view this, check out their blog, it's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit Sysdig.com and tell them that I sent you. That's S Y S D I G.com. And my thanks to them for their continued support of this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is brought to us by our friends at Google Cloud, and in so doing, they have gotten a guest to appear on this show that I have been low-key trying to get here for a number of years. Andi Gutmans is VP and GM of Databases at Google Cloud. Andi, thank you for joining me.Andi: Corey, thanks so much for having me.Corey: I have to begin with the obvious. Given that one of my personal passion projects is misusing every cloud service I possibly can as a database, where do you start and where do you stop as far as saying, “Yes, that's a database,” so it rolls up to me and, “No, that's not a database, so someone else can deal with the nonsense?”Andi: I'm in charge of the operational databases, so that includes both the managed third-party databases such as MySQL, Postgres, SQL Server, and then also the cloud-first databases, such as Spanner, Big Table, Firestore, and AlloyDB. So, I suggest that's where you start because those are all awesome services. And then what doesn't fall underneath, kind of, that purview are things like BigQuery, which is an analytics, you know, data warehouse, and other analytics engines. And of course, there's always folks who bring in their favorite, maybe, lesser-known or less popular database and self-manage it on GCE, on Compute.Corey: Before you wound up at Google Cloud, you spent roughly four years at AWS as VP of Analytics, which is, again, one of those very hazy type of things. Where does it start? Where does it stop? It's not at all clear from the outside. But even before that, you were, I guess, something of a legendary figure, which I know is always a weird thing for people to hear.But you were partially at least responsible for the Zend Framework in the PHP world, which I didn't realize what the heck that was, despite supporting it in production at a couple of jobs, until after I, for better or worse, was no longer trusted to support production environments anymore. Which, honestly, if you can get out, I'm a big proponent of doing that. You sleep so much better without a pager. How did you go from programming languages all the way on over to databases? It just seems like a very odd mix.Andi: Yeah. No, that's a great question. So, I was one of the core developers of PHP, and you know, I had been in the PHP community for quite some time. I also helped ideate. The Zend Framework, which was the company that, you know, I co-founded Zend Technologies was kind of the company behind PHP.So, like Red Hat supports Linux commercially, we supported PHP. And I was very much focused on developers, programming languages, frameworks, IDEs, and that was, you know, really exciting. I had also done quite a bit of work on interoperability with databases, right, because behind every application, there's a database, and so a lot of what we focused on is a great connectivity to MySQL, to Postgres, to other databases, and I got to kind of learn the database world from the outside from the application builders. We sold our company in I think it was 2015 and so I had to kind of figure out what's next. And so, one option would have been, hey, stay in programming languages, but what I learned over the many years that I worked with application developers is that there's a huge amount of value in data.And frankly, I'm a very curious person; I always like to learn, so there was this opportunity to join Amazon, to join the non-relational database side, and take myself completely out of my comfort zone. And actually, I joined AWS to help build the graph database Amazon Neptune, which was even more out of my comfort zone than even probably a relational database. So, I kind of like to do different things and so I joined and I had to learn, you know how to build a database pretty much from the ground up. I mean, of course, I didn't do the coding, but I had to learn enough to be dangerous, and so I worked on a bunch of non-relational databases there such as, you know, Neptune, Redis, Elasticsearch, DynamoDB Accelerator. And then there was the opportunity for me to actually move over from non-relational databases to analytics, which was another way to get myself out of my comfort zone.And so, I moved to run the analytic space, which included services like Redshift, like EMR, Athena, you name it. So, that was just a great experience for me where I got to work with a lot of awesome people and learn a lot. And then the opportunity arose to join Google and actually run the Google transactional databases including their older relational databases. And by the way, my job actually have two jobs. One job is running Spanner and Big Table for Google itself—meaning, you know, search ads and YouTube and everything runs on these databases—and then the second job is actually running external-facing databases for external customers.Corey: How alike are those two? Is it effectively the exact same thing, just with different API endpoints? Are they two completely separate universes? It's always unclear from the outside when looking at large companies that effectively eat versions of their own dog food, where their internal usage of these things starts and stops.Andi: So, great question. So, Cloud Spanner and Cloud Big Table do actually use the internal Spanner and Big Table. So, at the core, it's exactly the same engine, the same runtime, same storage, and everything. However, you know, kind of, internally, the way we built the database APIs was kind of good for scrappy, you know, Google engineers, and you know, folks are kind of are okay, learning how to fit into the Google ecosystem, but when we needed to make this work for enterprise customers, we needed a cleaner APIs, we needed authentication that was an external, right, and so on, so forth. So, think about we had to add an additional set of APIs on top of it, and management, right, to really make these engines accessible to the external world.So, it's running the same engine under the hood, but it is a different set of APIs, and a big part of our focus is continuing to expose to enterprise customers all the goodness that we have on the internal system. So, it's really about taking these very, very unique differentiated databases and democratizing access to them to anyone who wants to.Corey: I'm curious to get your position on the idea that seems to be playing it's—I guess, a battle that's been playing itself out in a number of different customer conversations. And that is, I guess, the theoretical decision between, do we go towards general-purpose databases and more or less treat every problem as a nail in search of a hammer or do you decide that every workload gets its own custom database that aligns the best with that particular workload? There are trade-offs in either direction, but I'm curious where you land on that given that you tend to see a lot more of it than I do.Andi: No, that's a great question. And you know, just for the viewers who maybe aren't aware, there's kind of two extreme points of view, right? There's one point of view that says, purpose-built for everything, like, every specific pattern, like, build bespoke databases, it's kind of a best-of-breed approach. The problem with that approach is it becomes extremely complex for customers, right? Extremely complex to decide what to use, they might need to use multiple for the same application, and so that can be a bit daunting as a customer. And frankly, there's kind of a law of diminishing returns at some point.Corey: Absolutely. I don't know what the DBA role of the future is, but I don't think anyone really wants it to be, “Oh, yeah. We're deciding which one of these three dozen manage database services is the exact right fit for each and every individual workload.” I mean, at some point it feels like certain cloud providers believe that not only every workload should have its own database, but almost every workload should have its own database service. It's at some point, you're allowed to say no and stop building these completely, what feel like to me, Byzantine, esoteric database engines that don't seem to have broad applicability to a whole lot of problems.Andi: Exactly, exactly. And maybe the other extreme is what folks often talk about as multi-model where you say, like, “Hey, I'm going to have a single storage engine and then map onto that the relational model, the document model, the graph model, and so on.” I think what we tend to see is if you go too generic, you also start having performance issues, you may not be getting the right level of abilities and trade-offs around consistency, and replication, and so on. So, I would say Google, like, we're taking a very pragmatic approach where we're saying, “You know what? We're not going to solve all of customer problems with a single database, but we're also not going to have two dozen.” Right?So, we're basically saying, “Hey, let's understand that the main characteristics of the workloads that our customers need to address, build the best services around those.” You know, obviously, over time, we continue to enhance what we have to fit additional models. And then frankly, we have a really awesome partner ecosystem on Google Cloud where if someone really wants a very specialized database, you know, we also have great partners that they can use on Google Cloud and get great support and, you know, get the rest of the benefits of the platform.Corey: I'm very curious to get your take on a pattern that I've seen alluded to by basically every vendor out there except the couple of very obvious ones for whom it does not serve their particular vested interests, which is that there's a recurring narrative that customers are demanding open-source databases for their workloads. And when you hear that, at least, people who came up the way that I did, spending entirely too much time on Freenode, back when that was not a deeply problematic statement in and of itself, where, yes, we're open-source, I guess, zealots is probably the best terminology, and yeah, businesses are demanding to participate in the open-source ecosystem. Here in reality, what I see is not ideological purity or anything like that and much more to do with, “Yeah, we don't like having a single commercial vendor for our databases that basically plays the insert quarter to continue dance whenever we're trying to wind up doing something new. We want the ability to not have licensing constraints around when, where, how, and how quickly we can run databases.” That's what I hear when customers are actually talking about open-source versus proprietary databases. Is that what you see or do you think that plays out differently? Because let's be clear, you do have a number of database services that you offer that are not open-source, but are also absolutely not tied to weird licensing restrictions either?Andi: That's a great question, and I think for years now, customers have been in a difficult spot because the legacy proprietary database vendors, you know, knew how sticky the database is, and so as a result, you know, the prices often went up and was not easy for customers to kind of manage costs and agility and so on. But I would say that's always been somewhat of a concern. I think what I'm seeing changing and happening differently now is as customers are moving into the cloud and they want to run hybrid cloud, they want to run multi-cloud, they need to prove to their regulator that it can do a stressed exit, right, open-source is not just about reducing cost, it's really about flexibility and kind of being in control of when and where you can run the workloads. So, I think what we're really seeing now is a significant surge of customers who are trying to get off legacy proprietary database and really kind of move to open APIs, right, because they need that freedom. And that freedom is far more important to them than even the cost element.And what's really interesting is, you know, a lot of these are the decision-makers in these enterprises, not just the technical folks. Like, to your point, it's not just open-source advocates, right? It's really the business people who understand they need the flexibility. And by the way, even the regulators are asking them to show that they can flexibly move their workloads as they need to. So, we're seeing a huge interest there and, as you said, like, some of our services, you know, are open-source-based services, some of them are not.Like, take Spanner, as an example, it is heavily tied to how we build our infrastructure and how we build our systems. Like, I would say, it's almost impossible to open-source Spanner, but what we've done is we've basically embraced open APIs and made sure if a customer uses these systems, we're giving them control of when and where they want to run their workloads. So, for example, Big Table has an HBase API; Spanner now has a Postgres interface. So, our goal is really to give customers as much flexibility and also not lock them into Google Cloud. Like, we want them to be able to move out of Google Cloud so they have control of their destiny.Corey: I'm curious to know what you see happening in the real world because I can sit here and come up with a bunch of very well-thought-out logical reasons to go towards or away from certain patterns, but I spent years building things myself. I know how it works, you grab the closest thing handy and throw it in and we all know that there is nothing so permanent as a temporary fix. Like, that thing is load-bearing and you'll retire with that thing still in place. In the idealized world, I don't think that I would want to take a dependency on something like—easy example—Spanner or AlloyDB because despite the fact that they have Postgres-squeal—yes, that's how I pronounce it—compatibility, the capabilities of what they're able to do under the hood far exceed and outstrip whatever you're going to be able to build yourself or get anywhere else. So, there's a dataflow architectural dependency lock-in, despite the fact that it is at least on its face, Postgres compatible. Counterpoint, does that actually matter to customers in what you are seeing?Andi: I think it's a great question. I'll give you a couple of data points. I mean, first of all, even if you take a complete open-source product, right, running them in different clouds, different on-premises environments, and so on, fundamentally, you will have some differences in performance characteristics, availability characteristics, and so on. So, the truth is, even if you use open-source, right, you're not going to get a hundred percent of the same characteristics where you run that. But that said, you still have the freedom of movement, and with I would say and not a huge amount of engineering investment, right, you're going to make sure you can run that workload elsewhere.I kind of think of Spanner in the similar way where yes, I mean, you're going to get all those benefits of Spanner that you can't get anywhere else, like unlimited scale, global consistency, right, no maintenance downtime, five-nines availability, like, you can't really get that anywhere else. That said, not every application necessarily needs it. And you still have that option, right, that if you need to, or want to, or we're not giving you a reasonable price or reasonable price performance, but we're starting to neglect you as a customer—which of course we wouldn't, but let's just say hypothetically, that you know, that could happen—that you still had a way to basically go and run this elsewhere. Now, I'd also want to talk about some of the upsides something like Spanner gives you. Because you talked about, you want to be able to just grab a few things, build something quickly, and then, you know, you don't want to be stuck.The counterpoint to that is with Spanner, you can start really, really small, and then let's say you're a gaming studio, you know, you're building ten titles hoping that one of them is going to take off. So, you can build ten of those, you know, with very minimal spend on Spanner and if one takes off overnight, it's really only the database where you don't have to go and re-architect the application; it's going to scale as big as you need it to. And so, it does enable a lot of this innovation and a lot of cost management as you try to get to that overnight success.Corey: Yeah, overnight success. I always love that approach. It's one of those, “Yeah, I became an overnight success after only ten short years.” It becomes this idea people believe it's in fits and starts, but then you see, I guess, on some level, the other side of it where it's a lot of showing up and doing the work. I have to confess, I didn't do a whole lot of admin work in my production years that touched databases because I have an aura and I'm unlucky, and it turns out that when you blow away some web servers, everyone can laugh and we'll reprovision stateless things.Get too close to the data warehouse, for example, and you don't really have a company left anymore. And of course, in the world of finance that I came out of, transactional integrity is also very much a thing. A question that I had [centers 00:17:51] really around one of the predictions you gave recently at Google Cloud Next, which is your prediction for the future is that transactional and analytical workloads from a database perspective will converge. What's that based on?Andi: You know, I think we're really moving from a world where customers are trying to make real-time decisions, right? If there's model drift from an AI and ML perspective, want to be able to retrain their models as quickly as possible. So, everything is fast moving into streaming. And I think what you're starting to see is, you know, customers don't have that time to wait for analyzing their transactional data. Like in the past, you do a batch job, you know, once a day or once an hour, you know, move the data from your transactional system to analytical system, but that's just not how it is always-on businesses run anymore, and they want to have those real-time insights.So, I do think that what you're going to see is transactional systems more and more building analytical capabilities, analytical systems building, and more transactional, and then ultimately, cloud platform providers like us helping fill that gap and really making data movement seamless across transactional analytical, and even AI and ML workloads. And so, that's an area that I think is a big opportunity. I also think that Google is best positioned to solve that problem.Corey: Forget everything you know about SSH and try Tailscale. Imagine if you didn't need to manage PKI or rotate SSH keys every time someone leaves. That'd be pretty sweet, wouldn't it? With Tailscale SSH, you can do exactly that. Tailscale gives each server and user device a node key to connect to its VPN, and it uses the same node key to authorize and authenticate SSH.Basically you're SSHing the same way you manage access to your app. What's the benefit here? Built-in key rotation, permissions as code, connectivity between any two devices, reduce latency, and there's a lot more, but there's a time limit here. You can also ask users to reauthenticate for that extra bit of security. Sounds expensive?Nope, I wish it were. Tailscale is completely free for personal use on up to 20 devices. To learn more, visit snark.cloud/tailscale. Again, that's snark.cloud/tailscaleCorey: On some level, I've found that, at least in my own work, that once I wind up using a database for something, I'm inclined to try and stuff as many other things into that database as I possibly can just because getting a whole second data store, taking a dependency on it for any given workload tends to be a little bit on the, I guess, challenging side. Easy example of this. I've talked about it previously in various places, but I was talking to one of your colleagues, [Sarah Ellis 00:19:48], who wound up at one point making a joke that I, of course, took way too far. Long story short, I built a Twitter bot on top of Google Cloud Functions that every time the Azure brand account tweets, it simply quote-tweets that translates their tweet into all caps, and then puts a boomer-style statement in front of it if there's room. This account is @cloudboomer.Now, the hard part that I had while doing this is everything stateless works super well. Where do I wind up storing the ID of the last tweet that it saw on his previous run? And I was fourth and inches from just saying, “Well, I'm already using Twitter so why don't we use Twitter as a database?” Because everything's a database if you're either good enough or bad enough at programming. And instead, I decided, okay, we'll try this Firebase thing first.And I don't know if it's Firestore, or Datastore or whatever it's called these days, but once I wrap my head around it incredibly effective, very fast to get up and running, and I feel like I made at least a good decision, for once in my life, involving something touching databases. But it's hard. I feel like I'm consistently drawn toward the thing I'm already using as a default database. I can't shake the feeling that that's the wrong direction.Andi: I don't think it's necessarily wrong. I mean, I think, you know, with Firebase and Firestore, that combination is just extremely easy and quick to build awesome mobile applications. And actually, you can build mobile applications without a middle tier which is probably what attracted you to that. So, we just see, you know, huge amount of developers and applications. We have over 4 million databases in Firestore with just developers building these applications, especially mobile-first applications. So, I think, you know, if you can get your job done and get it done effectively, absolutely stick to them.And by the way, one thing a lot of people don't know about Firestore is it's actually running on Spanner infrastructure, so Firestore has the same five-nines availability, no maintenance downtime, and so on, that has Spanner, and the same kind of ability to scale. So, it's not just that it's quick, it will actually scale as much as you need it to and be as available as you need it to. So, that's on that piece. I think, though, to the same point, you know, there's other databases that we're then trying to make sure kind of also extend their usage beyond what they've traditionally done. So, you know, for example, we announced AlloyDB, which I kind of call it Postgres on steroids, we added analytical capabilities to this transactional database so that as customers do have more data in their transactional database, as opposed to having to go somewhere else to analyze it, they can actually do real-time analytics within that same database and it can actually do up to 100 times faster analytics than open-source Postgres.So, I would say both Firestore and AlloyDB, are kind of good examples of if it works for you, right, we'll also continue to make investments so the amount of use cases you can use these databases for continues to expand over time.Corey: One of the weird things that I noticed just looking around this entire ecosystem of databases—and you've been in this space long enough to, presumably, have seen the same type of evolution—back when I was transiting between different companies a fair bit, sometimes because I was consulting and other times because I'm one of the greatest in the world at getting myself fired from jobs based upon my personality, I found that the default standard was always, “Oh, whatever the database is going to be, it started off as MySQL and then eventually pivots into something else when that starts falling down.” These days, I can't shake the feeling that almost everywhere I look, Postgres is the answer instead. What changed? What did I miss in the ecosystem that's driving that renaissance, for lack of a better term?Andi: That's a great question. And, you know, I have been involved in—I'm going to date myself a bit—but in PHP since 1997, pretty much, and one of the things we kind of did is we build a really good connector to MySQL—and you know, I don't know if you remember, before MySQL, there was MS SQL. So, the MySQL API actually came from MS SQL—and we bundled the MySQL driver with PHP. And so, kind of that LAMP stack really took off. And kind of to your point, you know, the default in the web, right, was like, you're going to start with MySQL because it was super easy to use, just fun to use.By the way, I actually wrote—co-authored—the tab completion in the MySQL client. So like, a lot of these kinds of, you know, fun, simple ways of using MySQL were there, and frankly, was super fast, right? And so, kind of those fast reads and everything, it just was great for web and for content. And at the time, Postgres kind of came across more like a science project. Like the folks who were using Postgres were kind of the outliers, right, you know, the less pragmatic folks.I think, what's changed over the past, how many years has it been now, 25 years—I'm definitely dating myself—is a few things: one, MySQL is still awesome, but it didn't kind of go in the direction of really, kind of, trying to catch up with the legacy proprietary databases on features and functions. Part of that may just be that from a roadmap perspective, that's not where the owner wanted it to go. So, MySQL today is still great, but it didn't go into that direction. In parallel, right, customers wanting to move more to open-source. And so, what they found this, the thing that actually looks and smells more like legacy proprietary databases is actually Postgres, plus you saw an increase of investment in the Postgres ecosystem, also very liberal license.So, you have lots of other databases including commercial ones that have been built off the Postgres core. And so, I think you are today in a place where, for mainstream enterprise, Postgres is it because that is the thing that has all the features that the enterprise customer is used to. MySQL is still very popular, especially in, like, content and web, and mobile applications, but I would say that Postgres has really become kind of that de facto standard API that's replacing the legacy proprietary databases.Corey: I've been on the record way too much as saying, with some justification, that the best database in the world that should be used for everything is Route 53, specifically, TXT records. It's a key-value store and then anyone who's deep enough into DNS or databases generally gets a slightly greenish tinge and feels ill. That is my simultaneous best and worst database. I'm curious as to what your most controversial opinion is about the worst database in the world that you've ever seen.Andi: This is the worst database? Or—Corey: Yeah. What is the worst database that you've ever seen? I know, at some level, since you manage all things database, I'm asking you to pick your least favorite child, but here we are.Andi: Oh, that's a really good question. No, I would say probably the, “Worst database,” double-quotes is just the file system, right? When folks are basically using the file system as regular database. And that can work for, you know, really simple apps, but as apps get more complicated, that's not going to work. So, I've definitely seen some of that.I would say the most awesome database that is also file system-based kind of embedded, I think was actually SQLite, you know? And SQLite is actually still very, very popular. I think it sits on every mobile device pretty much on the planet. So, I actually think it's awesome, but it's, you know, it's on a database server. It's kind of an embedded database, but it's something that I, you know, I've always been pretty excited about. And, you know, their stuff [unintelligible 00:27:43] kind of new, interesting databases emerging that are also embedded, like DuckDB is quite interesting. You know, it's kind of the SQLite for analytics.Corey: We've been using it for a few things around a bill analysis ourselves. It's impressive. I've also got to say, people think that we had something to do with it because we're The Duckbill Group, and it's DuckDB. “Have you done anything with this?” And the answer is always, “Would you trust me with a database? I didn't think so.” So no, it's just a weird coincidence. But I liked that a lot.It's also counterintuitive from where I sit because I'm old enough to remember when Microsoft was teasing the idea of WinFS where they teased a future file system that fundamentally was a database—I believe it's an index or journal for all of that—and I don't believe anything ever came of it. But ugh, that felt like a really weird alternate world we could have lived in.Andi: Yeah. Well, that's a good point. And by the way, you know, if I actually take a step back, right, and I kind of half-jokingly said, you know, file system and obviously, you know, all the popular databases persist on the file system. But if you look at what's different in cloud-first databases, right, like, if you look at legacy proprietary databases, the typical setup is wright to the local disk and then do asynchronous replication with some kind of bounded replication lag to somewhere else, to a different region, or so on. If you actually start to look at what the cloud-first databases look like, they actually write the data in multiple data centers at the same time.And so, kind of joke aside, as you start to think about, “Hey, how do I build the next generation of applications and how do I really make sure I get the resiliency and the durability that the cloud can offer,” it really does take a new architecture. And so, that's where things like, you know, Spanner and Big Table, and kind of, AlloyDB databases are truly architected for the cloud. That's where they actually think very differently about durability and replication, and what it really takes to provide the highest level of availability and durability.Corey: On some level, I think one of the key things for me to realize was that in my own experiments, whenever I wind up doing something that is either for fun or I just want see how it works in what's possible, the scale of what I'm building is always inherently a toy problem. It's like the old line that if it fits in RAM, you don't have a big data problem. And then I'm looking at things these days that are having most of a petabyte's worth of RAM sometimes it's okay, that definition continues to extend and get ridiculous. But I still find that most of what I do in a database context can be done with almost any database. There's no reason for me not to, for example, uses a SQLite file or to use an object store—just there's a little latency, but whatever—or even a text file on disk.The challenge I find is that as you start scaling and growing these things, you start to run into limitations left and right, and only then it's one of those, oh, I should have made different choices or I should have built-in abstractions. But so many of these things comes to nothing; it just feels like extra work. What guidance do you have for people who are trying to figure out how much effort to put in upfront when they're just more or less puttering around to see what comes out of it?Andi: You know, we like to think about ourselves at Google Cloud as really having a unique value proposition that really helps you future-proof your development. You know, if I look at both Spanner and I look at BigQuery, you can actually start with a very, very low cost. And frankly, not every application has to scale. So, you can start at low cost, you can have a small application, but everyone wants two things: one is availability because you don't want your application to be down, and number two is if you have to scale you want to be able to without having to rewrite your application. And so, I think this is where we have a very unique value proposition, both in how we built Spanner and then also how we build BigQuery is that you can actually start small, and for example, on Spanner, you can go from one-tenth of what we call an instance, like, a small instance, that is, you know, under $65 a month, you can go to a petabyte scale OLTP environment with thousands of instances in Spanner, with zero downtime.And so, I think that is really the unique value proposition. We're basically saying you can hold the stick at both ends: you can basically start small and then if that application doesn't need to scale, does need to grow, you're not reengineering your application and you're not taking any downtime for reprovisioning. So, I think that's—if I had to give folks, kind of, advice, I say, “Look, what's done is done. You have workloads on MySQL, Postgres, and so on. That's great.”Like, they're awesome databases, keep on using them. But if you're truly building a new app, and you're hoping that app is going to be successful at some point, whether it's, like you said, all overnight successes take at least ten years, at least you built in on something like Spanner, you don't actually have to think about that anymore or worry about it, right? It will scale when you need it to scale and you're not going to have to take any downtime for it to scale. So, that's how we see a lot of these industries that have these potential spikes, like gaming, retail, also some use cases in financial services, they basically gravitate towards these databases.Corey: I really want to thank you for taking so much time out of your day to talk with me about databases and your perspective on them, especially given my profound level of ignorance around so many of them. If people want to learn more about how you view these things, where's the best place to find you?Andi: Follow me on LinkedIn. I tend to post quite a bit on LinkedIn, I still post a bit on Twitter, but frankly, I've moved more of my activity to LinkedIn now. I find it's—Corey: That is such a good decision. I envy you.Andi: It's a more curated [laugh], you know, audience and so on. And then also, you know, we just had Google Cloud Next. I recorded a session there that kind of talks about database and just some of the things that are new in database-land at Google Cloud. So, that's another thing that if folks more interested to get more information, that may be something that could be appealing to you.Corey: We will, of course, put links to all of this in the [show notes 00:34:03]. Thank you so much for your time. I really appreciate it.Andi: Great. Corey, thanks so much for having me.Corey: Andi Gutmans, VP and GM of Databases at Google Cloud. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry, insulting comment, then I'm going to collect all of those angry, insulting comments and use them as a database.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

About AshishAshish has over 13+yrs experience in the Cybersecurity industry with the last 7 focusing primarily helping Enterprise with managing security risk at scale in cloud first world and was the CISO of a global Cloud First Tech company in his last role. Ashish is also a keynote speaker and host of the widely poplar Cloud Security Podcast, a SANS trainer for Cloud Security & DevSecOps. Ashish currently works at Snyk as a Principal Cloud Security Advocate. He is a frequent contributor on topics related to public cloud transformation, Cloud Security, DevSecOps, Security Leadership, future Tech and the associated security challenges for practitioners and CISOs.Links Referenced: Cloud Security Podcast: https://cloudsecuritypodcast.tv/ Personal website: https://www.ashishrajan.com/ LinkedIn: https://www.linkedin.com/in/ashishrajan/ Twitter: https://twitter.com/hashishrajan Cloud Security Podcast YouTube: https://www.youtube.com/c/CloudSecurityPodcast Cloud Security Podcast LinkedIn: https://www.linkedin.com/company/cloud-security-podcast/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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.Corey: This episode is sponsored in part by our friends at Thinkst Canary. Most folks find out way too late that they've been breached. Thinkst Canary changes this. Deploy canaries and canary tokens in minutes, and then forget about them. Attackers tip their hand by touching them, giving you one alert, when it matters. With zero administrative overhead to this and almost no false positives, Canaries are deployed and loved on all seven continents. Check out what people are saying at canary.love today. Corey: This episode is bought to you in part by our friends at Veeam. Do you care about backups? Of course you don't. Nobody cares about backups. Stop lying to yourselves! You care about restores, usually right after you didn't care enough about backups.  If you're tired of the vulnerabilities, costs and slow recoveries when using snapshots to restore your data, assuming you even have them at all living in AWS-land, there is an alternative for you. Check out Veeam, thats V-E-E-A-M for secure, zero-fuss AWS backup that won't leave you high and dry when it's time to restore. Stop taking chances with your data. Talk to Veeam. My thanks to them for sponsoring this ridiculous podcast.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is brought to us once again by our friends at Snyk. Snyk does amazing things in the world of cloud security and terrible things with the English language because, despite raising a whole boatload of money, they still stubbornly refuse to buy a vowel in their name. I'm joined today by Principal Cloud Security Advocate from Snyk, Ashish Rajan. Ashish, thank you for joining me.Corey: Your history is fascinating to me because you've been around for a while on a podcast of your own, the Cloud Security Podcast. But until relatively recently, you were a CISO. As has become relatively accepted in the industry, the primary job of the CISO is to get themselves fired, and then, “Well, great. What's next?” Well, failing upward is really the way to go wherever possible, so now you are at Snyk, helping the rest of us fix our security. That's my headcanon on all of that anyway, which I'm sure bears scant, if any, resemblance to reality, what's your version?Ashish: [laugh]. Oh, well, fortunately, I wasn't fired. And I think I definitely find that it's a great way to look at the CISO job to walk towards the path where you're no longer required because then I think you've definitely done your job. I moved into the media space because we got an opportunity to go full-time. I spoke about this offline, but an incident inspired us to go full-time into the space, so that's what made me leave my CISO job and go full-time into democratizing cloud security as much as possible for anyone and everyone. So far, every day, almost now, so it's almost like I dream about cloud security as well now.Corey: Yeah, I dream of cloud security too, but my dreams are of a better world in which people didn't tell me how much they really care about security in emails that demonstrate how much they failed to care about security until it was too little too late. I was in security myself for a while and got out of it because I was tired of being miserable all the time. But I feel that there's a deep spiritual alignment between people who care about cost and people who care about security when it comes to cloud—or business in general—because you can spend infinite money on those things, but it doesn't really get your business further. It's like paying for fire insurance. It isn't going to get you to your next milestone, whereas shipping faster, being more effective at launching a feature into markets, that can multiply revenue. That's what companies are optimized around. It's, “Oh, right. We have to do the security stuff,” or, “We have to fix the AWS billing piece.” It feels, on some level, like it's a backburner project most of the time and it's certainly invested in that way. What's your take on that?Ashish: I tend to disagree with that, for a couple reasons.Corey: Excellent. I love arguments.Ashish: I feel this in a healthy way as well. A, I love the analogy of spiritual animals where they are cost optimization as well as the risk aversion as well. I think where I normally stand—and this is what I had to unlearn after doing years of cybersecurity—was that initially, we always used to be—when I say ‘we,' I mean cybersecurity folks—we always used to be like police officers. Is that every time there's an incident, it turns into a crime scene, and suddenly we're all like, “Pew, pew, pew,” with trying to get all the evidence together, let's make this isolated as much—as isolated as possible from the rest of the environment, and let's try and resolve this.I feel like in Cloud has asked people to become more collaborative, which is a good problem to have. It also encourages that, I don't know how many people know this, but the reason we have brakes in our cars is not because we can slow down the car; it's so that we can go faster. And I feel security is the same thing. The guardrails we talk about, the risks that you're trying to avert, the reason you're trying to have security is not to slow down but to go faster. Say for example in an ideal world, to quote what you were saying earlier if we were to do the right kind of encryption—I'm just going to use the most basic example—if we just do encryption, right, and just ensure that as a guardrail, the entire company needs to have encryption at rest, encryption in transit, period, nothing else, no one cares about anything else.But if you just lay that out as a framework and this is our guardrail, no one brakes this, and whoever does, hey we—you know, slap on the wrist and come back on to the actual track, but keep going forward. That just means any project that comes in that meets [unintelligible 00:04:58] criteria. Keeps going forward, as many times we want to go into production. Doesn't matter. So, that is the new world of security that we are being asked to move towards where Amazon re:Invent is coming in, there will be another, I don't know, three, four hundred services that will be released. How many people, irrespective of security, would actually know all of those services? They would not. So, [crosstalk 00:05:20]—Corey: Oh, we've long since passed the point where I can convincingly talk about AWS services that don't really exist and not get called out on it by Amazon employees. No one keeps them on their head. Except me because I'm sad.Ashish: Oh, no, but I think you're right, though. I can't remember who was it—maybe Andrew Vogel or someone—they didn't release a service which didn't exist, and became, like, a thing on Twitter. Everyone—Corey: Ah, AWS's Infinidash. I want to say that was Joe Nash out of Twilio at the time. I don't recall offhand if I'm right on that, but that's how it feels. Yeah, it was certainly not me. People said that was my idea. Nope, nope, I just basically amplified it to a huge audience.But yeah, it was a brilliant idea, just because it's a fake service so everyone could tell stories about it. And amazing product feedback, if you look at it through the right lens of how people view your company and your releases when they get this perfect, platonic ideal of what it is you might put out there, what do people say about it?Ashish: Yeah. I think that's to your point, I will use that as an example as well to talk about things that there will always be a service which we will be told about for the first time, which we will not know. So, going back to the unlearning part, as a security team, we just have to understand that we can't use the old ways of, hey, I want to have all the controls possible, cover all there is possible. I need to have a better understanding of all the cloud services because I've done, I don't know, 15 years of cloud, there is no one that has 10, 15 years of cloud unless you're I don't know someone from Amazon employee yourself. Most people these days still have five to six years experience and they're still learning.Even the cloud engineering folks or the DevOps folks, they're all still learning and the tooling is continuing to evolve. So yeah, I think I definitely find that the security in this cloud world a lot more collaborative and it's being looked at as the same function as a brake would have in car: to help you go faster, not to just slam the brake every time it's like, oh, my God, is the situation isolated and to police people.Corey: One of the points I find that is so aligned between security and cost—and you alluded to it a minute ago—is the idea of helping companies go faster safely. To that end, guardrails have to be at least as easy as just going off and doing it cow-person style. Because if it's not, it's more work in any way, shape, or form, people won't do it. People will not tag their resources by hand, people will not go through and use the dedicated account structure you've got that gets in their way and screams at them every time they try to use one of the native features built into the platform. It has to get out of their way and make things easier, not worse, or people fight it, they go around it, and you're never going to get buy-in.Ashish: Do you feel like cost is something that a lot more people pay a lot more attention to because, you know, that creeps into your budget? Like, as people who've been leaders before, and this was the conversation, they would just go, “Well, I only have, I don't know, 100,000 to spend this quarter,” or, “This year,” and they are the ones who—are some of them, I remember—I used to have this manager, once, a CTO would always be conscious about the spend. It's almost like if you overspend, where do you get the money from? There's no money to bring in extra. Like, no. There's a set money that people plan for any year for a budget. And to your point about if you're not keeping an eye on how are we spending this in the AWS context because very easy to spend the entire money in one day, or in the cloud context. So, I wonder if that is also a big driver for people to feel costs above security? Where do you stand on that?Corey: When it comes to cost, one of the nice things about it—and this is going to sound sarcastic, but I swear to you it's not—it's only money.Ashish: Mmm.Corey: Think about that for a second because it's true. Okay, we wound up screwing up and misconfiguring something and overspending. Well, there are ways around that. You can call AWS, you can get credits, you can get concessions made for mistakes, you can sign larger contracts and get a big pile of proof of concept credit et cetera, et cetera. There are ways to make that up, whereas with security, it's there are no do-overs on security breaches.Ashish: No, that's a good point. I mean, you can always get more money, use a credit card, worst case scenario, but you can't do the same for—there's a security breach and suddenly now—hopefully, you don't have to call New York Times and say, “Can you undo that article that you just have posted that told you it was a mistake. We rewinded what we did.”Corey: I'm curious to know what your take is these days on the state of the cloud security community. And the reason I bring that up is, well, I started about a year-and-a-half ago now doing a podcast every Thursday. Which is Last Week in AWS: Security Edition because everything else I found in the industry that when I went looking was aimed explicitly at either—driven by the InfoSec community, which is toxic and a whole bunch of assumed knowledge already built in that looks an awful lot like gatekeeping, which is the reason I got out of InfoSec in the first place, or alternately was completely vendor-captured, where, okay, great, we're going to go ahead and do a whole bunch of interesting content and it's all brought to you by this company and strangely, all of the content is directly align with doing some pretty weird things that you wouldn't do unless you're trying to build a business case for that company's product. And it just feels hopelessly compromised. I wanted to find something that was aimed at people who had to care about security but didn't have security as part of their job title. Think DevOps types and you're getting warmer.That's what I wound up setting out to build. And when all was said and done, I wasn't super thrilled with, honestly, how alone it still felt. You've been doing this for a while, and you're doing a great job at it, don't get me wrong, but there is the question that—and I understand they're sponsoring this episode, but the nice thing about promoted guest episodes is that they can buy my attention, not my opinion. How do you retain creative control of your podcast while working for a security vendor?Ashish: So, that's a good question. So, Snyk by themselves have not ever asked us to change any piece of content; we have been working with them for the past few months now. The reason we kind of came along with Snyk was the alignment. And we were talking about this earlier for I totally believe that DevSecOps and cloud security are ultimately going to come together one day. That may not be today, that may not be tomorrow, that may not be in 2022, or maybe 2023, but there will be a future where these two will sit together.And the developer-first security mentality that they had, in this context from cloud prospective—developers being the cloud engineers, the DevOps people as you called out, the reason you went in that direction, I definitely want to work with them. And ultimately, there would never be enough people in security to solve the problem. That is the harsh reality. There would never be enough people. So, whether it's cloud security or not, like, for people who were at AWS re:Inforce, the first 15 minutes by Steve Schmidt, CSO of Amazon, was get a security guardian program.So, I've been talking about it, everyone else is talking about right now, Amazon has become the first CSP to even talk about this publicly as well that we should have security guardians. Which by the way, I don't know why, but you can still call it—it is technically DevSecOps what you're trying to do—they spoke about a security champion program as part of the keynote that they were running. Nothing to do with cloud security, but the idea being how much of this workload can we share? We can raise, as a security team—for people who may be from a security background listening to this—how much elevation can we provide the risk in front of the right people who are a decision-maker? That is our role.We help them with the governance, we help with managing it, but we don't know how to solve the risk or close off a risk, or close off a vulnerability because you might be the best person because you work in that application every day, every—you know the bandages that are put in, you know all the holes that are there, so the best threat model can be performed by the person who works on a day-to-day, not a security person who spent, like, an hour with you once a week because that's the only time they could manage. So, going back to the Snyk part, that's the mission that we've had with the podcast; we want to democratize cloud security and build a community around neutral information. There is no biased information. And I agree with what you said as well, where a lot of the podcasts outside of what we were finding was more focused on, “Hey, this is how you use AWS. This is how you use Azure. This is how you use GCP.”But none of them were unbiased in the opinion. Because real life, let's just say even if I use the AWS example—because we are coming close to the AWS re:Invent—they don't have all the answers from a security perspective. They don't have all the answers from an infrastructure perspective or cloud-native perspective. So, there are some times—or even most times—people are making a call where they're going outside of it. So, unbiased information is definitely required and it is not there enough.So, I'm glad that at least people like yourself are joining, and you know, creating the world where more people are trying to be relatable to DevOps people as well as the security folks. Because it's hard for a security person to be a developer, but it's easy for a developer or an engineer to understand security. And the simplest example I use is when people walk out of their house, they lock the door. They're already doing security. This is the same thing we're asking when we talk about security in the cloud or in the [unintelligible 00:14:49] as well. Everyone is, it just it hasn't been pointed out in the right way.Corey: I'm curious as to what it is that gets you up in the morning. Now, I know you work in security, but you're also not a CISO anymore, so I'm not asking what gets you up at 2 a.m. because we know what happens in the security space, then. There's a reason that my area of business focus is strictly a business hours problem. But I'd love to know what it is about cloud security as a whole that gets you excited.Ashish: I think it's an opportunity for people to get into the space without the—you know, you said gatekeeper earlier, those gatekeepers who used to have that 25 years experience in cybersecurity, 15 years experience in cybersecurity, Cloud has challenged that norm. Now, none of that experience helps you do AWS services better. It definitely helps you with the foundational pieces, definitely helps you do identity, networking, all of that, but you still have to learn something completely new, a new way of working, which allows for a lot of people who earlier was struggling to get into cybersecurity, now they have an opening. That's what excites me about cloud security, that it has opened up a door which is beyond your CCNA, CISSP, and whatever else certification that people want to get. By the way, I don't have a CISSP, so I can totally throw CISSP under the bus.But I definitely find that cloud security excites me every morning because it has shown me light where, to what you said, it was always a gated community. Although that's a very huge generalization. There's a lot of nice people in cybersecurity who want to mentor and help people get in. But Cloud security has pushed through that door, made it even wider than it was before.Corey: I think there's a lot to be said for the concept of sending the elevator back down. I really have remarkably little patience for people who take the perspective of, “Well, I got mine so screw everyone else.” The next generation should have it easier than we did, figuring out where we land in the ecosystem, where we live in the space. And there are folks who do a tremendous job of this, but there are also areas where I think there is significant need for improvement. I'm curious to know what you see as lacking in the community ecosystem for folks who are just dipping their toes into the water of cloud security.Ashish: I think that one, there's misinformation as well. The first one being, if you have never done IT before you can get into cloud security, and you know, you will do a great job. I think that is definitely a mistake to just accept the fact if Amazon re:Invent tells you do all these certifications, or Azure does the same, or GCP does the same. If I'll be really honest—and I feel like I can be honest, this is a safe space—that for people who are listening in, if you're coming to the space for the first time, whether it's cloud or cloud security, if you haven't had much exposure to the foundational pieces of it, it would be a really hard call. You would know all the AWS services, you will know all the Azure services because you have your certification, but if I was to ask you, “Hey, help me build an application. What would be the architecture look like so it can scale?”“So, right now we are a small pizza-size ten-people team”—I'm going to use the Amazon term there—“But we want to grow into a Facebook tomorrow, so please build me an architecture that can scale.” And if you regurgitate what Amazon has told you, or Azure has told you, or GCP has told you, I can definitely see that you would struggle in the industry because that's not how, say every application is built. Because the cloud service provider would ask you to drink the Kool-Aid and say they can solve all your problems, even though they don't have all the servers in the world. So, that's the first misinformation.The other one too, for people who are transitioning, who used to be in IT or in cybersecurity and trying to get into the cloud security space, the challenge over there is that outside of Amazon, Google, and Microsoft, there is not a lot of formal education which is unbiased. It is a great way to learn AWS security on how amazing AWS is from AWS people, the same way Microsoft will be [unintelligible 00:19:10], however, when it comes down to actual formal education, like the kind that you and I are trying to provide through a podcast, me with the Cloud Security Podcast, you with Last Week in AWS in the Security Edition, that kind of unbiased formal education, like free education, like what you and I are doing does definitely exist and I guess I'm glad we have company, that you and I both exist in this space, but formal education is very limited. It's always behind, say an expensive paid wall sometimes, and rightly so because it's information that would be helpful. So yeah, those two things. Corey: This episode is sponsored in part by our friends at Uptycs. Attackers don't think in silos, so why would you have siloed solutions protecting cloud, containers, and laptops distinctly? Meet Uptycs - the first unified solution prioritizes risk across your modern attack surface—all from a single platform, UI, and data model. Stop by booth 3352 at AWS re:Invent in Las Vegas to see for yourself and visit uptycs.com. That's U-P-T-Y-C-S.com. Corey: One of the problems that I have with the way a lot of cloud security stuff is situated is that you need to have something running to care about the security of. Yeah, I can spin up a VM in the free tier of most of these environments, and okay, “How do I secure a single Linux box?” Okay, yes, there are a lot of things you can learn there, but it's very far from a holistic point of view. You need to have the infrastructure running at reasonable scale first, in order to really get an effective lab that isn't contrived.Now, Snyk is a security company. I absolutely understand and have no problem with the fact that you charge your customers money in order to get security outcomes that are better than they would have otherwise. I do not get why AWS and GCP charge extra for security. And I really don't get why Azure charges extra for security and then doesn't deliver security by dropping the ball on it, which is neither here nor there.Ashish: [laugh].Corey: It feels like there's an economic form of gatekeeping, where you must spend at least this much money—or work for someone who does—in order to get exposure to security the way that grownups think about it. Because otherwise, all right, I hit my own web server, I have ten lines in the logs. Now, how do I wind up doing an analysis run to figure out what happened? I pull it up on my screen and I look at it. You need a point of scale before anything that the modern world revolves around doesn't seem ludicrous.Ashish: That's a good point. Also because we don't talk about the responsibility that the cloud service provider has themselves for security, like the encryption example that I used earlier, as a guardrail, it doesn't take much for them to enable by default. But how many do that by default? I feel foolish sometimes to tell people that, “Hey, you should have encryption enabled on your storage which is addressed, or in transit.”It should be—like, we have services like Let's Encrypt and other services, which are trying to make this easily available to everyone so everyone can do SSL or HTTPS. And also, same goes for encryption. It's free and given the choice that you can go customer-based keys or your own key or whatever, but it should be something that should be default. We don't have to remind people, especially if you're the providers of the service. I agree with you on the, you know, very basic principle of why do I pay extra for security, when you should have already covered this for me as part of the service.Because hey, technically, aren't you also responsible in this conversation? But the way I see shared responsibility is that—someone on the podcast mentioned it and I think it's true—shared responsibility means no one's responsible. And this is the kind of world we're living in because of that.Corey: Shared responsibility has always been an odd concept to me because AWS is where I first encountered it and they, from my perspective, turn what fits into a tweet into a 45-minute dog-and-pony show around, “Ah, this is how it works. This is the part we're responsible for. This is the part where the customer responsibility is. Now, let's have a mind-numbingly boring conversation around it.” Whereas, yeah, there's a compression algorithm here. Basically, if the cloud gets breached, it is overwhelmingly likely that you misconfigured something on your end, not the provider doing it, unless it's Azure, which is neither here nor there, once again.The problem with that modeling, once you get a little bit more business sophistication than I had the first time I made the observation, is that you can't sit down with a CISO at a company that just suffered a data breach and have your conversation be, “Doesn't it suck to be you—[singing] duh, duh—because you messed up. That's it.” You need that dog-and-pony show of being able to go in-depth and nuance because otherwise, you're basically calling out your customer, which you can't really do. Which I feel occludes a lot of clarity for folks who are not in that position who want to understand these things a bit better.Ashish: You're right, Corey. I think definitely I don't want to be in a place where we're definitely just educating people on this, but I also want to call out that we are in a world where it is true that Amazon, Azure, Google Cloud, they all have vulnerabilities as well. Thanks to research by all these amazing people on the internet from different companies out there, they've identified that, hey, these are not pristine environments that you can go into. Azure, AWS, Google Cloud, they themselves have vulnerabilities, and sometimes some of those vulnerabilities cannot be fixed until the customer intervenes and upgrades their services. We do live in a world where there is not enough education about this as well, so I'm glad you brought this up because for people who are listening in, I mean, I was one of those people who would always say, “When was the last time you heard Amazon had a breach?” Or, “Microsoft had a breach?” Or, “Google Cloud had a breach?”That was the idea when people were just buying into the concept of cloud and did not trust cloud. Every cybersecurity person that I would talk to they're like, “Why would you trust cloud? Doesn't make sense.” But this is, like, seven, eight years ago. Fast-forward to today, it's almost default, “Why would you not go into cloud?”So, for people who tend to forget that part, I guess, there is definitely a journey that people came through. With the same example of multi-factor authentication, it was never a, “Hey, let's enable password and multi-factor authentication.” It took a few stages to get there. Same with this as well. We're at that stage where now cloud service providers are showing the kinks in the armor, and now people are questioning, “I should update my risk matrix for what if there's actually a breach in AWS?”Now, Capital One is a great example where the Amazon employee who was sentenced, she did something which has—never even [unintelligible 00:25:32] on before, opened up the door for that [unintelligible 00:25:36] CISO being potentially sentenced. There was another one. Because it became more primetime news, now people are starting to understand, oh, wait. This is not the same as it used to be. Cloud security breaches have evolved as well.And just sticking to the Uber point, when Uber has that recent breach where they were talking about, “Hey, so many data records were gone,” what a lot of people did not talk about in that same message, it also mentioned the fact that, hey, they also got access to the AWS console of Uber. Now, that to me, is my risk metrics has already gone higher than where it was before because it just not your data, but potentially your production, your pre-prod, any development work that you were doing for, I don't know, self-driving cars or whatever that Uber [unintelligible 00:26:18] is doing, all that is out on the internet. But who was talking about all of that? That's a much worse a breach than what was portrayed on the internet. I don't know, what do you think?Corey: When it comes to trusting providers, where I sit is that I think, given their scale, they need to be a lot more transparent than they have been historically. However, I also believe that if you do not trust that these companies are telling you the truth about what they're doing, how they're doing it, what their controls are, then you should not be using them as a customer, full stop. This idea of confidential computing drives me nuts because so much of it is, “Well, what if we assume our cloud provider is lying to us about all of these things?” Like, hypothetically there's nothing stopping them from building an exact clone of their entire control plane that they redirect your request to that do something completely different under the hood. “Oh, yeah, of course, we're encrypting it with that special KMS key.” No, they're not. For, “Yeah, sure we're going to put that into this region.” Nope, it goes right back to Virginia. If you believe that's what's going on and that they're willing to do that, you can't be in cloud.Ashish: Yeah, a hundred percent. I think foundational trust need to exist and I don't think the cloud service providers themselves do a great job of building that trust. And maybe that's where the drift comes in because the business has decided they're going to cloud. The cyber security people are trying to be more aware and asking the question, “Hey, why do we trust it so blindly? I don't have a pen test report from Amazon saying they have tested service.”Yes, I do have a certificate saying it's PCI compliant, but how do I know—to what you said—they haven't cloned our services? Fortunately, businesses are getting smarter. Like, Walmart would never have their resources in AWS because they don't trust them. It's a business risk if suddenly they decide to go into that space. But the other way around, Microsoft may decides tomorrow that they want to start their own Walmart. Then what do you do?So, I don't know how many people actually consider that as a real business risk, especially because there's a word that was floating around the internet called supercloud. And the idea behind this was—oh, I can already see your reaction [laugh].Corey: Yeah, don't get me started on that whole mess.Ashish: [laugh]. Oh no, I'm the same. I'm like, “What? What now?” Like, “What are you—” So, one thing I took away which I thought was still valuable was the fact that if you look at the cloud service providers, they're all like octopus, they all have tentacles everywhere.Like, if you look at the Amazon of the world, they not only a bookstore, they have a grocery store, they have delivery service. So, they are into a lot of industries, the same way Google Cloud, Microsoft, they're all in multiple industries. And they can still have enough money to choose to go into an industry that they had never been into before because of the access that they would get with all this information that they have, potentially—assuming that they [unintelligible 00:29:14] information. Now, “Shared responsibility,” quote-unquote, they should not do it, but there is nothing stopping them from actually starting a Walmart tomorrow if they wanted to.Corey: So, because a podcast and a day job aren't enough, what are you going to be doing in the near future given that, as we record this, re:Invent is nigh?Ashish: Yeah. So, podcasting and being in the YouTube space has definitely opened up the creative mindset for me. And I think for my producer as well. We're doing all these exciting projects. We have something called Cloud Security Villains that is coming up for AWS re:Invent, and it's going to be released on our YouTube channel as well as my social media.And we'll have merchandise for it across the re:Invent as well. And I'm just super excited about the possibility that media as a space provides for everyone. So, for people who are listening in and thinking that, I don't know, I don't want to write for a blog or email newsletter or whatever the thing may be, I just want to put it out there that I used to be excited about AWS re:Invent just to understand, hey, hopefully, they will release a new security service. Now, I get excited about these events because I get to meet community, help them, share what they have learned on the internet, and sound smarter [laugh] as a result of that as well, and get interviewed where people like yourself. But I definitely find that at the moment with AWS re:Invent coming in, a couple of things that are exciting for me is the release of the Cloud Security Villains, which I think would be an exciting project, especially—hint, hint—for people who are into comic books, you will definitely enjoy it, and I think your kids will as well. So, just in time for Christmas.Corey: We will definitely keep an eye out for that and put a link to that in the show notes. I really want to thank you for being so generous with your time. If people want to learn more about what you're up to, where's the best place for them to find you?Ashish: I think I'm fortunate enough to be at that stage where normally if people Google me—and it's simply Ashish Rajan—they will definitely find me [laugh]. I'll be really hard for them not find me on the internet. But if you are looking for a source of unbiased cloud security knowledge, you can definitely hit up cloudsecuritypodcast.tv or our YouTube and LinkedIn channel.We go live stream every week with a new guest talking about cloud security, which could be companies like LinkedIn, Twilio, to name a few that have come on the show already, and a lot more than have come in and been generous with their time and shared how they do what they do. And we're fortunate that we get ranked top 100 in America, US, UK, as well as Australia. I'm really fortunate for that. So, we're doing something right, so hopefully, you get some value out of it as well when you come and find me.Corey: And we will, of course, put links to all of that in the show notes. Thank you so much for being so generous with your time. I really appreciate it.Ashish: Thank you, Corey, for having me. I really appreciate this a lot. I enjoyed the conversation.Corey: As did I. Ashish Rajan, Principal Cloud Security Advocate at Snyk who is sponsoring this promoted guest episode. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment pointing out that not every CISO gets fired; some of them successfully manage to blame the intern.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

This episode features Laura Dyrda, Vice President & Editor in Chief at Becker's ASC Review and Becker's Spine Review. Here, she discusses big health systems reporting operating losses, Google Cloud and Epic partnering with Hackensack being the first health system to migrate EHR, Meditech & Google Health partnering on clinician search tool, and more.

Washington Post author of the Cybersecurity 202 newsletter Tim Starks speaks with Phil Venables, chief information security officer at Google Cloud, and Tom Robinson, founder and chief scientist at Elliptic, about how companies and users can protect their information and money. Conversation recorded on Nov. 17, 2022.

Cloud computing powers most of the digital services you use today. Listen to this podcast episode to learn what it is and why it matters. Learning notes from this episode: The cloud computing is expecting huge growth: the total cloud computing market is estimated to be reach $1,614 by 2030 from $545 billion in 2022, according to Precedence Research. Before the advent of cloud computing, technology companies would have had to have their own servers to store data and run computations. Having your own servers is very expensive because you have to pay to keep them secure keep them cool keep them running 24 /7 and pay high electricity costs have a space to keep them maintain them with the help of a specialist Cloud computing means that companies do not have to buy and maintain their own servers. Instead, they can just rent space on another company's servers.  You can just pay for what you use and expand as you grow.  This is a picture of servers ran by a cloud computing company. Before cloud computing, businesses would have had to have own these things and maintain them at their own premises - a huge cost and a headache. Amazon launched cloud computing as a service in 2006, and remains the biggest player in the market today. It counts Netflix, Disney, the UK Ministry of Justice, Kellogs, Guardian News and Media, and the European Space Agency as its customers. Cloud computing is relevant to every industry: if you are storing data and using it to make decisions, you need to know about cloud computing.  The advent of cloud computing drove down the risk of innovation and spurred the creation of start-ups and the VCs funding them. Without cloud computing digital innovation was only available to those who could pay and maintain servers. The three biggest players in the cloud computing market are: Microsoft Azure, Google Cloud and IBM Cloud.   (Source: Statista) Join our next FREE Masterclass on 30 November 2022, 12 pm EST / 5 pm GMT How to Become a Digital Leader You will learn: The top mistake non-technical leaders make when it comes to tech Leadership case studies from Netflix & Microsoft How to go from traditional business manager to Digital Leader SIGN UP HERE   Listen here on Apple Podcasts Listen here on Spotify ----- If you like learning about how tech products and profits get made, you'll like our newsletter. It's funny too. Sign up here. -----   Tech for Non-Techies clients  Reach senior leadership positions in Big Tech firms Lead digital transformation in established businesses Create tech businesses as non-technical founders Pivot into careers in venture capital If you want to have a great career in the Digital Age, then APPLY FOR A CONSULTATION CALL.   What happens when you apply for a consultation call: Sophia and her team will look through your application. If they genuinely think Sophia could help you, you will get a link to her calendar.. You will have a 20 – 30 minute call to discuss your goals and see if you are a good fit for each other.  If we establish that Tech for Non-Techies courses + coaching could help you and believe we would enjoy working together, we will discuss a relevant approach to suit you. The aim of the call is not to sell you on anything that is not right for you. We both win if you get results, but we both lose if you don't. We love hearing from our readers and listeners. So if you have questions about the content or working with us, just get in touch on info@techfornontechies.co   Say hi to Sophia on Twitter and follow her on LinkedIn. Following us on Facebook, Instagram and TikTok will make you smarter. 

Stephanie Wong talks with guests Shachar Guz, Inna Weiner, and Gabe Weiss about Google's Database Migration Service and how it helps companies move data to Google Cloud. What typically is a complicated process, DMS simplifies everything from planning to security to validating database migrations. DMS has undergone some changes since last we spoke with Shachar and Gabe. It's gone GA and helped thousands of customers benefit from the service. Migrations are possible from any PostgreSQL database source to AlloyDB for PostgreSQL, which is designed to support HTAP data (transactional and analytical). One of the most exciting updates is the introduction of the DMS modernization journey, which allows customers to change database type during migration (heterogenous). In addition, migrations with DMS can be set up to continuously replicate data between the old and new database. With this feature, developers can compare the application performance against the old vs. new database. Inna talks about the benefits of keeping your data in the cloud, like secure, reliable, and scalable data storage. Google Cloud takes care of the maintenance work for you as well. DMS takes security seriously and supports multiple security methods to keep your data safe as it migrates. We talk about the different customers using DMS and how the process works for homogeneous and heterogeneous migrations. Before you even start, Gabe tells us, DMS helps you prepare for the migration. And tools like Dataflow can help when customers decide full migration would be too difficult. We talk about the difference between Datastream and DMS and use cases for each. We wrap up the show with a look at the future of DMS. Shachar Guz Shachar is a product manager at Google Cloud, he works on the Cloud Database Migration Service. Shachar worked in various product and engineering roles and shares a true passion about data and helping customers get the most out of their data. Shachar is passionate about building products that make cumbersome processes simple and straightforward and helping companies adopt Cloud technologies to accelerate their business. Inna Weiner Inna is a senior technical leader with 20+ years of global experience. She is a big data expert, specializing in deriving insights from data, product and user analytics. Currently, she leads engineering for Cloud DMS. Inna enjoys building diverse engineering organizations, with common vision, growth strategy and inclusive culture. Gabe Weiss Gabe leads the database advocacy team for the Google Cloud Platform team ensuring that developers can make awesome things, both inside and outside of Google. That could mean speaking at conferences, writing example code, running bootcamps, writing technical blogs or just doing some hand holding. Prior to Google he's worked in virtual reality production and distribution, source control, the games industry and professional acting. Cool things of the week Flexible committed use discounts — a simple new way to discount Compute Engine instances blog Understanding transactional locking in Cloud Spanner blog Interactive In-console Tutorial site Interview Database Migration Service site GCP Podcast Episode 262: Database Migration Service with Shachar Guz and Gabe Weiss podcast AlloyDB for PostgreSQL site PostgreSQL site Datastream site Dataflow site CloudSQL site Spanner site What's something cool you're working on? Gabe has been tinkering with new Google Cloud databases and managing a new team. Hosts Stephanie Wong

About ChenChen Goldberg is GM and Vice President of Engineering at Google Cloud, where she leads the Cloud Runtimes (CR) product area, helping customers deliver greater value, effortlessly. The CR  portfolio includes both Serverless and Kubernetes based platforms on Google Cloud, private cloud and other public clouds. Chen is a strong advocate for customer empathy, building products and solutions that matter. Chen has been core to Google Cloud's open core vision since she joined the company six years ago. During that time, she has led her team to focus on helping development teams increase their agility and modernize workloads. Prior to joining Google, Chen wore different hats in the tech industry including leadership positions in IT organizations, SI teams and SW product development, contributing to Chen's broad enterprise perspective. She enjoys mentoring IT talent both in and outside of Google. Chen lives in Mountain View, California, with her husband and three kids. Outside of work she enjoys hiking and baking.Links Referenced: Twitter: https://twitter.com/GoldbergChen LinkedIn: https://www.linkedin.com/in/goldbergchen/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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.Corey: Forget everything you know about SSH and try Tailscale. Imagine if you didn't need to manage PKI or rotate SSH keys every time someone leaves. That'd be pretty sweet, wouldn't it? With Tailscale SSH, you can do exactly that. Tailscale gives each server and user device a node key to connect to its VPN, and it uses the same node key to authorize and authenticate SSH.Basically you're SSHing the same way you manage access to your app. What's the benefit here? Built-in key rotation, permissions as code, connectivity between any two devices, reduce latency, and there's a lot more, but there's a time limit here. You can also ask users to reauthenticate for that extra bit of security. Sounds expensive?Nope, I wish it were. Tailscale is completely free for personal use on up to 20 devices. To learn more, visit snark.cloud/tailscale. Again, that's snark.cloud/tailscaleCorey: Welcome to Screaming in the Cloud, I'm Corey Quinn. When I get bored and the power goes out, I find myself staring at the ceiling, figuring out how best to pick fights with people on the internet about Kubernetes. Because, well, I'm basically sad and have a growing collection of personality issues. My guest today is probably one of the best people to have those arguments with. Chen Goldberg is the General Manager of Cloud Runtimes and VP of Engineering at Google Cloud. Chen, Thank you for joining me today.Chen: Thank you so much, Corey, for having me.Corey: So, Google has been doing a lot of very interesting things in the cloud, and the more astute listener will realize that interesting is not always necessarily a compliment. But from where I sit, I am deeply vested in the idea of a future where we do not have a cloud monoculture. As I've often said, I want, “What cloud should I build something on in five to ten years?” To be a hard question to answer, and not just because everything is terrible. I think that Google Cloud is absolutely a bright light in the cloud ecosystem and has been for a while, particularly with this emphasis around developer experience. All of that said, Google Cloud is sort of a big, unknowable place, at least from the outside. What is your area of responsibility? Where do you start? Where do you stop? In other words, what can I blame you for?Chen: Oh, you can blame me for a lot of things if you want to. I [laugh] might not agree with that, but that's—Corey: We strive for accuracy in these things, though.Chen: But that's fine. Well, first of all, I've joined Google about seven years ago to lead the Kubernetes and GKE team, and ever since, continued at the same area. So evolved, of course, Kubernetes, and Google Kubernetes Engine, and leading our hybrid and multi-cloud strategy as well with technologies like Anthos. And now I'm responsible for the entire container runtime, which includes Kubernetes and the serverless solutions.Corey: A while back, I, in fairly typical sarcastic form, wound up doing a whole inadvertent start of a meme where I joked about there being 17 ways to run containers on AWS. And then as that caught on, I wound up listing out 17 services you could use to do that. A few months went past and then I published a sequel of 17 more services you can use to run Kubernetes. And while that was admittedly tongue-in-cheek, it does lead to an interesting question that's ecosystem-wide. If I look at Google Cloud, I have Cloud Run, I have GKE, I have GCE if I want to do some work myself.It feels like more and more services are supporting Docker in a variety of different ways. How should customers and/or people like me—though, I am sort of a customer as well since I do pay you folks every month—how should we think about containers and services in which to run them?Chen: First of all, I think there's a lot of credit that needs to go to Docker that made containers approachable. And so, Google has been running containers forever. Everything within Google is running on containers, even our VMs, even our cloud is running on containers, but what Docker did was creating a packaging mechanism to improve developer velocity. So, that's on its own, it's great. And one of the things, by the way, that I love about Google Cloud approach to containers and Docker that yes, you can take your Docker container and run it anywhere.And it's actually really important to ensure what we call interoperability, or low barrier to entry to a new technology. So, I can take my Docker container, I can move it from one platform to another, and so on. So, that's just to start with on a containers. Between the different solutions, so first of all, I'm all about managed services. You are right, there are many ways to run a Kubernetes. I'm taking a lot of pride—Corey: The best way is always to have someone else run it for you. Problem solved. Great, the best kind of problems are always someone else's.Chen: Yes. And I'm taking a lot of pride of what our team is doing with Kubernetes. I mean, we've been working on that for so long. And it's something that you know, we've coined that term, I think back in 2016, so there is a success disaster, but there's also what we call sustainable success. So, thinking about how to set ourselves up for success and scale. Very proud of that service.Saying that, not everybody and not all your workloads you need the flexibility that Kubernetes gives you in all the ecosystem. So, if you start with containers your first time, you should start with Cloud Run. It's the easiest way to run your containers. That's one. If you are already in love with Kubernetes, we won't take it away from you. Start with GKE. Okay [laugh]? Go all-in. Okay, we are all in loving Kubernetes as well. But what my team and I are working on is to make sure that those will work really well together. And we actually see a lot of customers do that.Corey: I'd like to go back a little bit in history to the rise of Docker. I agree with you it was transformative, but containers had been around in various forms—depending upon how you want to define it—dating back to the '70s with logical partitions on mainframes. Well, is that a container? Is it not? Well, sort of. We'll assume yes for the sake of argument.The revelation that I found from Docker was the developer experience, start to finish. Suddenly, it was a couple commands and you were just working, where previously it had taken tremendous amounts of time and energy to get containers working in that same context. And I don't even know today whether or not the right way to contextualize containers is as sort of a lite version of a VM, as a packaging format, as a number of other things that you could reasonably call it. How do you think about containers?Chen: So, I'm going to do, first of all, a small [unintelligible 00:06:31]. I actually started my career as a system mainframe engineer—Corey: Hmm.Chen: And I will share that when you know, I've learned Kubernetes, I'm like, “Huh, we already have done all of that, in orchestration, in workload management on mainframe,” just to the side. The way I think about containers is as a—two things: one, it is a packaging of an application, but the other thing which is also critical is the decoupling between your application and the OS. So, having that kind of abstraction and allowing you to portable and move it between environments. So, those are the two things that are when I think about containers. And what technologies like Kubernetes and serverless gives on top of that is that manageability and making sure that we take care of everything else that is needed for you to run your application.Corey: I've been, how do I put this, getting some grief over the past few years, in the best ways possible, around a almost off-the-cuff prediction that I made, which was that in five years, which is now a lot closer to two, basically, nobody is going to care about Kubernetes. And I could have phrased that slightly more directly because people think I was trying to say, “Oh, Kubernetes is just hype. It's going to go away. Nobody's going to worry about it anymore.” And I think that is a wildly inaccurate prediction.My argument is that people are not going to have to think about it in the same way that they are today. Today, if I go out and want to go back to my days of running production services in anger—and by ‘anger,' I of course mean in production—then it would be difficult for me to find a role that did not at least touch upon Kubernetes. But people who can work with that technology effectively are in high demand and they tend to be expensive, not to mention then thinking about all of the intricacies and complexities that Kubernetes brings to the foreground, that is what doesn't feel sustainable to me. The idea that it's going to have to collapse down into something else is, by necessity, going to have to emerge. How are you seeing that play out? And also, feel free to disagree with the prediction. I am thrilled to wind up being told that I'm wrong it's how I learn the most.Chen: I don't know if I agree with the time horizon of when that will happen, but I will actually think it's a failure on us if that won't be the truth, that the majority of people will not need to know about Kubernetes and its internals. And you know, we keep saying that, like, hey, we need to make it more, like, boring, and easy, and I've just said like, “Hey, you should use managed.” And we have lots of customers that says that they're just using GKE and it scales on their behalf and they don't need to do anything for that and it's just like magic. But from a technology perspective, there is still a way to go until we can make that disappear.And there will be two things that will push us into that direction. One is—you mentioned that is as well—the talent shortage is real. All the customers that I speak with, even if they can find those great people that are experts, they're actually more interesting things for them to work on, okay? You don't need to take, like, all the people in your organization and put them on building the infrastructure. You don't care about that. You want to build innovation and promote your business.So, that's one. The second thing is that I do expect that the technology will continue to evolve and are managed solutions will be better and better. So hopefully, with these two things happening together, people will not care that what's under the hood is Kubernetes. Or maybe not even, right? I don't know exactly how things will evolve.Corey: From where I sit, what are the early criticisms I had about Docker, which I guess translates pretty well to Kubernetes, are that they solve a few extraordinarily painful problems. In the case of Docker, it was, “Well, it works on my machine,” as a grumpy sysadmin, the way I used to be, the only real response we had to that was, “Well. Time to backup your email, Skippy, because your laptop is going into production, then.” Now, you can effectively have a high-fidelity copy of production, basically anywhere, and we've solved the problem of making your Mac laptop look like a Linux server. Great, okay, awesome.With Kubernetes, it also feels, on some level, like it solves for very large-scale Google-type of problems where you want to run things across at least a certain point of scale. It feels like even today, it suffers from having an easy Hello World-style application to deploy on top of it. Using it for WordPress, or some other form of blogging software, for example, is stupendous overkill as far as the Hello World story tends to go. Increasingly as a result, it feels like it's great for the large-scale enterprise-y applications, but the getting started story of how do I have a service I could reasonably run in production? How do I contextualize that, in the world of Kubernetes? How do you respond to that type of perspective?Chen: We'll start with maybe a short story. I started my career in the Israeli army. I was head of the department and one of the lead technology units and I was responsible for building a PAS. In essence, it was 20-plus years ago, so we didn't really call it a PAS but that's what it was. And then at some point, it was amazing, developers were very productive, we got innovation again, again. And then there was some new innovation just at the beginning of web [laugh] at some point.And it was actually—so two things I've noticed back then. One, it was really hard to evolve the platform to allow new technologies and innovation, and second thing, from a developer perspective, it was like a black box. So, the developers team that people were—the other development teams couldn't really troubleshoot environment; they were not empowered to make decisions or [unintelligible 00:12:29] in the platform. And you know, when it was just started with Kubernetes—by the way, beginning, it only supported 100 nodes, and then 1000 nodes. Okay, it was actually not for scale; it actually solved those two problems, which I'm—this is where I spend most of my time.So, the first one, we don't want magic, okay? To be clear on, like, what's happening, I want to make sure that things are consistent and I can get the right observability. So, that's one. The second thing is that we invested so much in the extensibility an environment that it's, I wouldn't say it's easy, but it's doable to evolve Kubernetes. You can change the models, you can extend it you can—there is an ecosystem.And you know, when we were building it, I remember I used to tell my team, there won't be a Kubernetes 2.0. Which is for a developer, it's [laugh] frightening. But if you think about it and you prepare for that, you're like, “Huh. Okay, what does that mean with how I build my APIs? What does that mean of how we build a system?” So, that was one. The second thing I keep telling my team, “Please don't get too attached to your code because if it will still be there in 5, 10 years, we did something wrong.”And you can see areas within Kubernetes, again, all the extensions. I'm very proud of all the interfaces that we've built, but let's take networking. This keeps to evolve all the time on the API and the surface area that allows us to introduce new technologies. I love it. So, those are the two things that have nothing to do with scale, are unique to Kubernetes, and I think are very empowering, and are critical for the success.Corey: One thing that you said that resonates most deeply with me is the idea that you don't want there to be magic, where I just hand it to this thing and it runs it as if by magic. Because, again, we've all run things in anger in production, and what happens when the magic breaks? When you're sitting around scratching your head with no idea how it starts or how it stops, that is scary. I mean, I recently wound up re-implementing Google Cloud Distinguished Engineer Kelsey Hightower's “Kubernetes the Hard Way” because he gave a terrific tutorial that I ran through in about 45 minutes on top of Google Cloud. It's like, “All right, how do I make this harder?”And the answer is to do it on AWS, re-implement it there. And my experiment there can be found at kubernetesthemuchharderway.com because I have a vanity domain problem. And it taught me he an awful lot, but one of the challenges I had as I went through that process was, at one point, the nodes were not registering with the controller.And I ran out of time that day and turned everything off—because surprise bills are kind of what I spend my time worrying about—turn it on the next morning to continue and then it just worked. And that was sort of the spidey sense tingling moment of, “Okay, something wasn't working and now it is, and I don't understand why. But I just rebooted it and it started working.” Which is terrifying in the context of a production service. It was understandable—kind of—and I think that's the sort of thing that you understand a lot better, the more you work with it in production, but a counterargument to that is—and I've talked about it on this show before—for this podcast, I wind up having sponsors from time to time, who want to give me fairly complicated links to go check them out, so I have the snark.cloud URL redirector.That's running as a production service on top of Google Cloud Run. It took me half an hour to get that thing up and running; I haven't had to think about it since, aside from a three-second latency that was driving me nuts and turned out to be a sleep hidden in the code, which I can't really fault Google Cloud Run for so much as my crappy nonsense. But it just works. It's clearly running atop Kubernetes, but I don't have to think about it. That feels like the future. It feels like it's a glimpse of a world to come, we're just starting to dip our toes into. That, at least to me, feels like a lot more of the abstractions being collapsed into something easily understandable.Chen: [unintelligible 00:16:30], I'm happy you say that. When talking with customers and we're showing, like, you know, yes, they're all in Kubernetes and talking about Cloud Run and serverless, I feel there is that confidence level that they need to overcome. And that's why it's really important for us in Google Cloud is to make sure that you can mix and match. Because sometimes, you know, a big retail customer of ours, some of their teams, it's really important for them to use a Kubernetes-based platform because they have their workloads also running on-prem and they want to serve the same playbooks, for example, right? How do I address issues, how do I troubleshoot, and so on?So, that's one set of things. But some cloud only as simple as possible. So, can I use both of them and still have a similar developer experience, and so on? So, I do think that we'll see more of that in the coming years. And as the technology evolves, then we'll have more and more, of course, serverless solutions.By the way, it doesn't end there. Like, we see also, you know, databases and machine learning, and like, there are so many more managed services that are making things easy. And that's what excites me. I mean, that's what's awesome about what we're doing in cloud. We are building platforms that enable innovation.Corey: I think that there's an awful lot of power behind unlocking innovation from a customer perspective. The idea that I can use a cloud provider to wind up doing an experiment to build something in the course of an evening, and if it works, great, I can continue to scale up without having to replace, you know, the crappy Raspberry Pi-level hardware in my spare room with serious enterprise servers in a data center somewhere. The on-ramp and the capability and the lack of long-term commitments is absolutely magical. What I'm also seeing that is contributing to that is the de facto standard that's emerged of most things these days support Docker, for better or worse. There are many open-source tools that I see where, “Oh, how do I get this up and running?”“Well, you can go over the river and through the woods and way past grandmother's house to build this from source or run this Docker file.” I feel like that is the direction the rest of the world is going. And as much fun as it is to sit on the sidelines and snark, I'm finding a lot more capability stories emerging across the board. Does that resonate with what you're seeing, given that you are inherently working at very large scale, given the [laugh] nature of where you work?Chen: I do see that. And I actually want to double down on the open standards, which I think this is also something that is happening. At the beginning, we talked about I want it to be very hard when I choose the cloud provider. But innovation doesn't only come from cloud providers; there's a lot of companies and a lot of innovation happening that are building new technologies on top of those cloud providers, and I don't think this is going to stop. Innovation is going to come from many places, and it's going to be very exciting.And by the way, things are moving super fast in our space. So, the investment in open standard is critical for our industry. So, Docker is one example. Google is in [unintelligible 00:19:46] speaking, it's investing a lot in building those open standards. So, we have Docker, we have things like of course Kubernetes, but we are also investing in open standards of security, so we are working with other partners around [unintelligible 00:19:58], defining how you can secure the software supply chain, which is also critical for innovation. So, all of those things that reduce the barrier to entry is something that I'm personally passionate about.Corey: Scaling containers and scaling Kubernetes is hard, but a whole ‘nother level of difficulty is scaling humans. You've been at Google for, as you said, seven years and you did not start as a VP there. Getting promoted from Senior Director to VP at Google is a, shall we say, heavy lift. You also mentioned that you previously started with, I believe, it was a seven-person team at one point. How have you been able to do that? Because I can see a world in which, “Oh, we just write some code and we can scale the computers pretty easily,” I've never found a way to do that for people.Chen: So yes, I started actually—well not 7, but the team was 30 people [laugh]. And you can imagine how surprised I was when I joining Google Cloud with Kubernetes and GKE and it was a pretty small team, to the beginning of those days. But the team was already actually on the edge of burning out. You know, pings on Slack, the GitHub issues, there was so many things happening 24/7.And the thing was just doing everything. Everybody were doing everything. And one of the things I've done on my second month on the team—I did an off-site, right, all managers; that's what we do; we do off-sites—and I brought the team in to talk about—the leadership team—to talk about our team values. And in the beginning, they were a little bit pissed, I would say, “Okay, Chen. What's going on? You're wasting two days of our lives to talk about those things. Why we are not doing other things?”And I was like, “You know guys, this is really important. Let's talk about what's important for us.” It was an amazing it worked. By the way, that work is still the foundation of the culture in the team. We talked about the three values that we care about and how that will look like.And the reason it's important is that when you scale teams, the key thing is actually to scale decision-making. So, how do you scale decision-making? I think there are two things there. One is what you're trying to achieve. So, people should know and understand the vision and know where we want to get to.But the second thing is, how do we work? What's important for us? How do we prioritize? How do we make trade-offs? And when you have both the what we're trying to do and the how, you build that team culture. And when you have that, I find that you're set up more for success for scaling the team.Because then the storyteller is not just the leader or the manager. The entire team is a storyteller of how things are working in this team, how do we work, what you're trying to achieve, and so on. So, that's something that had been a critical. So, that's just, you know, from methodology of how I think it's the right thing to scale teams. Specifically, with a Kubernetes, there were more issues that we needed to work on.For example, building or [recoding 00:23:05] different functions. It cannot be just engineering doing everything. So, hiring the first product managers and information engineers and marketing people, oh my God. Yes, you have to have marketing people because there are so many events. And so, that was one thing, just you know, from people and skills.And the second thing is that it was an open-source project and a product, but what I was personally doing, I was—with the team—is bringing some product engineering practices into the open-source. So, can we say, for example, that we are going to focus on user experience this next release? And we're not going to do all the rest. And I remember, my team was like worried about, like, “Hey, what about that, and what about this, and we have—” you know, they were juggling everything together. And I remember telling them, “Imagine that everything is on the floor. All the balls are on the floor. I know they're on the floor, you know they're on the floor. It's okay. Let's just make sure that every time we pick something up, it never falls again.” And that idea is a principle that then evolved to ‘No Heroics,' and it evolved to ‘Sustainable Success.' But building things towards sustainable success is a principle which has been very helpful for us.Corey: This episode is sponsored in part by our friend at Uptycs. Attackers don't think in silos, so why would you have siloed solutions protecting cloud, containers, and laptops distinctly? Meet Uptycs - the first unified solution that prioritizes risk across your modern attack surface—all from a single platform, UI, and data model. Stop by booth 3352 at AWS re:Invent in Las Vegas to see for yourself and visit uptycs.com. That's U-P-T-Y-C-S.com. My thanks to them for sponsoring my ridiculous nonsense.Corey: When I take a look back, it's very odd to me to see the current reality that is Google, where you're talking about empathy, and the No Heroics, and the rest of that is not the reputation that Google enjoyed back when a lot of this stuff got started. It was always oh, engineers should be extraordinarily bright and gifted, and therefore it felt at the time like our customers should be as well. There was almost an arrogance built into, well, if you wrote your code more like Google will, then maybe your code wouldn't be so terrible in the cloud. And somewhat cynically I thought for a while that oh Kubernetes is Google's attempt to wind up making the rest of the world write software in a way that's more Google-y. I don't think that observation has aged very well. I think it's solved a tremendous number of problems for folks.But the complexity has absolutely been high throughout most of Kubernetes life. I would argue, on some level, that it feels like it's become successful almost in spite of that, rather than because of it. But I'm curious to get your take. Why do you believe that Kubernetes has been as successful as it clearly has?Chen: [unintelligible 00:25:34] two things. One about empathy. So yes, Google engineers are brilliant and are amazing and all great. And our customers are amazing, and brilliant, as well. And going back to the point before is, everyone has their job and where they need to be successful and we, as you say, we need to make things simpler and enable innovation. And our customers are driving innovation on top of our platform.So, that's the way I think about it. And yes, it's not as simple as it can be—probably—yet, but in studying the early days of Kubernetes, we have been investing a lot in what we call empathy, and the customer empathy workshop, for example. So, I partnered with Kelsey Hightower—and you mentioned yourself trying to start a cluster. The first time we did a workshop with my entire team, so then it was like 50 people [laugh], their task was to spin off a cluster without using any scripts that we had internally.And unfortunately, not many folks succeeded in this task. And out of that came the—what you you call it—a OKR, which was our goal for that quarter, is that you are able to spin off a cluster in three commands and troubleshoot if something goes wrong. Okay, that came out of that workshop. So, I do think that there is a lot of foundation on that empathetic engineering and the open-source of the community helped our Google teams to be more empathetic and understand what are the different use cases that they are trying to solve.And that actually bring me to why I think Kubernetes is so successful. People might be surprised, but the amount of investment we're making on orchestration or placement of containers within Kubernetes is actually pretty small. And it's been very small for the last seven years. Where do we invest time? One is, as I mentioned before, is on the what we call the API machinery.So, Kubernetes has introduced a way that is really suitable for a cloud-native technologies, the idea of reconciliation loop, meaning that the way Kubernetes is—Kubernetes is, like, a powerful automation machine, which can automate, of course, workload placement, but can automate other things. Think about it as a way of the Kubernetes API machinery is observing what is the current state, comparing it to the desired state, and working towards it. Think about, like, a thermostat, which is a different automation versus the ‘if this, then that,' where you need to anticipate different events. So, this idea about the API machinery and the way that you can extend it made it possible for different teams to use that mechanism to automate other things in that space.So, that has been one very powerful mechanism of Kubernetes. And that enabled all of innovation, even if you think about things like Istio, as an example, that's how it started, by leveraging that kind of mechanism to separate storage and so on. So, there are a lot of operators, the way people are managing their databases, or stateful workloads on top of Kubernetes, they're extending this mechanism. So, that's one thing that I think is key and built that ecosystem. The second thing, I am very proud of the community of Kubernetes.Corey: Oh, it's a phenomenal community success story.Chen: It's not easy to build a community, definitely not in open-source. I feel that the idea of values, you know, that I was talking about within my team was actually a big deal for us as we were building the community: how we treat each other, how do we help people start? You know, and we were talking before, like, am I going to talk about DEI and inclusivity, and so on. One of the things that I love about Kubernetes is that it's a new technology. There is actually—[unintelligible 00:29:39] no, even today, there is no one with ten years experience in Kubernetes. And if anyone says they have that, then they are lying.Corey: Time machine. Yes.Chen: That creates an opportunity for a lot of people to become experts in this technology. And by having it in open-source and making everything available, you can actually do it from your living room sofa. That excites me, you know, the idea that you can become an expert in this new technology and you can get involved, and you'll get people that will mentor you and help you through your first PR. And there are some roles within the community that you can start, you know, dipping your toes in the water. It's exciting. So, that makes me really happy, and I know that this community has changed the trajectory of many people's careers, which I love.Corey: I think that's probably one of the most impressive things that it's done. One last question I have for you is that we've talked a fair bit about the history and how we see it progressing through the view toward the somewhat recent past. What do you see coming in the future? What does the future of Kubernetes look like to you?Chen: Continue to be more and more boring. There is the promise of hybrid and multi-cloud, for example, is only possible by technologies like Kubernetes. So, I do think that, as a technology, it will continue to be important by ensuring portability and interoperability of workloads. I see a lot of edge use cases. If you think about it, it's like just lagging a bit around, like, innovation that we've seen in the cloud, can we bring that innovation to the edge, this will require more development within Kubernetes community as well.And that's really actually excites me. I think there's a lot of things that we're going to see there. And by the way, you've seen it also in KubeCon. I mean, there were some announcements in that space. In Google Cloud, we just announced before, like, with customers like Wendy's and Rite Aid as well. So, taking advantage of this technology to allow innovation everywhere.But beyond that, my hope is that we'll continue and hide the complexity. And our challenge will be to not make it a black box. Because that will be, in my opinion, a failure pattern, doesn't help those kinds of platforms. So, that will be the challenge. Can we scope the project, ensure that we have the right observability, and from a use case perspective, I do think edge is super interesting.Corey: I would agree. There are a lot of workloads out there that are simply never going to be hosted in the cloud provider region, for a variety of reasons of varying validity, but it is the truth. I think that the focus on addressing customers where they are has been an emerging best practice for cloud providers and I'm thrilled to see Google leading the charge on that.Chen: Yeah. And you just reminded me, the other thing that we see also more and more is definitely AI and ML workloads running on Kubernetes, which is part of that, right? So, Google Cloud is investing a lot in making an AI/ML easy. And I don't know if many people know, but, like, even Vertex AI, our own platform, is running on GKE. So, that's part of seeing how do we make sure that platform is suitable for these kinds of workloads and really help customers do the heavy lifting.So, that's another set of workloads that are very relevant at the edge. And one of our customers—MLB, for example—two things are interesting there. The first one, I think a lot of people sometimes say, “Okay, I'm going to move to the cloud and I want to know everything right now, how that will evolve.” And one of the things that's been really exciting with working with MLB for the last four years is the journey and the iterations. So, they started somewhat, like, at one phase and then they saw what's possible, and then moved to the next one, and so on. So, that's one. The other thing is that, really, they have so much ML running at the stadium with Google Cloud technology, which is very exciting.Corey: I'm looking forward to seeing how this continues to evolve and progress, particularly in light of the recent correction we're seeing in the market where a lot of hype-driven ideas are being stress test, maybe not in the way we might have hoped that they would, but it'll be really interesting to see what shakes out as far as things that deliver business value and are clear wins for customers versus a lot of the speculative stories that we've been hearing for a while now. Maybe I'm totally wrong on this. And this is going to be a temporary bump in the road, and we'll see no abatement in the ongoing excitement around so many of these emerging technologies, but I'm curious to see how it plays out. But that's the beautiful part about getting to be a pundit—or whatever it is people call me these days that's at least polite enough to say on a podcast—is that when I'm right, people think I'm a visionary, and when I'm wrong, people don't generally hold that against you. It seems like futurist is the easiest job in the world because if you predict and get it wrong, no one remembers. Predict and get it right, you look like a genius.Chen: So, first of all, I'm optimistic. So usually, my predictions are positive. I will say that, you know, what we are seeing, also what I'm hearing from our customers, technology is not for the sake of technology. Actually, nobody cares [laugh]. Even today.Okay, so nothing needs to change for, like, nobody would c—even today, nobody cares about Kubernetes. They need to care, unfortunately, but what I'm hearing from our customers is, “How do we create new experiences? How we make things easy?” Talent shortage is not just with tech people. It's also with people working in the warehouse or working in the store.Can we use technology to help inventory management? There's so many amazing things. So, when there is a real business opportunity, things are so much simpler. People have the right incentives to make it work. Because one thing we didn't talk about—right, we talked about all these new technologies and we talked about scaling team and so on—a lot of time, the challenge is not the technology.A lot of time, the challenge is the process. A lot of time, the challenge is the skills, is the culture, there's so many things. But when you have something—going back to what I said before—how you unite teams, when there's something a clear goal, a clear vision that everybody's excited about, they will make it work. So, I think this is where having a purpose for the innovation is critical for any successful project.Corey: I think and I hope that you're right. I really want to thank you for spending as much time with me as you have. If people want to learn more, where's the best place for them to find you?Chen: So, first of all, on Twitter. I'm there or on LinkedIn. I will say that I'm happy to connect with folks. Generally speaking, at some point in my career, I recognized that I have a voice that can help people, and I've experienced that can also help people build their careers. I'm happy to share that and [unintelligible 00:36:54] folks both in the company and outside of it.Corey: I think that's one of the obligations on a lot of us, once we wanted to get into a certain position or careers to send the ladder back down, for lack of a better term. It's I've never appreciated the perspective, “Well, screw everyone else. I got mine.” The whole point the next generation should have it easier than we did.Chen: Yeah, definitely.Corey: Chen Goldberg, General Manager of Cloud Runtimes and VP of Engineering at Google. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry rant of a comment talking about how LPARs on mainframes are absolutely not containers, making sure it's at least far too big to fit in a reasonably-sized Docker container.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

According to Ulfar Erlingsson, Chief Architect at Lacework, the fundamentals of security can be compared to a house – one must keep all windows and doors closed, have locks and keys to all the entry points, and a plan for what to do if something fails.

To remove the organizational “inertia” to meet the ever-changing business and market needs, organizations need to make a bold move with cloud, seek to operate with a clean core, and look for more ways to make the business more intelligent and responsive. Pavan Srivastava at Deloitte, Edy Sardilli at Google Cloud, and Chip Kleinheksel at Deloitte will share insights that can help you understand the art of the possible with cloud and SAP® solutions and explore ideas for accelerating the move to cloud. They will take a high-level look at key cloud players and technologies that can contribute to the Kinetic Enterprise, and major benefits of cloud solutions. Find out how cloud is fueling digital enterprise transformation today and learn how leading global organizations are now using cloud as the DNA of the “built to evolve” Kinetic Enterprise™, capable of moving at the speed of disruption. Join us for The Kinetic Enterprise: Leveraging Cloud to Accelerate Your Kinetic Enterprise Journey.

On The Cloud Pod this week, Amazon announces Neptune Serverless, Google introduces Google Blockchain Node Engine, and we get some cost management updates from Microsoft. Thank you to our sponsor, Foghorn Consulting, which provides top notch cloud and DevOps engineers to the world's most innovative companies. Initiatives stalled because you're having trouble hiring? Foghorn can be burning down your DevOps and Cloud backlogs as soon as next week. General News [1:24]

Leonard S. Johnson is the Founder and CEO of AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses. Victoria talks to Leonard about using artificial intelligence for good, bringing the power of AI to local economics, and truly democratizing AI. The Artificial Intelligence Economic Development Corporation (AIEDC) (https://netcapital.com/companies/aiedc) Follow AIEDC on Twitter (https://twitter.com/netcapital), Instagram (https://www.instagram.com/netcapital/), Facebook (https://www.facebook.com/Netcapital/), or LinkedIn (https://www.linkedin.com/company/aiedc/). Follow Leonard on Twitter (https://twitter.com/LeonardSJ) and LinkedIn (https://www.linkedin.com/in/leonardsjohnson84047/). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Leonard S. Johnson or LS, Founder and CEO AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses. Leonard, thanks for being with us today. LEONARD: Thank you for having me, Victoria. VICTORIA: I should say LS, thank you for being with us today. LEONARD: It's okay. It's fine. VICTORIA: Great. So tell us a little more about AIEDC. LEONARD: Well, AIEDC stands for Artificial Intelligence Economic Development Corporation. And the original premise that I founded it for...I founded it after completing my postgraduate work at Stanford, and that was 2016. And it was to use AI for economic development, and therefore use AI for good versus just hearing about artificial intelligence and some of the different movies that either take over the world, and Skynet, and watch data privacy, and these other things which are true, and it's very evident, they exist, and they're out there. But at the end of the day, I've always looked at life as a growth strategy and the improvement of what we could do and focusing on what we could do practically. You do it tactically, then you do it strategically over time, and you're able to implement things. That's why I think we keep building collectively as humanity, no matter what part of the world you're in. VICTORIA: Right. So you went to Stanford, and you're from South Central LA. And what about that background led you to pursue AI for good in particular? LEONARD: So growing up in the inner city of Los Angeles, you know, that South Central area, Compton area, it taught me a lot. And then after that, after I completed high school...and not in South Central because I moved around a lot. I grew up with a single mother, never knew my real father, and then my home life with my single mother wasn't good because of just circumstances all the time. And so I just started understanding that even as a young kid, you put your brain...you utilize something because you had two choices. It's very simple or binary, you know, A or B. A, you do something with yourself, or B, you go out and be social in a certain neighborhood. And I'm African American, so high probability that you'll end up dead, or in a gang, or in crime because that's what it was at that time. It's just that's just a situation. Or you're able to challenge those energies and put them toward a use that's productive and positive for yourself, and that's what I did, which is utilizing a way to learn. I could always pick up things when I was very young. And a lot of teachers, my younger teachers, were like, "You're very, very bright," or "You're very smart." And there weren't many programs because I'm older than 42. So there weren't as many programs as there are today. So I really like all of the programs. So I want to clarify the context. Today there's a lot more engagement and identification of kids that might be sharper, smarter, whatever their personal issues are, good or bad. And it's a way to sort of separate them. So you're not just teaching the whole group as a whole and putting them all in one basket, but back then, there was not. And so I just used to go home a lot, do a lot of reading, do a lot of studying, and just knick-knack with things in tech. And then I just started understanding that even as a young kid in the inner city, you see economics very early, but they don't understand that's really what they're studying. They see economics. They can see inflation because making two ends meet is very difficult. They may see gang violence and drugs or whatever it might end up being. And a lot of that, in my opinion, is always an underlining economic foundation. And so people would say, "Oh, why is this industry like this?" And so forth. "Why does this keep happening?" It's because they can't function. And sometimes, it's just them and their family, but they can't function because it's an economic system. So I started focusing on that and then went into the Marine Corps. And then, after the Marine Corps, I went to Europe. I lived in Europe for a while to do my undergrad studies in the Netherlands in Holland. VICTORIA: So having that experience of taking a challenge or taking these forces around you and turning into a force for good, that's led you to bring the power of AI to local economics. And is that the direction that you went eventually? LEONARD: So economics was always something that I understood and had a fascination prior to even starting my company. I started in 2017. And we're crowdfunding now, and I can get into that later. But I self-funded it since 2017 to...I think I only started crowdfunding when COVID hit, which was 2020, and just to get awareness and people out there because I couldn't go to a lot of events. So I'm like, okay, how can I get exposure? But yeah, it was a matter of looking at it from that standpoint of economics always factored into me, even when I was in the military when I was in the Marine Corps. I would see that...we would go to different countries, and you could just see the difference of how they lived and survived. And another side note, my son's mother is from Ethiopia, Africa. And I have a good relationship with my son and his mother, even though we've been apart for over 15 years, divorced for over 15 years or so or longer. But trying to keep that, you can just see this dichotomy. You go out to these different countries, and even in the military, it's just so extreme from the U.S. and any part of the U.S, but that then always focused on economics. And then technology, I just always kept up with, like, back in the '80s when the mobile brick phone came out, I had to figure out how to get one. [laughs] And then I took it apart and then put it back together just to see how it works, so yeah. But it was a huge one, by the way. I mean, it was like someone got another and broke it, and they thought it was broken. And they're like, "This doesn't work. You could take this piece of junk." I'm like, "Okay." [laughs] VICTORIA: Like, oh, great. I sure will, yeah. Now, I love technology. And I think a lot of people perceive artificial intelligence as being this super futuristic, potentially harmful, maybe economic negative impact. So what, from your perspective, can AI do for local economics or for people who may not have access to that advanced technology? LEONARD: Well, that's the key, and that's what we're looking to do with AIEDC. When you look at the small and midsize businesses, it's not what people think, or their perception is. A lot of those in the U.S. it's the backbone of the United States, our economy, literally. And in other parts of the world, it's the same where it could be a one or two mom-and-pop shops. That's where that name comes from; it's literally two people. And they're trying to start something to build their own life over time because they're using their labor to maybe build wealth or somehow a little bit not. And when I mean wealth, it's always relative. It's enough to sustain themselves or just put food on the table and be able to control their own destiny to the best of their ability. And so what we're looking to do is make a mobile app maker that's 5G that lives in the cloud, that's 5G compliant, that will allow small and midsize businesses to create their own iOS or Android mobile app with no-code or low-code, basically like creating an email. That's how simple we want it to be. When you create your own email, whether you use Microsoft, Google, or whatever you do, and you make it that simple. And there's a simple version, and there could be complexity added to it if they want. That would be the back office digitization or customization, but that then gets them on board with digitization. It's intriguing that McKinsey just came out with a report stating that in 2023, in order to be economically viable, and this was very recent, that all companies would need to have a digitization strategy. And so when you look at small businesses, and you look at things like COVID-19, or the COVID current ongoing issue and that disruption, this is global. And you look at even the Ukrainian War or the Russian-Ukrainian War, however you term it, invasion, war, special operation, these are disruptions. And then, on top of that, we look at climate change which has been accelerating in the last two years more so than it was prior to this that we've experienced. So this is something that everyone can see is self-evident. I'm not even focused on the cause of the problem. My brain and the way I think, and my team, we like to focus on solutions. My chairman is a former program director of NASA who managed 1,200 engineers that built the International Space Station; what was it? 20-30 years ago, however, that is. And he helped lead and build that from Johnson Center. And so you're focused on solutions because if you're building the International Space Station, you can only focus on solutions and anticipate the problems but not dwell on them. And so that kind of mindset is what I am, and it's looking to help small businesses do that to get them on board with digitization and then in customization. And then beyond that, use our system, which is called M.I.N.D. So we own these...we own patents, three patents, trademarks, and service marks related to artificial intelligence that are in the field of economics. And we will utilize DEVS...we plan to do that which is a suite of system specifications to predict regional economic issues like the weather in a proactive way, not reactive. A lot of economic situations are reactive. It's reactive to the Federal Reserve raising interest rates or lowering rates, Wall Street, you know, moving money or not moving money. It is what it is. I mean, I don't judge it. I think it's like financial engineering, and that's fine. It's profitability. But then, at the end of the day, if you're building something, it's like when we're going to go to space. When rockets launch, they have to do what they're intended to do. Like, I know that Blue Origin just blew up recently. Or if they don't, they have a default, and at least I heard that the Blue Origin satellite, if it were carrying passengers, the passengers would have been safe because it disembarked when it detected its own problem. So when you anticipate these kinds of problems and you apply them to the local small business person, you can help them forecast and predict better like what weather prediction has done. And we're always improving that collectively for weather prediction, especially with climate change, so that it can get to near real-time as soon as possible or close a window versus two weeks out versus two days out as an example. VICTORIA: Right. Those examples of what you call a narrow economic prediction. LEONARD: Correct. It is intriguing when you say narrow economic because it wouldn't be narrow AI. But it would actually get into AGI if you added more variables, which we would. The more variables you added in tenancies...so if you're looking at events, the system events discretion so discrete event system specification you would specify what they really, really need to do to have those variables. But at some point, you're working on a system, what I would call AGI. But AGI, in my mind, the circles I run in at least or at least most of the scientists I talk to it's not artificial superintelligence. And so the general public thinks AGI...and I've said this to Stephen Ibaraki, who's the founder of AI for Good at Global Summit at the United Nations, and one of his interviews as well. It's just Artificial General Intelligence, I think, has been put out a lot by Hollywood and entertainment and so forth, and some scientists say certain things. We won't be at artificial superintelligence. We might get to Artificial General Intelligence by 2030 easily, in my opinion. But that will be narrow AI, but it will cover what we look at it in the field as cross-domain, teaching a system to look at different variables because right now, it's really narrow. Like natural language processing, it's just going to look at language and infer from there, and then you've got backward propagation that's credit assignment and fraud and detection. Those are narrow data points. But when you start looking at something cross-domain...who am I thinking of? Pedro Domingos who wrote the Master Algorithm, which actually, Xi Jinping has a copy of, the President of China, on his bookshelf in his office because they've talked about that, and these great minds because Stephen Ibaraki has interviewed these...and the founder of Google Brain and all of these guys. And so there's always this debate in the scientific community of what is narrow AI what it's not. But at the end of the day, I just like Pedro's definition of it because he says the master algorithm will be combining all five, so you're really crossing domains, which AI hasn't done that. And to me, that will be AGI, but that's not artificial superintelligence. And artificial superintelligence is when it becomes very, you know, like some of the movies could say, if we as humanity just let it run wild, it could be crazy. VICTORIA: One of my questions is the future of AI more like iRobot or Bicentennial Man? LEONARD: Well, you know, interesting. That's a great question, Victoria. I see most of AI literally as iRobot, as a tool more than anything, except at the end when it implied...so it kind of did two things in that movie, but a wonderful movie to bring up. And I like Will Smith perfectly. Well, I liked him a lot more before -- VICTORIA: I think iRobot is really the better movie. LEONARD: Yeah, so if people haven't seen iRobot, I liked Will Smith, the actor. But iRobot showed you two things, and it showed you, one, it showed hope. Literally, the robot...because a lot of people put AI and robots. And AI by itself is the brain or the mind; I should say hardware are the robots or the brain. Software...AI in and of itself is software. It's the mind itself. That's why we have M.I.N.D Machine Intelligence NeuralNetwork Database. We literally have that. That's our acronym and our slogan and everything. And it's part of our patents. But its machine intelligence is M.I.N.D, and we own that, you know; the company owns it. And so M.I.N.D...we always say AI powered by M.I.N.D. We're talking about that software side of, like, what your mind does; it iterates and thinks, the ability to think itself. Now it's enclosed within a structure called, you know, for the human, it's called a brain, the physical part of it, and that brain is enclosed within the body. So when you look at robots...and my chairman was the key person for robotics for the International Space Station. So when you look at robotics, you are putting that software into hardware, just like your cell phone. You have the physical, and then you have the actual iOS, which is the operating system. So when you think about that, yeah, iRobot was good because it showed how these can be tools, and they were very, in the beginning of the movie, very helpful, very beneficial to humanity. But then it went to a darker side and showed where V.I.K.I, which was an acronym as well, I think was Virtual Interactive Kinetic technology of something. Yeah, I believe it was Virtual Interactive Kinetic inference or technology or something like that, V.I.K.I; I forgot the last I. But that's what it stood for. It was an acronym to say...and then V.I.K.I just became all aware and started killing everyone with robots and just wanted to say, you know, this is futile. But then, at the very, very end, V.I.K.I learned from itself and says, "Okay, I guess this isn't right." Or the other robot who could think differently argued with V.I.K.I, and they destroyed her. And it made V.I.K.I a woman in the movie, and then the robot was the guy. But that shows that it can get out of hand. But it was intriguing to me that they had her contained within one building. This wouldn't be artificial superintelligence. And I think sometimes Hollywood says, "Just take over everything from one building," no. It wouldn't be on earth if it could. But that is something we always have to think about. We have to think about the worst-case scenarios. I think every prudent scientist or business person or anyone should do that, even investors, I mean, if you're investing something for the future. But you also don't focus on it. You don't think about the best-case scenario, either. But there's a lot of dwelling on the worst-case scenario versus the good that we can do given we're looking at where humanity is today. I mean, we're in 2022, and we're still fighting wars that we fought in 1914. VICTORIA: Right. Which brings me to my next question, which is both, what are the most exciting opportunities to innovate in the AI space currently? And conversely, what are the biggest challenges that are facing innovation in that field? LEONARD: Ooh, that's a good question. I think, in my opinion, it's almost the same answer; one is...but I'm in a special field. And I'm surprised there's not a lot of competition for our company. I mean, it's very good for me and the company's sense. It's like when Mark Zuckerberg did Facebook, there was Friendster, and there was Myspace, but they were different. They were different verticals. And I think Mark figured out how to do it horizontally, good or bad. I'm talking about the beginning of when he started Facebook, now called Meta. But I'm saying utilizing AI in economics because a lot of times AI is used in FinTech and consumerism, but not economic growth where we're really talking about growing something organically, or it's called endogenous growth. Because I studied Paul Romer's work, who won the Nobel Prize in 2018 for economic science. And he talked about the nature of ideas. And we were working on something like that in Stanford. And I put out a book in 2017 of January talking about cryptocurrencies, artificial intelligence but about the utilization of it, but not the speculation. I never talked about speculation. I don't own any crypto; I would not. It's only once it's utilized in its PureTech form will it create something that it was envisioned to do by the protocol that Satoshi Nakamoto sort of created. And it still fascinates me that people follow Bitcoin protocol, even for the tech and the non-tech, but they don't know who Satoshi is. But yeah, it's a white paper. You're just following a white paper because I think logically, the world is going towards that iteration of evolution. And that's how AI could be utilized for good in an area to focus on it with economics and solving current problems. And then going forward to build a new economy where it's not debt-based driven or consumer purchase only because that leaves a natural imbalance in the current world structure. The western countries are great. We do okay, and we go up and down. But the emerging and developing countries just get stuck, and they seem to go into a circular loop. And then there are wars as a result of these things and territory fights and so forth. So that's an area I think where it could be more advanced is AI in the economic realm, not so much the consumer FinTech room, which is fine. But consumer FinTech, in my mind, is you're using AI to process PayPal. That's where I think Elon just iterated later because PayPal is using it for finance. You're just moving things back and forth, and you're just authenticating everything. But then he starts going on to SpaceX next because he's like, well, let me use technology in a different way. And I do think he's using AI on all of his projects now. VICTORIA: Right. So how can that tech solve real problems today? Do you see anything even particular about Southern California, where we're both at right now, where you think AI could help predict some outcomes for small businesses or that community? LEONARD: I'm looking to do it regionally then globally. So I'm part of this Southern Cal Innovation Hub, which is just AI. It's an artificial intelligence coordination between literally San Diego County, Orange County, and Los Angeles County. And so there's a SoCal Innovation Hub that's kind of bringing it together. But there are all three groups, like; I think the CEO in Orange County is the CEO of Leadership Alliance. And then in San Diego, there's another group I can't remember their name off the top of my head, and I'm talking about the county itself. So each one's representing a county because, you know. And then there's one in Northern California that I'm also associated with where if you look at California as its own economy in the U.S., it's still pretty significant as an economic cycle in the United States, period. That's why so many politicians like California because they can sway the votes. So yeah, we're looking to do that once, you know, we are raising capital. We're crowdfunding currently. Our total raise is about 6 million. And so we're talking to venture capitalists, private, high net worth investors as well. Our federal funding is smaller. It's just like several hundred thousand because most people can only invest a few thousand. But I always like to try to give back. If you tell people...if you're Steve Jobs, like, okay, I've got this Apple company. In several years, you'll see the potential. And people are like, ah, whatever, but then they kick themselves 15 years later. [laughs] Like, oh, I wish I thought about that Apple stock for $15 when I could. But you give people a chance, and you get the word out, and you see what happens. Once you build a system, you share it. There are some open-source projects. But I think the open source, like OpenAI, as an example, Elon Musk funds that as well as Microsoft. They both put a billion dollars into it. It is an open-source project. OpenAI claims...but some of the research does go back to Microsoft to be able to see it. And DeepMind is another research for AI, but they're owned by Google. And so, I'm also very focused on democratizing artificial intelligence for the benefit of everyone. I really believe that needs to be democratized in a sense of tying it to economics and making it utilized for everyone that may need it for the benefit of humanity where it's profitable and makes money, but it's not just usurping. MID-ROLL AD: As life moves online, brick-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what's important to your customers to help you transition to intuitive digital services your customers will trust. We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. VICTORIA: With that democratizing it, is there also a need to increase the understanding of the ethics around it and when there are certain known use cases for AI where it actually is discriminatory and plays to systemic problems in our society? Are you familiar with that as well? LEONARD: Yes, absolutely. Well, that's my whole point. And, Victoria, you just hit the nail on the head. Truly democratizing AI in my mind and in my brain the way it works is it has opened up for everyone. Because if you really roll it back, okay, companies now we're learning...we used to call it several years ago UGC, User Generated Content. And now a lot of people are like, okay, if you're on Facebook, you're the product, right? Or if you're on Instagram, you're the product. And they're using you, and you're using your data to sell, et cetera, et cetera. But user-generated content it's always been that. It's just a matter of the sharing of the economic. That's why I keep going back to economics. So if people were, you know, you wouldn't have to necessarily do advertising if you had stakeholders with advertising, the users and the company, as an example. If it's a social media company, just throwing it out there, so let's say you have a social media...and this has been talked about, but I'm not the first to introduce this. This has been talked about for over ten years, at least over 15 years. And it's you share as a triangle in three ways. So you have the user and everything else. So take your current social media, and I won't pick on Facebook, but I'll just use them, Facebook, Instagram, or Twitter. Twitter's having issues recently because Elon is trying to buy them or get out of buying them. But you just looked at that data, and then you share with the user base. What's the revenue model? And there needs to be one; let me be very clear. There has to be incentive, and there has to be profitability for people that joined you earlier, you know, joined the corporation, or become shareholders, or investors, or become users, or become customers. They have to be able to have some benefit, not extreme greater than everyone else but a great benefit from coming in earlier by what they contributed at the time. And that is what makes this system holistic in my opinion, like Reddit or any of these bloggers. But you make it where they use their time and the users, and you share it with the company and then the data and so forth, and whatever revenue economic model you have, and it's a sort of a three-way split. It's just not always equal. And that's something that I think in economics, we're still on a zero-sum game, I win, you lose sort of economic model globally. That's why there's a winner of a war and a loser of a war. But in reality, as you know, Victoria, there are no winners of any war. So it's funny, [laughs] I was just saying, well, you know, because of the economic mode, but Von Neumann, who talked about that, also talked about something called a non-zero-sum game when he talked about it in mathematics that you can win, and I can win; we just don't win equally because they never will match that. So if I win, I may win 60; you win 40. Or you may win 60, I win 40, and we agree to settle on that. It's an agreement versus I'm just going to be 99, and you'll be 1%, or I'm just going to be 100, and you're at 0. And I think that our economic model tends to be a lot of that, like, when you push forth and there needs to be more of that. When you talk about the core of economics...and I go way back, you know, prior to the Federal Reserve even being started. I just look at the world, and it's always sort of been this land territorial issue of what goods are under the country. But we've got technology where we can mitigate a lot of things and do the collective of help the earth, and then let's go off to space, all of space. That's where my brain is focused on. VICTORIA: Hmm. Oh yeah, that makes sense to me. I think that we're all going to have to evolve our economic models here in the future. I wonder, too, as you're building your startup and you're building your company, what are some of the technology trade-offs you're having to make in the stack of the AI software that you're building? LEONARD: Hmm. Good question. But clarify, this may be a lot deeper dive because that's a general question. And I don't want to...yeah, go ahead. VICTORIA: Because when you're building AI, and you're going to be processing a lot of data, I know many data scientists that are familiar with tools like Jupyter Notebooks, and R, and Python. And one issue that I'm aware of is keeping the environments the same, so everything that goes into building your app and having those infrastructure as code for your data science applications, being able to afford to process all that data. [laughs] And there are just so many factors that go into building an AI app versus building something that's more easy, like a web-based user form. So just curious if you've encountered those types of trade-offs or questions about, okay, how are we going to actually build an app that we can put out on everybody's phone and that works responsibly? LEONARD: Oh, okay. So let me be very clear, but I won't give too much of the secret sauce away. But I can define this technically because this is a technical audience. This is not...so what you're really talking about is two things, and I'm clear about this, though. So the app maker won't really read and write a lot of data. It'll just be the app where people could just get on board digitalization simple, you know, process payments, maybe connect with someone like American Express square, MasterCard, whatever. And so that's just letting them function. That's sort of small FinTech in my mind, you know, just transaction A to B, B to A, et cetera. And it doesn't need to be peer-to-peer and all of the crypto. It doesn't even need to go that level yet. That's just level one. Then they will sign up for a service, which is because we're really focused on artificial intelligence as a service. And that, to me, is the next iteration for AI. I've been talking about this for about three or four years now, literally, in different conferences and so forth for people who haven't hit it. But that we will get to that point where AI will become AI as a service, just like SaaS is. We're still at the, you know, most of the world on the legacy systems are still software as a service. We're about to hit AI as a service because the world is evolving. And this is true; they did shut it down. But you did have okay, so there are two case points which I can bring up. So JP Morgan did create something called a Coin, and it was using AI. And it was a coin like crypto, coin like a token, but they called it a coin. But it could process, I think, something like...I may be off on this, so to the sticklers that will be listening, please, I'm telling you I may be off on the exact quote, but I think it was about...it was something crazy to me, like 200,000 of legal hours and seconds that it could process because it was basically taking the corporate legal structure of JP Morgan, one of the biggest banks. I think they are the biggest bank in the U.S. JPMorgan Chase. And they were explaining in 2017 how we created this, and it's going to alleviate this many hours of legal work for the bank. And I think politically; something happened because they just pulled away. I still have the original press release when they put it out, and it was in the media. And then it went away. I mean, no implementation [laughs] because I think there was going to be a big loss of jobs for it. And they basically would have been white-collar legal jobs, most specifically lawyers literally that were working for the bank. And when they were talking towards investment, it was a committee. I was at a conference. And I was like, I was fascinated by that. And they were basically using Bitcoin protocol as the tokenization protocol, but they were using AI to process it. And it was basically looking at...because legal contracts are basically...you can teach it with natural language processing and be able to encode and almost output it itself and then be able to speak with each other. Another case point was Facebook. They had...what was it? Two AI systems. They began to create their own language. I don't know if you remember that story or heard about it, and Facebook shut it down. And this was more like two years ago, I think, when they were saying Facebook was talking, you know, when they were Facebook, not Meta, so maybe it was three years ago. And they were talking, and they were like, "Oh, Facebook has a language. It's talking to each other." And it created its own little site language because it was two AI bots going back and forth. And then the engineers at Facebook said, "We got to shut this down because this is kind of getting out of the box." So when you talk about AI as a service, yes, the good and the bad, and what you take away is AWS, Oracle, Google Cloud they do have services where it doesn't need to cost you as much anymore as it used to in the beginning if you know what you're doing ahead of time. And you're not just running iterations or data processing because you're doing guesswork versus, in my opinion, versus actually knowing exactly specifically what you're looking for and the data set you're looking to get out of it. And then you're talking about just basically putting in containers and clustering it because it gets different operations. And so what you're really looking at is something called an N-scale graph data that can process data in maybe sub seconds at that level, excuse me. And one of my advisors is the head of that anyway at AGI laboratory. So he's got an N graph database that can process...when we implement it, we'll be able to process data at the petabyte level at sub-seconds, and it can run on platforms like Azure or AWS, and so forth. VICTORIA: Oh, that's interesting. So it sounds like cloud providers are making compute services more affordable. You've got data, the N-scale graph data, that can run more transactions more quickly. And I'm curious if you see any future trends since I know you're a futurist around quantum computing and how that could affect capacity for -- LEONARD: Oh [laughs] We haven't even gotten there yet. Yes. Well, if you look at N-scale, if you know what you're doing and you know what to look for, then the quantum just starts going across different domains as well but at a higher hit rate. So there's been some quantum computers online. There's been several...well, Google has their quantum computer coming online, and they've been working on it, and Google has enough data, of course, to process. So yeah, they've got that data, lots of data. And quantum needs, you know, if it's going to do something, it needs lots of data. But then the inference will still be, I think, quantum is very good at processing large, large, large amounts of data. We can just keep going if you really have a good quantum computer. But it's really narrow. You have to tell it exactly what it wants, and it will do it in what we call...which is great like in P or NP square or P over NP which is you want to do it in polynomial time, not non-polynomial, polynomial time which is...now speaking too fast. Okay, my brain is going faster than my lips. Let me slow it down. So when you start thinking about processing, if we as humans, let's say if I was going to process A to Z, and I'm like, okay, here is this equation, if I tell you it takes 1000 years, it's of no use to us, to me and you Victoria because we're living now. Now, the earth may benefit in 1000 years, but it's still of no use. But if I could take this large amount of data and have it process within minutes, you know, worst case hours...but then I'll even go down to seconds or sub-seconds, then that's really a benefit to humanity now, today in present term. And so, as a futurist, yes, as the world, we will continue to add data. We're doing it every day, and we already knew this was coming ten years ago, 15 years ago, 20 years ago, even actually in the '50s when we were in the AI winter. We're now in AI summer. In my words, I call it the AI summer. So as you're doing this, that data is going to continue to increase, and quantum will be needed for that. But then the specific need...quantum is very good at looking at a specific issue, specifically for that very narrow. Like if you were going to do the trajectory to Jupiter or if we wanted to send a probe to Jupiter or something, I think we're sending something out there now from NASA, and so forth, then you need to process all the variables, but it's got one trajectory. It's going one place only. VICTORIA: Gotcha. Well, that's so interesting. I'm glad I asked you that question. And speaking of rockets going off to space, have you ever seen a SpaceX launch from LA? LEONARD: Actually, I saw one land but not a launch. I need to go over there. It's not too far from me. But you got to give credit where credit's due and Elon has a reusable rocket. See, that's where technology is solving real-world problems. Because NASA and I have, you know, my chairman, his name is Alexander Nawrocki, you know, he's Ph.D., but I call him Rocki. He goes by Rocki like I go by LS. But it's just we talk about this like NASA's budget. [laughs] How can you reduce this? And Elon says they will come up with a reusable rocket that won't cost this much and be able to...and that's the key. That was the kind of Holy Grail where you can reuse the same rocket itself and then add some little variables on top of it. But the core, you wouldn't constantly be paying for it. And so I think where the world is going...and let me be clear, Elon pushes a lot out there. He's just very good at it. But I'm also that kind of guy that I know that Tesla itself was started by two Stanford engineers. Elon came on later, like six months, and then he invested, and he became CEO, which was a great investment for Elon Musk. And then CEO I just think it just fit his personality because it was something he loved. But I also have studied for years Nikola Tesla, and I understand what his contributions created where we are today with all the patents that he had. And so he's basically the father of WiFi and why we're able to communicate in a lot of this. We've perfected it or improved it, but it was created by him in the 1800s. VICTORIA: Right. And I don't think he came from as fortunate a background as Elon Musk, either. Sometimes I wonder what I could have done born in similar circumstances. [laughter] And you certainly have made quite a name for yourself. LEONARD: Well, I'm just saying, yeah, he came from very...he did come from a poor area of Russia which is called the Russian territory, to be very honest, Eastern Europe, definitely Eastern Europe. But yeah, I don't know once you start thinking about that [laughs]. You're making me laugh, Victoria. You're making me laugh. VICTORIA: No, I actually went camping, a backpacking trip to the Catalina Island, and there happened to be a SpaceX launch that night, and we thought it was aliens because it looked wild. I didn't realize what it was. But then we figured it was a launch, so it was really great. I love being here and being close to some of this technology and the advancements that are going on. I'm curious if you have some thoughts about...I hear a lot about or you used to hear about Silicon Valley Tech like very Northern California, San Francisco focus. But what is the difference in SoCal? What do you find in those two communities that makes SoCal special? [laughs] LEONARD: Well, I think it's actually...so democratizing AI. I've been in a moment like that because, in 2015, I was in Dubai, and they were talking about creating silicon oasis. And so there's always been this model of, you know, because they were always, you know, the whole Palo Alto thing is people would say it and it is true. I mean, I experienced it. Because I was in a two-year program, post-graduate program executive, but we would go up there...I wasn't living up there. I had to go there maybe once every month for like three weeks, every other month or something. But when you're up there, it is the air in the water. It's just like, people just breathe certain things. Because around the world, and I would travel to Japan, and China, and other different parts of Asia, Vietnam, et cetera and in Africa of course, and let's say you see this and people are like, so what is it about Silicon Valley? And of course, the show, there is the Hollywood show about it, which is pretty a lot accurate, which is interesting, the HBO show. But you would see that, and you would think, how are they able to just replicate this? And a lot of it is a convergence. By default, they hear about these companies' access because the key is access, and that's what we're...like this podcast. I love the concept around it because giving awareness, knowledge, and access allows other people to spread it and democratize it. So it's just not one physical location, or you have to be in that particular area only to benefit. I mean, you could benefit in that area, or you could benefit from any part of the world. But since they started, people would go there; engineers would go there. They built company PCs, et cetera. Now that's starting to spread in other areas like Southern Cal are creating their own innovation hubs to be able to bring all three together. And those three are the engineers and founders, and idea makers and startups. And you then need the expertise. I'm older than 42; I'm not 22. [laughs] So I'm just keeping it 100, keeping it real. So I'm not coming out at 19. I mean, my son's 18. And I'm not coming out, okay, this my new startup, bam, give me a billion dollars, I'm good. And let me just write off the next half. But when you look at that, there's that experience because even if you look at Mark Zuckerberg, I always tell people that give credit where credit is due. He brought a senior team with him when he was younger, and he didn't have the experience. And his only job has been Facebook out of college. He's had no other job. And now he's been CEO of a multi-billion dollar corporation; that's a fact. Sometimes it hurts people's feelings. Like, you know what? He's had no other job. Now that can be good and bad, [laughs] but he's had no other jobs. And so that's just a credit, like, if you can surround yourself with the right people and be focused on something, it can work to the good or the bad for your own personal success but then having that open architecture. And I think he's been trying to learn and others versus like an Elon Musk, who embraces everything. He's just very open in that sense. But then you have to come from these different backgrounds. But let's say Elon Musk, Mark Zuckerberg, let's take a guy like myself or whatever who didn't grow up with all of that who had to make these two ends meet, figure out how to do the next day, not just get to the next year, but get to the next day, get to the next week, get to the next month, then get to the next year. It just gives a different perspective as well. Humanity's always dealing with that. Because we had a lot of great engineers back in the early 1900s. They're good or bad, you know, you did have Nikola Tesla. You had Edison. I'm talking about circa around 1907 or 1909, prior to World War I. America had a lot of industries. They were the innovators then, even though there were innovations happening in Europe, and Africa, and China, as well and Asia. But the innovation hub kind of created as the America, quote, unquote, "industrial revolution." And I think we're about to begin a new revolution sort of tech and an industrial revolution that's going to take us to maybe from 20...we're 2022 now, but I'll say it takes us from 2020 to 2040 in my head. VICTORIA: So now that communities can really communicate across time zones and locations, maybe the hubs are more about solving specific problems. There are regional issues. That makes a lot more sense. LEONARD: Yes. And collaborating together, working together, because scientists, you know, COVID taught us that. People thought you had to be in a certain place, but then a lot of collaboration came out of COVID; even though it was bad globally, even though we're still bad, if people were at home, they start collaborating, and scientists will talk to scientists, you know, businesses, entrepreneurs, and so forth. But if Orange County is bringing together the mentors, the venture capital, or at least Southern California innovation and any other place, I want to say that's not just Silicon Valley because Silicon Valley already has it; we know that. And that's that region. It's San Jose all the way up to...I forgot how far north it's past San Francisco, actually. But it's that region of area where they encompass the real valley of Silicon Valley if you're really there. And you talk about these regions. Yes, I think we're going to get to a more regional growth area, and then it'll go more micro to actually cities later in the future. But regional growth, I think it's going to be extremely important globally in the very near term. I'm literally saying from tomorrow to the next, maybe ten years, regional will really matter. And then whatever you have can scale globally anyway, like this podcast we're doing. This can be distributed to anyone in the world, and they can listen at ease when they have time. VICTORIA: Yeah, I love it. It's both exciting and also intimidating. [laughs] And you mentioned your son a little bit earlier. And I'm curious, as a founder and someone who spent a good amount of time in graduate and Ph.D. programs, if you feel like it's easy to connect with your son and maintain that balance and focusing on your family while you're building a company and investing in yourself very heavily. LEONARD: Well, I'm older, [laughs] so it's okay. I mean, I've mentored him, you know. And me and his mom have a relationship that works. I would say we have a better relationship now than when we were together. It is what it is. But we have a communication level. And I think she was just a great person because I never knew my real father, ever. I supposedly met him when I was two or one; I don't know. But I have no memories, no photos, nothing. And that was just the environment I grew up in. But with my son, he knows the truth of everything about that. He's actually in college. I don't like to name the school because it's on the East Coast, and it's some Ivy League school; that's what I will say. And he didn't want to stay on the West Coast because I'm in Orange County and his mom's in Orange County. He's like, "I want to get away from both of you people." [laughter] And that's a joke, but he's very independent. He's doing well. When he graduated high school, he graduated with 4.8 honors. He made the valedictorian. He was at a STEM school. VICTORIA: Wow. LEONARD: And he has a high GPA. He's studying computer science and economics as well at an Ivy League, and he's already made two or three apps at college. And I said, "You're not Mark, so calm down." [laughter] But anyway, that was a recent conversation. I won't go there. But then some people say, "LS, you should be so happy." What is it? The apple doesn't fall far from the tree. But this was something he chose around 10 or 11. I'm like, whatever you want to do, you do; I'll support you no matter what. And his mom says, "Oh no, I think you programmed him to be like you." [laughs] I'm like, no, I can't do that. I just told him the truth about life. And he's pretty tall. VICTORIA: You must have -- LEONARD: He played basketball in high school a lot. I'm sorry? VICTORIA: I was going to say you must have inspired him. LEONARD: Yeah. Well, he's tall. He did emulate me in a lot of ways. I don't know why. I told him just be yourself. But yes, he does tell me I'm an inspiration to that; I think because of all the struggles I've gone through when I was younger. And you're always going through struggles. I mean, it's just who you are. I tell people, you know, you're building a company. You have success. You can see the future, but sometimes people can't see it, [laughs] which I shouldn't really say, but I'm saying anyway because I do that. I said this the other night to some friends. I said, "Oh, Jeff Bezo's rocket blew up," going, you know, Blue Origin rocket or something. And then I said Elon will tell Jeff, "Well, you only have one rocket blow up. I had three, [laughter] SpaceX had three." So these are billionaires talking to billionaires about, you know, most people don't even care. You're worth X hundred billion dollars. I mean, they're worth 100 billion-plus, right? VICTORIA: Right. LEONARD: I think Elon is around 260 billion, and Jeff is 160 or something. Who cares about your rocket blowing up? But it's funny because the issues are still always going to be there. I've learned that. I'm still learning. It doesn't matter how much wealth you have. You just want to create wealth for other people and better their lives. The more you search on bettering lives, you're just going to have to wake up every day, be humble with it, and treat it as a new day and go forward and solve the next crisis or problem because there will be one. There is not where there are no problems, is what I'm trying to say, this panacea or a utopia where you personally, like, oh yeah, I have all this wealth and health, and I'm just great. Because Elon has had divorce issues, so did Jeff Bezos. So I told my son a lot about this, like, you never get to this world where it's perfect in your head. You're always going to be doing things. VICTORIA: That sounds like an accurate future prediction if I ever heard one. [laughs] Like, there will be problems. No matter where you end up or what you choose to do, you'll still have problems. They'll just be different. [laughs] LEONARD: Yeah, and then this is for women and men. It means you don't give up. You just keep hope alive, and you keep going. And I believe personally in God, and I'm a scientist who actually does. But I look at it more in a Godly aspect. But yeah, I just think you just keep going, and you keep building because that's what we do as humanity. It's what we've done. It's why we're here. And we're standing on the shoulders of giants, and I just always considered that from physicists and everyone. VICTORIA: Great. And if people are interested in building something with you, you have that opportunity right now to invest via the crowdfunding app, correct? LEONARD: Yes, yes, yes. They can do that because the company is still the same company because eventually, we're going to branch out. My complete vision for AIEDC is using artificial intelligence for economic development, and that will spread horizontally, not just vertically. Vertically right now, just focus on just a mobile app maker digitization and get...because there are so many businesses even globally, and I'm not talking only e-commerce. So when I say small to midsize business, it can be a service business, car insurance, health insurance, anything. It doesn't have to be selling a particular widget or project, you know, product. And I'm not saying there's nothing wrong with that, you know, interest rates and consumerism. But I'm not thinking about Shopify, and that's fine, but I'm talking about small businesses. And there's the back office which is there are a lot of tools for back offices for small businesses. But I'm talking about they create their own mobile app more as a way to communicate with their customers, update them with their customers, and that's key, especially if there are disruptions. So let's say that there have been fires in California. In Mississippi or something, they're out of water. In Texas, last year, they had a winter storm, electricity went out. So all of these things are disruptions. This is just in the U.S., And of course, I won't even talk about Pakistan, what's going on there and the flooding and just all these devastating things, or even in China where there's drought where there are these disruptions, and that's not counting COVID disrupts, the cycle of business. It literally does. And it doesn't bubble up until later when maybe the central banks and governments pay attention to it, just like in Japan when that nuclear, unfortunately, that nuclear meltdown happened because of the earthquake; I think it was 2011. And that affected that economy for five years, which is why the government has lower interest rates, negative interest rates, because they have to try to get it back up. But if there are tools and everyone's using more mobile apps and wearables...and we're going to go to the metaverse and all of that. So the internet of things can help communicate that. So when these types of disruptions happen, the flow of business can continue, at least at a smaller level, for an affordable cost for the business. I'm not talking about absorbing costs because that's meaningless to me. VICTORIA: Yeah, well, that sounds like a really exciting project. And I'm so grateful to have this time to chat with you today. Is there anything else you want to leave for our listeners? LEONARD: If they want to get involved, maybe they can go to our crowdfunding page, or if they've got questions, ask about it and spread the word. Because I think sometimes, you know, they talk about the success of all these companies, but a lot of it starts with the founder...but not a founder. If you're talking about a startup, it starts with the founder. But it also stops with the innovators that are around that founder, male or female, whoever they are. And it also starts with their community, building a collective community together. And that's why Silicon Valley is always looked at around the world as this sort of test case of this is how you create something from nothing and make it worth great value in the future. And I think that's starting to really spread around the world, and more people are opening up to this. It's like the crowdfunding concept. I think it's a great idea, like more podcasts. I think this is a wonderful idea, podcasts in and of themselves, so people can learn from people versus where in the past you would only see an interview on the business news network, or NBC, or Fortune, or something like that, and that's all you would understand. But this is a way where organically things can grow. I think the growth will continue, and I think the future's bright. We just have to know that it takes work to get there. VICTORIA: That's great. Thank you so much for saying that and for sharing your time with us today. I learned a lot myself, and I think our listeners will enjoy it as well. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobot.fm. You can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Leonard S. Johnson.

On the show this week, Carter Morgan and Anu Srivastava talk about AI and ML data analytics with Dataiku VP of Platform Strategy, Jed Dougherty, and Head of Product Marketing, Dan Darnell. Dataiku is an AI platform targeted for business team collaboration. The low and no code environments make it easy for developers and not so tech savvy employees to work together on analytics projects. It strives for everyday AI, making these normally highly technical data processes more accessible. Our guests detail the tools Dataiku provides customers, including ML Ops features for efficient models. Dataiku's managed offering allows businesses to concentrate on the model while Dataiku takes care of things like the deployment processes behind the scenes. We hear about the partnership between Dataiku and Google Cloud and Dataiku's integration with AlloyDB. Through a real example, our guests run us through the use of these two tools together. Jed talks about why Google Cloud works so well with Dataiku, especially for businesses looking for cutting edge technology. Jed Dougherty Jed is the VP of Platform Strategy at Dataiku. In this role he acts as a strategic technical advisor to Dataiku customers and prospects. He also works tightly with Engineering and Product stakeholders in order to ensure that all technical platform requests are properly followed, scoped and implemented. Dan Darnell Dan has over 20 years of experience in the analytics industry at established software companies, hyper-growth technology companies, and small technology start-ups. As the Head of Product Marketing at Dataiku, he owns positioning, evangelism, and content creation for product offerings and education on products for customers and partners. Cool things of the week Google Cloud supercharges NLP with large language models blog Practicing the principle of least privilege with Cloud Build and Artifact Registry blog Interview Dataiku site Dataiku YouTube videos BigQuery site Kubernetes site GKE site AlloyDB for PostgreSQL site Accelerate AI Adoption: 3 Steps to Deploy Dataiku for Google Cloud Platform blog Implementing Dataiku with BigQuery docs GCP Podcast Episode 238: ASML with Arnaud Hubaux podcast GCP Podcast Episode 229: Lucidworks with Radu Miclaus podcast What's something cool you're working on? Anu is working on interesting speech use cases and Google's Speech to Text. Join in with this tutorial! Carter is working on getting organized and working on something super cool! Hosts Carter Morgan and Anu Srivastava

To deliver for its customers, Botify continues to reinvent how companies perform SEO. From those early days of the manual indexing of websites to the eras of keyword stuffing and anchor links, Botify is changing the landscape of optimization. In this extended conversation of The Transformation Debrief, Chris Hood, Digital Strategist at Google Cloud, hosts Pierre Couzy, Chief Technology Officer at Botify, and Robert Rothschild, Chief Marketing Officer at Botify, to discuss how they are helping drive more traffic and revenue with machine learning and artificial intelligence to reinvent how companies perform SEO.

Thierry Cammal, directeur général de Renault Software Labs, et Anthony Cirot, directeur général de Google Cloud France, étaient les invités de Frédéric Simottel dans Tech & Co, ce mercredi 9 novembre. Ils sont revenus sur le partenariat Renault et Google pour développer la voiture connectée de demain sur BFM Business. Retrouvez l'émission du lundi au jeudi et réécoutez la en podcast.

DevOps is a concept that has exploded in the past few years, allowing software development teams to release software and automate the process. This decreases time to market and speeds up learning cycles. Continuous Integration and Continuous Delivery (CI/CD), automates the software delivery pipeline, continuously deploying new software releases in an automated fashion. But when we deploy code quickly, it's imperative that we don't ignore the security aspect from the beginning. Ideally, we shift security left and incorporate it into the pipeline right from the start. This reduces software vulnerabilities and makes sure our cloud resources are configured following the best practices in terms of security. Google Cloud Principle Architect Anjali Khatri and Google Cloud Solutions Engineer Nitin Vashishtha join the show to discuss DevOps, DevSecOps, the shift left movement, and how to use Google Cloud to create a secure CI/CD pipeline. Topics: How has the cloud changed the way people need to think about architecting secure systems? How does the scale of cloud potentially impact the scale of a security or privacy issue? What is DevOps? Why is this area so hot right now? What problems has the DevOps movement helped solve that were traditionally difficult or impossible to address? How does the Shift Left movement for security relate to what's happening in DevOps? What is DevSecOps? How does DevSecOps fit into a company's overall security and privacy program and strategy? When it comes to things like CI/CD, what are the common mistakes people can make when it comes to security, privacy, or compliance? Cloud Build is a serverless CI/CD platform, why do I need something beyond this to automate my pipeline? What other Cloud tools and components should I be using to make sure my CI/CD system is not only able to support my team's day to day development but is actually secure? Can you talk about Artifact Registry and what that product means in terms of security? How does Cloud's Binary Authorization system work? Why would I use it and how does that improve my security posture? Does the addition of security as part of say my CI/CD pipeline impact performance in a meaningful way? Can you walk me through what the CI/CD process looks like using the combination of Cloud tools and resources? How much knowledge and experience do I need to set this up? How does a combination of tools like this play with configuring Cloud resources directly within the Google Cloud Console? Are there Cloud products that help me lock down my source code? Are there Cloud products that automatically scan my code for security or privacy vulnerabilities? What are your thoughts on the future of cloud security? Are there technologies in this space that you are particularly excited about? Where should someone looking to learn more DevSecOps and cloud security? Resources: Building a secure CI/CD pipeline using Google Cloud built-in services Introducing Google Cloud's new Assured Open Source Software Service Software Delivery Shield overview Cloud Workstations Identity & Security Google Cloud Security Best Practices

The art of listening and simultaneously learning from customers is a top-notch skill in the tech industry, and it is one that SADA and SaaS Alliance Partner, Ocient, have mastered. The force is unstoppable when you bring two partners together with similar values. ☁️