Podcasts about API

Whit Gibbs is the Founder and CEO of Compass Mining. One of the fastest growing mining businesses in the industry In this conversation, we discuss Bitcoin Mining, Geometric Hashrate Distribution, Decentralization of the network, and how you can invest and get in the mining game today. ======================= BlockFi provides financial products for crypto investors. Products include high-yield interest accounts, USD loans, and no fee trading. To start earning today visit: http://www.blockfi.com/Pomp ======================= Choice is a new self-directed IRA product that I'm really excited about. If you are listening to this, you are likely part of the 7.1 million bitcoin owners who have retirement accounts with dollars in them, but not bitcoin. I was in that situation too. Now you can actually buy real Bitcoin in your retirement account. I'm talking about owning your private keys and using tax-advantaged dollars to do it too. Absolute game changer. https://www.retirewithchoice.com/pomp ======================= Circle is a global financial technology firm that enables businesses of all sizes to harness the power of stablecoins and public blockchains for payments, commerce and financial applications worldwide. Circle is also a principal developer of USD Coin (USDC), the fastest growing, fully reserved and regulated dollar stablecoin in the world. The free Circle Account and suite of platform API services bridge the gap between traditional payments and crypto for trading, DeFi, and NFT marketplaces. Create seamless, user-friendly, mainstream customer experiences with crypto-native infrastructure under the hood with Circle. Learn more at circle.com.

AT&T customers hit with malware CISA announces advisory panel Palo Alto Networks looks at speed of compromise in the cloud Thanks to our episode sponsor, Votiro Your users need to accept and open files to do their jobs. Keep them safe and productive with Votiro. With Votiro zero trust file sanitization API, your users can download and use any file instantly, from PDF to Autodesk CAD, with malicious code already removed—and full file usability intact. The signatureless file sanitization process happens in milliseconds without user friction. Visit Votiro.com and learn why millions of users trust Votiro to disarm billions of files each year.

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: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 sponsored in part by my friends at ThinkstCanary. Most companies find out way too late that they've been breached. ThinksCanary changes this and I love how they do it. Deploy canaries and canary tokens in minutes and then forget about them. What's great is the attackers tip their hand by touching them, giving you one alert, when it matters. I use it myself and I only remember this when I get the weekly update with a “we're still here, so you're aware” from them. It's glorious! There is zero admin overhead  to this, there are effectively no false positives unless I do something foolish. Canaries are deployed and loved on all seven continents. You can check out what people are saying at canary.love. And, their Kub config canary token is new and completely free as well. You can do an awful lot without paying them a dime, which is one of the things I love about them. It is useful stuff and not an, “ohh, I wish I had money.” It is speculator! Take a look; that's canary.love because it's genuinely rare to find a security product that people talk about in terms of love. It really is a unique thing to see. Canary.love. Thank you to ThinkstCanary for their support of my ridiculous, ridiculous nonsense.   Corey: Writing ad copy to fit into a 30 second slot is hard, but if anyone can do it the folks at Quali can. Just like their Torque infrastructure automation platform can deliver complex application environments anytime, anywhere, in just seconds instead of hours, days or weeks. Visit Qtorque.io today and learn how you can spin up application environments in about the same amount of time it took you to listen to this ad.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at InfluxData. And my guest is titled as the Chief Marketing Officer at InfluxData, and I don't even care because his bio has something absolutely fascinating that I want to address instead. Brian Mullen is an accomplished dealmaker is how the bio starts. And so many of us spend time negotiating deals, but so few people describe ourselves in that way. First, Brian, thank you for joining us. And secondly, what's up with that?Brian: [laugh]. Well, thanks, Corey, very excited to be here. And yes, dealmaker; I guess that would be apropos. How did I get into marketing? Well, a lot of my career is spent in business development, and so I think that's where the dealmaker part comes from.Several different roles, including my first role at Influx—when I joined Influx—was in business development and partnerships. And so, prior to coming to Influx, I spent many years building out the business development team at Twilio, growing that up, and we did a lot of deals with carriers, with Cloud partners, with all kinds of different partners; you name it, we worked with them. And then moving into Influx, joined in an BD capacity here and had a couple different roles that eventually evolved to Chief Marketing Officer. But  that's where the dealmaker comes from. I like to do deals, it's always nice to have one on the side   in whatever capacity you're working in, it's nice to have a deal or two working on the side. It kind of keeps you fresh.Corey: It's fun because people think, “Oh, a deal. You're thinking of mergers and acquisitions, and how hard could that be? You just show up with a bag of money and give it to people and then you have a deal closed.” And oh, if only it were that simple. Every client engagement we have on the consulting side has been a negotiation back and forth, and the idea is to ideally get everyone to the point where they're happy, but honestly, if everyone's slightly unhappy but can live with the result, we'll take that too.And as people go through their own careers it's, you're always trying to make a deal in some form: when you try to get a project approved, or you're trying to get resources thrown at something—by which I generally mean money, not people, though people, too—it's something that isn't necessarily clearly understood or discussed very often, despite the fact that half of what I do is negotiating with AWS on behalf of clients for better contractual terms. The thing that I think takes people by surprise the most is that dealmaking is almost never about pounding the table, being angry, and walking out, like you read the world's worst guide to buying a car or something. It's about finding the win for everyone. At least that's the way I've always approached it.Brian: That's a good point. And actually that wording that you described of finding a win for everybody, that's how I always thought about it. I think about it as first of all, you're trying to understand what the other party—and it could be an individual, it could be a company, it could be a group of companies, sometimes—you're trying to understand what their goals are, what their agenda is and see how that matches with your own; sometimes they're opposing, sometimes they're overlapping. And then everyone has to have some perceived win  in a deal. And it's not competitively; it's more like you just have to have value, that is kind of what the win is – having value in that deal.And so that's the way I always approached it. And doing deals, whether you're in BD or sales, or if you're working with vendors and you're in a different functional role, sometimes it's not even commercial, it's just about aligning resources, perhaps. Our deal might be that you and I are both going to put a collective effort into building something or taking something to market. In another scenario might be like, I'm going to pay for this service that you're delivering, or vice versa. Or we're going to go and bring two revenue-generating products together and take them to market. Whatever it might be, it doesn't matter so much what the mechanics are of the deal, but it's usually about aligning those agendas and in having someone get utility, get value on the other side.Corey: I think that people lose sight of the fact as well, that when you're talking about a service provider—and let's be clear, InfluxData has launched a cloud platform that we'll talk about in a minute—this is not the one-off transactional relationship; once the deal is signed, you've got to work with these people. When they host parts of your production infrastructure, whether you want to admit it or not they're your partner more so than they are your vendor. It has to be an ongoing relationship that people are, if they at least aren't thrilled with it, can at least be happy enough to live with, otherwise it just winds up with this growing sense of resentment and it just sort of leads nowhere.Brian: Yeah, there really is no deal moment. Yes, people sign agreements with companies, but that's just the very beginning. Your relationship evolves from there. We're delivering a product, we're delivering this platform that handles time-series data to our customers, and we're asking them to trust us with their product that they're taking out to market. They're asking us to handle their data and to deliver service to them that they're turning into their production applications. And so it's a big responsibility. And so we care about the relationship with our customers to continue that.Corey: So, I first really became aware of time-series data a few years back during a re:Invent keynote when they pre-announced Timestream, which took entirely too long to come to market. Okay, great. So, you're talking about time-series data. Can you explain what that means in simple terms? And I learned over the next eight minutes that they were talking about it, that no, no, they couldn't. I wound up more confused by the end of the announcement than I was at the beginning.So, assuming that I have the same respect for databases as you would expect for someone whose favorite data store is Route 53—because you can misuse it as a beautiful database—what is time-series data and why does it matter in 2021?Brian: Sure, it's a good question. And I was there in that audience as well that day. So, we think of time-series data as really any type of data that's stamped in time, in some way. It could be every hour, every minute, every second, every half second, whatever. But more specifically, it's any type of data that is generated by some source—and that could be a sensor sources within systems or an actual application—and these things change over time, and then therefore, stamped in time in some way.They can come at different frequencies, like I said, from nanoseconds to seconds, or minutes and hours, but the most important thing is that they usually trigger a workflow, trigger some sort of action. And so that's really what our platform is about. It allows people to handle this type of data and then work with it from there in their applications, trigger new workflows, et cetera. Because the historical context of what happens is super important.And when we talk about sources, it could be really many things. It could be in physical spaces, and we have a lot of IoT types of customers and use cases. And those are things like devices and sensors on the factory floor, out in the field, it's on a vehicle. It's even in space, believe it or not. There are customers that are using us on satellites.And then it can also be sources from within software, applications, and infrastructure, things like VMs, and containers, and microservices, all emitting time-series data. And it could be applications like crypto, or financial, or stock market, agricultural type of applications that are themselves as applications emitting data. So, you think about all these sources that are out there from the physical world to the virtual world, and they're all generating time-series data, and our platform is really specially designed to handle that kind of data. And we can get into some details of what exactly that means, but that's really why we're here. That's what time-series is all about.Corey: And this is the inherent challenge I think we're seeing across the entire industry slash ecosystem. I mean, this is airing during re:Invent week, but at the time we are recording this, we have not yet seen the Tuesday keynote that Adam Selipsky will take to the stage, and no doubt, render the stat I'm about to throw at you completely obsolete. But depending on how you count them, there's somewhere between 13 and 15 managed database or database-like services today that AWS offers. And they never turn things off and they're always releasing new things, supposedly on behalf of customers; in practice because someone somewhere wants to get promoted by launching a new service; good for them. Godspeed.If we look into the uncertain future, at some point, someone's job is going to be disambiguating between the 40 different managed database services that AWS offers and picking the one that works. What differentiates time-series from—let's just start with an easy one—something like MySQL or Postgres—or ‘Postgres-squeal' is how I insist on pronouncing that one. Let's stay away from things like Neptune because no one knows what a social graph database is and I assure you, you almost certainly don't need one. Where does something like Influx work in a way that, “Huh. Running this on MySQL is really starting to suck.”Brian: When and why is it time to consider a specialized tool. And in fact, that's actually what we see a lot with our customers is coming to us around that time when a time-series is a problem to solve for them is reaching the point where they really need a specialized tool that's kind of built for that. And so one way to look at that is really just to think about time-series in general as a type of data. It's rapidly rising. It's the fastest growing data category out there right now.And the reason for that is it's being driven by two big macro trends. One is the explosion of all these applications and services running in the cloud. They're expanding horizontally, they're running in more regions, they're in many cases running on multiple clouds, and so it's just getting big—the workloads are getting bigger and bigger. And those are emitting time-series data. And then simultaneously, you have this  growth of all these devices and sensors that are coming online out in the real world: batteries, and temperature gauges, and all kinds of stuff, both new and old, that is coming online, and those sources are generating a lot of time-series data.So typically, we're in a moment now, where a lot of developers are faced with this massive growth of time-series data. And if you think about some data set that you have, that you're putting into some kind of traditional database, now add the component of time as a multiplier by all the data you have. Instead of that one data, that one metric, you're now looking at doing that every one second in perpetuity. And so it's just an order of magnitude more data that you're dealing with. And then you also have this notion of—when you have that magnitude of data, you have fidelity, you're taking a lot of it in at the same time, I mean, very quickly, so you have  batch or stream data coming in at super high volume, and you may need that for a few minutes or a few hours or days, but maybe you don't need it for months and years.And so you'd maybe dropped down to kind of a lower fidelity for the longer-term. But you really have this  toggling back and forth of the high fidelity and low fidelity, all coming at you at pretty high volume. And so typically what happens is, is when the workloads get big enough, the legacy tools, they're just not equipped to do it. And a developer—if they have a small set of time-series they're dealing with, what is the first thing they're going to do? They're going to look around and be like, “Hey, what do I have here? Oh, I've got Mongo over here. I've got Splunk, or I've got this old relational database, I can put it in.”And that's typically what they'll do, and that works fine until it doesn't. And then that's when they come around looking for a specialized tool. So, we really sit in Influx and, frankly, other time-series products really do sit at that point where people are considering a specialized tool just because the workload has gotten such that it requires that.Corey: Yeah. Taking a look at most of the offerings in the space; anything that winds up charging anything more than a very tiny fraction of a penny—from what you're describing—is going to quickly become non-economical, where it's, “Oh, we're going to charge you”—like using S3: every, I think, 1000 writes cost a penny—“Oh, we're just going to use S3 for this.” Well, at some of these data volumes, that means that your request charge on S3 is very quickly going to become the largest single line item in your bill, which is nothing short of impressive in a lot of cases, but it also probably means that you've taken a very specific tool—like an iPad—and tried to use it as something else—like a hammer—and no one's particularly happy with that outcome.Brian: Yeah. First of all, having usage-based pricing is really important. We think about it as allowing people to have the full version of the product without a major commitment, and be using it in test scenarios and then later in the very early production scenarios. But as a principle, it's important for people that just signed up two hours ago using your product are basically using the same full product that the biggest customers that you have are using that are paying many, many thousands or tens of thousands per month. And so the way to do that is to offer usage-based pricing and not force people to commit to something before they're ready to do it.And so there's ways to unlock lower pricing, and we, like a lot of companies, offer annual pricing and we have a sales team that worked with folks to basically draw down their unit costs on the use of the platform once they kind of get comfortable with their workload. So, there's definitely avenues to get lower price, and we're believers in that. And we also want to, from a product development perspective, try to make the product more efficient. And so we basically are trying to drive down the costs through efficiencies in the product: make it run faster, make queries take less time, and also ship products on top of it that require developers to write less code themselves, kind of, do more of the work for them.Corey: One of the things I find particularly compelling about what you've done is it is an open-source project. If I want to go ahead and run some time-series experiments myself, I can spin it up anywhere I want and run it however I see fit. Now, at some point, if I'm doing this for anything more than, “Oh, let's see how I can misuse this today,” I probably want to at least consider letting someone who's better at running these things than I am take it over. And as I'm looking through your customer list, the thing that strikes me is how none of these things are quite like the other. We're talking about companies like Hulu is probably not using it the same way as Capital One is, at least I certainly hope not. You have Texas Instruments; you also have Adobe. And it sort of runs an entire gamut of none of these companies quite look alike; I have to imagine their use cases are also somewhat varied, too.Brian: Yeah, that's right. And we really do see as a platform, and with time-series being the common problem that people are looking to solve, we see this pretty broad set of use cases and customer types. And we have some more traditional customers like the Cisco's and the IBM's of the world, and then some  relatively new folks like Tesla and Hulu and others that are a little bit more recent. But they're all trying to solve the same fundamental problem with time-series, which is “How can I handle it in an efficient way and make use of it meaningfully in my applications and services?”And we were talking earlier about having some sources of time-series data being in, kind of a virtual space, like in infrastructure and software, and then some being in physical space, like in devices and sensors out in the real world. So, we have breadth in that way, too. We have folks who are building big software observability infrastructure solutions on us, and we also have people that are pulling data off of the devices on a solar panel that's sitting on a house in the emerging world, right? So, you have basically these two far ends of the spectrum, but all using this specialized tool to handle the time-series data that they're generating.Corey: It seems to me that for most of these use cases and the way you describe it, it's more about the overall shape of the data when we're talking about time-series more so than it is any particular data point in isolation. Is that accurate, or are there cases where that is very much not the case?Brian: I think that's accurate. What people are mostly trying to understand is context for what's happening. And so it's not necessarily—to your point—not searching for one specific data point or moment, but it's really understanding context for some general state that has changed or some trend that has emerged, whatever that might be, and then making sense of that, and then taking action on that. And taking an action could mean a couple of different things, too. It could be in an observability sense, where somebody in  an operator type of mode where they're looking at dashboards and paying attention to  infrastructure that's running and then need to take some sort of action based on that. It also, in many cases, is automated in some way: it's either some series of automated responses to some state that is reached that is visible in the data, or is actually kicking off some new series of tasks or actions inside of an application based on what is occurring and shown by the time-series data.Corey: You know what doesn't add to your AWS bill? Free developer security from Snyk. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDEs, repos, and pipelines. And Snyk integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, and oh so much more.Secure with Snyk and save some loot. Learn more at snyk.io/scream. That's S-N-Y-K-dot-I-O/screamCorey: So, we've talked about, you have an open-source product, which is the sort of thing that most people listening to this should have a vague idea of, “Oh, that means I can go on GitHub and download it and start using it, if it's not already in my package manager.” Great. You also have the enterprise offering, which is more or less, I presume, a supported distribution of this—for lack of a better term—that you then wind up providing blessed configurations thereof and helping run support for that—for companies that want to run it on-prem. Is that directionally accurate, or am I grossly mischaracterizing [laugh] what your enterprise offering is?Brian: Directionally accurate, of course. You could have a great job in marketing. I really think you could.Corey: Oh, you know, I would argue, on some level, I probably do. The challenge I have is that I keep conflating marketing with spectacle and that leads down to really unfortunate, weird places. But one additional area, which is relatively recent since the last time I spoke with Paul—one of the cofounders of your company—on this show is InfluxDB Cloud, which is one of those, “Oh, let me see if I look—if I'm right.” And sure enough, yeah, you wind up managing the infrastructure for us and it becomes a pay-per consumption model the way that most cloud service providers do, without the really obnoxious hidden 15 levels of billing dimensions.Brian: Yes, we are trying to bring the transparency back. But yes, you're correct. We have open-source and we have—it's very popular—we have over 500,000-plus instances of that deployed globally today in the community. And that's typically very common for developers to get started using the open-source, easily recognizable, it's been out for a long time, and so many people start the journey there.And then we have InfluxDB Enterprise, which it's actually a clustered version of InfluxDB open-source. So, it allows you to basically handle in an environment that you want to manage yourself, you manage a cluster and scale it out and handle ever-increasing workloads and have things like redundancy and replication, et cetera. But that's really specifically for people who want to deploy and operate the software themselves, which is a good set of people; we have a lot of folks who have done that. But one of the areas that's a little bit more recent is InfluxDB Cloud, which is really, for folks who don't want to have anything to do with the management; they really just want to use it as a service, send their data in—Corey: Yeah, give me an API endpoint, and I want you to worry about the care, and the feeding, and the waking up at two in the morning when a disk starts filling up. Yeah, that is the best kind of problem from my perspective: someone else's.Brian: Exactly. That's our job. And increasingly, we've seen folks gravitate to that. We've got a lot of folks have signed up on this product since it launched in 2019, and it's really increasingly where they begin their journey, maybe not even going to the open-source just going directly to this because it's relatively simple to get started.It's priced based on usage. People pay for three vectors: they have the amount of data in; they have number of queries made against the platform; and then storage, how much data you have and for how long. And depending on the use case, some people keep it around for relatively short time, like a few days or a couple of weeks. Other folks have it for many, many months and potentially years in some places. So, you really have that option.But I would say the three products are really about how you want to run it. Do you care about running the, kind of, underlying infrastructure and managing it or do you just want to hit an endpoint, as you said.Corey: You launched this, I want to say in 2019, which feels about directionally right. And I know it was after Timestream was announced, so I just want to say first, how kind and selfless it was of you to validate AWS's market, which is, you know how they always like to clarify and define what they're doing when they decide to enter every single market anywhere to compete with everyone. It turns out, I don't get the sense that they like it quite [laugh] as much being on the other side of that particular divide, but that's the best kind of problem, too: again, someone else's.Brian: Yeah, I think that's really true.Corey: The challenge that I have is that it seems like a weird direction to go in as a company, though it is clearly based upon a number of press releases you have made about the success and market traction that you found, it feels, on some level, like it is falling into an older version of an open-source trap of assuming that, “Well, we wrote the software therefore we are the best people you could pick to run it.” That was what a lot of companies did; it turns out that AWS has this operational excellence, as they call it, and what the rest of us call burning through people and making them wake up in the middle of the night to fix things before it becomes customer-visible. But from the outside, there's no difference. It seems, however, that you have built something that is clearly resonating, and in a big way, in a way that—I've got to be direct with you—the AWS time-series service that they are offering has not been finding success.Brian: Thank you for saying that, and we feel pretty excited about the success we've had even being in the same market as Amazon. And Amazon does a phenomenal job at running products at scale, and the breadth that they have in their product lineup is pretty impressive, especially when they roll out new stuff at AWS re:Invent every year. But we've been able to find some pretty good success with our approach, and it's based on a couple of things. So, one is being the company that actually develops and still deploys the open-source is really important. People gravitate to that.Our roots as a company are open-source, we've been a part of and fostered this community over many, many years, and there's a certain trust in the direction that we're taking the company. And Paul, our founder who you mentioned, he's been front and center with that community, pretty deeply engaged for many, many years. I think that carries a lot of weight. At least that's the way we think about it. But then as far as commercial products go, we really think about it as going to where our customers are, going to where developers are. And that could mean the language that they prefer, the language of preference for them. And that could [crosstalk 00:22:25]—Corey: Oh, and it's very clear; it seems that most database companies that I talk to—again, without naming names—tend to focus on the top-down sale, but I've never worked in an environment where the database that will be used was dictated by anyone other than the application developers who are the closest to the technical requirements for the workload. I've never understood this model of, “Oh, we're going to talk to the C suite because we believe that they're going to pick a database vendor based upon who has box seats this season.” I've never gotten that and that probably means I'm a terrible enterprise marketer, on some level. But unlike almost every other player in the database space, I've never struggled to understand what the hell your messaging has meant, other than the technical bits that I just don't have quite enough neurons to bang together to create sparks to fully understand. It is very clearly targeted at a builder rather than someone who's more or less spending their entire life in meetings. Which, oh, God, that's me.Brian: [laugh]. Yes, it's very much the case. We are focused on the developer. And that developer is a builder of an application or service that is seeing the light of day, it's going out and being used by their own end-users and end-customers.And so we care about going to where those developers are, and that could mean going and making your product easily used in the language and tool that customer cares about. So, if you're a Python developer, it's important for us to have tools and make it easy for Python developers. We have client libraries for Python, for example. It also means going to the cloud where your customers are. And this is something that differentiates us as well, when you start looking at what the other cloud providers are offering, in that data—like it or not—has gravity. And so somebody that has built their whole stack on AWS and sure they care about using a service that is going to receive their data, and that also being in AWS, but—Corey: It has to live where the customers are, especially with data egress charges being what they are, too.Brian: Exactly.Corey: And data gravity is real. The cloud provider people pick is the one where their data lives because of that particular inflection in the market.Brian: Absolutely true. And so that's great if you're only going after people who are on AWS, but what about Google Cloud and what about Microsoft Azure? There are a lot of developers that are building on those platforms as well, and that's one of the reasons we want to go there as well. So, InfluxDB Cloud is a multi-cloud offering, and it's equal experience and capability and pricing on each of the three major clouds. You can buy directly from us; you can put it on any of your cloud bills in one of those marketplaces, and to us that's like a really, really fundamental point is to bring your product and make it as easy to use on those platforms and in those languages, and in those realms and use cases where people are already working.Corey: I'm a big believer in multi-cloud for the use case you just defined. Because I know I'm going to get letters if I don't say this based upon my public multi-cloud is a dumb default worst practice for most folks—because it is, on a workload-by-workload basis—but you're building a service that has to be close to where your customers are and for that specific thing, yeah, it makes an awful lot of sense for you to have a presence across all the different providers. Now, here's the $64,000 question for you: is the experience as an InfluxDB Cloud customer meaningfully different between different providers?Brian: It's not. We actually pride ourselves on it being the same. Using InfluxDB, you sign up for InfluxDB Cloud, you come in, you set up your account, create your organization, and then you choose which underlying cloud provider you want your account to be provisioned in. And so it actually comes as a secondary choice; it's not something that is gated in the beginning, and that allows us to deliver a uniform experience across the board. And you may in a future use case, maybe somebody wants to have part of what they're building data living in AWS and maybe part of it living in Azure, I mean, that could be a scenario as well.However, typically what we've seen—and you've probably seen this as well—is  most developers are—and organizations—are building mostly on one cloud. I don't see a lot of  multi-cloud in that organization. But we ourselves need to be multi-cloud in order to go to where those people are working. And so that's the distinction. It's for us as a company that delivers product to those people, it's important for us to go where they are, whereas they themselves are not necessarily running on all three cloud products; they're probably running on one platform.Corey: Yeah. On a workload-by-workload basis, that's what generally makes sense. Anytime you have someone who has a particular workload that needs to be in multiple providers, okay, great, you're going to put that out there, but their backend systems, their billing, their marketing, all the rest, is not going to go down that path for a variety of excellent reasons, mostly that it is a colossal pain, and a bunch of, more or less, solving the same problems over and over, rather than the whole point of cloud being to make it someone else's. I want to thank you for taking so much time to speak to me about how you're viewing the evolution of the market, how you're seeing your move into cloud, and how you're effectively targeting folks who can actually care about the implementation details of a database rather than, honestly, suits. If people want to learn more, where can they find you?Brian: They can go to our website; it's the easiest place to go. So, influxdata.com. You can read all about InfluxDB, it's a pretty easy sign up to get underway. So, I recommend that people get their hands dirty with the product. That's the easiest way to understand what it's all about.Corey: And if you do end up doing that, please tell them I sent you because the involuntary flinch whenever people mention my name to vendors is one of my favorite parts of being me. Brian, thank you so much for being so generous with your time. I appreciate it.Brian: Thanks so much for having us on. It was great.Corey: Brian Mullen, Chief Marketing Officer—and dealmaker—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 a long, angry comment telling me that you work on the Timestream service team, and your product is the best. It's found huge success, but I've just never met any of your customers and I can't because they all live in Canada.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.

Twitter bans sharing private images and videos without consent DNA testing firm discloses data breach affecting over 2 million people Critical ‘Printing Shellz' bugs impact 150 HP printer models Thanks to our episode sponsor, Votiro Your users need to accept and open files to do their jobs. Keep them safe and productive with Votiro. With Votiro zero trust file sanitization API, your users can download and use any file instantly, from PDF to Autodesk CAD, with malicious code already removed—and full file usability intact. The signatureless file sanitization process happens in milliseconds without user friction. Visit Votiro.com and learn why millions of users trust Votiro to disarm billions of files each year. For the stories behind the headlines, head to CISOseries.com

About ThomasThomas Hazel is Founder, CTO, and Chief Scientist of ChaosSearch. He is a serial entrepreneur at the forefront of communication, virtualization, and database technology and the inventor of ChaosSearch's patented IP. Thomas has also patented several other technologies in the areas of distributed algorithms, virtualization and database science. He holds a Bachelor of Science in Computer Science from University of New Hampshire, Hall of Fame Alumni Inductee, and founded both student & professional chapters of the Association for Computing Machinery (ACM).Links:ChaosSearch: https://www.chaossearch.io 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 my friends at ThinkstCanary. Most companies find out way too late that they've been breached. ThinksCanary changes this and I love how they do it. Deploy canaries and canary tokens in minutes and then forget about them. What's great is the attackers tip their hand by touching them, giving you one alert, when it matters. I use it myself and I only remember this when I get the weekly update with a “we're still here, so you're aware” from them. It's glorious! There is zero admin overhead  to this, there are effectively no false positives unless I do something foolish. Canaries are deployed and loved on all seven continents. You can check out what people are saying at canary.love. And, their Kub config canary token is new and completely free as well. You can do an awful lot without paying them a dime, which is one of the things I love about them. It is useful stuff and not an, “ohh, I wish I had money.” It is speculator! Take a look; that's canary.love because it's genuinely rare to find a security product that people talk about in terms of love. It really is a unique thing to see. Canary.love. Thank you to ThinkstCanary for their support of my ridiculous, ridiculous non-sense.   Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is brought to us by our friends at ChaosSearch.We've been working with them for a long time; they've sponsored a bunch of our nonsense, and it turns out that we've been talking about them to our clients since long before they were a sponsor because it actually does what it says on the tin. Here to talk to us about that in a few minutes is Thomas Hazel, ChaosSearch's CTO and founder. First, Thomas, nice to talk to you again, and as always, thanks for humoring me.Thomas: [laugh]. Hi, Corey. Always great to talk to you. And I enjoy these conversations that sometimes go up and down, left and right, but I look forward to all the fun we're going to have.Corey: So, my understanding of ChaosSearch is probably a few years old because it turns out, I don't spend a whole lot of time meticulously studying your company's roadmap in the same way that you presumably do. When last we checked in with what the service did-slash-does, you are effectively solving the problem of data movement and querying that data. The idea behind data warehouses is generally something that's shoved onto us by cloud providers where, “Hey, this data is going to be valuable to you someday.” Data science teams are big proponents of this because when you're storing that much data, their salaries look relatively reasonable by comparison. And the ChaosSearch vision was, instead of copying all this data out of an object store and storing it on expensive disks, and replicating it, et cetera, what if we queried it in place in a somewhat intelligent manner?So, you take the data and you store it, in this case, in S3 or equivalent, and then just query it there, rather than having to move it around all over the place, which of course, then incurs data transfer fees, you're storing it multiple times, and it's never in quite the format that you want it. That was the breakthrough revelation, you were Elasticsearch—now OpenSearch—API compatible, which was great. And that was, sort of, a state of the art a year or two ago. Is that generally correct?Thomas: No, you nailed our mission statement. No, you're exactly right. You know, the value of cloud object stores, S3, the elasticity, the durability, all these wonderful things, the problem was you couldn't get any value out of it, and you had to move it out to these siloed solutions, as you indicated. So, you know, our mission was exactly that, transformed customers' cloud storage into an analytical database, a multi-model analytical database, where our first use case was search and log analytics, replacing the ELK stack and also replacing the data pipeline, the schema management, et cetera. We automate the entire step, raw data to insights.Corey: It's funny we're having this conversation today. Earlier, today, I was trying to get rid of a relatively paltry 200 gigs or so of small files on an EFS volume—you know, Amazon's version of NFS; it's like an NFS volume except you're paying Amazon for the privilege—great. And it turns out that it's a whole bunch of operations across a network on a whole bunch of tiny files, so I had to spin up other instances that were not getting backed by spot terminations, and just firing up a whole bunch of threads. So, now the load average on that box is approaching 300, but it's plowing through, getting rid of that data finally.And I'm looking at this saying this is a quarter of a terabyte. Data warehouses are in the petabyte range. Oh, I begin to see aspects of the problem. Even searching that kind of data using traditional tooling starts to break down, which is sort of the revelation that Google had 20-some-odd years ago, and other folks have since solved for, but this is the first time I've had significant data that wasn't just easily searched with a grep. For those of you in the Unix world who understand what that means, condolences. We're having a support group meeting at the bar.Thomas: Yeah. And you know, I always thought, what if you could make cloud object storage like S3 high performance and really transform it into a database? And so that warehouse capability, that's great. We like that. However to manage it, to scale it, to configure it, to get the data into that, was the problem.That was the promise of a data lake, right? This simple in, and then this arbitrary schema on read generic out. The problem next came, it became swampy, it was really hard, and that promise was not delivered. And so what we're trying to do is get all the benefits of the data lake: simple in, so many services naturally stream to cloud storage. Shoot, I would say every one of our customers are putting their data in cloud storage because their data pipeline to their warehousing solution or Elasticsearch may go down and they're worried they'll lose the data.So, what we say is what if you just said activate that data lake and get that ELK use case, get that BI use case without that data movement, as you indicated, without that ETL-ing, without that data pipeline that you're worried is going to fall over. So, that vision has been Chaos. Now, we haven't talked in, you know, a few years, but this idea that we're growing beyond what we are just going after logs, we're going into new use cases, new opportunities, and I'm looking forward to discussing with you.Corey: It's a great answer that—though I have to call out that I am right there with you as far as inappropriately using things as databases. I know that someone is going to come back and say, “Oh, S3 is a database. You're dancing around it. Isn't that what Athena is?” Which is named, of course, after the Greek Goddess of spending money on AWS? And that is a fair question, but to my understanding, there's a schema story behind that does not apply to what you're doing.Thomas: Yeah, and that is so crucial is that we like the relational access. The time-cost complexity to get it into that, as you mentioned, scaled access, I mean, it could take weeks, months to test it, to configure it, to provision it, and imagine if you got it wrong; you got to redo it again. And so our unique service removes all that data pipeline schema management. And because of our innovation because of our service, you do all schema definition, on the fly, virtually, what we call views on your index data, that you can publish an elastic index pattern for that consumption, or a relational table for that consumption. And that's kind of leading the witness into things that we're coming out with this quarter into 2022.Corey: I have to deal with a little bit of, I guess, a shame here because yeah, I'm doing exactly what you just described. I'm using Athena to wind up querying our customers' Cost and Usage Reports, and we spend a couple hundred bucks a month on AWS Glue to wind up massaging those into the way that they expect it to be. And it's great. Ish. We hook it up to Tableau and can make those queries from it, and all right, it's great.It just, burrr goes the money printer, and we somehow get access and insight to a lot of valuable data. But even that is knowing exactly what the format is going to look like. Ish. I mean, Cost and Usage Reports from Amazon are sort of aspirational when it comes to schema sometimes, but here we are. And that's been all well and good.But now the idea of log files, even looking at the base case of sending logs from an application, great. Nginx, or Apache, or [unintelligible 00:07:24], or any of the various web servers out there all tend to use different logging formats just to describe the same exact things, start spreading that across custom in-house applications and getting signal from that is almost impossible. “Oh,” people say, “So, we'll use a structured data format.” Now, you're putting log and structuring requirements on application developers who don't care in the first place, and now you have a mess on your hands.Thomas: And it really is a mess. And that challenge is, it's so problematic. And schemas changing. You know, we have customers and one reasons why they go with us is their log data is changing; they didn't expect it. Well, in your data pipeline, and your Athena database, that breaks. That brings the system down.And so our system uniquely detects that and manages that for you and then you can pick and choose how you want to export in these views dynamically. So, you know, it's really not rocket science, but the problem is, a lot of the technology that we're using is designed for static, fixed thinking. And then to scale it is problematic and time-consuming. So, you know, Glue is a great idea, but it has a lot of sharp [pebbles 00:08:26]. Athena is a great idea but also has a lot of problems.And so that data pipeline, you know, it's not for digitally native, active, new use cases, new workloads coming up hourly, daily. You think about this long-term; so a lot of that data prep pipelining is something we address so uniquely, but really where the customer cares is the value of that data, right? And so if you're spending toils trying to get the data into a database, you're not answering the questions, whether it's for security, for performance, for your business needs. That's the problem. And you know, that agility, that time-to-value is where we're very uniquely coming in because we start where your data is raw and we automate the process all the way through.Corey: So, when I look at the things that I have stuffed into S3, they generally fall into a couple of categories. There are a bunch of logs for things I never asked for nor particularly wanted, but AWS is aggressive about that, first routing through CloudTrail so you can get charged 50-cent per gigabyte ingested. Awesome. And of course, large static assets, images I have done something to enter colloquially now known as shitposts, which is great. Other than logs, what could you possibly be storing in S3 that lends itself to, effectively, the type of analysis that you built around this?Thomas: Well, our first use case was the classic log use cases, app logs, web service logs. I mean, CloudTrail, it's famous; we had customers that gave up on elastic, and definitely gave up on relational where you can do a couple changes and your permutation of attributes for CloudTrail is going to put you to your knees. And people just say, “I give up.” Same thing with Kubernetes logs. And so it's the classic—whether it's CSV, where it's JSON, where it's log types, we auto-discover all that.We also allow you, if you want to override that and change the parsing capabilities through a UI wizard, we do discover what's in your buckets. That term data swamp, and not knowing what's in your bucket, we do a facility that will index that data, actually create a report for you for knowing what's in. Now, if you have text data, if you have log data, if you have BI data, we can bring it all together, but the real pain is at the scale. So classically, app logs, system logs, many devices sending IoT-type streams is where we really come in—Kubernetes—where they're dealing with terabytes of data per day, and managing an ELK cluster at that scale. Particularly on a Black Friday.Shoot, some of our customers like—Klarna is one of them; credit card payment—they're ramping up for Black Friday, and one of the reasons why they chose us is our ability to scale when maybe you're doing a terabyte or two a day and then it goes up to twenty, twenty-five. How do you test that scale? How do you manage that scale? And so for us, the data streams are, traditionally with our customers, the well-known log types, at least in the log use cases. And the challenge is scaling it, is getting access to it, and that's where we come in.Corey: I will say the last time you were on the show a couple of years ago, you were talking about the initial logging use case and you were speaking, in many cases aspirationally, about where things were going. What a difference a couple years is made. Instead of talking about what hypothetical customers might want, or what—might be able to do, you're just able to name-drop them off the top of your head, you have scaled to approximately ten times the number of employees you had back then. You've—Thomas: Yep. Yep.Corey: —raised, I think, a total of—what, 50 million?—since then.Thomas: Uh, 60 now. Yeah.Corey: Oh, 60? Fantastic.Thomas: Yeah, yeah.Corey: Congrats. And of course, how do you do it? By sponsoring Last Week in AWS, as everyone should. I'm taking clear credit for that every time someone announces around, that's the game. But no, there is validity to it because telling fun stories and sponsoring exciting things like this only carry you so far. At some point, customers have to say, yeah, this is solving a pain that I have; I'm willing to pay you money to solve it.And you've clearly gotten to a point where you are addressing the needs of those customers at a pretty fascinating clip. It's bittersweet from my perspective because it seems like the majority of your customers have not come from my nonsense anymore. They're finding you through word of mouth, they're finding through more traditional—read as boring—ad campaigns, et cetera, et cetera. But you've built a brand that extends beyond just me. I'm no longer viewed as the de facto ombudsperson for any issue someone might have with ChaosSearch on Twitters. It's kind of, “Aww, the company grew up. What happened there?”Thomas: No, [laugh] listen, this you were great. We reached out to you to tell our story, and I got to be honest. A lot of people came by, said, “I heard something on Corey Quinn's podcasts,” or et cetera. And it came a long way now. Now, we have, you know, companies like Equifax, multi-cloud—Amazon and Google.They love the data lake philosophy, the centralized, where use cases are now available within days, not weeks and months. Whether it's logs and BI. Correlating across all those data streams, it's huge. We mentioned Klarna, [APM Performance 00:13:19], and, you know, we have Armor for SIEM, and Blackboard for [Observers 00:13:24].So, it's funny—yeah, it's funny, when I first was talking to you, I was like, “What if? What if we had this customer, that customer?” And we were building the capabilities, but now that we have it, now that we have customers, yeah, I guess, maybe we've grown up a little bit. But hey, listen to you're always near and dear to our heart because we remember, you know, when you stop[ed by our booth at re:Invent several times. And we're coming to re:Invent this year, and I believe you are as well.Corey: Oh, yeah. But people listening to this, it's if they're listening the day it's released, this will be during re:Invent. So, by all means, come by the ChaosSearch booth, and see what they have to say. For once they have people who aren't me who are going to be telling stories about these things. And it's fun. Like, I joke, it's nothing but positive here.It's interesting from where I sit seeing the parallels here. For example, we have both had—how we say—adult supervision come in. You have a CEO, Ed, who came over from IBM Storage. I have Mike Julian, whose first love language is of course spreadsheets. And it's great, on some level, realizing that, wow, this company has eclipsed my ability to manage these things myself and put my hands-on everything. And eventually, you have to start letting go. It's a weird growth stage, and it's a heck of a transition. But—Thomas: No, I love it. You know, I mean, I think when we were talking, we were maybe 15 employees. Now, we're pushing 100. We brought on Ed Walsh, who's an amazing CEO. It's funny, I told him about this idea, I invented this technology roughly eight years ago, and he's like, “I love it. Let's do it.” And I wasn't ready to do it.So, you know, five, six years ago, I started the company always knowing that, you know, I'd give him a call once we got the plane up in the air. And it's been great to have him here because the next level up, right, of execution and growth and business development and sales and marketing. So, you're exactly right. I mean, we were a young pup several years ago, when we were talking to you and, you know, we're a little bit older, a little bit wiser. But no, it's great to have Ed here. And just the leadership in general; we've grown immensely.Corey: Now, we are recording this in advance of re:Invent, so there's always the question of, “Wow, are we going to look really silly based upon what is being announced when this airs?” Because it's very hard to predict some things that AWS does. And let's be clear, I always stay away from predictions, just because first, I have a bit of a knack for being right. But also, when I'm right, people will think, “Oh, Corey must have known about that and is leaking,” whereas if I get it wrong, I just look like a fool. There's no win for me if I start doing the predictive dance on stuff like that.But I have to level with you, I have been somewhat surprised that, at least as of this recording, AWS has not moved more in your direction because storing data in S3 is kind of their whole thing, and querying that data through something that isn't Athena has been a bit of a reach for them that they're slowly starting to wrap their heads around. But their UltraWarm nonsense—which is just, okay, great naming there—what is the point of continually having a model where oh, yeah, we're going to just age it out, the stuff that isn't actively being used into S3, rather than coming up with a way to query it there. Because you've done exactly that, and please don't take this as anything other than a statement of fact, they have better access to what S3 is doing than you do. You're forced to deal with this thing entirely from a public API standpoint, which is fine. They can theoretically change the behavior of aspects of S3 to unlock these use cases if they chose to do so. And they haven't. Why is it that you're the only folks that are doing this?Thomas: No, it's a great question, and I'll give them props for continuing to push the data lake [unintelligible 00:17:09] to the cloud providers' S3 because it was really where I saw the world. Lakes, I believe in. I love them. They love them. However, they promote the move the data out to get access, and it seems so counterintuitive on why wouldn't you leave it in and put these services, make them more intelligent? So, it's funny, I've trademark ‘Smart Object Storage,' I actually trademarked—I think you [laugh] were a part of this—‘UltraHot,' right? Because why would you want UltraWarm when you can have UltraHot?And the reason, I feel, is that if you're using Parquet for Athena [unintelligible 00:17:40] store, or Lucene for Elasticsearch, these two index technologies were not designed for cloud storage, for real-time streaming off of cloud storage. So, the trick is, you have to build UltraWarm, get it off of what they consider cold S3 into a more warmer memory or SSD type access. What we did, what the invention I created was, that first read is hot. That first read is fast.Snowflake is a good example. They give you a ten terabyte demo example, and if you have a big instance and you do that first query, maybe several orders or groups, it could take an hour to warm up. The second query is fast. Well, what if the first query is in seconds as well? And that's where we really spent the last five, six years building out the tech and the vision behind this because I like to say you go to a doctor and say, “Hey, Doc, every single time I move my arm, it hurts.” And the doctor says, “Well, don't move your arm.”It's things like that, to your point, it's like, why wouldn't they? I would argue, one, you have to believe it's possible—we're proving that it is—and two, you have to have the technology to do it. Not just the index, but the architecture. So, I believe they will go this direction. You know, little birdies always say that all these companies understand this need.Shoot, Snowflake is trying to be lake-y; Databricks is trying to really bring this warehouse lake concept. But you still do all the pipelining; you still have to do all the data management the way that you don't want to do. It's not a lake. And so my argument is that it's innovation on why. Now, they have money; they have time, but, you know, we have a big head start.Corey: I remembered last year at re:Invent they released a, shall we say, significant change to S3 that it enabled read after write consistency, which is awesome, for again, those of us in the business of misusing things as databases. But for some folks, the majority of folks I would say, it was a, “I don't know what that means and therefore I don't care.” And that's fine. I have no issue with that. There are other folks, some of my customers for example, who are suddenly, “Wait a minute. This means I can sunset this entire janky sidecar metadata system that is designed to make sure that we are consistent in our use of S3 because it now does it automatically under the hood?” And that's awesome. Does that change mean anything for ChaosSearch?Thomas: It doesn't because of our architecture. We're append-only, write-once scenario, so a lot of update-in-place viewpoints. My viewpoint is that if you're seeing S3 as the database and you need that type of consistency, it make sense of why you'd want it, but because of our distributive fabric, our stateless architecture, our append-only nature, it really doesn't affect us.Now, I talked to the S3 team, I said, “Please if you're coming up with this feature, it better not be slower.” I want S3 to be fast, right? And they said, “No, no. It won't affect performance.” I'm like, “Okay. Let's keep that up.”And so to us, any type of S3 capability, we'll take advantage of it if benefits us, whether it's consistency as you indicated, performance, functionality. But we really keep the constructs of S3 access to really limited features: list, put, get. [roll-on 00:20:49] policies to give us read-only access to your data, and a location to write our indices into your account, and then are distributed fabric, our service, acts as those indices and query them or searches them to resolve whatever analytics you need. So, we made it pretty simple, and that is allowed us to make it high performance.Corey: I'll take it a step further because you want to talk about changes since the last time we spoke, it used to be that this was on top of S3, you can store your data anywhere you want, as long as it's S3 in the customer's account. Now, you're also supporting one-click integration with Google Cloud's object storage, which, great. That does mean though, that you're not dependent upon provider-specific implementations of things like a consistency model for how you've built things. It really does use the lowest common denominator—to my understanding—of object stores. Is that something that you're seeing broad adoption of, or is this one of those areas where, well, you have one customer on a different provider, but almost everything lives on the primary? I'm curious what you're seeing for adoption models across multiple providers?Thomas: It's a great question. We built an architecture purposely to be cloud-agnostic. I mean, we use compute in a containerized way, we use object storage in a very simple construct—put, get, list—and we went over to Google because that made sense, right? We have customers on both sides. I would say Amazon is the gorilla, but Google's trying to get there and growing.We had a big customer, Equifax, that's on both Amazon and Google, but we offer the same service. To be frank, it looks like the exact same product. And it should, right? Whether it's Amazon Cloud, or Google Cloud, multi-select and I want to choose either one and get the other one. I would say that different business types are using each one, but our bulk of the business isn't Amazon, but we just this summer released our SaaS offerings, so it's growing.And you know, it's funny, you never know where it comes from. So, we have one customer—actually DigitalRiver—as one of our customers on Amazon for logs, but we're growing in working together to do a BI on GCP or on Google. And so it's kind of funny; they have two departments on two different clouds with two different use cases. And so do they want unification? I'm not sure, but they definitely have their BI on Google and their operations in Amazon. It's interesting.Corey: You know its important to me that people learn how to use the cloud effectively. Thats why I'm so glad that Cloud Academy is sponsoring my ridiculous non-sense. They're a great way to build in demand tech skills the way that, well personally, I learn best which I learn by doing not by reading. They have live cloud labs that you can run in real environments that aren't going to blow up your own bill—I can't stress how important that is. Visit cloudacademy.com/corey. Thats C-O-R-E-Y, don't drop the “E.” Use Corey as a promo-code as well. You're going to get a bunch of discounts on it with a lifetime deal—the price will not go up. It is limited time, they assured me this is not one of those things that is going to wind up being a rug pull scenario, oh no no. Talk to them, tell me what you think. Visit: cloudacademy.com/corey,  C-O-R-E-Y and tell them that I sent you!Corey: I know that I'm going to get letters for this. So, let me just call it out right now. Because I've been a big advocate of pick a provider—I care not which one—and go all-in on it. And I'm sitting here congratulating you on extending to another provider, and people are going to say, “Ah, you're being inconsistent.”No. I'm suggesting that you as a provider have to meet your customers where they are because if someone is sitting in GCP and your entire approach is, “Step one, migrate those four petabytes of data right on over here to AWS,” they're going to call you that jackhole that you would be by making that suggestion and go immediately for option B, which is literally anything that is not ChaosSearch, just based upon that core misunderstanding of their business constraints. That is the way to think about these things. For a vendor position that you are in as an ISV—Independent Software Vendor for those not up on the lingo of this ridiculous industry—you have to meet customers where they are. And it's the right move.Thomas: Well, you just said it. Imagine moving terabytes and petabytes of data.Corey: It sounds terrific if I'm a salesperson for one of these companies working on commission, but for the rest of us, it sounds awful.Thomas: We really are a data fabric across clouds, within clouds. We're going to go where the data is and we're going to provide access to where that data lives. Our whole philosophy is the no-movement movement, right? Don't move your data. Leave it where it is and provide access at scale.And so you may have services in Google that naturally stream to GCS; let's do it there. Imagine moving that amount of data over to Amazon to analyze it, and vice versa. 2020, we're going to be in Azure. They're a totally different type of business, users, and personas, but you're getting asked, “Can you support Azure?” And the answer is, “Yes,” and, “We will in 2022.”So, to us, if you have cloud storage, if you have compute, and it's a big enough business opportunity in the market, we're there. We're going there. When we first started, we were talking to MinIO—remember that open-source, object storage platform?—We've run on our laptops, we run—this [unintelligible 00:25:04] Dr. Seuss thing—“We run over here; we run over there; we run everywhere.”But the honest truth is, you're going to go with the big cloud providers where the business opportunity is, and offer the same solution because the same solution is valued everywhere: simple in; value out; cost-effective; long retention; flexibility. That sounds so basic, but you mentioned this all the time with our Rube Goldberg, Amazon diagrams we see time and time again. It's like, if you looked at that and you were from an alien planet, you'd be like, “These people don't know what they're doing. Why is it so complicated?” And the simple answer is, I don't know why people think it's complicated.To your point about Amazon, why won't they do it? I don't know, but if they did, things would be different. And being honest, I think people are catching on. We do talk to Amazon and others. They see the need, but they also have to build it; they have to invent technology to address it. And using Parquet and Lucene are not the answer.Corey: Yeah, it's too much of a demand on the producers of that data rather than the consumer. And yeah, I would love to be able to go upstream to application developers and demand they do things in certain ways. It turns out as a consultant, you have zero authority to do that. As a DevOps team member, you have limited ability to influence it, but it turns out that being the ‘department of no' quickly turns into being the ‘department of unemployment insurance' because no one wants to work with you. And collaboration—contrary to what people wish to believe—is a key part of working in a modern workplace.Thomas: Absolutely. And it's funny, the demands of IT are getting harder; the actual getting the employees to build out the solutions are getting harder. And so a lot of that time is in the pipeline, is the prep, is the schema, the sharding, and et cetera, et cetera, et cetera. My viewpoint is that should be automated away. More and more databases are being autotune, right?This whole knobs and this and that, to me, Glue is a means to an end. I mean, let's get rid of it. Why can't Athena know what to do? Why can't object storage be Athena and vice versa? I mean, to me, it seems like all this moving through all these services, the classic Amazon viewpoint, even their diagrams of having this centralized repository of S3, move it all out to your services, get results, put it back in, then take it back out again, move it around, it just doesn't make much sense. And so to us, I love S3, love the service. I think it's brilliant—Amazon's first service, right?—but from there get a little smarter. That's where ChaosSearch comes in.Corey: I would argue that S3 is in fact, a modern miracle. And one of those companies saying, “Oh, we have an object store; it's S3 compatible.” It's like, “Yeah. We have S3 at home.” Look at S3 at home, and it's just basically a series of failing Raspberry Pis.But you have this whole ecosystem of things that have built up and sprung up around S3. It is wildly understated just how scalable and massive it is. There was an academic paper recently that won an award on how they use automated reasoning to validate what is going on in the S3 environment, and they talked about hundreds of petabytes in some cases. And folks are saying, ah, S3 is hundreds of petabytes. Yeah, I have clients storing hundreds of petabytes.There are larger companies out there. Steve Schmidt, Amazon's CISO, was recently at a Splunk keynote where he mentioned that in security info alone, AWS itself generates 500 petabytes a day that then gets reduced down to a bunch of stuff, and some of it gets loaded into Splunk. I think. I couldn't really hear the second half of that sentence because of the sound of all of the Splunk salespeople in that room becoming excited so quickly you could hear it.Thomas: [laugh]. I love it. If I could be so bold, those S3 team, they're gods. They are amazing. They created such an amazing service, and when I started playing with S3 now, I guess, 2006 or 7, I mean, we were using for a repository, URL access to get images, I was doing a virtualization [unintelligible 00:29:05] at the time—Corey: Oh, the first time I played with it, “This seems ridiculous and kind of dumb. Why would anyone use this?” Yeah, yeah. It turns out I'm really bad at predicting the future. Another reason I don't do the prediction thing.Thomas: Yeah. And when I started this company officially, five, six years ago, I was thinking about S3 and I was thinking about HDFS not being a good answer. And I said, “I think S3 will actually achieve the goals and performance we need.” It's a distributed file system. You can run parallel puts and parallel gets. And the performance that I was seeing when the data was a certain way, certain size, “Wait, you can get high performance.”And you know, when I first turned on the engine, now four or five years ago, I was like, “Wow. This is going to work. We're off to the races.” And now obviously, we're more than just an idea when we first talked to you. We're a service.We deliver benefits to our customers both in logs. And shoot, this quarter alone we're coming out with new features not just in the logs, which I'll talk about second, but in a direct SQL access. But you know, one thing that you hear time and time again, we talked about it—JSON, CloudTrail, and Kubernetes; this is a real nightmare, and so one thing that we've come out with this quarter is the ability to virtually flatten. Now, you heard time and time again, where, “Okay. I'm going to pick and choose my data because my database can't handle whether it's elastic, or say, relational.” And all of a sudden, “Shoot, I don't have that. I got to reindex that.”And so what we've done is we've created a index technology that we're always planning to come out with that indexes the JSON raw blob, but in the data refinery have, post-index you can select how to unflatten it. Why is that important? Because all that tooling, whether it's elastic or SQL, is now available. You don't have to change anything. Why is Snowflake and BigQuery has these proprietary JSON APIs that none of these tools know how to use to get access to the data?Or you pick and choose. And so when you have a CloudTrail, and you need to know what's going on, if you picked wrong, you're in trouble. So, this new feature we're calling ‘Virtual Flattening'—or I don't know what we're—we have to work with the marketing team on it. And we're also bringing—this is where I get kind of excited where the elastic world, the ELK world, we're bringing correlations into Elasticsearch. And like, how do you do that? They don't have the APIs?Well, our data refinery, again, has the ability to correlate index patterns into one view. A view is an index pattern, so all those same constructs that you had in Kibana, or Grafana, or Elastic API still work. And so, no more denormalizing, no more trying to hodgepodge query over here, query over there. You're actually going to have correlations in Elastic, natively. And we're excited about that.And one more push on the future, Q4 into 2022; we have been given early access to S3 SQL access. And, you know, as I mentioned, correlations in Elastic, but we're going full in on publishing our [TPCH 00:31:56] report, we're excited about publishing those numbers, as well as not just giving early access, but going GA in the first of the year, next year.Corey: I look forward to it. This is also, I guess, it's impossible to have a conversation with you, even now, where you're not still forward-looking about what comes next. Which is natural; that is how we get excited about the things that we're building. But so much less of what you're doing now in our conversations have focused around what's coming, as opposed to the neat stuff you're already doing. I had to double-check when we were talking just now about oh, yeah, is that Google cloud object store support still something that is roadmapped, or is that out in the real world?No, it's very much here in the real world, available today. You can use it. Go click the button, have fun. It's neat to see at least some evidence that not all roadmaps are wishes and pixie dust. The things that you were talking to me about years ago are established parts of ChaosSearch now. It hasn't been just, sort of, frozen in amber for years, or months, or these giant periods of time. Because, again, there's—yeah, don't sell me vaporware; I know how this works. The things you have promised have come to fruition. It's nice to see that.Thomas: No, I appreciate it. We talked a little while ago, now a few years ago, and it was a bit of aspirational, right? We had a lot to do, we had more to do. But now when we have big customers using our product, solving their problems, whether it's security, performance, operation, again—at scale, right? The real pain is, sure you have a small ELK cluster or small Athena use case, but when you're dealing with terabytes to petabytes, trillions of rows, right—billions—when you were dealing trillions, billions are now small. Millions don't even exist, right?And you're graduating from computer science in college and you say the word, “Trillion,” they're like, “Nah. No one does that.” And like you were saying, people do petabytes and exabytes. That's the world we're living in, and that's something that we really went hard at because these are challenging data problems and this is where we feel we uniquely sit. And again, we don't have to break the bank while doing it.Corey: Oh, yeah. Or at least as of this recording, there's a meme going around, again, from an old internal Google Video, of, “I just want to serve five terabytes of traffic,” and it's an internal Google discussion of, “I don't know how to count that low.” And, yeah.Thomas: [laugh].Corey: But there's also value in being able to address things at much larger volume. I would love to see better responsiveness options around things like Deep Archive because the idea of being able to query that—even if you can wait a day or two—becomes really interesting just from the perspective of, at that point, current cost for one petabyte of data in Glacier Deep Archive is 1000 bucks a month. That is ‘why would I ever delete data again?' Pricing.Thomas: Yeah. You said it. And what's interesting about our technology is unlike, let's say Lucene, when you index it, it could be 3, 4, or 5x the raw size, our representation is smaller than gzip. So, it is a full representation, so why don't you store it efficiently long-term in S3? Oh, by the way, with the Glacier; we support Glacier too.And so, I mean, it's amazing the cost of data with cloud storage is dramatic, and if you can make it hot and activated, that's the real promise of a data lake. And, you know, it's funny, we use our own service to run our SaaS—we log our own data, we monitor, we alert, have dashboards—and I can't tell you how cheap our service is to ourselves, right? Because it's so cost-effective for long-tail, not just, oh, a few weeks; we store a whole year's worth of our operational data so we can go back in time to debug something or figure something out. And a lot of that's savings. Actually, huge savings is cloud storage with a distributed elastic compute fabric that is serverless. These are things that seem so obvious now, but if you have SSDs, and you're moving things around, you know, a team of IT professionals trying to manage it, it's not cheap.Corey: Oh, yeah, that's the story. It's like, “Step one, start paying for using things in cloud.” “Okay, great. When do I stop paying?” “That's the neat part. You don't.” And it continues to grow and build.And again, this is the thing I learned running a business that focuses on this, the people working on this, in almost every case, are more expensive than the infrastructure they're working on. And that's fine. I'd rather pay people than technologies. And it does help reaffirm, on some level, that—people don't like this reminder—but you have to generate more value than you cost. So, when you're sitting there spending all your time trying to avoid saving money on, “Oh, I've listened to ChaosSearch talk about what they do a few times. I can probably build my own and roll it at home.”It's, I've seen the kind of work that you folks have put into this—again, you have something like 100 employees now; it is not just you building this—my belief has always been that if you can buy something that gets you 90, 95% of where you are, great. Buy it, and then yell at whoever selling it to you for the rest of it, and that'll get you a lot further than, “We're going to do this ourselves from first principles.” Which is great for a weekend project for just something that you have a passion for, but in production mistakes show. I've always been a big proponent of buying wherever you can. It's cheaper, which sounds weird, but it's true.Thomas: And we do the same thing. We have single-sign-on support; we didn't build that ourselves, we use a service now. Auth0 is one of our providers now that owns that [crosstalk 00:37:12]—Corey: Oh, you didn't roll your own authentication layer? Why ever not? Next, you're going to tell me that you didn't roll your own payment gateway when you wound up charging people on your website to sign up?Thomas: You got it. And so, I mean, do what you do well. Focus on what you do well. If you're repeating what everyone seems to do over and over again, time, costs, complexity, and… service, it makes sense. You know, I'm not trying to build storage; I'm using storage. I'm using a great, wonderful service, cloud object storage.Use whats works, whats works well, and do what you do well. And what we do well is make cloud object storage analytical and fast. So, call us up and we'll take away that 2 a.m. call you have when your cluster falls down, or you have a new workload that you are going to go to the—I don't know, the beach house, and now the weekend shot, right? Spin it up, stream it in. We'll take over.Corey: Yeah. So, if you're listening to this and you happen to be at re:Invent, which is sort of an open question: why would you be at re:Invent while listening to a podcast? And then I remember how long the shuttle lines are likely to be, and yeah. So, if you're at re:Invent, make it on down to the show floor, visit the ChaosSearch booth, tell them I sent you, watch for the wince, that's always worth doing. Thomas, if people have better decision-making capability than the two of us do, where can they find you if they're not in Las Vegas this week?Thomas: So, you find us online chaossearch.io. We have so much material, videos, use cases, testimonials. You can reach out to us, get a free trial. We have a self-service experience where connect to your S3 bucket and you're up and running within five minutes.So, definitely chaossearch.io. Reach out if you want a hand-held, white-glove experience POV. If you have those type of needs, we can do that with you as well. But we booth on re:Invent and I don't know the booth number, but I'm sure either we've assigned it or we'll find it out.Corey: Don't worry. This year, it is a low enough attendance rate that I'm projecting that you will not be as hard to find in recent years. For example, there's only one expo hall this year. What a concept. If only it hadn't taken a deadly pandemic to get us here.Thomas: Yeah. But you know, we'll have the ability to demonstrate Chaos at the booth, and really, within a few minutes, you'll say, “Wow. How come I never heard of doing it this way?” Because it just makes so much sense on why you do it this way versus the merry-go-round of data movement, and transformation, and schema management, let alone all the sharding that I know is a nightmare, more often than not.Corey: And we'll, of course, put links to that in the [show notes 00:39:40]. Thomas, thank you so much for taking the time to speak with me today. As always, it's appreciated.Thomas: Corey, thank you. Let's do this again.Corey: We absolutely will. Thomas Hazel, CTO and Founder of ChaosSearch. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast episode, please leave a five-star review on your podcast platform of choice, whereas if you've hated this episode, please leave a five-star review on your podcast platform of choice along with an angry comment because I have dared to besmirch the honor of your homebrewed object store, running on top of some trusty and reliable Raspberries Pie.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.

Dark web market shuts down after DDoS Clearview facing fines in the UK New Chinese surveillance system will target journalists and students Thanks to our episode sponsor, Votiro Your users need to accept and open files to do their jobs. Keep them safe and productive with Votiro. With Votiro zero trust file sanitization API, your users can download and use any file instantly, from PDF to Autodesk CAD, with malicious code already removed—and full file usability intact. The signatureless file sanitization process happens in milliseconds without user friction. Visit Votiro.com and learn why millions of users trust Votiro to disarm billions of files each year.

Tim Daly, the Executive Vice President at Metropolitan Mechanical Contractors sits down with Laura to talk about his journey to APi group and the transition into the APi family. He shares insights on changing leadership at a company, the growth at MMC and introduces their new residential service offerings.

In this episode, Dave and Jamison answer these questions: Questions Starting to work on a team that is split across time zones. With a majority of the company based in one time zone and a handful spread in others. I want to emphasis the importance of asynchronous communication. I have found Slack to begin to feel like I need to respond ASAP instead of when it is convenient. If we were to say slack is used for asynchronous communication, is asking the team to use signal or even text appropriate for a quicker response? What is a good way to reach out to team members in cases where a response is needed more immediately? After about 1 year at my developer job, I was moved to work for a client company helping them launch a new product. This other client had different plans, it turns out, and now I'm just testing their API for them. That's fine but I never get questions answered and I hate my job with my client and hate my job with this company that sells me like a cheap piece of meat. I want to quit, I will quit, but I have a lot to say about why I'm quitting. How can I NOT be nice about quitting and the reasons I'm quitting, and still feel comfortable showing my face in the industry again? I haven't quit a job before, and this is my first job in the tech industry. Searching how to quit a job always comes with “remain light and positive.

Preston Pysh is a financial investor and host of the "We Study Billionaires" podcast. In this conversation, we discuss negative yielding debt, increasing stress on pension plans, and how Bitcoin can solve recent macro economic problems. ======================= BlockFi provides financial products for crypto investors. Products include high-yield interest accounts, USD loans, and no fee trading. To start earning today visit: http://www.blockfi.com/Pomp ======================= Choice is a new self-directed IRA product that I'm really excited about. If you are listening to this, you are likely part of the 7.1 million bitcoin owners who have retirement accounts with dollars in them, but not bitcoin. I was in that situation too. Now you can actually buy real Bitcoin in your retirement account. I'm talking about owning your private keys and using tax-advantaged dollars to do it too. Absolute game changer. https://www.retirewithchoice.com/pomp ======================= Circle is a global financial technology firm that enables businesses of all sizes to harness the power of stablecoins and public blockchains for payments, commerce and financial applications worldwide. Circle is also a principal developer of USD Coin (USDC), the fastest growing, fully reserved and regulated dollar stablecoin in the world. The free Circle Account and suite of platform API services bridge the gap between traditional payments and crypto for trading, DeFi, and NFT marketplaces. Create seamless, user-friendly, mainstream customer experiences with crypto-native infrastructure under the hood with Circle. Learn more at circle.com.

RATDispenser spreads multiple remote access trojans into the wild North Korea-linked Zinc group posed as Samsung recruiters to target security firms Interpol arrests over 1,000 suspects linked to cyber crime Thanks to our episode sponsor, Votiro Your users need to accept and open files to do their jobs. Keep them safe and productive with Votiro. With Votiro zero trust file sanitization API, your users can download and use any file instantly, from PDF to Autodesk CAD, with malicious code already removed—and full file usability intact. The signatureless file sanitization process happens in milliseconds without user friction. Visit Votiro.com and learn why millions of users trust Votiro to disarm billions of files each year. For the stories behind the headlines, head to CISOseries.com.

Could the API revolution and the digital transformation be exposing everyone to security risks? An API is the connective tissue that binds together cloud-native architecture and enables us to enjoy digital services. While these are fundamental for the way we work and live, they're exposing organizations to a new domain of security risk. Peter Klimek, Director of Technology, Office of the CTO at Imperva joins me on the Tech Talks Daily Podcast in a conversation about the benefits, and pitfalls, of APIs. Imperva is a cybersecurity leader with a mission to protect data and all paths to it. They protect the data of over 6,000 global customers from cyberattacks through all stages of their digital transformation. Their products are informed by the Imperva Research Lab, an international threat intelligence community that feeds the latest security and compliance expertise into our solutions.

Does your team make your company an acquisition target?  That's what Paul Singh (@paulsingh) and Edward Pizzarello (@pizzainmotion) start off the show with this week.  Your team can be your greatest asset.We're talking about the super sizing of Y Combinator, one of the most well-known accelerators.We also  talk about Paul's idea for a verified revenue API on Twitter.  And, robots ordering burgers.  Of course.

Qualcomm es la última compañía en incorporarse a la apuesta por la realidad aumentada con un framework propio, uniéndose a otras decenas. La apuesta por la realidad aumentada por parte de todas las grandes compañías que hoy día producen hardware y software, es algo que puede pasar desapercibido para la mayoría, pero es una realidad que no puede ser ignorada.  Qualcomm es una de esas compañías que presenta su nuevo framework Spaces XR que se suma al estándar OpenXR del grupo Kronos que ha creado una estandarización para que las decenas de API y soluciones tanto de dispositivos como librerías tengan unas guías comunes. Analizamos ese futuro y os hablamos de sus posibilidades y lo que está por llegar tanto de Apple como el resto de compañías. Descubre nuestro canal de Twitch en: twitch.tv/applecoding. Descubre nuestras ofertas para oyentes: Cursos en Udemy (con código de oferta) https://acoding.academy/cursos-udemy Apple Coding Academy https://acoding.academy Suscríbete a Apple Coding en nuestro Patreon https://patreon.com/applecoding. Canal de Telegram de Swift. Acceso al canal t.me/desarrollandoconswift. --------------- Consigue las camisetas oficiales de Apple Coding con los logos de Swift y Apple Coding así como todo tipo de merchadising como tazas o fundas. Tienda de merchandising de Apple Coding https://teespring.com/stores/acacademy. --------------- Tema musical: "For the Win" de "Two Steps from Hell", compuesto por Thomas Bergensen. Usado con permisos de fair use. Escúchalo en Apple Music https://itunes.apple.com/es/album/for-the-win/573729318?i=573729656 o Spotify https://open.spotify.com/track/34x22hY9CKf3ZoPjQwZSgc.

Cloud Security News this week 24 November 2021 CSA recently announced that they have now had 1500 Cloud services evaluated across to the STAR registry principles. According to CSA, by publishing to the registry organizations can show current and potential customers their security and compliance posture which may prevent the need for them to complete multiple security questionnaires. You can find more information about CSA and STAR registry here Security researcher Schütz was rewarded a $4,133 bounty by the Google Vulnerability Rewards Program for his Google Internal API vulnerability discovery. Google has now fixed this bug. You can read more about this here and the Schütz has documented his discovery here Palo Alto Networks - a well known cybersecurity Vendor - Their Chairman and CEO Nikesh Arora told investors that they are “18-to-24 months ahead from a competitive platform perspective”. There a few exciting players in the Cloud Security Market right now and you can read more about this here You can also find more about Palo Alto, Orca Security, Wiz and Lacework on the links Lacework, they have recently raised $1.3 billion in fresh capital at a valuation of $8.3 billion, making this one of the largest venture funding rounds of the year in the United States. Nasdaq covered a bit more about this here. In comparison Orca Security raised $550 million in Series C funding to raise their valuation to $1.8 Billion and Wiz raised $250 million on a $6 billion valuation Clubhouse, an audio based chatroom launched in 2020 which gained popularity during the pandemic has launched a BugBounty program on HackerOne. The scope of the Bounty includes their API and websites. The program has upto $3000 on offer for any critical vulnerabilities reported. You can find more about the program here Using a compromised password, an unauthorised third party has managed to infiltrate GoDaddy's systems affecting atleast 1.2 million users. Along with usernames, passwords and emails, the attackers also gained access to SSL private keys for a subset of users. Episode Show Notes on Cloud Security Podcast Website. Podcast Twitter - Cloud Security Podcast (@CloudSecPod) Instagram - Cloud Security News If you want to watch videos of this LIVE STREAMED episode and past episodes, check out: - Cloud Security Podcast: - Cloud Security Academy:

About StephanieStephanie Wong is an award-winning speaker, engineer, pageant queen, and hip hop medalist. She is a leader at Google with a mission to blend storytelling and technology to create remarkable developer content. At Google, she's created over 400 videos, blogs, courses, and podcasts that have helped developers globally. You might recognize her as the host of the GCP Podcast. Stephanie is active in her community, fiercely supporting women in tech and mentoring students.Links: Personal Website: https://stephrwong.com Twitter: https://twitter.com/stephr_wong 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 Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the things that makes me a little weird in the universe is that I do an awful lot of… let's just call it technology explanation slash exploration in public, and turning it into a bit of a brand-style engagement play. What makes this a little on the weird side is that I don't work for a big company, which grants me a tremendous latitude. I have a whole lot of freedom that lets me be all kinds of different things, and I can't get fired, which is something I'm really good at.Inversely, my guest today is doing something remarkably similar, except she does work for a big company and could theoretically be fired if they were foolish enough to do so. But I don't believe that they are. Stephanie Wong is the head of developer engagement at Google. Stephanie, thank you for volunteering to suffer my slings and arrows about all of this.Stephanie: [laugh]. Thanks so much for having me today, Corey.Corey: So, at a very high level, you're the head of developer engagement, which is a term that I haven't seen a whole lot of. Where does that start and where does that stop?Stephanie: Yeah, so I will say that it's a self-proclaimed title a bit because of the nuance of what I do. I would say at its heart, I am still a part of developer relations. If you've heard of developer advocacy or developer evangelist, I would say this slight difference in shade of what I do is that I focus on scalable content creation and becoming a central figure for our developer audiences to engage and enlighten them with content that, frankly, is remarkable, and that they'd want to share and learn about our technology.Corey: Your bio is fascinating in that it doesn't start with the professional things that most people do with, “This is my title and this is my company,” is usually the first sentence people put in. Yours is, “Stephanie Wong is an award-winning speaker, engineer, pageant queen, and hip hop medalist.” Which is both surprising and more than a little bit refreshing because when I read a bio like that my immediate instinctive reaction is, “Oh, thank God. It's a real person for a change.” I like the idea of bringing the other aspects of what you are other than, “This is what goes on in an IDE, the end,” to your audience.Stephanie: That is exactly the goal that I had when creating that bio because I truly believe in bringing more interdisciplinary and varied backgrounds to technology. I, myself have gone through a very unconventional path to get to where I am today and I think in large part, my background has had a lot to do with my successes, my failures, and really just who I am in tech as an uninhibited and honest, credible person today.Corey: I think that there's a lack of understanding, broadly, in our industry about just how important credibility and authenticity are and even the source of where they come from. There are a lot of folks who are in the DevRel space—devrelopers, as I insist upon calling them, over their protests—where, on some level, the argument is, what is developer relations? “Oh, you work in marketing, but they're scared to tell you,” has been my gag on that one for a while. But they speak from a position of, “I know what's what because I have been in the trenches, working on these large-scale environments as an engineer for the last”—fill in the blank, however long it may have been—“And therefore because I have done things, I am going to tell you how it is.” You explicitly call out that you don't come from the traditional, purely technical background. Where did you come from? It's unlikely that you've sprung fully-formed from the forehead of some god, but again, I'm not entirely sure how Google finds and creates the folks that it winds up advancing, so maybe you did.Stephanie: Well, to tell you the truth. We've all come from divine creatures. And that's where Google sources all employees. So. You know. But—[laugh].Corey: Oh, absolutely. “We climbed to the top of Olympus and then steal fire from the gods.” “It's like, isn't that the origin story of Prometheus?” “Yeah, possibly.” But what is your background? Where did you come from?Stephanie: So, I have grown up, actually, in Silicon Valley, which is a little bit ironic because I didn't go to school for computer science or really had the interest in becoming an engineer in school. I really had no idea.Corey: Even been more ironic than that because most of Silicon Valley appears to never have grown up at all.Stephanie: [laugh]. So, true. Maybe there's a little bit of that with me, too. Everybody has a bit of Peter Pan syndrome here, right? Yeah, I had no idea what I wanted to do in school and I just knew that I had an interest in communicating with one another, and I ended up majoring in communication studies.I thought I wanted to go into the entertainment industry and go into production, which is very different and ended up doing internships at Warner Brothers Records, a YouTube channel for dance—I'm a dancer—and I ended up finding a minor in digital humanities, which is sort of this interdisciplinary minor that combines technology and the humanities space, including literature, history, et cetera. So, that's where I got my start in technology, getting an introduction to information systems and doing analytics, studying social media for certain events around the world. And it wasn't until after school that I realized that I could work in enterprise technology when I got an offer to be a sales engineer. Now, that being said, I had no idea what sales engineering was. I just knew it had something to do with enterprise technology and communications, and I thought it was a good fit for my background.Corey: The thing that I find so interesting about that is that it breaks the mold of what people expect, when, “If someone's going to talk to me about technology—especially coming from a”—it's weird; it's one of the biggest companies on the planet, and people still on some level equate Google with the startup-y mentality of being built in someone's garage. That's an awfully big garage these days, if that's even slightly close to true, which it isn't. But there's this idea of, “Oh, you have to go to Stanford. You have to get a degree in computer science. And then you have to go and do this, this, this, this, and this.”And it's easy to look dismissively at what you're doing. “Communications? Well, all that would teach you to do is communicate to people clearly and effectively. What possible good is that in tech?” As we look around the landscape and figure out exactly why that is so necessary in tech, and also so lacking?Stephanie: Exactly. I do think it's an underrated skill in tech. Maybe it's not so much anymore, but I definitely think that it has been in the past. And even for developers, engineers, data scientists, other technical practitioner, especially as a person in DevRel, I think it's such a valuable skill to be able to communicate complex topics simply and understandably to a wide variety of audiences.Corey: The big question that I have for you because I've talked to an awful lot of folks who are very concerned about the way that they approach developer relations, where—they'll have ratios, for example—where I know someone and he insists that he give one deeply technical talk for every four talks that are not deeply technical, just because he feels the need to re-establish and shore up his technical bona fides. Now, if there's one thing that people on the internet love, it is correcting people on things that are small trivia aspect, or trying to pull out the card that, “Oh, I've worked on this system for longer than you've worked on this system, therefore, you should defer to me.” Do you find that you face headwinds for not having the quote-unquote, “Traditional” engineering technical background?Stephanie: I will say that I do a bit. And I did, I would say when I first joined DevRel, and I don't know if it was much more so that it was being imposed on me or if it was being self-imposed, something that I felt like I needed to prove to gain credibility, not just in my organization, but in the industry at large. And it wasn't until two or three years into it, that I realized that I had a niche myself. It was to create stories with my content that could communicate these concepts to developers just as effectively. And yes, I can still prove that I can go into an hour-long or a 45-minute-long tech talk or a webinar about a topic, but I can also easily create a five to ten-minute video that communicates concepts and inspires audiences just the same, and more importantly, be able to point to resources, code labs, tutorials, GitHub repos, that can allow the audience to be hands-on themselves, too. So really, I think that it was over time that I gained more experience and realized that my skill sets are valuable in a different way, and it's okay to have a different background as long as you bring something to the table.Corey: And I think that it's indisputable that you do. The concept of yours that I've encountered from time to time has always been insightful, it is always been extremely illuminating, and—you wouldn't think of this as worthy of occasion and comment, but I feel it needs to be said anyway—at no point in any of your content did I feel like I was being approached in a condescending way, where at every point it was always about uplifting people to a level of understanding, rather than doing the, “Well, I'm smarter than you and you couldn't possibly understand the things that I've been to.” It is relatable, it is engaging, and you add a very human face to what is admittedly an area of industry that is lacking in a fair bit of human element.Stephanie: Yeah, and I think that's the thing that many folks DevRel continue to underline is the idea of empathy, empathizing with your audiences, empathizing with the developers, the engineers, the data engineers, whoever it is that you're creating content for, it's being in their shoes. But for me, I may not have been in those shoes for years, like many other folks historically have been in for DevRel, but I want to at least go through the journey of learning a new piece of technology. For example, if I'm learning a new platform on Google Cloud, going through the steps of creating a demo, or walking through a tutorial, and then candidly explaining that experience to my audience, or creating a video about it. I really just reject the idea of having ego in tech and I would love to broaden the opportunity for folks who came from a different background like myself. I really want to just represent the new world of technology where it wasn't full of people who may have had the privilege to start coding at a very early age, in their garages.Corey: Yeah, privilege of, in many respects, also that privilege means, “Yes, I had the privilege of not having to have friends and deal with learning to interact with other human beings, which is what empowered me to build this company and have no social skills whatsoever.” It's not the aspirational narrative that we sometimes are asked to believe. You are similar in some respects to a number of things that I do—by which I mean, you do it professionally and well and I do it as basically performance shitpost art—but you're on Twitter, you make videos, you do podcasts, you write long-form and short-form as well. You are sort of all across the content creation spectrum. Which of those things do you prefer to do? Which ones of those are things you find a little bit more… “Well, I have to do it, but it's not my favorite?” Or do you just tend to view it as content is content; you just look at different media to tell your story?Stephanie: Well, I will say any form of content is queen—I'm not going to say king, but—[laugh] content is king, content is queen, it doesn't matter.Corey: Content is a baroness as it turns out.Stephanie: [laugh]. There we go. I have to say, so given my background, I mentioned I was into production and entertainment before, so I've always had a gravitation towards video content. I love tinkering with cameras. Actually, as I got started out at Google Cloud, I was creating scrappy content using webcams and my own audio equipment, and doing my own research, and finding lounges and game rooms to do that, and we would just upload it to our own YouTube channel, which probably wasn't allowed at the time, but hey, we got by with it.And eventually, I got approached by DevRel to start doing it officially on the channel and I was given budget to do it in-studio. And so that was sort of my stepping stone to doing this full-time eventually, which I never foresaw for myself. And so yeah, I have this huge interest in—I'm really engaged with video content, but once I started expanding and realizing that I could repurpose that content for podcasting, I could repurpose it for blogs, then you start to realize that you can shard content and expand your reach exponentially with this. So, that's when I really started to become more active on social media and leverage it to build not just content for Google Cloud, but build my own brand in tech.Corey: That is the inescapable truth of DevRel done right is that as you continue doing it, in time, in your slice of the industry, it is extremely likely that your personal brand eclipses the brand of the company that you represent. And it's in many ways a test of corporate character—if it makes sense—as do how they react to that. I've worked in roles before I started this place where I was starting to dabble with speaking a lot, and there was always a lot of insecurity that I picked up of, “Well, it feels like you're building your personal brand, not advancing the company here, and we as a company do not see the value in you doing that.” Direct quote from the last boss I had. And, well, that partially explains why I'm here, I suppose.But there's insecurity there. I'd see the exact opposite coming out of Google, especially in recent times. There's something almost seems to be a renaissance in Google Cloud, and I'm not sure where it came from. But if I look at it across the board, and you had taken all the labels off of everything, and you had given me a bunch of characteristics about different companies, I would never have guessed that you were describing Google when you're talking about Google Cloud. And perhaps that's unfair, but perceptions shape reality.Stephanie: Yeah, I find that interesting because I think traditionally in DevRel, we've also hired folks for their domain expertise and their brand, depending on what you're representing, whether it's in the Kubernetes space or Python client library that you're supporting. But it seems like, yes, in my case, I've organically started to build my brand while at Google, and Google has been just so spectacular in supporting that for me. But yeah, it's a fine line that I think many people have to walk. It's like, do you want to continue to build your own brand and have that carry forth no matter what company you stay at, or if you decide to leave? Or can you do it hand-in-hand with the company that you're at? For me, I think I can do it hand-in-hand with Google Cloud.Corey: It's taken me a long time to wrap my head around what appears to be a contradiction when I look at Google Cloud, and I think I've mostly figured it out. In the industry, there is a perception that Google as an entity is condescending and sneering toward every other company out there because, “You're Google, you know how to do all these great, amazing things that are global-spanning, and over here at Twitter for Pets, we suck doing these things.” So, Google is always way smarter and way better at this than we could ever hope to be. But that is completely opposed to my personal experiences talking with Google employees. Across the board, I would say that you all are self-effacing to a fault.And I mean that in the sense of having such a limited ego, in some cases, that it's, “Well, I don't want to go out there and do a whole video on this. It's not about me, it's about the technology,” are things that I've had people who work at Google say to me. And I appreciate the sentiment; it's great, but that also feels like it's an aloofness. It also fails to humanize what it is that you're doing. And you are a, I've got to say, a breath of fresh air when it comes to a lot of that because your stories are not just, “Here's how you do a thing. It's awesome. And this is all the intricacies of the API.”And yeah, you get there, but you also contextualize that in a, “Here's why it matters. Here's the problem that solves. Here is the type of customer's problem that this is great for,” rather than starting with YAML and working your way up. It's going the other way, of, “We want to sell some underpants,” or whatever it is the customer is trying to do today. And that is the way that I think is one of the best ways to drive adoption of what's going on because if you get people interested and excited about something—at least in my experience—they're going to figure out how the API works. Badly in many cases, but works. But if you start on the API stuff, it becomes a solution looking for a problem. I like your approach to this.Stephanie: Thank you. Yeah, I appreciate that. I think also something that I've continued to focus on is to tell stories across products, and it doesn't necessarily mean within just Google Cloud's ecosystem, but across the industry as well. I think we need to, even at Google, tell a better story across our product space and tie in what developers are currently using. And I think the other thing that I'm trying to work on, too, is contextualizing our products and our launches not just across the industry, but within our product strategy. Where does this tie in? Why does it matter? What is our forward-looking strategy from here? When we're talking about our new data cloud products or analytics, [unintelligible 00:17:21], how does this tie into our API strategy?Corey: And that's the biggest challenge, I think, in the AI space. My argument has been for a while—in fact, I wrote a blog post on it earlier this year—that AI and machine learning is a marvelously executed scam because it's being pushed by cloud providers and the things that you definitely need to do a machine learning experiment are a bunch of compute and a whole bunch of data that has to be stored on something, and wouldn't you know it, y'all sell that by the pound. So, it feels, from a cynical perspective, which I excel at espousing, that approach becomes one of you're effectively selling digital pickaxes into a gold rush. Because I see a lot of stories about machine learning how to do very interesting things that are either highly, highly use-case-specific, which great, that would work well, for me too, if I ever wind up with, you know, a petabyte of people's transaction logs from purchasing coffee at my national chain across the country. Okay, that works for one company, but how many companies look like that?And on the other side of it, “It's oh, here's how we can do a whole bunch of things,” and you peel back the covers a bit, and it looks like, “Oh, but you really taught me here is bias laundering?” And, okay. I think that there's a definite lack around AI and machine learning of telling stories about how this actually matters, what sorts of things people can do with it that aren't incredibly—how do I put this?—niche or a problem in search of a solution?Stephanie: Yeah, I find that there are a couple approaches to creating content around AI and other technologies, too, but one of them being inspirational content, right? Do you want to create something that tells the story of how I created a model that can predict what kind of bakery item this is? And we're going to do it by actually showcasing us creating the outcome. So, that's one that's more like, okay. I don't know how relatable or how appropriate it is for an enterprise use case, but it's inspirational for new developers or next gen developers in the AI space, and I think that can really help a company's brand, too.The other being highly niche for the financial services industry, detecting financial fraud, for example, and that's more industry-focused. I found that they both do well, in different contexts. It really depends on the channel that you're going to display it on. Do you want it to be viral? It really depends on what you're measuring your content for. I'm curious from you, Corey, what you've seen across, as a consumer of content?Corey: What's interesting, at least in my world, is that there seems to be, given that what I'm focusing on first and foremost is the AWS ecosystem, it's not that I know it the best—I do—but at this point, it's basically Stockholm Syndrome where it's… with any technology platform when you've worked with it long enough, you effectively have the most valuable of skill sets around it, which is not knowing how it works, but knowing how it doesn't, knowing what the failure mode is going to look like and how you can work around that and detect it is incredibly helpful. Whereas when you're trying something new, you have to wait until it breaks to find the sharp edges on it. So, there's almost a lock-in through, “We failed you enough times,” story past a certain point. But paying attention to that ecosystem, I find it very disjointed. I find that there are still events that happen and I only find out when the event is starting because someone tweets about it, and for someone who follows 40 different official AWS RSS feeds, to be surprised by something like that tells me, okay, there's not a whole lot of cohesive content strategy here, that is at least making it easy for folks to consume the things that they want, especially in my case where even the very niche nature of what I do, my interest is everything.I have a whole bunch of different filters that look for various keywords and the rest, and of course, I have helpful folks who email me things constantly—please keep it up; I'm a big fan—worst case, I'd rather read something twice than nothing. So, it's helpful to see all of that and understand the different marketing channels, different personas, and the way that content approaches, but I still find things that slip through the cracks every time. The thing that I've learned—and it felt really weird when I started doing it—was, I will tell the same stories repeatedly in different forums, or even the same forum. I could basically read you a Twitter thread from a year ago, word-for-word, and it would blow up bigger than it did the first time. Just because no one reads everything.Stephanie: Exactly.Corey: And I've already told my origin story. You're always new to someone. I've given talks internally at Amazon at various times, and I'm sort of loud and obnoxious, but the first question I love to ask is, “Raise your hand if you've never heard of me until today.” And invariably, over three-quarters of the room raises their hand every single time, which okay, great. I think that's awesome, but it teaches me that I cannot ever expect someone to have, quote-unquote, “Done the reading.”Stephanie: I think the same can be said about the content that I create for the company. You can't assume that people, A) have seen my tweets already or, B) understand this product, even if I've talked about it five times in the past. But yes, I agree. I think that you definitely need to have a content strategy and how you format your content to be more problem-solution-oriented.And so the way that I create content is that I let them fall into three general buckets. One being that it could be termed definition: talking about the basics, laying the foundation of a product, defining terms around a topic. Like, what is App Engine, or Kubeflow 101, or talking about Pub/Sub 101.The second being best practices. So, outlining and explaining the best practices around a topic, how do you design your infrastructure for scale and reliability.And the third being diagnosis: investigating; exploring potential issues, as you said; using scripts; Stackdriver logging, et cetera. And so I just kind of start from there as a starting point. And then I generally follow a very, very effective model. I'm sure you're aware of it, but it's called the five point argument model, where you are essentially telling a story to create a compelling narrative for your audience, regardless of the topic or what bucket that topic falls into.So, you're introducing the problem, you're sort of rising into a point where the climax is the solution. And that's all to build trust with your audience. And as it falls back down, you're giving the results in the conclusion, and that's to inspire action from your audience. So, regardless of what you end up talking about this problem-solution model—I've found at least—has been highly effective. And then in terms of sharing it out, over and over again, over the span of two months, that's how you get the views that you want.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don't use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you'll have a chance to prove yourself. Compete in four unique lab challenges, where they'll be awarding more than $2000 in cash and prizes. I'm not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That's cloudacademy.com/corey. We're gonna have some fun with this one!Corey: See, that's a key difference right there. I don't do anything regular in terms of video as part of my content. And I do it from time to time, but you know, getting gussied up and whatnot is easier than just talking into a microphone. As I record this, it's Friday, I'm wearing a Hawaiian shirt, and I look exactly like the middle-aged dad that I am. And for me at least, a big breakthrough moment was realizing that my audience and I are not always the same.Weird confession for someone in my position: I don't generally listen to podcasts. And the reason behind that is I read very quickly, and even if I speed up a podcast, I'm not going to be able to consume the information nearly as quickly as I could by reading it. That, amongst other reasons, is one of the reasons that every episode of this show has a full transcript attached to it. But I'm not my audience. Other people prefer to learn by listening and there's certainly nothing wrong with that.My other podcast, the AWS Morning Brief, is the spoken word version of the stuff that I put out in my newsletter every week. And that is—it's just a different area for people to consume the content because that's what works for them. I'm not one to judge. The hard part for me was getting over that hump of assuming the audience was like me.Stephanie: Yeah. And I think the other key part of is just mainly consistency. It's putting out the content consistently in different formats because everybody—like you said—has a different learning style. I myself do. I enjoy visual styles.I also enjoy listening to podcasts at 2x speed. [laugh]. So, that's my style. But yeah, consistency is one of the key things in building content, and building an audience, and making sure that you are valuable to your audience. I mean, social media, at the end of the day is about the people that follow you.It's not about yourself. It should never be about yourself. It's about the value that you provide. Especially as somebody who's in DevRel in this position for a larger company, it's really about providing value.Corey: What are the breakthrough moments that I had relatively early in my speaking career—and I think it's clear just from what you've already said that you've had a similar revelation at times—I gave a talk, that was really one of my first talks that went semi-big called, “Terrible Ideas in Git.” It was basically, learn how to use Git via anti-pattern. What it secretly was, was under the hood, I felt it was time I learned Git a bit better than I did, so I pitched it and I got a talk accepted. So well, that's what we call a forcing function. By the time I give that talk, I'd better be [laugh] able to have built a talk that do this intelligently, and we're going to hope for the best.It worked, but the first version of that talk I gave was super deep into the plumbing of Git. And I'm sure that if any of the Git maintainers were in the audience, they would have found it great, but there aren't that many folks out there. I redid the talk and instead approached it from a position of, “You have no idea what Git is. Maybe you've heard of it, but that's as far as it goes.” And then it gets a little deeper there.And I found that making the subject more accessible as opposed to deeper into the weeds of it is almost always the right decision from a content perspective. Because at some level, when you are deep enough into the weeds, the only way you're going to wind up fixing something or having a problem that you run into get resolved, isn't by listening to a podcast or a conference talk; it's by talking to the people who built the thing because at that level, those are the only people who can hang at that level of depth. That stops being fodder for conference talks unless you turn it into an after-action report of here's this really weird thing I learned.Stephanie: Yeah. And you know, to be honest, the one of the most successful pieces of content I've created was about data center security. I visited a data center and I essentially unveiled what our security protocols were. And that wasn't a deeply technical video, but it was fun and engaging and easily understood by the masses. And that's what actually ended up resulting in the highest number of views.On top of that, I'm now creating a video about our subsea fiber optic cables. Finding that having to interview experts from a number of different teams across engineering and our strategic negotiators, it was like a monolith of information that I had to take in. And trying to format that into a five-minute story, I realized that bringing it up a layer of abstraction to help folks understand this at a wider level was actually beneficial. And I think it'll turn into a great piece of content. I'm still working on it now. So, [laugh] we'll see how it turns out.Corey: I'm a big fan of watching people learn and helping them get started. The thing that I think gets lost a lot is it's easy to assume that if I look back in time at myself when I was first starting my professional career two decades ago, that I was exactly like I am now, only slightly more athletic and can walk up a staircase without getting winded. That's never true. It never has been true. I've learned a lot about not just technology but people as I go, and looking at folks are entering the workforce today through the same lens of, “Well, that's not how I would handle that situation.” Yeah, no kidding. I have two decades of battering my head against the sharp edges and leaving dents in things to inform that opinion.No, when I was that age, I would have handled it way worse than whatever it is I'm critiquing at the time. But it's important to me that we wind up building those pathways and building those bridges so that people coming into the space, first, have a clear path to get here, and secondly, have a better time than I ever did. Where does the next generation of talent come from has been a recurring question and a recurring theme on the show.Stephanie: Yeah. And that's exactly why I've been such a fierce supporter of women in tech, and also, again, encouraging a broader community to become a part of technology. Because, as I said, I think we're in the midst of a new era of technology, of people from all these different backgrounds in places that historically have had more remote access to technology, now having the ability to become developers at an early age. So, with my content, that's what I'm hoping to drive to make this information more easily accessible. Even if you don't want to become a Google Cloud engineer, that's totally fine, but if I can help you understand some of the foundational concepts of cloud, then I've done my job well.And then, even with women who are already trying to break into technology or wanting to become a part of it, then I want to be a mentor for them, with my experience not having a technical background and saying yes to opportunities that challenged me and continuing to build my own luck between hard work and new opportunities.Corey: I can't wait to see how this winds up manifesting as we see understandings of what we're offering to customers in different areas in different ways—both in terms of content and terms of technology—how that starts to evolve and shift. I feel like we're at a bit of an inflection point now, where today if I graduate from school and I want to start a business, I have to either find a technical co-founder or I have to go to a boot camp and learn how to code in order to build something. I think that if we can remove that from the equation and move up the stack, sure, you're not going to be able to build the next Google or Pinterest or whatnot from effectively Visual Basic for Interfaces, but you can build an MVP and you can then continue to iterate forward and turn it into something larger down the road. The other part of it, too, is that moving up the stack into more polished solutions rather than here's a bunch of building blocks for platforms, “So, if you want a service to tell you whether there's a picture of a hot dog or not, here's a service that does exactly that.” As opposed to, “Oh, here are the 15 different services, you can bolt together and pay for each one of them and tie it together to something that might possibly work, and if it breaks, you have no idea where to start looking, but here you go.” A packaged solution that solves business problems.Things move up the stack; they do constantly. The fact is that I started my career working in data centers and now I don't go to them at all because—spoiler—Google, and Amazon, and people who are not IBM Cloud can absolutely run those things better than I can. And there's no differentiated value for me in solving those global problems locally. I'd rather let the experts handle stuff like that while I focus on interesting problems that actually affect my business outcome. There's a reason that instead of running all the nonsense for lastweekinaws.com myself because I've worked in large-scale WordPress hosting companies, instead I pay WP Engine to handle it for me, and they, in turn, hosted on top of Google Cloud, but it doesn't matter to me because it's all just a managed service that I pay for. Because me running the website itself adds no value, compared to the shitpost I put on the website, which is where the value derives from. For certain odd values of value.Stephanie: [laugh]. Well, two things there is that I think we actually had a demo created on Google Cloud that did detect hot dogs or not hot dogs using our Vision API, years in the past. So, thanks for reminding me of that one.Corey: Of course.Stephanie: But yeah, I mean, I completely agree with that. I mean, this is constantly a topic in conversation with my team members, and with clients. It's about higher level of abstractions. I just did a video series with our fellow, Eric Brewer, who helped build cloud infrastructure here at Google over the past ten decades. And I asked him what he thought the future of cloud would be in the next ten years, and he mentioned, “It's going to be these higher levels of abstraction, building platforms on top of platforms like Kubernetes, and having more services like Cloud run serverless technologies, et cetera.”But at the same time, I think the value of cloud will continue to be providing optionality for developers to have more opinionated services, services like GKE Autopilot, et cetera, that essentially take away the management of infrastructure or nodes that people don't really want to deal with at the end of the day because it's not going to be a competitive differentiator for developers. They want to focus on building software and focusing on keeping their services up and running. And so yeah, I think the future is going to be that, giving developers flexibility and freedom, and still delivering the best-of-breed technology. If it's covering something like security, that's something that should be baked in as much as possible.Corey: You're absolutely right, first off. I'm also looking beyond it where I want to be able to build a website that is effectively Twitter, only for pets—because that is just a harebrained enough idea to probably raise a $20 million seed round these days—and I just want to be able to have the barks—those are like tweets, only surprisingly less offensive and racist—and have them just be stored somewhere, ideally presumably under the hood somewhere, it's going to be on computers, but whether it's in containers, or whether it's serverless, or however is working is the sort of thing that, “Wow, that seems like an awful lot of nonsense that is not central nor core to my business succeeding or failing.” I would say failing, obviously, except you can lose money at scale with the magic of things like SoftBank. Here we are.And as that continues to grow and scale, sure, at some point I'm going to have bespoke enough needs and a large enough scale where I do have to think about those things, but building the MVP just so I can swindle some VCs is not the sort of thing where I should have to go to that depth. There really should be a golden-path guardrail-style thing that I can effectively drag and drop my way into the next big scam. And that is, I think, the missing piece. And I think that we're not quite ready technologically to get there yet, but I can't shake the feeling and the hope that's where technology is going.Stephanie: Yeah. I think it's where technology is heading, but I think part of the equation is the adoption by our industry, right? Industry adoption of cloud services and whether they're ready to adopt services that are that drag-and-drop, as you say. One thing that I've also been talking a lot about is this idea of service-oriented networking where if you have a service or API-driven environment and you simply want to bring it to cloud—almost a plug-and-play there—you don't really want to deal with a lot of the networking infrastructure, and it'd be great to do something like PrivateLink on AWS, or Private Service Connect on Google Cloud.While those conversations are happening with customers, I'm finding that it's like trying to cross the Grand Canyon. Many enterprise customers are like, “That sounds great, but we have a really complex network topology that we've been sitting on for the past 25 years. Do you really expect that we're going to transition over to something like that?” So, I think it's about providing stepping stones for our customers until they can be ready to adopt a new model.Corey: Yeah. And of course, the part that never gets said out loud but is nonetheless true and at least as big of a deal, “And we have a whole team of people who've built their entire identity around that network because that is what they work on, and they have been ignoring cloud forever, and if we just uplift everything into a cloud where you folks handle that, sure, it's better for the business outcome, but where does that leave them?” So, they've been here for 25 years, and they will spend every scrap of political capital they've managed to accumulate to torpedo a cloud migration. So, any FUD they can find, any horse-trading they can do, anything they can do to obstruct the success of a cloud initiative, they're going to do because people are people, and there is no real plan to mitigate that. There's also the fact that unless there's a clear business value story about a feature velocity increase or opening up new markets, there's also not an incentive to do things to save money. That is never going to be the number one priority in almost any case short of financial disaster at a company because everything they're doing is building out increasing revenue, rather than optimizing what they're already doing.So, there's a whole bunch of political challenges. Honestly, moving the computer stuff from on-premises data centers into a cloud provider is the easiest part of a cloud migration compared to all of the people that are involved.Stephanie: Yeah. Yeah, we talked about serverless and all the nice benefits of it, but unless you are more a digitally-born, next-gen developer, it may be a higher burden for you to undertake that migration. That's why we always [laugh] are talking about encouraging people to start with newer surfaces.Corey: Oh, yeah. And that's the trick, too, is if you're trying to learn a new cloud platform these days—first, if you're trying to pick one, I'd be hard-pressed to suggest anything other than Google Cloud, with the possible exception of DigitalOcean, just because the new user experience is so spectacularly good. That was my first real, I guess, part of paying attention to Google Cloud a few years ago, where I was, “All right, I'm going to kick the tires on this and see how terrible this interface is because it's a Google product.” And it was breathtakingly good, which I did not expect. And getting out of the way to empower someone who's new to the platform to do something relatively quickly and straightforwardly is huge. And sure, there's always room to prove, but that is the right area to focus on. It's clear that the right energy was spent in the right places.Stephanie: Yeah. I will say a story that we don't tell quite as well as we should is the One Google story. And I'm not talking about just between Workspace and Google Cloud, but our identity access management and knowing your Google account, which everybody knows. It's not like Microsoft, where you're forced to make an account, or it's not like AWS where you had a billion accounts and you hate them all.Corey: Oh, my God, I dread logging into the AWS console every time because it is such a pain in the ass. I go to cloud.google.com sometimes to check something, it's like, “Oh, right. I have to dig out my credentials.” And, “Where's my YubiKey?” And get it. Like, “Oh. I'm already log—oh. Oh, right. That's right. Google knows how identity works, and they don't actively hate their customers. Okay.” And it's always a breath of fresh air. Though I will say that by far and away, the worst login experience I've seen yet is, of course, Azure.Stephanie: [laugh]. That's exactly right. It's Google account. It's yours. It's personal. It's like an Apple iCloud account. It's one click, you're in, and you have access to all the applications. You know, so it's the same underlying identity structure with Workspace and Gmail, and it's the same org structure, too, across Workspace and Google Cloud. So, it's not just this disingenuous financial bundle between GCP and Workspace; it's really strategic. And it's kind of like the idea of low code or no code. And it looks like that's what the future of cloud will be. It's not just by VMs from us.Corey: Yeah. And there are customers who want to buy VMs and that's great. Speed up what they're doing; don't get in the way of people giving you their money, but if you're starting something net-new, there's probably better ways to do it. So, I want to thank you for taking as much time as you have to wind up going through how you think about, well, the art of storytelling in the world of engineering. If people want to learn more about who you are, what you're up to, and how you approach things, where can they find you?Stephanie: Yeah, so you can head to stephrwong.com where you can see my work and also get in touch with me if you want to collaborate on any content. I'm always, always, always open to that. And my Twitter is @stephr_wong.Corey: And we will, of course, put links to that in the [show notes 00:40:03]. Thank you so much for taking the time to speak with me.Stephanie: Thanks so much.Corey: Stephanie Wong, head of developer engagement 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 comment telling me that the only way to get into tech these days is, in fact, to graduate with a degree from Stanford, and I can take it from you because you work in their admissions office.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.

In this episode of Syntax, Scott and Wes talk about ways they troubleshoot issues with their code. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the "How did you hear about us?" section. Mux - Sponsor Mux Video is an API-first platform that makes it easy for any developer to build beautiful video. Powered by data and designed by video experts, your video will work perfectly on every device, every time. Mux Video handles storage, encoding, and delivery so you can focus on building your product. Live streaming is just as easy and Mux will scale with you as you grow, whether you're serving a few dozen streams or a few million. Visit mux.com/syntax. Show Notes 01:13 Furniture shortages 02:29 Managing stuff 03:05 Basic troubleshooting skills are missing 06:09 Sanity check CodePen Codesandbox 08:05 Isolate the issue 08:57 Commenting out code is free 12:17 Replicate the issue 15:07 Svelte and VS Code error Svelte VS Code 17:02 Wes' course upgrades Parcel 2 Patch package 18:07 Sponsor: Logrocket 19:15 Rollback 20:30 Reading the error message Syntax 47 - How to Get Better at Debugging Syntax 152 - Debugging Tools 23:59 Crack open the node modules directory 26:06 Sponsor: Freshbooks 27:29 Write step by step comments to the code 29:01 Consider outside sources 30:56 Using the right tools for the job 33:19 Rubber ducking it 34:16 Wes' Big Mouth Bass story 37:20 Scott's blown away by his leaf blower 39:56 Copy paste a message into Google Twitter - What are your tips for troubleshooting code or a system that doesn't work? 41:33 Logs and metrics 42:36 CI CD issues and Error Handler 43:41 Using a step debugger 44:24 Explain what's happening to someone else 45:31 Read the documentation 47:05 Take a break, have a cuppa 48:42 Sponsor: Mux 50:57 SIIIIICK PIIICKS 57:05 Shamless plugs Links @jimbomoso - Do you know of any resources for developing/improving code trouble shooting? ××× SIIIIICK ××× PIIIICKS ××× Scott: Forehead Wes: EGO EXINNO 240W/120W Chargers Shameless Plugs Scott: Astro Course - Sign up for the year and save 25%! Wes: All Courses - Use the coupon code 'Syntax' for $10 off! Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Welcome to Hearts and Minds—A QTAPI Community Conversation Series, Session Three: FTAPIs—The Personal and the Political. Join us for an intergenerational panel discussion of QTAPI (queer and trans Asian Pacific Islander) people discussing and sharing stories of their personal involvement in politics and community organizing. The Asian and the Pacific Islander communities are not monoliths unto themselves, so no program can possibly speak to the breadth of diversity and uniqueness in those communities. But we will explore certain moments in the panelists' own personal histories and lived experiences as they reflect on questions such as: What got them involved in API and/or LGBTQ issues? Was there a specific moment that moved you to become involved? Who were your mentors? How has your involvement changed from when you started? What is the most rewarding aspect of this work? And more. SPEAKERS James Coleman Member, South San Francisco City Council Valli Kalei Kanuha Ph.D., Teaching Professor and Assistant Dean for Diversity, Equity and Inclusion, University of Washington Sammie Ablaza Wills Community Organizer; Outgoing Executive Director, APIENC Willy Wilkinson M.P.H., Writer; Public Health Consultant; Cultural Competency Trainer; Author, Born on the Edge of Race and Gender: A Voice for Cultural Competency Michelle Meow Producer and Host, "The Michelle Meow Show" on KBCW/KPIX TV and Podcast; Member, Commonwealth Club Board of Governors; Twitter @msmichellemeow—Host In response to the COVID-19 pandemic, we are currently hosting all of our live programming via YouTube live stream. This program was recorded via video conference on November 16th, 2021 by the Commonwealth Club of California. Learn more about your ad choices. Visit megaphone.fm/adchoices

Welcome to Hearts and Minds—A QTAPI Community Conversation Series, Session Three: FTAPIs—The Personal and the Political. Join us for an intergenerational panel discussion of QTAPI (queer and trans Asian Pacific Islander) people discussing and sharing stories of their personal involvement in politics and community organizing. The Asian and the Pacific Islander communities are not monoliths unto themselves, so no program can possibly speak to the breadth of diversity and uniqueness in those communities. But we will explore certain moments in the panelists' own personal histories and lived experiences as they reflect on questions such as: What got them involved in API and/or LGBTQ issues? Was there a specific moment that moved you to become involved? Who were your mentors? How has your involvement changed from when you started? What is the most rewarding aspect of this work? And more. SPEAKERS James Coleman Member, South San Francisco City Council Valli Kalei Kanuha Ph.D., Teaching Professor and Assistant Dean for Diversity, Equity and Inclusion, University of Washington Sammie Ablaza Wills Community Organizer; Outgoing Executive Director, APIENC Willy Wilkinson M.P.H., Writer; Public Health Consultant; Cultural Competency Trainer; Author, Born on the Edge of Race and Gender: A Voice for Cultural Competency Michelle Meow Producer and Host, "The Michelle Meow Show" on KBCW/KPIX TV and Podcast; Member, Commonwealth Club Board of Governors; Twitter @msmichellemeow—Host In response to the COVID-19 pandemic, we are currently hosting all of our live programming via YouTube live stream. This program was recorded via video conference on November 16th, 2021 by the Commonwealth Club of California. Learn more about your ad choices. Visit megaphone.fm/adchoices

Alex Vilhena was born in Rio de Janeiro, but moved to Los Angeles to pursue a Bachelor's degree in Communications and had a chance to try out the startup scene in the US. Big lover of jiu-jitsu, he has over 10 years of client-facing roles under his purple belt, and helped build Santander's Loyalty Program before moving on to his own projects in the financial industry.Now CEO of Plug Pagamentos, he gets to brag about being a YC portfolio company while he and his co-founders are simplifying payment services by providing a one-stop solution to manage multiple providers through a single API integration.Building something new? Apply for the Latitud Fellowship at apply.latitud.com

Your medical records don't make pleasant bedtime reading. And not only are they inscrutable—they're often mutually (and deliberately) incompatible, meaning different hospitals and doctor's offices can't share them across institutional boundaries. Harry's guest this week, Ardy Arianpour, is trying to fix all that. He's the co-founder and CEO of Seqster, a San Diego company that's spent the last five years working on ways to pull patient data from all the places where it lives, smooth out all the formatting differences, and create a unified picture that patients themselves can understand and use.The way Ardy explains it, Seqster “smashes the data siloes.” Meaning, the company can combine EMR data, gene sequence data, wearable device data, pharmacy data, and insurance claims data all in one place. The big goal guiding Seqster, he says, is to put the patient back at the center of healthcare.Please rate and review The Harry Glorikian Show on Apple Podcasts! Here's how to do that from an iPhone, iPad, or iPod touch:1. Open the Podcasts app on your iPhone, iPad, or Mac. 2. Navigate to The Harry Glorikian Show podcast. You can find it by searching for it or selecting it from your library. Just note that you'll have to go to the series page which shows all the episodes, not just the page for a single episode.3. Scroll down to find the subhead titled "Ratings & Reviews."4. Under one of the highlighted reviews, select "Write a Review."5. Next, select a star rating at the top — you have the option of choosing between one and five stars. 6. Using the text box at the top, write a title for your review. Then, in the lower text box, write your review. Your review can be up to 300 words long.7. Once you've finished, select "Send" or "Save" in the top-right corner. 8. If you've never left a podcast review before, enter a nickname. Your nickname will be displayed next to any reviews you leave from here on out. 9. After selecting a nickname, tap OK. Your review may not be immediately visible.That's it! Thanks so much.Full TranscriptHarry Glorikian: Hello. I'm Harry Glorikian. Welcome to The Harry Glorikian Show, the interview podcast that explores how technology is changing everything we know about healthcare. Artificial intelligence. Big data. Predictive analytics. In fields like these, breakthroughs are happening way faster than most people realize. If you want to be proactive about your own health and the health of your loved ones, you'll need to learn everything you can about how medicine is changing and how you can take advantage of all the new options.Explaining this approaching world is the mission of my new book, The Future You. And it's also our theme here on the show, where we bring you conversations with the innovators, caregivers, and patient advocates who are transforming the healthcare system and working to push it in positive directions.If you've ever gotten a copy of your medical files from your doctor or hospital, you probably know these records don't make pleasant bedtime reading. They aren't designed to be clear or user-friendly for patients. In fact, it's usually just the opposite.The data itself is highly technical. And on top of that, there's the inscrutable formatting, which is dictated by whatever electronic medical record or “EMR” system your provider happens to use. But the problem isn't just that EMR data is incomprehensible.It's also that different EMRs are often incompatible with each other.So if you're being treated by multiple providers, it can be really tricky to share your data across institutional boundaries. That's why medicine is one of the last industries that still uses old-fashioned fax machines. Because sometimes a fax is the only way to send the data back and forth.But my guest today is trying to fix all that.His name is Ardy Arianpour, and he's the co-founder and CEO of Seqster.It's a company in San Diego that's spent the last five years working on ways to pull patient data from all the places where it lives, smooth out all the formatting differences, and create a unified picture that patients themselves can understand and use.The way Ardy explains it, Seqster quote-unquote “smashes the data siloes.” Meaning, the company can combine EMR data, gene sequence data, wearable device data, pharmacy data, and insurance claims data all in one place.The big goal guiding Seqster, according to Ardy, is to put the patient back at the center of healthcare.At the moment, however, consumers can't sign up for the service directly. Seqster's actual customers are players from inside the healthcare industry. For example, a life science companies might hire Seqster to help them make the experience of participating in a clinical trial more user friendly for patients.Or a health plan might use a Seqster dashboard to get patients more involved in their own care.Seqster did let me do a test run on my own medical data as part of my research for this interview. And I was impressed by how quickly it pulled in data that normally lives in a bunch of separate places. I'm hoping Seqster and other companies in this space will continue to make progress.Because, frankly, I think poor patient access to health data and the lack of interoperability between EMRs are two of the biggest factors holding back improvements in healthcare quality.If we can finally get those two things right, I think it can help unlock the data-driven healthcare revolution that I describe in my new book, The Future You. Which, by the way, is out now in paperback and ebook format at Barnes & Noble and Amazon.When we spoke back in September, Ardy and I talked about better EMRs and many other things. And now here's our conversation.Harry Glorikian: Ardy, welcome to the show. So, it's good to have you here, and you know, for everybody who doesn't know your story and the story of the company, I'd love to, you know, start covering some basics like, you know, the when, the what, the how, the why. What's the founding story of Seqster and what was the problems that you were really trying to go out there and solve when you started the company in 2016?Ardy Arianpour: Thanks so much, Harry. Always been a fan. I think we've known each other for quite some time, but it's been a long time since we've ran into each other since the genomic and precision medicine days. So great to see you. I hope you and your family are well and yeah, look, Seqster is super special and there's a secret story, I guess, that never has been told. It really starts way beyond 2016 when I founded the company. So I spent 15 plus years in DNA sequencing, next gen sequencing genomic market. And during that time in the 2000s to early 2010s, I was fortunate enough of being part of some amazing endeavors and organizations that allowed my team and I to take some risk. And when you take risk, when you're in biotech, pharma, precision medicine, genomics, bioinformatics, you learn new things that most people don't learn because you're you're you're, you know, trailblazing, I guess you could say. And we were able to do that back with one of my old companies where we were able to launch the first clinical exome test, launch the first BRCA cancer panels, launch the first next gen sequencing panels in a CLIA lab. Ardy Arianpour: And then, you know, it wasn't about the testing. It was all about the data, and we didn't realize that till later and we kept on seeing that wow genome data is really only one set of all the other data pieces, right? I think the genomics folks, me being a genomics guy, I guess you could say, for a decade and a half, we're so forward thinking that we forget about the simple things within science, and we never really thought, Oh, collect your medical data and pair it with your genomic data. We never really thought there would be a wearable out there. That data was going to be siloed, too. We never thought there was going to be, you know, many different medical devices and instruments that would be Bluetooth and sensor enabled, where there would be data that would be siloed. Claims data, pharmacy data. Never even crossed our minds. So, you know, when you put this all together, my inspiration with Seqster was actually really simple. And when I founded the company, I wanted to combine the genomic data with your EMR medical data as well as your wearable data, because in 2016, the tailwinds of those other, you know, services was really taken off.Harry Glorikian: Right. Totally understand it. And you know, as we were talking about before I hit record, it's like it was funny because I was just talking to another company that's working on NLP and they're able to look at, you know, papers and see drugs being used in different, you know, medical conditions. And then they figured out, well, they needed to tap into the unstructured data of a medical record to really, like, add the next layer of value to it. So, you know, there's a lot of activity going on about there. But how do you guys, how do you, how do your co-founders, you know, Zhang and Dana play into like the science, the technology and what's the sort of angle that you guys have taken to solve this problem? Or what's your idea on how to fix it? I'm not saying it's been solved yet, because that would be a Herculean task in and of itself. But how are you guys approaching it that? Is a little different than the. You know, maybe any any of your other you would you would consider anybody else out there, the working on this?Ardy Arianpour: Yeah, look for us we spent a lot of time understanding the power of data. But how what makes Seqster different is no one knows the power of the patient better than us. We've spent time with our platform with, you know, tens of thousands of patients: rare disease patients, oncology patients, parents, autoimmune disease patients, patients that have that are seeing functional medicine folks. Patients that were having issues sharing data through telemedicine, clinical trial patients. All these sorts of patients are very different. At Seqster we focused on putting the patient at the center of health care in order to smash all the data silos from their medical institutions to their wearable technology that they wear to the DNA testing that they get and even maybe a COVID test or a vaccine. How do you bring a 360-degree patient view? And you know, you tried the system, so I think you got a small teaser of how we can do that and we've really cracked this large problem. It is Herculean, I believe, and a lot of people believe because it's interoperability, it is the number one problem in all of health care.Harry Glorikian: Yeah, I mean, I had the pleasure of trying it and imported my data and was able to see, you know, individual pieces. I mean, I made some suggestions on what might make it easier for me to hone in in different areas, right, and have the system highlighting different things. But I guess each data stream is being brought in separately and then at some point you're going to create a master dashboard above it, because now each one is separate from when I go into each record, right, When I go into my medical record, it gives me one set of data with my lab results and everything else and the notes, and then it pulls in my wearable data separately that I have to look at, right? So you've got to look at it separately. It doesn't. Then I guess the next step would be creating a master sort of view of how everything would look in a sort of I don't want to say integrated, but at least a timeline view of the world. But. You know, following up on the the sort of the what question, you know, how do you sort of combine data from different EMRs, tests, apps, devices in a sort of scalable, repeatable way? I mean, it seems like to date, that's been a hugely manual process, and I can imagine you could figure out every provider's ontology and then create a table that shows what's equivalent to. And but you know, there's got to be sort of a translation scheme that would be required that that provides some constant readjustment as the main providers tweak and evolve their own systems, right? Because if the provider is tweaking their system, your system has then got to adapt to changes that are happening in that end. So how are you guys managing all that craziness?Ardy Arianpour: Yeah. So I think it all and you hit on so many points, I'll try and cover them if I remember them all. Look, the number one thing for us is we can connect to any data source. It doesn't matter. And you saw it. And just before I continue, just tell the audience how fast, how fast, how long did it take for your data to be populated after you connected it?Harry Glorikian: Oh, it was. I mean, yeah, as soon as I created it, I could see that it was, you know, it was digesting and then populating. And, you know, I was just I was watching it as a matter of fact, when I was on the phone with your person, that was helping me. Yeah. At first I said, Oh, it's not there. And then a couple of seconds later, I'm like, Oh no, it's showing up, right? So it was happening in, I don't want to say real time, but it was happening as as we were watching it evolve, right? It was sort of it was. It was almost like watching time lapse.Ardy Arianpour: And that's actually a great way. That's a great way to actually describe it. We created the time lapse of all your health data. Now let's get to the what and the how. So we connect to any health data source. The patient is fully in control. You own your data, you control it. It's all consented by you. We don't own your data and we connect to every single medical record. And that's huge that we've achieved nationwide coverage. We didn't know what data you have, but we're you're able to connect to it. Why? Because our team, which our engineering team gets all the credit for six years now, almost since founding of the company we have written, I don't know, seven million lines of code, that standardizes and harmonizes all of the ICD 9, ICD 10, SNOMED codes and every single lab result to every single wearable terminology, from biking to cycling to, you know, you name it, VitaminDB, you know, characterized in 40 different ways. You know, we're harnessing data to improve patient lives at scale. We built it for scale because you can't do it by the traditional method of just faxes and PDFs. Now, you know, being able to do that is not a bad thing.Ardy Arianpour: We can bring that service into our platform as well. It's already integrated, but that type of service takes 30 to 60 days and it's static data. It's not real time right now. If Harry goes, I don't know, you go on a bike ride and you fall and you go to the E.R. and you had whatever data connected automatically in your sister portal, it'll be populated without you even touching Seqster. That's how our real time data works and another way that we're totally differentiated than anything else in the marketplace. I was never a fan of API businesses because they're just data in data out. I truly wanted us to create a patient engagement platform, a PEP right, or a patient relationship management system, what I call a PRM instead of a CRM. And that's what we created with Seqster. So that is beyond an API, beyond just data. We're visualizing the data, as you saw. We really nailed the longitudinal health record or the individualized health record. And I think it's, I always say this, health data is medicine. The reason why it's medicine is because our platform has saved patient lives.Harry Glorikian: Ardy, how do you, how are you handling the free form notes, right, because I noticed that I could look at all my notes, but they weren't necessarily, it wasn't pulling from the note and sort of making sense of it. I mean, I could look at all of it and it was all in one place. But the the system wasn't necessarily processing it, sort of. I was talking to Jeff Felton from ConcertAI and they do a lot of sort of, their big thing is the NLP that sort of tries to choose chew through that, which is not trivial, you know, yesterday today, context matters in health care.Ardy Arianpour: Yeah. Look, if we created the the the Tesla of health care, let's just say, right, we're we're changing the game. From static data to real time data. Ok. Well, you're talking about is, are you going to create a helicopter as well? Right, OK. And all right. So, no, we're not going to go create the helicopter. Is there going to be an electric helicopter by Tesla? There's no market for that, right? So that's why they're not doing it now. I'm not saying there's not a market for NLP. It's just the fact that we'll go ahead and partner with a third party NLP provider. And we already have we have like four of them and they all have their strengths and weaknesses because it's not a one size fits all thing. And you know, we can already run OCR, you know, over the free text and pull certain ontology information out. And then, you know, when you partner with an NLP company, once you have a system that can capture data, you could do anything. So people always ask me, Are you going to get into AI? It's just the buzzword. There's a million A.I. companies. What have they really done right in health care? It's not really there. Maybe for imaging they've done some things, but it's more of a buzzword. AI only becomes valuable if you have a system, Harry, that can instantly populate data, then you can run some great artificial intelligence things on it. So NLP, AI, OCR, all those things are just many tools that can add. Now, in your experience, you only got to see about 5 percent of the power of Seqster, and that probably blew you away, even though it was five percent of the power. Because you probably never -- I don't know, you tell me, have you ever been able to collect your data that quickly? It took, what, less than a minute or two?Harry Glorikian: Yeah, well, thank God, I don't have a lot of data. So, you know, just when I tap into my my health care provider, you know, my data is there and it's funny, I always tell people, being a not exciting patient is a really good thing in one way, and it's a really bad thing because you can't play with all the data. But you know, like even when I did my genome, it's an extremely boring genome.Ardy Arianpour: My question is it's not about it being exciting or not, because thankfully you're not a chronically ill patients. But imagine if you were and how this helps, but take a step back. I'm just asking the speed, yes, and the quality of the presentation of the data that seeks to you. It was less than what hundred seconds?Harry Glorikian: Yeah. Well, it was very quick. And I've already it's funny because I texted my doctor and I was like, I need to talk to you about a couple of these lab results that look out of out of norm, right? And they weren't anything crazy. But I'm just curious like, you know, how do I get them in norm? I'm just I'm always trying to be in in the normal band, if I can be.Ardy Arianpour: So it's interesting you say that because as a healthy individual. You know, and even a chronically ill patient, it doesn't matter. The best way to actually QC data is through visualization, and this is what this is. That's foundational to interoperability. So we hit on semantic and structural interoperability with our, you know, backend engine that we've created to harmonize and standardize the data. We built many different types of retrievers and then we parse that data and then it's standardized and harmonizes it. But that visualization, which some people call the Tableau of health data, you know that we've created when they see it, is really, we got to give the credit to the patients. We had so many patients, healthy ones and unhealthy ones that told us exactly how they want it to look. We did this on the genomic data, we did this on the wearable data. We did this on the medical device data and we have some great new features that can superimpose your clinical data with your fitness data on our integrated view and timeline.Harry Glorikian: Oh, that? See, now that would be, you know, another level of value, even for a healthy patient, right to be able to see that in an integrated way. I made a suggestion, I think that when a panel shows up is. You know, highlight the ones that are out of Norm very quickly, as opposed to having to look at, you know, the panel of 20 to find the one that's out of whack, just either color them differently or reorient them so that they're easier to find. But those are simple changes just from a UI perspective. But so. How would you describe that that Seqster creates value and say translates that into revenue, right? I'm just trying to figure out like, what's the revenue model for you guys? I know that you're I can actually, I'm not even sure if I can sign up for it myself. I would probably have to do it through a system if I remember your revenue model correctly. But how do you guys generate revenue from what you're doing?Ardy Arianpour: Yeah, I'll share another secret on your show here from the founding of Seqster. My dream was to empower seven billion people on our little mothership here called Earth to have all their health data in one place. And I had a direct to consumer model in 2016. The market wasn't really ready for it, number one. Number two, it was going to cost $500 million worth of marketing to just get the message out for people to know that it exists. So long story short, in 2016, you know, when I founded the company, not that many people wanted to talk to us. They thought we were just like nuts to go after this problem. 2017, we got some calls from some investors, we raised some great seed funding after I personally put in some money in in 2016 to get the company going. And then in 2018, I got a call from Bill Gates and that was when everything changed. Bill called and wanted to meet in person, I was supposed to get 30 minutes with him. And the reason why he called is because our first beachhead was with Alzheimer's patients. My grandmother, both my grandmothers, passed away due to Alzheimer's disease. Both my maternal and paternal grandmothers and being a caregiver for my mom's mom and being very close to her since she raised me, I learned a lot about a multigenerational health record, so I actually filed patents in 2016 on a multigenerational health record because I wanted to have my grandma's data, my mom's data, my data, and be able to pass it on to research as well as to generations down my family.Ardy Arianpour: Long story short there, Bill gets all the credit for telling me after I showed him our platform, "You got to take this enterprise. You guys built something that Google Health failed at and Microsoft Vault Health Vault failed at." And it's funny we're talking about this. Look, Google just dismantled their health division again. Why? Because tech companies just don't get it. They have a lot of money. They have a lot of power. They've got a lot of smart people. But they they they don't know where, I'll give you an example. It's like a tourist with a lot of money coming into a city. You don't know where the really good local bar is, right? Why is that? You don't know where the really good, you know, slice of pizza is. You're going to go to the regular joints that everyone finds on TripAdvisor and whatever. You know your friends told you, but if you're a local, you know where to get the authentic cocktails and the authentic, you know, drinks and food. Why? Because you've lived and breathed it in the city. So we've lived and breathed it right. And so we know what not to do. It's not about knowing what to do in health care or in genomics or in biotech. It's actually knowing what you shouldn't be doing. Yeah.Harry Glorikian: And knowing I got to tell you, there's some problems where I'm like, OK, I know exactly who to call for that problem, because there aren't, you know, they're not falling off trees in that particular problem. There's a small handful of people that understand that problem well enough that they can come in and sort of surgically help you solve that problem. And you can have all the money in the world and have all the smart people you want. Doesn't mean they're going to be able to solve that particular problem, especially in health care, because it's so arcane.Ardy Arianpour: And it's getting, you know, this is a problem that is growing like cancer, interoperability. Just on this 20 minute conversation with you it has grown by hundreds of millions of dollars. Do you know why? Because data is being siloed.Harry Glorikian: Yeah. And I think, look, I've always I've said this on, you know, whatever show or and I've actually I've written letters to Congress. You know, I think this this needs to be mandated because expecting the large EMR companies to do anything is a waste of time. They're not going to do it on their own if their feet are not put to the fire and it changes. And honestly, I believe that if anything will stop the innovation of health care or slow it down is the EMR systems. You know, if you don't have the data, you can't do the work.Ardy Arianpour: Absolutely. But you know what people don't understand. And not to go off that tangent, but I'll get back to the business model in a second to answer that question because I just recalled in my mind here that I didn't answer that. Look, people don't understand that at least the EMR companies, even though they're like Darth Vader, you know, they needed. They've put some foundation there at least. If that wasn't there, we would be in a much worse situation here, right?Harry Glorikian: Correct, but if Satya Nadella hadn't really changed Microsoft, really redone it right, it wouldn't be the company it is now, and I think they [the EMR companies] are just back in the dark ages.Ardy Arianpour: Of course, I totally agree. I'm surprised, actually. Microsoft, as an example, didn't come up with their own EMR system and launch it to the hospitals to go, compete with the servers and all scripts and Epics of the world. If I was Microsoft, that's what I would do. I would have enough money in power, know exactly what to do. I would take a system like Seqster and I would explode it in a good way and be the good guys and have it completely open source and open network. But that's a whole cocktail conversation if anyone's listening on the on the podcast that wants to talk about that. Give me a call or shoot me an email or find me on LinkedIn.Ardy Arianpour: Let me go back to the business model real quick so people understand. So direct to consumer was what I wanted to do. We built it for the consumer, for the patients. It was the smartest and dumbest thing I ever did. Let's go to why it was the dumbest thing first, because it was really, really hard. It was the smartest because we would not be where we are today. You wouldn't have called me to talk on your podcast and all these other great, you know, amazing people that want to hear about how we're, you know, cracking the code on interoperability now and changing the health care system, changing clinical trials, changing decentralized trials with our system.Ardy Arianpour: Why? Well, it's because our system was built by patients. Right, and so it's a patient centric, real time, real world data platform that layers in engagements for both the providers, the payers, the pharma companies and any other enterprise that white labels our platform. We have both iOS and Android SDK and Web available. It gets fully branded. We're the Intel Inside with the Salesforce.com business model. It's a Software as a Service service that we offer to enterprises. Patients never pay for the service. And we do give VIP codes to chronically ill patients and VIPs, you know, journalists, podcasters and to be honest, anyone who emails me that wants to try it. I've been always giving on that. That costs us time and money, and I'm happy to do it because it's my way of giving back to the community and health care because I know our team and I have built a system that have saved lives. It's been covered by the news multiple times.Harry Glorikian: So, so in essence, a large provider comes, buys the access to the system and then offers it to its patient population to utilize to aggregate all this information, right? How can the platform stay patient centric if the patients aren't directly paying for it?Ardy Arianpour: Ok, very simple. All of these enterprises in health care, whether that's Big Pharma, right, or Big Oayer from Pfizer to Cigna, to United Healthcare group to Humana to even Amazon, right, to other tech companies, they all want to go down a patient centric way. It's just what's happening. You know, I've been talking about this since 2016 because we pioneered patient centric interoperability. That's what we did. That's what Seqster did. That's that's what we set out to do. And we did it. Some, you know, a lot of people say they can do it. Very few actually. Do we fit in that model now, right? And you had the experience yourself. And I think the first time I saw patient centric ads was. 2020. No, sorry. Yeah, 2020, JP Morgan Health Care Conference in January, just three months before the lockdowns and the pandemic started. It was the first time I went to Johnson & Johnson's afterparty in downtown San Francisco. And saw a huge banner saying, you know, blah blah blah, patient centricity. It's the 22nd century, you know, whatever. So they add a bunch of ads that were all patient centric, and I looked to my co-founder, Dana, and I'm like, Look at this, these guys finally caught on. I wonder if they've been, because we've been in discussions with a lot of these folks, long story short, it's not because of Seqster, I think it's just the market was headed that way. We were so far ahead of the market and there was no tailwinds. Now it is all there. And the pandemic afterwards accelerated digital health, as I say, by 7 to 10 years.[musical interlude]Harry Glorikian: Let's pause the conversation for a minute to talk about one small but important thing you can do, to help keep the podcast going. And that's to make it easier for other listeners discover the show by leaving a rating and a review on Apple Podcasts.All you have to do is open the Apple Podcasts app on your smartphone, search for The Harry Glorikian Show, and scroll down to the Ratings & Reviews section. Tap the stars to rate the show, and then tap the link that says Write a Review to leave your comments. It'll only take a minute, but you'll be doing us a huge favor.And one more thing. If you enjoy hearing from the kinds of innovators and entrepreneurs I talk to on the show, I know you'll like my new book, The Future You: How Artificial Intelligence Can Help You Get Healthier, Stress Less, and Live Longer.It's a friendly and accessible tour of all the ways today's information technologies are helping us diagnose diseases faster, treat them more precisely, and create personalized diet and exercise programs to prevent them in the first place.The book is out in print and ebook format from Amazon and Barnes & Noble. Just go to either site and search for The Future You by Harry Glorikian. Thanks. And now, back to the show.[musical interlude]Harry Glorikian: So the platform combines EHR, genetic, and fitness data, so. Why did you start with those three?Ardy Arianpour: So we started with those three, and I'll get to that, but we also do pharmacy, social determinants of health, and claims data as well. So we've added three other very large pillars. We can connect to any data source. We've created a universal interoperability platform that's patient centric that brings real time, real world data. And we're just super excited about all the business opportunities and the big pain points that we're solving for enterprise as well as for the patient. Why did we start with genomics, EMR, fitness. Ok. Here's the story. So I named the company Seqster after actually going on a five or six mile run in downtown San Diego, coming back and watching The Italian Job. And in the movie The Italian Job, it's one of my favorite movies, actually. I love that movie. I could just keep watching it over again, the real Napster was in the movie, and I used to be a Napster user where, you know, it was the way of actually pulling all your music and having it kind of in one place. Not really exactly Seqster's model, Seqster's model is is much more legal because it's patient centric. Yes, Napster was kind of stealing the data, right? So long story short, I was trying to think of a company name and I'm like, Oh my God. I don't know what hit me. I'll remember that moment like it was yesterday, Harry. Sequster came up because I had dived into DNA sequencing. We are doing everything that you can on next gen sequencing. And so I was like, Wow! Seqster. S-E-Q-S-T-E-R.Ardy Arianpour: And I went on GoDaddy.com. I bought it for $9.99. And the story started from right then. It was just me and the website. No co-founders, no onee else. I was just thinking, this is a great name. Now, you fast forward to why it's medical data plus genomic data, plus fitness data, to begin with. Well, the genomic data was an easy one because, right, I have 15 years underneath my belt on genomic sequencing technologies and clinical diagnostics and doing a lot of great things for patients in that arena. And I knew that it couldn't just be the genome, right? That's where the medical data came in because we knew and I never knew that we would be able to actually build something that would be able to pull it on together. I knew it was going to be really tough. I didn't think it was going to be this tough. We would have never done it if I knew that it was this tough. It's so great that we did because we solved it. But if you go back and say, "Ardy, would you do it again if you knew it was going to be this tough?" I wouldn't, because it's really, it's not the number two problem, it's the number one problem. And we're just, you know, I'm a peon. I'm a very small dot. I'm not anyone special. I'm just very passionate about solving this problem. That's it. And so is my team, and we got a great team and we've execute on. So great.Ardy Arianpour: And then, you know, it was my idea. I was forcing the wearable and fitness data because I was interested in that. And when the Apple Series One Watch came out, it was very limited, but I saw how it was going to change, you know, just connection of data. And my team being bioinformaticians and from the genomics world were so against bringing it in, I mean, I could show you emails of fights about me saying, get fitness data in here. They were not interested. I forced it on them. And then next thing you knew, clinical trials. One of the biggest things was how do you bring sleeping data and wearable data to x y z data? And that market started taking off. Decentralized trials. You can't even do it if you don't have wearable data. And so everyone started saying, you know, OK, you were right. That was one. I get one big pat on the back. And then we realized we can't be limited to just those three pillars. So what are the next three that we can work on? And that was claims data so we can marry it with the EMR and medical data for payers. And then we ran into pharmacy data. We just signed our first digital pharmacy deal three weeks ago with Paragon Health. And if we didn't have those capabilities, we wouldn't have the business opportunities. And the social determinants of health data being our last integrations comes in very handy for various different use cases.Harry Glorikian: So, three sort of things, right? You know, you combine all this data. What can you learn that wasn't obvious before? How do you translate into better health outcomes for consumers or, say, smarter decision making by consumers, right, so those are two potentially different ways to look at it.Ardy Arianpour: Absolutely. So one word for you: Seqster's longitudinal health record drives health economics, outcomes, research. It drives it.Harry Glorikian: Is that your clients doing that, you doing that, a third party group coming in?Ardy Arianpour: Yeah. We don't do that. We're just the patient engagement and data aggregation operating system that gets implemented for enterprise. And then the enterprise can run the analytics on top of it. They can, you know, take all of the raw data. So we're the only 21 CFR Part 11 compliant platform too. We're fully FDA compliant, Harry. It took us 19 months working with the FDA in order to get our compliance letter in September, October of last year, 2020. So about a year ago. And not only are we HIPAA compliance, not only are we High Trust certified and 256 bit encrypted on all the data that comes in, but having that FDA compliance sets us apart number one. Number two, because we're not an API, we have FHIR fully integrated. We have an API for sharing data, but we're not an API business. We're a SaaS business in health care, in digital health. We can make any company a digital health company. Let's say it's Coca-Cola, and they want to empower their 200,000 employees. They could launch a Coca-Cola Seqster white label in 72 hours to 200,000 employees. That's what we've created. Now, take that and imagine that now within pharma, within precision medicine, within clinical trials, within the payer network, which we're the only platform that's CMS ONC interoperability compliance from the Twenty First Century CURES Act as well.Harry Glorikian: So let me let me see if I... I'm trying to figure out like the angle, right? So I mean, ideally for interoperability, if we talk about the highest level right, you really want to get Epic, Cerner, Kaiser, et cetera, all in a room right? And get them to agree to something. Which is like an act of God.Ardy Arianpour: Some people say, we're doing, you know, it's not my words, but again, a figure of speech, people say, we're doing God's work.Harry Glorikian: But stepping back here for a second, what I see you guys doing is actually giving a platform to the patient and the patient is then connecting the record, not necessarily the systems themselves allowing for interoperability to take place.Ardy Arianpour: So yes, but you're speaking of it because of the direct to consumer experience that you had. The experience we gave you is much different than the experience from the enterprise side. We have a full BI platform built for enterprise as well. Right. And then we have the white label for the enterprise where they launch it to a million patients.Harry Glorikian: That's what, I'm trying to think about that, right? So. Coca-cola says, like, going down your example, Coca-Cola says, "Love to do this. Want to offer it to all of our employees." We make it available to them. But it's the employee that has to push the start button and say, yes, I want my electronic medical record to be integrated into this single platform, right?Ardy Arianpour: But that's that's an example with Coca-Cola. If we're doing something with Big Pharma, they're running a clinical trial for 500,000 COVID patients, as an example. They're getting data collection within one day versus two months, and guess what, we're going to be driving a new possible vaccine. Why? Because of the time it takes for data collection at scale. We empower patients to do that and they get something back. They get to track and monitor all their family health.Harry Glorikian: Right. So so it's sort of, you know, maybe I'm being dense, but sort of the same thing, right? Big Pharma makes it available to the patient. The patient then clicks, Yes, I want to do this and pull in my medical records to make it all everything to be in one place. Yes.Ardy Arianpour: Yes. And I think it's about the fact that we've created a unique data sharing environments. So that's, you know, Harry and Stacey and John and Jennifer and whoever, you know, with whatever use case can share their data and also consent is built with E-consent and digital consent is built within that process. You don't share anything you don't want to share.Harry Glorikian: Right. So let me see if I got this correct. So Seqster is providing a translation and aggregation between systems through a new layer of technology. Not creating true interoperability between systems, right?Ardy Arianpour: Yes. There's a spider web. And. We have untangled the spider beb in the United States of America. We've done all the plumbing and piping to every single health institution, doctor's office clinic, wearable sensor, medical device pharmacy, the list goes on and on, Harry.Harry Glorikian: So let's... Another question. So how does the 21st Century CURES Act of 2016 relate to your business? I think you know you've said something like Seqster has become law, but I'm trying to. I'm trying to understand, what do you mean when you say that?Ardy Arianpour: So when we founded Seqster, we didn't know there was going to be a Twenty First Century CURES Act. We didn't know there was going to be GDPR. We are GDPR compliance before GDPR even came out. Right? Because of our the way that we've structured our business, number one. Number two, how we built the platform by patients for CMS ONC interoperability, you know, final rulings and the Twenty First Century CURES Act, which is, they're synonymous. We worked hand in hand with Don Rucker's team and Seema Verma on the last administration that was doing a lot of the work. Now a wonderful gentleman, Mickey Tripathy has taken the role of ONC, and he understands, you know, the value of Seqster's technology at scale because of his background in interoperability. But what was interesting in the two years that we worked with HHS and CMS was the fact that they used Seqster as the model to build the rules. I was personally part of that, my team was personally part of that, you know, and so we were in private meetings with these folks showing our platform and they were trying to draft certain rules.Ardy Arianpour: We didn't know that they were going to be coming out with rules until they did. And then that's when high level folks in the government told us specifically on calls and also even at Datapalooza when I gave a keynote talk on on Seqster, when Don Rucker did as well right before me. You know, we're sitting in the speaker room and folks are like, "You're going to become law in a month." And this was in February of 2020. March 9th, those rules dropped. I was supposed to give a keynote talk at HL7,  at HIMMS. HIMMS got cancelled in 2020. I just got back from HIMMS 2021 in Vegas just a week and a half ago. It was fantastic. Everyone was masked up. There was only three cases of COVID with 10,000 people there. They did a great job, you know, regulating it. You had to show your vaccine card and all that good stuff. But you know, I would have never thought Seqster becomes law when we were founding the company. And so this is really special now.Harry Glorikian: So what does success look like for Seqster?Ardy Arianpour: It depends how you measure it. So we're in the Olympics. It's a great question. Here's my answer to you. We're in the Olympics just finished, right? So we started out in track and field. We were really good at running the 400 Meters and then somehow we got a use case on the 4x1 and the 4x4. And then we did really well there, too. And then because of our speed, you know, we got some strength and then they wanted us to get into the shot put and the javelin throw and then we started winning there, too. And then somehow, now people are calling us saying, "Are you interested in trying to swim?" We got the 100 meter butterfly. Well, we've never done that. So success for us is based off of use cases. And every use case that we deal with, within clinical trials and pharma, we've define 24 distinct use cases that we're generating business on. Within the payer community now, because of the CMS ONC Twenty First Century Cures Act, there's a major tailwind. Within life insurance for real time underwriting, there's, you know, a plethora of folks that are calling us for our system because of the patient engagement. So this patient centricity for us has been a central pillar, and I've never allowed anyone in our company, whether it's the board or our investors or employees, you know, get sidetracked from that. We've been laser focused on the patients and success at impacting patient lives at scale.Harry Glorikian: So as a venture guide, though, right, like I'm going to, there's only so much money on so much time to tackle, so many different opportunities, right? So it's there is a how do we create a recurring revenue stream and keep plugging along and then generate either enough revenue or raise enough money to do more? And so just trying to think through that for what you guys are trying to do, I get the 4x100 and the swimming. But all of that takes money and resources right to be able to prove out, of course.Ardy Arianpour: And here's another thing we're in a different state. Look, my team and I had a major exit before. We built a billion dollar company out of $3 million. And even though we weren't founders of that company, you know, I was the senior vice president and we we did really well. So, you know, that allowed us to not take salaries that allowed us to take our money and put it into doing something good. And we did that in 2016 to seed it. And then afterwards, I raised, you know, millions of dollars from folks that were interested in, you know, this problem and saw that our team had a track record. And I actually was not interested, Harry, in raising a Series A because of our experience, but we kept on getting calls. And then just six months ago, we announced, you know, our series a funding. Well, we actually announced it in March, I think it was, but we closed our Series A in January of this year and it was led by Takeda Pharma, Anne Wojcicki's 23andMe and United Healthcare Group's Equian folks that created Omniclaim and sold to UnitedHealth Group Omni Health Holdings.Ardy Arianpour: So check this out. Imagine my vision in 2016 of having medical data, genomic data fitness data. Well, if you look at the investors that backed us, it's pretty interesting. What I reflect on is I didn't plan that either. We got amazing genomic investors. I mean, it doesn't get better than getting Anne Wojcicki and 23andMe. Amazing female entrepreneur and, you know, just the just the force. Secondly, Takeda Pharma, a top 10 pharma company. How many digital health startups do you know within Series A that got a top 10 pharma? And then also getting some payer investors from UnitedHealth Group's Omniclaim folks and Equian OmniHealth Holdings. So this is to me, very interesting. But going to focus our focus has been pharma and clinical trials. And so Takeda has been phenomenal for us because of, you know, they they built out the platform and they built it out better for us and they knew exactly what to do with things that we didn't know. And with things that patients didn't know on the enterprise, you know, Takeda did a phenomenal job. And now other pharma companies are utilizing our platform, not just Takeda.Harry Glorikian: Yeah, well, they want their data aggregation. They want as much data on the patient aggregated in one place to make sense of it.Ardy Arianpour: So not necessarily that they actually want to empower patients with a patient centric engagement tool. That's pharma's number one thing right now, the data part, obviously is important, but empowering patient lives at scale is the key, and that's that's our mission. And so, yeah, that's that's a whole 'nother cocktail conversation when I see you soon hopefully in a couple of weeks.Harry Glorikian: Hopefully as life gets, or if it gets back to normal, depending on the variants, you know, we'll hopefully get to meet him in person and have a glass of wine or a cocktail together. So it was great to speak to you. Glad we had this time, and I look forward to, you know, hearing updates on the company and, you know, continually seeing the progress going forward.Ardy Arianpour: Thanks so much, Harry, for having me. Big fan of Moneyball, so thank you to you and your organizers for having me and Seqster on. If anyone wants to get in touch with me personally, you can find me on LinkedIn or you can follow Seqster at @Seqster. And again, thank you so much for. For having a great discussion around, you know, the the insights behind Seqster.Harry Glorikian: Excellent. Thank you.Harry Glorikian: That's it for this week's episode.  You can find past episodes of The Harry Glorikian Show and MoneyBall Medicine at my website, glorikian.com, under the tab Podcasts.Don't forget to go to Apple Podcasts to leave a rating and review for the show. You can find me on Twitter at hglorikian. And we always love it when listeners post about the show there, or on other social media. Thanks for listening, stay healthy, and be sure to tune in two weeks from now for our next interview. 

This week's episode, "The Developer-Led Landscape," features Tyler Jewell, Managing Director at Dell Technologies Capital, who shares his top trends in DevOps and views on how DevOps and DevOps landscapes differ. Jewell also sheds light on causes for the growing tech talent shortage and the increasing imbalance of demand for solutions in the API economy. 

This week's Pipeliners Podcast episode features Keith Coyle of Babst Calland returning to the podcast to discuss the timely news of PHMSA publishing the long-awaited final Gas Gathering Rule. In this episode, you will gain insights into what is contained in the final Gas Gathering Rule, including the significant legal deadlines and dates associated with the rule, the categories of gas gathering lines and their diameter limitations, what's expected of the new classification of Type C and Type R operators, and the new limitations on incidental gathering. - Access the show notes and full episode transcript at PipelinersPodcast.com.

In this episode, Damir and I take a deep dive on API design.Damir.Svrtan.meDamir Svrtan on TwitterDamir Svrtan on GitHub

AQI Air Quality Index - measures particles in the air Ozone good at high altitudes bad on the earth surface https://en.wikipedia.org/wiki/Ozone#Low_level_ozone PM2.5 Particulate Matter, 2.5 micrometers https://en.wikipedia.org/wiki/Particulates#Size,_shape_and_solubility_matter https://en.wikipedia.org/wiki/Particulates#Wildfire_smoke_risk Getting AQI data Determining air quality in my area is as simple as visiting https://www.airnow.gov and entering my zip code. Although my zip code covers 139.56 square miles, the result is accurate enough for my needs. When my zip code was submitted, the web page did not refresh. This means that the client interface made an API call to the backend server. It sure would be nice if the AQI status was emailed to my phone every hour, if the AQI was above a certain threshold. In order to get the data from the API, it is necessary to emulate the request made by the client to the API. This can be accomplished using Firefox. open Firefox go to https://www.airnow.gov open the Firefox developer tools, either through the menu or with CTRL+SHIFT+i in the dev tools, select the Network tab enter the zip code in the form and submit watch the Network tab for a POST request to https://airnowgovapi.com/reportingarea/get click on the request in the network tab Another set of tabs are now available to display various bits of information regarding the request. From this data, it is possible to recreate the query. However, I took an even easier route, and right-clicked on the query in the Network tab, and selected Copy > Copy as cURL to get the request as a curl command complete with all necessary arguments prefilled. Since I didn't want to write my entire AQI fetching script in bash, I copied the curl command into a text file and ported the request to Ruby. The Finished Script #!/usr/bin/env ruby require 'net/http' require 'uri' require 'json' uri ="https://airnowgovapi.com/reportingarea/get" parsed_uri = URI.parse(uri) payload={latitude:39.88,longitude:-120.76,stateCode:'CA',maxDistance:50} response = Net::HTTP.post_form(parsed_uri, payload) data = JSON.parse(response.body)[0] aqi=data["aqi"].to_i category=data['category'] parameter=data['parameter'] output= "#{parameter}: #{aqi} - #{category}" puts output /opt/textjezra "#{output}"` if aqi > 70

This is a throwback episode that was recorded with Murad Mahmudov that was recorded on October 31, 2008. It was only the 25th episode we had created for the podcast. In the conversation, Murad explains why he is so bullish on bitcoin, including the path to bitcoin reaching $10 million per coin. Enjoy!  ======================= BlockFi provides financial products for crypto investors. Products include high-yield interest accounts, USD loans, and no fee trading. To start earning today visit: http://www.blockfi.com/Pomp ======================= Choice is a new self-directed IRA product that I'm really excited about. If you are listening to this, you are likely part of the 7.1 million bitcoin owners who have retirement accounts with dollars in them, but not bitcoin. I was in that situation too. Now you can actually buy real Bitcoin in your retirement account. I'm talking about owning your private keys and using tax-advantaged dollars to do it too. Absolute game changer. https://www.retirewithchoice.com/pomp ======================= Circle is a global financial technology firm that enables businesses of all sizes to harness the power of stablecoins and public blockchains for payments, commerce and financial applications worldwide. Circle is also a principal developer of USD Coin (USDC), the fastest growing, fully reserved and regulated dollar stablecoin in the world. The free Circle Account and suite of platform API services bridge the gap between traditional payments and crypto for trading, DeFi, and NFT marketplaces. Create seamless, user-friendly, mainstream customer experiences with crypto-native infrastructure under the hood with Circle. Learn more at circle.com.

This episode focuses on API calls and the entitlements that Microsoft expects customers to follow based on their licenses. Gustaf Westerlund joins me to share everything you need to know about API calls. P.S. If you are On-Prem this show is not for you. :)

Juanma Gironella, Guros: Reshaping The Latin American Insurance Industry, Ep 156   The traditional insurance experience in Latin America is an inefficient, non tech process. Most people don't want to buy it but know they have to. At the same time, customer expectations of instant digital transactions sustained seamlessly across digital channels are increasingly the norm. This is exactly what Juanma Gironella is providing with Guros, the operating system for insurance in Latin America.    After working in financial services consulting, Juanma decided to build digital tools to help bring the insurance industry into the digital age.    In this episode, I sat down with Juanma to discuss how Guros is making inroads into the insurance industry and gaining market share with a digital model that is democratizing access to insurance and bringing new opportunities to innovate, improve customer experience, and ultimately, driving growth.   Improving the insurance experience Juanma contrasts the experience of comparing and purchasing auto insurance in Guros as easy as booking a flight or a hotel online. But the innovation opportunities do not stop there: on top of offering a better buying experience, what sets Guros apart is the fact that they provide value to the customers after purchase with new products, like a wallet that allows users to have multiple insurance products, and an API integration for fintech companies. This integration works like an embedded marketplace, enabling fintech companies to rapidly deploy integration into their app and allowing users to self-serve with a few clicks.   Learn more about how Guros is helping customers and fintech partners in this episode of Crossing Borders.   The insurance opportunity in Mexico and Latin America Guros is building their business model by addressing the pain points customers experience in their relationships with incumbent insurers. Of the $240 billion a year industry in Latin America, no player has over 5% of the market, which reflects that the (poor) value proposition essentially is pretty much the same in the entire region.   Check out this episode of Crossing Borders to learn more about this massive opportunity in Latam and why Guros is already thinking of other verticals.   Fundraising during Covid times Juanma's first fundraising experience was with Guros during the Covid pandemic. He explains that finding the right partners and bringing in the right people is key to getting the insights that allow things to start happening at a faster pace.    Learn more about Juanma's fundraising journey with Guros, and how it is to have never met in person over 95% of his team in this episode of Crossing Borders.   In Mexico and other relevant Latin American markets, insurance in general, and especially auto insurance, are radically fragmented markets. Consumers have to go through a painful experience when signing up for and purchasing insurance, and even after purchasing, it's hard to get value from the insurer provider. Guros is leading the change to disrupt innovation in the insurance industry. Outline of this episode: [03:01] - About Guros [03:44] - Before and after for insurance retail users [08:20] - Doing partnerships with potential partners [14:51] - From the idea to real traction [18:27] - Insurance opportunities in Mexico and Latin America [21:47] - The growth opportunity in the insurance industry [25:00] - The fundraising experience during the pandemic [28:20] - Resources and recommendations [29:49] - Advice to Juanma's younger self   Resources & people mentioned: Juanma Gironella Guros Growth Series by Reforge Training courses at ​​ConversionXL First Round Review Mexico Investment %of GDP "Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time." ― Thomas Alva Edison “What the mind can conceive and believe, and the heart desire, you can achieve.” ― Norman Vincent Peale This episode of Crossing Borders is brought to you by AWS Startups. AWS Startups supports entrepreneurs in Latin America across multiple programs, including Cloud Credits to help startups test features and extend runway, technical support to help optimize AWS solutions and integrations with your product, and – on the business side – help you build strategic contacts with investment funds, accelerators, and corporations to accelerate your growth. For more information, check out aws.amazon.com/es/campaigns/founders, where you can access $1,350 in AWS credits for your startup.

Mayo's new laptop has arrived but he's not quite ready to talk about it yet. Apple surprises everyone with the announcement of a new self-service repair program coming next year. Apple follows up on macro mode for iPhone 13 with much-welcomed refinements in iOS 15.2. And Twitter wants Services revenue, but also opens the floodgates for third-party clients to exist and — possibly — thrive. Sponsored by Overland: So don't wait another day to slip into something way more comfortable. Get the best, highest-quality sheepskin slippers on the market at Overland.com/HAPPYHOUR. You'll get free shipping and free returns. Sponsored by Headspace: You deserve to feel happier, and Headspace is meditation made simple. Go to Headspace.com/MAC for a one-month free trial. Sponsored by BetterHelp: As a listener, you'll get 10% off your first month by visiting our sponsor at BetterHelp.com/MacHappyHour. Follow Zac Hall @apollozac Benjamin Mayo @bzamayo Read More iOS 15.2 beta no longer disables Face ID on iPhone 13 after screen replacement Apple releases iOS 15.1.1 with fixes for dropped calls on iPhone 12 and 13 You can now search within Apple Music playlists in iOS 15.2 Apple launches ‘Self Service Repair,' allowing you to do your own iPhone screen repairs and more Apple Music app arrives on LG smart TVs Apple developing new ‘SportsKit' framework as it invests in sports content for Apple TV What's new in iOS 15.2 beta 3? Macro mode tweaks, Apple Arcade, more Tweetbot for iOS adds support for limiting replies to tweets, creating polls WhatsApp developing universal macOS and iPadOS app with Catalyst Safari Technology Preview updated with 120Hz scrolling support on new MacBook Pro Twitter makes its new API default for developers; Top Articles now available on iOS Amazon releases native Prime Video app for macOS with purchase support and more Listen to more Happy Hour Episodes Subscribe Apple Podcasts Overcast Spotify Listen to more 9to5 Podcasts Stacktrace Apple @ Work Alphabet Scoop Electrek The Buzz Podcast Space Explored Rapid Unscheduled Discussions Enjoy the podcast? Shop Apple at Amazon to support 9to5Mac Happy Hour!

Apple će vam rado prodati alat, rezervne delove i dati uputstva kako da ih sami zamenite. Apple Self Repair program je koji kreće početkom sledeće godine i omogućiće vam da sami servisirate svoj iPhone (12 i 13 za sada). Očekuje se da mu se priključe i drugi uređaji, za sada će biti dostupni samo ekran, baterija i kamera, jer su to, kako Apple kaže, delovi koji se najčešće menjaju. Sva je prilika da Apple želi da iPhone duže traje, kako biste što duže neometano plaćali njihove servise, čak i ako ste malo ili srednje preduzeće. Apple Business Essentials nudiće mogućnost upravljanja Appleovim uređajima u kompaniji, ako kompanija ima manje od 500 zaposlenih. Kad smo kod plaćanja, sud je naložio da nema čekanja, Apple mora podići zabranu za alternativne sisteme naplate u App Storeu do 9. decembra. Izašao je Samsungov OneUI 4 na Androidu 12, imali smo sreće da imamo S21, pa smo probali i prenosimo prve utiske. Twitter je uveo novi paket pretplate, ali i novi API za koji se očekuje da ga vrati na staze stare slave kada je otvorenost platforme u pitanju. Na marginama ove epizode DoorDash kupio Wolt za 8,1 milijadru dolara, a problem koji Huawei ima ne zove se Donald Trump, nego Sjedinjene Američke Države. Hvala na slušanju! Pratite Tehnopolis podcast RSS: https://www.b92.net/podcast/tehnopolis/feed/ Apple Podcasts: https://podcasts.apple.com/podcast/tehnopolis/id1185520336?mt=2 Google Podcasts: https://bit.ly/32Y1mlO Aleksandar Miladinović https://twitter.com/alexmiladinovic Ivan Jelić https://twitter.com/escapetofreedom https://mastodon.social/@escapetofreedom

About Micheal BenedictMicheal Benedict leads Engineering Productivity at Pinterest. He and his team focus on developer experience, building tools and platforms for over a thousand engineers to effectively code, build, deploy and operate workloads on the cloud. Mr. Benedict has also built Infrastructure and Cloud Governance programs at Pinterest and previously, at Twitter -- focussed on managing cloud vendor relationships, infrastructure budget management, cloud migration, capacity forecasting and planning and cloud cost attribution (chargeback). Links: Pinterest: https://www.pinterest.com Twitter: https://twitter.com/micheal LinkedIn: https://www.linkedin.com/in/michealb/ 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: You know how git works right?Announcer: Sorta, kinda, not really Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Sometimes when I have conversations with guests here, we run long. Really long. And then we wind up deciding it was such a good conversation, and there's still so much more to say that we schedule a follow-up, and that's what happened today. Please welcome back Micheal Benedict, who is, as of the last time we spoke and presumably still now, the head of engineering productivity at Pinterest. Micheal, how are you?Micheal: I'm doing great, and thanks for that introduction, Corey. Thankfully, yes, I am still the head of engineering productivity; I'm really glad to speak more about it today.Corey: The last time that we spoke, we went up one side and down the other of large-scale environments running on AWS and billing aspects thereof, et cetera, et cetera. I want to stay away from that this time and instead focus on the rest of engineering productivity, which is always an interesting and possibly loaded term. So, what is productivity engineering? It sounds almost like it's an internal dev tools team, or is it something more?Micheal: Well, thanks for asking because I get this question asked a lot of times. So, for one, our primary job is to enable every developer, at least at our company, to do their best work. And we want to do this by providing them a fast, safe, and a reliable path to take any idea into production without ever worrying about the infrastructure. As you clearly know, learning anything about how AWS works—or any public cloud provider works—is a ton of investment, and we do want our product engineers, our mobile engineers, and all the other folks to be focused on delivering amazing experiences to our Pinners. So, we could be doing some of the hard work in providing those abstractions for them in such way, and taking away the pain of managing infrastructure.Corey: The challenge, of course, that I've seen is that a lot of companies take the approach of, “Ah. We're going to make AWS available to all of our engineers in it's raw, unfiltered form.” And that lasts until the first bill shows up. And then it's, “Okay. We're going to start building some guardrails around that.” Which makes a lot of sense. There then tends to be a move towards internal platforms that effectively wrap cloud services.And for a while now, I've been generally down on the concept and publicly so in the general sense. That said, what I say that applies as a best practice or something that most people should consider does tend to fall apart when we talk about specific use cases. You folks are an extremely large environment; how do you view it? First off, do you do internal platforms like that? And secondly, would you recommend that other companies do the same thing?Micheal: I think that's such a great question because every company evolves with its own pace of development. And I wouldn't say Pinterest by itself had a developer productivity or an engineering productivity organization from the get-go. I think this happens when you start realizing that your core engineers who are working on product are now spending a certain fraction of time—which starts ballooning pretty fast—in managing the underlying systems and the infrastructure. And at that point in time, it's probably a good question to ask, how can I reduce the friction in those people's lives such that they could be focused more on the product. And, kind of, centralize or provide some sort of common abstractions through a central team which can take away all that pain.So, that is generally a good guiding principle to think about when your engineers are spending at least 30% of their time on operating the systems rather than building capabilities, that's probably a good time to revisit and see whether a central team would make sense to take away some of that. And just simple examples, right? This includes upgrading OS on your EC2 machines, or just trying to make sure you're patching all the right versions on your next big Kubernetes cluster you're running for serving x number of users. The moment you start seeing that, you want to start thinking about, if there is a central team who could take away that pain, what are the things they could be investing on to help up-level every other engineer within your organization. And I think that's one of the best ways to be thinking about it.And it was also a guiding principle for us within Pinterest to view what investments we could make in these central teams which can up-level each and every different type of engineer in the company as well. And just an example on that could be your mobile engineer would have very different expectations from your backend engineer who was working on certain aspects of code in your product. And it is truly important to understand where you want to centralize capabilities, which both these types of engineers could use, or you want to divest and have unique capabilities where it's going to make them productive. There's no one-size-fits-all solution for this, but I'm happy to talk about what we have at Pinterest, which has been reasonably working well. But I do think there's a lot more improvements we could be doing.Corey: Yeah, but let's also be clear that, as you've mentioned, you are heavily biased towards EC2 instances for a lot of what you do. If we look at the AWS console and we see hundreds of different services now, and it's easy to sit here and say, “Oh, internal platforms are terrible because all of those services are going to be enhanced in various ways and you're never going to be able to keep up with feature parity.” Yeah, but if you can wrap something like EC2 in an internal platform wrapper, that begins to be a different story because sure, someone's going to go and try something new with a different AWS service, they're going to need direct access. But the EC2 product across the board generally does not evolve in leaps and bounds with transformative changes overnight. Let's also not forget that at a company with the scale that Pinterest operates at, “Hey, AWS just dusted off a new feature and docs are still rolling out, and it's not in CloudFormation yet, but we're going to roll it out to production,” probably seems like the wrong direction to go in, I would assume.Micheal: And yes, I think that brings one of the key guardrails, I think, which these groups provide. So, when we start thinking about what teams, centralized teams like engineering productivity, developer tools, developer platforms actually do is they help with a couple of things. The top three are: they can help pave a path for the most common use cases. Like to your point, provisioning EC2 does take a set of steps, all the time. If you're going to have a thousand people doing that every time they're building a new service or trying to expand capacity playing with their launch templates, those are things you can start streamlining and making it simple by some wrapper because you want to address those 80% use cases which are usually common, and you can have a wrapper or could just automate that. And that's one of the key things: can you provide a paved path for those use cases?The second thing is, can you do that by having the right guardrails in place? How often have you heard the story that, “I just clicked a button and that now spun up, like, a thousand-plus instances.” And now you have to juggle between trying to stop them or do something about it.Corey: Back in 2013, you folks were still focusing on this fair bit. I remember because Jeremy Carroll, who I believe was your first SRE there once upon a time, wound up doing a whole series of talks around how Pinterest approached doing an AMI Factory. And back in those days, the challenges were, “Okay. We have the baseline AMI, and that's great, but we also want to do deployments of things and we don't really want to do a new deploy of an entire fleet of EC2 instances for a single line of config change, so how do we wind up weighing off of when you bake a new AMI versus when you just change something that has—in what is deployed to them?” And it was really a complicated problem back then.I'm not convinced it's not still a complicated problem, but the answers are a lot more cohesive. And making sure that every team—when you're talking about a company as large as Pinterest with that many teams—is doing things in the same way, seems like it's critically important otherwise you wind up with a whole bunch of unique-looking instances that each have to be managed by hand as opposed to something that can be reasoned around collectively.Micheal: Yep. And that last part you mentioned is extremely crucial as well because like I said, our audience or our customers are just not the engineers; we do work with our product managers and business partners as well because at times, we have to tie or change our architecture based on certain cost optimizations which would make sense, like you just articulated. We don't want to have all the instance types. It does not add much value to a developer unless they're explicitly seeking a high-memory instance or a [GP-based instance in a 00:10:25] certain way. So, we can then work with our business partners to make sure that we're committing to only a certain type of instances, and how we can abstract our tools to only give you that. For example, our deployment system, Teletraan which is an open-source system, actually condenses down all these instance types to a couple of categories like high-compute, high-memory—and you've probably seen that in many of the new cloud providers as well—so people don't have to learn or know the underlying instance type.When we moved from c3 to c5, it was just called as a high-compute system, so the next time someone provisioned a new service or deployed it using our system, they would just select high-compute as the de facto instance type and we would just automatically provision a C5 for them. So, that just reduces the extra complexity or the cognitive overhead individuals would have to go through in learning each instance type, what is the base AMI that comes on it, what are the different configurations that need to go in terms of setting up your AZ-scaling properties. We give them a good reasonable set of defaults to get started with, and then they can then work on optimizing or making changes to it.Corey: Ignoring entirely your mispronunciation of AMI, which is, of course, three syllables—and that is a petty hill upon which I will die—it occurs to me the more I work with AWS in various ways, the easier it gets. And I used to think in some respects, it was because the platform was so—it was improving so dramatically around me. But no, in many cases, it's because the first time you write some CloudFormation by hand, it's a nightmare and you keep smacking into weird issues. But the second or third time, it's super easy because you just copy the thing you've already built and change the relevant bits around. And that was the learning curve that I went through playing around with a lot of these things.When you start looking at this from a large-scale environment where it's not just about upskilling the people that you have to understand how these things integrate in AWS land, but also the consistent onboarding of engineers at a fairly progressive clip is, great, you effectively have to start doing trainings on all these things, and there's a lot of knobs and dials that can blow up and hurt people. At some point, building the guardrails or building the environment in which you are getting all the stuff abstracted away from where the application engineers have to think about this at all, it eventually reaches a tipping point where it starts to feel like it's no longer optional if you want to continue growing as a company because you don't have the luxury of spending six months of onboarding before you let someone touch the thing they were hired to build.Micheal: And you will see that many companies very often have very similar programming practices like you just described. Even I learned that the same way: you have a base template, you just copy-paste it and start from there on. And no one goes through the bootstrapping process manually anymore; you want to—I think we call it cargo-culting, but in general, just get something to bootstrap and start from there. But one of the things we learned in sort of the hard way is that can also lead to, kind of, you pushing, you know, not great practices because people don't know what is a blessed version of a good template or what actually would make sense. So, some of those things, we have been working on.And this is where centralized teams like engineering productivity are really helpful is we provide you with the blessed or the canonical way to do certain things. Case in point example is a CI/CD pipeline or delivery of software services. We have invested enough in experimenting on what works with some of the more nuanced use cases at Pinterest, in helping generate, sort of, a canonical version which would cover 80% of the use cases. Someone could just go and try to build a service and they could just use the same canonical pipeline without learning much or making changes to it. This also reduces that cargo-culting nature which I called, rather than copying it from unknown sources and trying to like—again, it may cause havoc to our systems, so we can avoid a lot of that because of these practices.Corey: So, let's step a little bit beyond AWS—I know I hate doing it, too—but I'm going to assume that your remit is broader than, oh, AWS whisperer-slash-Wrangler. So, tell me a little bit more about what it is that your day-to-day looks like if there is anything that could be said not to focus purely around AWS whispering.Micheal: So, one of the challenges—and I want to talk about this a bit more—is our environments have become extremely complex over time. And it's the nature of, like, rising entropy. Like, we've just noticed that there's two things: we have a diverse set of customer base, and these include everyone trying to do different workloads or work service types. What that essentially translates into is that we realized that our solution may not fit all of them. For example, what works for a machine-learning engineer in terms of iterating on building a model and delivering a model is not the same as someone working on a long-running service and trying to deploy that. The same would apply for someone trying to operate a Kafka system.And that has made, I think, definitely our job a bit challenging in trying to assess where do you actually draw the line on the abstraction? What is the right layer of abstraction across your local development experience, across when you move over to staging your code in a PR model and getting feedback and subsequently actually releasing it to production? Because this changes dramatically based on what is the workload type you're working on. And we feel like that has been one of the biggest challenges where I know I spent my day-to-day and my team does too, in trying to help provide some of the right solutions for these individuals. There's—very often we'll also get asked from individuals trying to do a very nuanced thing.Of late, we have been talking about thinking about how you operate functions, like provide Functions as a Service within the company? It just put us in a difficult spot at times because we have to ask the hard question, “Is this required?” I know the industry is doing it; it's definitely there. I personally believe, yes, it could be a future, but is that absolutely important? Is that going to benefit Pinterest in any formal way if we invest on some core abstractions?And those are difficult conversations to have because we have exciting engineers coming in trying to do amazing things; it puts us in a hard spot, as well, as to sometimes saying graciously, no. I know many companies deal with it when they have these centralized teams, but I think it's part of that job. Like when you say it's day-to-day, I would say I'm probably saying no a couple of times in that day.Corey: Let's pretend for the sake of argument that I am, tomorrow morning, starting another company—Twitter for Pets—and over the next ten years, it grows to be larger than Pinterest in terms of infrastructure, probably not revenue because it turns out pets are not the lucrative source of ad revenue that I was hoping it would be but, you know, directionally the same thing. It seems to me that building out this sort of function with this sort of approach to things is dramatically early as far as optimizations go when it's just me puttering around on something. I'm always cognizant of the wrong people taking the wrong message when we're talking about things that happen like this at scale. When does having an engineering productivity group begin to make sense?Micheal: I mentioned this earlier; like, yeah, there is definitely not a right answer, but we can start small. For example, this group actually started more as a delivery team. You know, when we started, we realized that we had different ways of deploying services or software at Pinterest, so we first gathered together to figure out, okay, what are the different ways and can we start simplifying that part? And that's where it started expanding. Okay, we are doing button-based deployments right now we have thousand-plus microservices, and we are seeing more incidents than we wanted to because anything where there's a human involved means there's a potential gap for error. I myself was involved in a SEV 0 incident, and I will be honest; we ended up deploying a Hello World application in one of our production fleet. Not the thing I wanted to be associated with my name, but, you know—Corey: And you were suddenly saying hello to the world, in fact—Micheal: [laugh].Corey: —and oops-a-doozy.Micheal: Yeah. So—and that really prompted us to rethink how we need to enable guardrails to do safe production rollouts. And that's how those conversations start ballooning out.Corey: And the healthy correct way. We've all broken production in various ways, and it's—you correctly are identifying, I believe, the direction you're heading in where this is a process problem and a tooling problem; it is not that you are secretly crap and should never have been allowed near anything in production. I mean, that's my excuse for me, but in your case, this is a common thing where it's, if someone can unintentionally cause issues like that, there needs to be better processes and procedures as the organization matures.Micheal: Yep. And that's kind of like always the route or the starting point for these discussions. And it starts growing from there on because, okay, you've helped improve the deploy process but now we're seeing insane amount of slowness, say on the build processes, or even post-deploy, there's, like, issues on how we monitor and look into data.And that I think forces these conversations, okay, where do we have these bespoke tools available? What are people doing today? And you have to ask those hard questions, like what can we actually remove from here? The goal is not to introduce yet another new system. Many a times, to be honest bash just gets the job done. [laugh].Personally, I'm okay with that as long as it's consistent and people, you know, are able to contribute to it and you have good practices in validating it, if it works, we should go for it rather than introducing yet another YAML [laugh] and some of that other aspects of doing that work. And that's what we encourage as well. That's how I think a lot of this starts connecting together in terms of, okay, now this is becoming a productivity group; they're focused on certain challenges where investing probably one person here may up-level a few other engineers who don't have to do that on a day-to-day basis. And I think that's one of the key items for, especially, folks who are running mid-sized companies to realize and start investing in these type of teams to really up-level, sort of, the rest of the engineering.Corey: You've been doing this for a fair while. If you were to go back and start over again on day one—which is always a terrifying question, on some level—what would you have done differently about building out this function as Pinterest continued to scale out?Micheal: Well, first, I must acknowledge that this was just not me, and there's, like, ton of people involved in helping make this happen.Corey: No, that's fair. We'll blame them for the missteps; that is—Micheal: [laugh].Corey: —just fine with me. I kid. I kid.Micheal: I think, definitely the nuances. If I look back, all the decisions that were made then at that point in time, there was a decision made to move to Phabricator, which was back then a great open-source code management system where with the current information at that point in time. And I'm not—I think it's very hard to always look back and say, “Oh, we could have chosen x at one point in time.” And I think in reality, that's how engineering organizations always evolve, that you have to make do with the information you have right now to make a decision that works for you over a couple of years.And I'll give you a small example of this. There was a time when Pinterest was actually on GitHub Enterprise—this was like circa 2013, I would say—and it really served as well for, like, five-plus years. Only then at certain point, we realized that it's hard to hire PHP engineers to support a tool like that, and we had to rethink what is the ROI and the investments we've made here? Can we ever map up or match back to one of the offerings in the industry today? And that's when you make decisions that, okay, at this point in time, it's clear that business continuity talks, you know, and it's hard to operate a system, which is, at this moment not supported, and then you make a call about making a shift or moving.And I think that's the key item. I don't think there's anything dramatically I would have changed since the start. Perhaps definitely investing a bit more individuals into the group and going from there. But that said, I'm really, sort of, at least proud of the fact that usually these teams are extremely lean and small, and they always have an outsized impact, especially when they're working with other engineers, other [opinionated 00:22:13] engineers for what it's worth.This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: Most folks show up intending to do good today, and you make the best decision at the time with the context and constraints that you have, but my question I think is less around, “Well, what were the biggest mistakes you made?” But more to do with the idea of, based upon what you've learned and as you have shown—as you've shined light on these dark areas, as you have been exploring it, has anything jumped out at you that is, “Oh, yeah. Now, that I know—if I had known then what I know now, I would definitely have made this other decision.” Ideally, something that applies a little more globally than specific within Pinterest, just because the whole idea, aspirationally, is that people might learn something from our conversation. At least I will, if nothing else.Micheal: No, I think that's a great question. And I think the three things that jump to me, top of mind. I think technology is means to an end unless it gives you a competitive edge. And it's really hard to figure out at what point in time what technology and why we adopted it, it's going to make the biggest difference. Humans always tend to have a bias towards aligning towards where we want to go. So, that's the first one in my mind.The second one is, and we spoke about this last time, embrace your cloud provider as much as possible. You'd want to avoid taking on operational burden which is not going to add value to the business. If there is something you see your operating which can be offloaded—because your provider can, trust me, do a way better job than you or your team of few can ever do—embrace that as soon as possible. It's better that way because then it frees up your time to focus on the most important thing, which I've realized over time is—I really think teams like ours are actually—we're probably the most value as a glue to all the different experiences a software engineer would go through as part of their SDLC lifecycle.If we can simplify someone's life by giving them a clear view as to where their commit or the work is in this grand scheme of rolling out and giving them the right amount of data to take action when something goes wrong, trust me, they will love you for what you're doing because you're saving them ton of time. Many times, we don't realize that when we publish 11 different ways for you to go and check to just get your basic validation of work done. We tend to so much focus on the technological aspect of what the tool does, rather than the experience of it, and I've realized, if you can bridge the experience, especially for teams like ours, people really don't even need to know whether you're running Kubernetes or any of those solutions behind the scenes. And I think that's one of the biggest takeaways I have.Corey: I want to double down on something you said about the fact that you are not going to be able to run these services as effectively as your provider can. And relatively recently—in fact, since the first time we spoke—AWS has released a investment report in Virginia. And from 2011 through 2020, they have invested in building AWS data centers there, $35 billion. I promise almost no company that employs people listening to this that are not themselves a cloud provider is going to make that kind of investment in running these things themselves.Now, do cloud providers have sharp edges? Yes, absolutely. That is what my entire career is about, unfortunately. But you're not going to do a better job of running things more sustainably, more reliably, et cetera, et cetera. But there are other problems with this—and that's what I want to start exploring here—where in the olden days, when I ran things in data centers and they went down a lot more as a result, sometimes when there were outages, I would have the CEO of the company just standing there nervous worrying over my shoulder as I frantically typed to fix things.Spoiler: my typing accuracy did not improve by having someone looming over me. Now, when there's an outage that your cloud provider takes, in many cases the thing that you are doing to fix it is reloading the status page and waiting for an update because it is completely out of your hands. Is that something that you've had to encounter? Because you can push buttons and turn dials when things are broken and you control it, but in an AWS—or other cloud provider—outage, all you can really do is wait unless you have a DR plan that is large-scale and effective enough that you won't feel foolish or have wasted a huge amount of time and energy migrating off and then—because then it gets repaired in ten minutes. How do you approach that, from your perspective? I guess, the expectation management piece?Micheal: It's definitely I know something which keeps a lot of folks within infrastructure up at night because, like you just said, at times we can feel extremely powerless when we obviously don't have direct control—or visibility at times, as well—on what's happening. One of the things we have realized over time as part of running on our cloud provider for over a decade now, it forces us to rethink a bit on our priority workflows, what we want our Pinners to always have access to, what they need to see, what is not important or critical. Because it puts into perspective, even for the infrastructure teams, is to what is the most important thing we should always have it available and running, what is okay to be in a degraded state, until what time, right? So, it actually forces us to define SLOs and availability criteria within the team where we can broadcast that to the larger audience including the executives. So, none of this comes as a surprise at that point.I mean, it's not the answer, probably, you're looking for because is there's nothing we can do except set expectations clearly on what we can do and how when you think about the business when these things do happen. So, I know people may have I have a different view on this; I'm definitely curious to hear as well, but I know at Pinterest at least we have converged on our priority workflows. When something goes out, how do we jump in to provide a degraded experience? We have very clear run books to do that, and especially when it's a SEV 0, we do have clear processes in place on how often we need to update our entire company on where things are. And especially this is where your partnership with the cloud provider is going to be a big, big boon because you really want to know or have visibility, at the minimum some predictability on when things can get resolved, and how you want to work with them on some creative solutions. This is outside the DR strategy, obviously; you should still be focused on a DR strategy, but these are just simple things we've learned over time on how to just make it predictable for individuals within the company, so not everyone is freaking out.Corey: Yeah, from my perspective, I think the big things that I found that have worked, in my experience—mostly by getting them wrong the first time—is explain that someone else running the infrastructure when they take an outage; there's not much we can do. And no, it's not the sort of thing where picking up the phone and screaming at someone is going to help us, is the sort of thing that is best to communicate to executive stakeholders when things are running well, not in the middle of that incident.Then when things break, it's one of those, “Great, you're an exec. You know what your job is? Literally anything other than standing in the middle of the engineering floor, making everyone freak out even more. We'll have a discussion later about what the contributing factors were when you demand that we fire someone because of an outage. Then we're going to have a long and hard talk about what kind of culture you're trying to build here again?” But there are no perfect answers here.It's easy to sit here in the silver light of day with things working correctly and say, “Oh, yeah. This is how outages should be handled.” But then when it goes down, we're all basically an inch away at best from running around with our hair on fire, screaming, “Fix it, fix it, fix it, fix it, now.” And I am empathetic to that. There's a reason but I fix AWS bills for a living, and one of those big reasons is that it's a strictly business-hours problem and I don't have to run production infrastructure that faces anything that people care about, which is kind of amazing and freeing for someone who spent too many years on call.Micheal: Absolutely. And one of the things is that this is not only with the cloud provider, I think in today's nature of how our businesses are set up, there's probably tons of other APIs you are using or you're working with you may not be aware of. And we ended up finding that the hard way as well. There were a certain set of APIs or services we were using in the critical path which we were not aware of. When these outages happen, that's when you find that out.So, you're not only beholden to your provider at that point in time; you have to have those SLO expectations set with your other SaaS providers as well, other folks you're working with. Because I don't think that's going to change; it's probably only going to get complicated with all the different types of tools you're using. And then that's a trade-off you need to really think about. An example here is just like—you know, like I said, we moved in the past from GitHub to Phabricator—I didn't close the loop on that because we're moving back to GitHub right now [laugh] and that's one of the key projects I'm working with. Yeah, it's circle of life.But the thing is, we did a very strong evaluation here because we felt like, “Okay, there's a probability that GitHub can go down and that means people will be not productive for that couple of hours. What do we do then?” And we had to put a plan together to how we can mitigate that part and really build that confidence with the engineering teams, internally. And it's not the best solution out there; the other solution was just run our own, but how is that going to make any other difference because we do have libraries being pulled out of GitHub and so many other aspects of our systems which are unknowingly dependent on it anyways. So, you have to still mitigate those issues at some point in your entire SDLC process.So, that was just one example I shared, but it's not always on the cloud provider; I think there are just many aspects of—at least today how businesses are run, you're dependent; you have critical dependencies, probably, on some SaaS provider you haven't really vetted or evaluated. You will find out when they go down.Corey: So, I don't think I've told this story before, but before I started this place, I was doing a fair bit of consulting work for other companies. And I was doing a project at Pinterest years ago. And this was one of the best things I've ever experienced at a company site, let alone a client site, where I was there early in the morning, eight o'clock or so, so you know, engineers love to show up at the crack of 11:30. But so I was working a little early; it was great. And suddenly my SSH session that I was using to remote into something or other hung.And it's tap up, tap enter a couple of times, tap it a couple more. It was hung hard. “What's the—” and then someone gently taps me on the shoulder. So, I take the headphones off. It was someone from corporate IT was coming around saying, “Hey, there's a slight problem with our corporate firewall that we're fixing. Here's a MiFi device just for you that you can tether to get back online and get worked on until the firewall gets back.”And it was incredible, just the level of just being on top of things, and the focus on keeping the people who were building things and doing expensive engineering work that was awesome—and also me—productive during that time frame was just something I hadn't really seen before. It really made me think about the value of where do you remove bottlenecks from people getting their jobs done? It was—it remains one of the most impressive things I've seen.Micheal: That is great. And as you were telling me that I did look up our [laugh] internal system to see whether a user called Corey Quinn existed, and I should confirm this with you. I do see entries over here, a couple of commits, but this was 2015. Was that the time you were around, or is this before that even?Corey: That would have been around then, yes. I didn't start this place until late 2016.Micheal: I do see your commits, like, from 2015, and I—Corey: And they're probably terrible, I have no doubt. There's a reason I don't read code for a living anymore.Micheal: Okay, I do see a lot of GIFs—and I hope it's pronounced as GIF—okay, this is cool. We should definitely have a chat about this separately, Corey?Corey: Oh, yeah. “Would you explain this code?” “Absolutely not. I wrote it. Of course, I have no idea what it does. That's the rule. That's the way code always works.”Micheal: Oh, you are an honorary Pinterest engineer at this point, and you have—yes—contributed to our API service and a couple of Puppet profiles I see over here.Corey: Oh, yes—Micheal: [Amazing 00:36:11]. [laugh].Corey: You don't wind up thinking that's a risk factor that should be disclosed. I kid. I kid. It's, I made a joke about this when VMware acquired SaltStack and I did some analytics and found that 60 some odd lines of code I had written, way back when that were still in the current version of what was being shipped. And they thought, “Wait, is this actually a risk?”And no, I am making a joke. The joke is, is my code is bad. Fortunately, there are smart people around me who review these things. This is why code review is so important. But there was a lot to admire when I was there doing various things at Pinterest. It was a fun environment to work in, the level of professionalism was phenomenal, and I was just a big fan of a lot of the automation stuff.Phabricator was great. I love working with it, and, “Great, I'm going to use this to the next place I go.” And I did and then it was—I looked at what it took to get it up and running, and oh, yeah, I can see why GitHub is so popular these days. But it was neat. It was interesting seeing that type of environment up close.Micheal: That is great to hear. You know, this is what I enjoy, like, hearing some of these war stories. I am surprised; you seem to have committed way more than I've ever done in my [laugh] duration here at Pinterest. I do managing for a living, but then again—Corey, the good news is your code is still running on production. And we—Corey: Oh dear.Micheal: —haven't—[laugh]. We haven't removed or made any changes to it, so that's pretty amazing. And thank you for all your contributions.Corey: Oh, please, you don't have to thank me. I was paid, it was fine. That's the value of—Micheal: [laugh].Corey: —[work 00:37:38] for hire. It's kind of amazing. And the best part about consultants is, is when we're done with a project, we get the hell out everyone's happy about it.More happy when it's me that's leaving because of obvious personality-related reasons. But it was just an interesting company from start to finish. I remember one other time, I wound up opening a ticket about having a slight challenge with a flickering on my then Apple-branded display that everyone was using before they discontinued those. And I expected there to be, “Oh, okay. You're a consultant. Great. How did we not put you in the closet with a printer next to that thing, breathing the toner?” Like most consulting clients tend to do, and sure enough, three minutes later, I'm getting that tap on the shoulder again; they have a whole replacement monitor. “Can you go grab a cup of coffee? We'll run the cable for it. It'll just be about five minutes.” I started to feel actively bad about requesting things because I did a lot of consulting work for a lot of different companies, and not to be unkind, but treating consultants and contractors super well is not something that a lot of companies optimize for. I can't necessarily blame them for that. It just really stood out.Micheal: Yep, I do hope we are keeping up with that right now because I know our team definitely has a lot of consultants working with us as well. And it's always amazing to see; we do want to treat them as FTs. It doesn't even matter at that point because we're all individuals and we're trying to work towards common goals. Like you just said, I think I personally have learned a few items as well from some of these folks. Which is again, I think speaks to how we want to work and create a culture of, like, we're all engineers; we want to be solving problems together, and as you were doing it, we want to do it in such a way that it's still fun, and we're not having the restrictions of titles or roles and other pieces. But I think I digressed. It was really fun to see your commits though, I do want to track this at some point before we move completely over to GitHub, at least keep this as a record, for what it's worth.Corey: Yeah basically look at this graffiti in the codebase of, “A shit-poster was here,” and here I am. And that tends to be, on some level, the mark we live on the universe. What's always terrifying is looking at things I did 15 years ago in my first Linux admin job. Can I still ping the thing that I built there? Yes, I can. And how is that even possible? That should not have outlived me; honestly, it should never have seen the light of day in production, but here we are. And you never know how long that temporary kluge you put together is going to last.Micheal: You know, one of the things I was recalling, I was talking to someone in my team about this topic as well. We always talk about 10x engineers. I don't know what your thoughts are on that, but the fact that you just mentioned you built something; it still pings. And there's a bunch of things, in my mind, when you are writing code or you're working on some projects, the fact that it can outlast you and live on, I think that's a big, big contribution. And secondly, if your code can actually help up-level, like, ten other people, I think you've really made the mark of 10x engineer at that point.Corey: Yeah, the idea of the superhuman engineer is always been a strange and dangerous one. If for nothing else, from where I sit, excellence is inherently situational. Like we just talked about someone at Pinterest: is potentially going to be able to have that kind of impact specifically because—to my worldview—that there's enough process and things around there that empower them to succeed. Then if you were to take that engineer and drop them into a five-person startup where none of those things exist, they might very well flounder. It's why I'm always a little suspicious of this is a startup founded by engineers from Google or Facebook, or wherever it is.It's, yeah, and what aspects of that culture do you think are one-to-one matches with the small scrappy startup in the garage? Right, I predicting some challenges here. Excellence is always situational. An amazing employee at one company can get fired at a second one for lack of performance, and that does not mean that there's anything wrong with them and it does not mean that they are a fraud. It means that what they needed to be successful was present in one of those shops, but not the other.Micheal: This is so true. And I really appreciate you bringing this up because whenever we discuss any form of performance management, that is a—in my view personally—I think that's an incorrect term to be using. It is really at that point in time, either you have outlived the environment you are in, or the environment is going in a different direction where I think your current skill set probably could be best used in the environment where it's going to work. And I know it's very fuzzy at that point, but like you said, yes, excellence really means you don't want to tie it to the number of commits you have pushed out, or any specific aspect of your deliverables or how you work.Corey: There are no easy answers to any of these things, and it's always situational. It's why I think people are sometimes surprised when I will make comments about the general case of how things should be, then I talk to a specific environment where they do the exact opposite, and I don't yell at them for it. It's there—in a general sense, I have some guidance, but they are usually reasons things are the way they are, and I'm interested in hearing them out. Everything's situational, the worst consultant in the world is the one that shows up, has no idea what's going on, and then asked, “What moron set this up?” Invariably, two said, quote-unquote, “Moron.” And the engagement doesn't go super well from there. It's, “Okay, why is this the way that it is? What constraints shaped it? What was the context behind the problem you were trying to solve?” And, “Well, why didn't you use this AWS service?” “Because it didn't exist for another three years when we were building that thing,” is a—Micheal: Yes.Corey: —common answer.Micheal: Yes, you should definitely appreciate that of all the decisions that have been made in past. People tend to always forget why they were made. You're absolutely right; what worked back then will probably not work now, or vice versa, and it's always situational. So, I think I can go on about this for hours, but I think you hit that to the point, Corey.Corey: Yeah, I do my best. I want to thank you for taking another block of time out of your day to wind up talking with me about various aspects of what it takes to effectively achieve better levels of engineering productivity at large companies, with many teams, working on shared codebases. If people want to learn more about what you're up to, where can they find you?Micheal: I'm definitely on Twitter. So, please note that I'm spelled M-I-C-H-E-A-L on Twitter. So, you can definitely read on to my tweets there. But otherwise, you can always reach out to me on LinkedIn, too.Corey: Fantastic and we will, of course, include a link to that in the [show notes 00:44:02]. Thanks once again for your time. I appreciate it.Micheal: Thanks a lot, Corey.Corey: Micheal Benedict, head of engineering productivity at Pinterest. 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 a comment telling me that you work at Pinterest, have looked at the codebase, and would very much like a refund and an apology.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.

In episode no. 68 my guest is serial public sector transformer, Pia Andrews. We discuss: how her pursuit of “truth” led her to the open-source movement and working in policy development; how technological tools relate to our quality of life; ‘open source' – its philosophy and implementation and the idea of “clever hacks”; how ‘rules as code' addresses issues with enforcing regulation; prescriptive and principles-based rules and when each are appropriate; the connection between the cost of implementing regulation and its effectiveness; how an API for prescriptive rules relating to anti-money laundering and counter-terrorism funding could have saved one bank $16M per year!; how ‘rules as code' make compliance more transparent by allowing for modelling, and how this could increase accountability of the public sector; how current policy creation is insufficient and requires input from community and an example from France which incorporated co-design of policy; Taiwan's response to the introduction of Uber! the importance of multidisciplinary teams in developing policy and how ‘rules as code' facilities doing so in real time; how ‘rules as code' improves trust and compliance with administrative law and shifts the onus to government; different public sector approaches to the “new normal”; how the relationship between the public sector and its government drives outcomes; whether a public sector should serve – the government, parliament or the people? 3 things necessary to create an environment for innovation and solving wicked problems; the connection between capacity and innovation, and Pia's ideas about how to increase civic participation through a “civic gap year” and “policy difference engine”; and of course Pia's definition of legal innovation. Proudly sponsored by Neota Logic Links: Linux Home TedX multipotentialite Emilie Wapnick: Why some of us don't have one true calling | TED Talk Docassemble  Legislation as Code and better rules Building a trustworthy public sector with trust infrastructure Neota Logic's App Gallery Neota Logic Churchill Trust project Andrea Perry-Petersen – LinkedIn - Twitter @winkiepp – andreaperrypetersen.com.au Twitter - @ReimaginingJ Facebook – Reimagining Justice group

David will discuss advancements in the medicinal use of psilocybin mushrooms for mental and physical wellness.David Nikzad heads the psychedelic medicine initiative, Ei Ventures, which works to empower mental wellness through psychoactive compounds and technology. Ei's ambition is to deliver governmental approved therapeutic treatment options that address the current global mental healthcare pandemic.The organization is focused on developing botanical API for the psychedelic supply chain, novel psychedelic compounds for various indications, unique delivery mechanisms and treatment protocols, and medicinal mushroom nutraceuticals for improving well-being and health. David is also the founder of Orthogonal Thinker, whose mission is to give people access to nature's most effective health solutions while setting the standard of a new “Farma”, Food as Medicine, with the intention to create a revolution when it comes to mental health and wellness. The aim is to open the pathway to the billion + people worldwide who need to receive these life-changing treatments and natural solutions.https://invest.ei.ventures

What makes fine grind barite different than conventional API barite? Where and when is it used to improve fluid performance?

It's another Potluck! In this episode, Scott and Wes answer your questions about GitHub Copilot, glasses, databases, dealing with stress, self-employment vs employment, design, CORS, and much more! Linode - Sponsor Whether you're working on a personal project or managing enterprise infrastructure, you deserve simple, affordable, and accessible cloud computing solutions that allow you to take your project to the next level. Simplify your cloud infrastructure with Linode's Linux virtual machines and develop, deploy, and scale your modern applications faster and easier. Get started on Linode today with a $100 in free credit for listeners of Syntax. You can find all the details at linode.com/syntax. Linode has 11 global data centers and provides 24/7/365 human support with no tiers or hand-offs regardless of your plan size. In addition to shared and dedicated compute instances, you can use your $100 in credit on S3-compatible object storage, Managed Kubernetes, and more. Visit linode.com/syntax and click on the “Create Free Account” button to get started. Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the “How did you hear about us?” section. Show Notes 03:12 - Ders: Has GitHub Copilot become part of your daily workflow, or have you turned it off? 05:50 - Gaston Gmzi: Hey guys you rock!!! I'd like to know if you use eyeglasses and if you have any preference regarding models, design and features like blue-light blocking and anti-reflection. Also, where do you buy them? Do you go to a store to try them out, or do you buy them online? And if ordering online, which specifications do you use besides the doctor's prescription? If you guys have any sick picks about eyeglasses it would be great to hear it too. Thanks for the show and have a great week!!! 11:04 - Hi, I would like to know how the two of you deal with stress? I am a freelancer and sometimes clients can get the worst in me. When they do, I usually take a long walk and listen to a podcast, but I don't always have the time for that. I can actually go into my commit history and show which one was under stress. I think a lot of developers especially freelancers could benefit from that. Thanks. 16:47 - Mike Varela: Question for you guys about dynamic database fields and API requests. How do you let the user store dynamic metadata? Thanks. Love the show, avid listener. 21:04 - Valentine Michael Smith: Can you touch on the use of the word “grok” in the dev world? I know a lot of people who have no idea what this word means. I just happened to have tried to read Stranger in a Strange Land, the novel the word originated from, a few years ago or else I wouldn't have ever heard it before starting dev work. Have either of you read the book? Anyways, why do devs say this? 24:50 - Steve Lewis: If you guys were not self-employed, would you prefer to work for a big company (like FAANG) or go to a smaller agency or startup, etc.? 27:08 - So Many Localhost Errors: This may be a softball, but how do you set up your logging (Sentry and/or LogRocket) so your dev environment isn't firing all the time? I can't seem to find a way to do this well (and it's probably because I'm trying to learn as I go). 31:03 - Josh J from Jersey: Hey guys, loving the podcast, I've been listening for about a month but bingeing through your episodes during my mind-numbing warehouse job, helps me keep my mind on JavaScript and what I have managed to learn in my spare time. I was wondering, when you're sitting down to a new project, how do you design the website? Does it just slowly develop as you code or have you sat down and drawn out what you want it to look like ahead of time? I have heard talk of a remarkable pad. I've seen ads for this on Instagram and YouTube but always assumed it was a very gimmicky thing. Is this a good investment? Also wondering how you both met? Have you worked on any projects together outside of courses and Syntax? Keep the content coming! 38:14 - Andras: Hi Wes and Scott. You have talked a lot on the show about headless CMS's like Sanity, Prismic or even WordPress being used as a headless CMS. I am curious what the setup in a real world project is like. How would you host the CMS? And what will the admin surface look like? Will the button styles, background color etc. be different than the actual website that the end user sees? Is that a problem for the admin users? Does the admin user see all the menu for creating new content types or adding new features? Or do they only see the input fields of all the contents that can be added to a specific page? Thank you! 42:14 - Dave: Hey guys, love the podcast! I understand that CORS prevention is in place in the browser to help improve security/prevent malicious requests across domains, but I don't understand why you can get around this by performing the request server side, for example via cURL? If I were a malicious actor, surely I could just send my cross domain request through a proxy to avoid the CORS issue? I'm sure I'm missing something obvious here, can I please get your thoughts on this? 44:48 - Lemon: How do you implement authentication with GraphQL? Especially in Fastify, I know Scott recently moved over from Meteor to Fastify, so I too was checking Fastify but couldn't find a satisfying auth solution that fits well with GraphQL. 48:08 - Zack Vogel: I love when you play games on the podcast. I'm a high school technology teacher and I play a game with my students called the 5 Second Rule. It's based on a board game, but I have changed the topics to technology-themed questions. The game works like this. One person reads a topic “Name Three VS Code Extensions” and the other person has five seconds to respond with three correct answers. I think this could be a fun game to play on the podcast. Links http://www.seeeyewear.com/ https://www.warbyparker.com/ https://www.costco.com/ MariaDB dynamic columns https://en.wikipedia.org/wiki/Grok https://twitter.com/argyleink https://remarkable.com/ https://figma.com/ https://graphql.org/ https://www.meteor.com/ https://www.fastify.io/ https://docs.google.com/presentation/d/1oRqz1rSUXiLc5pJF2cMygNrodcRrRU77x0KdWGV67Iw/edit?usp=sharing ××× SIIIIICK ××× PIIIICKS ××× Scott: myQ Chamberlain Smart Garage Control Wes: ATOTO Head Unit Shameless Plugs Scott: Level Up Tutorials Pro - Sign up for the year and save 25%! Wes: All Courses - Use the coupon code ‘Syntax' for $10 off! Tweet us your tasty treats! Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

¿Planeta 9 visto en 1983? / AirPods vs. la contra-cultura / Rechazo a la decisión de YouTube / 10 millones de Quest 2 / Coche eléctrico con cerebro Huawei / Nariz para drones / Brave tiene cartera nativa / Twitter quiere otra vez a los desarrolladores Patrocinador: La gala de premios Huawei Next Image son el mayor concurso de fotografía móvil https://consumer.huawei.com/es/community/next-image/ del mundo. Más de dos millones de personas de todo el mundo han participado, y este año viene con más premios que nunca. — Las inscripciones están abiertas https://consumer.huawei.com/es/community/next-image/ hasta el 30 de noviembre, y puedes participar en múltiples categorías. Si algún lector gana que lo comparta conmigo, ¿eh? ¿Planeta 9 visto en 1983? / AirPods vs. la contra-cultura / Rechazo a la decisión de YouTube / 10 millones de Quest 2 / Coche eléctrico con cerebro Huawei / Nariz para drones / Brave tiene cartera nativa / Twitter quiere otra vez a los desarrolladores

In the second episode of ARC Talk's Omnichannel Chatter miniseries, Sarah Boyd and Shelly Younger are joined by Duffel CEO Steve Domin. Domin discusses founding Duffel to meet industry needs, how Duffel's API makes it easier to build a travel business, and the future of omnichannel retailing. Follow the ARC Talk podcast on our social media—LinkedIn, Twitter, Facebook and YouTube—as well as what's trending in travel data by following #ARCdata.

Jake and Michael discuss all the latest Laravel releases, tutorials, and happenings in the community.This episode is sponsored by Honeybadger - combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform - and was streamed live.Show links Laravel 8.69 released Laravel masked DB dump Laravel 8.70 released Getting started with PHP in 2022 Larastan v1.0 released Provide country and other locale data in Laravel Standardize data formats in your Laravel application Automatically sanitize model data Conduct better email testing with Mail Intercept Video: Getting ready for PHP 8.1 How to add server timing header information for Laravel applications Efficient distance querying in MySQL Laravel Shift CI Generator Laravel Worldwide Meetup #11: Building APIs & Models/Spotlight with Livewire Taylor working on adding API-specific scaffolding for new Laravel projects

Cherish Santoshi is a Founding Member and Head of Community at SAWO Labs, an API authentication service. He is specialized in strategy and management and is currently managing programs for over 4 million developers across the globe and has worked for companies including Google, Microsoft, Amazon and the Government of India. Cherish is an advocate of change and believes that communities can change the world with innovation and constant progress. He is enthusiastic about building and expanding tech communities, as well as supporting technical education. During this interview we cover: 00:00 - Intro 01:27 - Insight Into User Authentication 04:44 - Authentication Before Or After Building Product? 06:12 - SAWO Labs' Advantages for Developers 09:15 - The Three Factors of Authentication 10:57 - The Building Of AppStore 14:23 - Growth Through Building Connections 15:19 - Factors of a Community & How to Build It as a SaaS Founder 18:26 - SAWO Labs Developers Community 21:45 - Cherish's Path To Build Developers Communities 25:41 - https://my.captivate.fm/Contentfy.co (Contentfy.co) Your On-Demand Podcast Editing Team 27:14 - SAWO Labs Community As a Service 29:16 - How To Give Back To The Community 33:13 - SAWO Labs Size Today 34:50 - Cherish's Vision While Starting SAWO Labs 36:51 - Piece Of Advice Cherish Would Give To His 25 Years-Old Self 38:46 - Cherish's Greatest Challenges as Being CEO at SAWO Labs 41:24 - Instrumental Resources For Cherish's Success 43:16 - What Does Success Mean To Cherish Today 43:51 - Get in Touch With Cherish Mentions: https://wordpress.com (Wordpress) https://www.shopify.com (Shopify) https://2021.devrel.net (Devrelcon) Kunal Shah https://www.notion.so/product?fredir=1 (Notion) Get In Touch With Cherish: https://www.linkedin.com/in/cherish-santoshi-55a51943/ (Cherish Santoshi's Linkedin) Tag us & follow: https://www.facebook.com/HorizenCapitalOfficial/ (Facebook)  https://www.linkedin.com/company/horizen-capital (LinkedIn)  https://www.instagram.com/saasdistrict/ (Instagram)  More about Akeel: Twitter - https://twitter.com/AkeelJabber (https://twitter.com/AkeelJabber) LinkedIn - https://linkedin.com/in/akeel-jabbar (https://linkedin.com/in/akeel-jabbar) More Podcast Sessions - https://horizencapital.com/saas-podcast (https://horizencapital.com/saas-podcast) 

This week's episode comes to you from Odense in Denmark, where we're joined by Connor Jensen Murphy and Justin Ihnken from Danish full service cannabis testing and analysis lab, QNTM Labs.We examine the importance of continuity, standardisation, and frameworks with the context of cannabis laboratory testing, and how QNTM Labs are helping to bring pharmaceutical testing standards to the European medical cannabis industry.About QNTM LabsQNTM Labs is an advanced analytical laboratory providing research, development, and regulatory compliance services for pharmaceutical companies.Founded in 2020 and headquartered in Odense, Denmark, QNTM is dedicated to developing innovative analytical methods while maintaining the highest quality levels to forge new industry standards.As global sentiment is increasingly focused on quality data, QNTM Labs is determined to improve transparency and access to robust scientific analysis, working hand-in-hand with global cultivators, API manufacturers, and pharmaceutical industry stakeholders through analytical testing, contract research and clinical trials support.About Justin IhnkenJustin Ihnken is the Chief Executive Officer and Co-founder of QNTM Labs, a state-of-the-art GMP-certified laboratory dedicated to supporting plant-based pharmaceuticals. Outside of QNTM Labs, Justin also currently sits on the Board of Directors for the American Club of Copenhagen.Prior to founding QNTM Labs, Justin worked in Copenhagen for Danish global shipping conglomerate, A.P. Møller-Mærsk, where he was responsible for interest rate portfolio management and derivative trading, as a part of the company's global treasury team. Before moving to Denmark in 2018, Justin built his professional career in institutional banking in New York City, within fixed income trading and interest rates.  Justin completed his education at Seton Hall University's Stillman School of Business where he studied Mathematical Finance. About Connor Jensen MurphyConnor Jensen Murphy co-founded QNTM Labs in March 2020 and is currently the company's Chief Operating Officer.  Connor has spent his career advising middle-market and founder-owned companies in corporate restructuring and M&A transactions.Prior to starting QNTM, Connor was a VP on EY's Investment Banking team in Copenhagen focused on M&A transactions. Before moving to Copenhagen, he was based in San Francisco, California and also worked with EY's Investment Banking group. Connor holds a B.A. from Colgate University where he studied Environmental Economics.ResourcesFollow QNTM Labs on LinkedIn: https://www.linkedin.com/company/qntmlabs/QNTM Labs Website: https://qntmlabs.com/Connect with Connor on LinkedIn: https://www.linkedin.com/in/connor-jensen-murphyConnect with Justin on LinkedIn: https://www.linkedin.com/in/justin-ihnken

While talking with a client recently about their performance challenges, I was relieved to find that the database wasn't the problem. Instead, their API server was overloaded by the number of calls taking place in their application. While the database did provide the backing for the API calls, there was a fair amount of caching. However, as they'd moved to microservices, more and more of the interaction between modules was taking place as a network call to a single server, which became overloaded.Certainly, they could add more API servers, or break out different types of API servers, but each of these changes potentially has downsides. Data can become out of sync across two systems, which is why we often want a single database storing all data. Distributed systems are hard to architect and implement, and I suspect as more developers try to build them, we'll find more issues like this. Not that developers are doing anything wrong, but they often don't realize the challenges of building a distributed system when the workload scales. Read the rest of The API Bottleneck

Liyas Thomas is the founder of Hoppscotch, an open source API development ecosystem that's seen exponential growth. Encouraged by his own mentors, Liyas now maintains Hoppscotch full time. Whether he's programming or pursuing his passion for art, he always puts beauty at the core of his work. During this conversation, he shares his path to Hoppscotch, the importance of community, and a preview of his newest endeavor: a book. Liyas on GitHub: https://github.com/liyasthomas Liyas' website: https://liyasthomas.com/ Be sure to check-out The ReadME Project for more episodes, stories and features: https://github.com/readme

Have you ever wondered how businesses achieve operational excellence?  Diana Eestermans, the Business Performance Manager at SK Fire, discusses her own journey to her role in helping businesses evolve.  She shares insights into working as a team and highlights effective ways to help those around her. Plus, she talks about her company and gives listeners an understanding of SK Fire and what it will add to the APi family. 

About MatthewMatthew Prince is co-founder and CEO of Cloudflare. Cloudflare's mission is to help build a better Internet. Today the company runs one of the world's largest networks, which spans more than 200 cities in over 100 countries. Matthew is a World Economic Forum Technology Pioneer, a member of the Council on Foreign Relations, winner of the 2011 Tech Fellow Award, and serves on the Board of Advisors for the Center for Information Technology and Privacy Law. Matthew holds an MBA from Harvard Business School where he was a George F. Baker Scholar and awarded the Dubilier Prize for Entrepreneurship. He is a member of the Illinois Bar, and earned his J.D. from the University of Chicago and B.A. in English Literature and Computer Science from Trinity College. He's also the co-creator of Project Honey Pot, the largest community of webmasters tracking online fraud and abuse.Links: Cloudflare: https://www.cloudflare.com Blog post: https://blog.cloudflare.com/aws-egregious-egress/ Bandwidth Alliance: https://www.cloudflare.com/bandwidth-alliance/ Announcement of R2: https://blog.cloudflare.com/introducing-r2-object-storage/ Blog.cloudflare.com: https://blog.cloudflare.com Duckbillgroup.com: https://duckbillgroup.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: Writing ad copy to fit into a 30 second slot is hard, but if anyone can do it the folks at Quali can. Just like their Torque infrastructure automation platform can deliver complex application environments anytime, anywhere, in just seconds instead of hours, days or weeks. Visit Qtorque.io today and learn how you can spin up application environments in about the same amount of time it took you to listen to this ad.Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. Today, my guest is someone I feel a certain kinship with, if for no other reason than I spend the bulk of my time antagonizing AWS incredibly publicly. And my guest periodically descends into the gutter with me to do the same sort of things. The difference is that I'm a loudmouth with a Twitter account and Matthew Prince is the co-founder and CEO of Cloudflare, which is, of course, publicly traded. Matthew, thank you for deigning to speak with me today. I really appreciate it.Matthew: Corey, it's my pleasure, and appreciate you having me on.Corey: So, I'm mostly being facetious here, but not entirely, in that you have very publicly and repeatedly called out some of the same things I love calling out, which is AWS's frankly egregious egress pricing. In fact, that was a title of a blog post that you folks put out, and it was so well done I'm ashamed I didn't come up with it myself years ago. But it's something that is resonating with a large number of people in very specific circumstances as far as what their company does. Talk to me a little bit about that. Cloudflare is a CDN company and increasingly looking like something beyond that. Where do you stand on this? What got you on this path?Matthew: I was actually searching through really old emails to find something the other day, and I found a message from all the way back in 2009, so actually even before Michelle and I had come up with a name for Cloudflare. We were really just trying to understand the pricing on public clouds and breaking it all down. How much does the compute cost? How much does storage cost? How much does bandwidth cost?And we kept running the numbers over and over and over again, and the storage and compute costs actually seemed relatively reasonable and you could understand it, but the economics behind the bandwidth just made no sense. It was clear that as bandwidth usage grew and you got scale that your costs eventually effectively went to zero. And I think it was that insight that led to us starting Cloudflare. And the self-service plans at Cloudflare have always been unlimited bandwidth, and from the beginning, we didn't charge for bandwidth. People told us at the time we were crazy to not do that, but I think that that realization, that over time and at scale, bandwidth costs do go to zero is really core to who Cloudflare is.Cloudflare launched a little over 11 years ago now, and as we've watched the various public clouds and AWS in particular just really over that same 11 years not only not follow the natural price of bandwidth down, but really hold their costs steady. At some point, we've got a lot of mutual customers and it's a complaint that we hear from our mutual customers all the time, and we decided that we should do something about it. And so that started four years ago, when we launched the Bandwidth Alliance, and worked with almost all the major public clouds with the exception of Amazon, to say that if someone is sending traffic from a public cloud network to Cloudflare's network, we're not going to charge them for the bandwidth. It's going across a piece of fiber optic cable that yeah, there's some cost to put it in place and maybe there's some maintenance costs associated with it, but there's not—Corey: And the equipment at the end costs money, but it's not cloud cost; it just cost on a per second, every hour of your lifetime basis. It's a capital expense that is amortized across a number of years et cetera, et cetera.Matthew: And it's a fixed cost. It's not a variable cost. You put that fiber optic cable and you use a port on a router on each side. There's cost associated with that, but it's relatively de minimis. And so we said, “If it's not costing us anything and it's not costing a cloud provider anything, why are we charging customers for that?”And I think it's an argument that resonated with almost every other provider that was out there. And so Google discounts traffic when it's sent to us, Microsoft discounts traffic when it's sent to us, and we just announced that Oracle has joined this discounting their traffic, which was already some of the most cost-effective bandwidth from any cloud provider.Corey: Oh, yeah. Oracle's fantastic. As you were announced, I believe today, the fact that they're joining the Bandwidth Alliance is both fascinating and also, on some level, “Okay. It doesn't matter as much because their retail starting cost is 10% of Amazon's.” You have to start pushing an awful lot of traffic relative to what you would do AWS before it starts to show up. It's great to see.Matthew: And the fact that they're taking that down to effectively zero if you're using us is even better, right? And I think it again just illustrates how Amazon's really alone in this at being so egregious in how they do that. And it's, when we've done the math to calculate what their markups are, it's almost 80 times what reasonable assumptions on what their wholesale costs are. And so we really do believe in fighting for our customers and being customer-centric, and this seems like a place where—again, Amazon provides an incredible service and so many things, but the data transfer costs are just completely outrageous. And I'm glad that you're calling them out on it, and I'm glad we're calling them out on it and I think increasingly they look isolated and very anti-customer.Corey: What's interesting to me is that ingress to AWS at all the large public tier-one cloud providers is free. Which has led, I think, to the assumption—real or not—that bandwidth doesn't actually cost anything, whereas going outbound, all I can assume is that one day, some Amazon VP was watching a rerun of Meet the Parents and they got to the line where Ben Stiller says, “Oh, you can milk anything with nipples,” and said, “Holy crap. Our customers all have nipples; we can milk them with egress charges.” And here we are. As much as I think the cloud empowers some amazing stuff, the egress charges are very much an Achilles heel to a point where it starts to look like people won't even consider public cloud for certain workloads based upon that.People talk about how Netflix is a great representation of the ideal AWS customers. Yeah, but they don't stream a single byte to customers from AWS. They have their own CDN called Open Connect that they put all around the internet, specifically for that use case because it would bankrupt them otherwise.Matthew: If you're a small customer, bandwidth does cost something because you have to pay someone to do the work of interconnecting with all of the various networks that are out there. If you start to be, though, a large customer—like a Cloudflare, like an AWS, like an Azure—that is sending serious traffic to the internet, then it starts to actually be in the interest of ISPs to directly interconnect with you, and the costs of your bandwidth over time will approach zero. And that's the just economic reality of how bandwidth pricing works. I think that the confusion, to some extent, comes from all of us having bought our own home internet connection. And I think that the fact that you get more bandwidth up in most internet connections, and you get down, people think that there's some physics, which is associated with that.And there are; that turns out just to be the legacy of the cable system that was really designed to send pictures down to your—Corey: It wasn't really a listening post. Yeah.Matthew: Right. And so they have dedicated less capacity for up and again, in-home network connections, that makes a ton of sense, but that's not how internet connections work globally. In fact, you pay—you get a symmetric connection. And so if they can demonstrate that it's free to take the traffic in, we can't figure out any reason that's not simply about customer lock-in; why you would charge to take data out, but you wouldn't charge to put it in. Because actually cost more from writing data to a disk, it costs more than reading it from a disk.And so by all reasonable accounts, if they were actually charging based on what their costs were, they would charge for ingress but they want to charge for egress. But the approach that we've taken is to say, “For standard bandwidth, we just aren't going to charge for it.” And we do charge for if you use our premium routing services, which is something called Argo, but even then it's relatively cheap compared with what is just standard kind of internet connectivity that's out there. And as we see more of the clouds like Microsoft and Google and Oracle show that this is a place where they can be much more customer-centric and customer-friendly, over time I'm hopeful that will put pressure on Amazon and they will eliminate their egress fees.Corey: People also tend to assume that when I talk about this, that I'm somehow complaining about the level of discounting or whatnot, and they yell at me and say, “Oh, well, you should know by now, Corey, that no one at significant scale pays retail pricing.” “Thanks, professor. I appreciate that, but four years ago, or so I sat down with a startup founder who was sketching out the idea for a live video streaming service and said, ‘There's something wrong with my math because if I built this on AWS—which he knew very well, incidentally—it looks like it would cost me at our scale of where we're hoping to hit $65,000 a minute.'” And I checked and yep, sure enough, his math was not wrong, so he obviously did not build his proof of concept on top of AWS. And the last time I checked, they had raised several 100 million dollars in a bunch of different funding rounds.That is a company now that will not be on AWS because it was never an option. I want to talk as well about your announcement of R2, which is just spectacular. It is—please correct me if I get any of this wrong—it's an object store that lives in your existing distributed-points-of-presence-slash-data-centers-slash-colo-slash-a-bunch-of-computers-in-fancy-warehouse-rooms-with-the-lights-are-always-on-And-it's-always-cold-and-noisy. And people can store data there—Matthew: [crosstalk 00:10:23] aisles it's cold; in the other aisles, it's hot. But yes.Corey: Exactly. But it turns out when you lurk around to the hot aisle, that's not where all the buttons are and the things you're able to plug into, so it's freeze or sweat, and there's never a good answer. But it's an object store that costs a fair bit less than retail pricing for Amazon S3, or most other object stores out there. Which, okay, great. That's always good to see competition in the storage space, but specifically, you're not charging any data transfer costs whatsoever for doing this. First, where did this come from?Matthew: So, we needed it ourselves. I think all of the great products at Cloudflare start with an internal need. If you look at why do we build our zero-trust solutions? It's because we said we needed a security solution that was fast and reliable and secure to protect our employees as they were going out and using the internet.Why did we build Cloudflare Workers? Because we needed a very flexible compute platform where we could build systems ourselves. And that's not unique to us. I mean, why did Amazon build AWS? They built it because they needed those tools in order to continue to grow and expand as quickly as possible.And in fact, I think if you look at the products that Google makes that are really great, it ends up being the ones that Google's employees use themselves. Gmail started as Caribou once upon a time, which was their internal email system. And so we needed an object store and the sometimes belligerent CEO of Cloudflare insisted that our team couldn't use any of the public cloud object stores. And so we had to build it.That was the start of it and we've been using it internally for products over time. It powers, for example, Cloudflare Images, it powers a lot of our streaming video services, and it works great. And at some point, we said, “Can we take this and make it available to everyone?” The question that you've asked on Twitter, and I think a lot of people reasonably ask us, “What's the catch?”Corey: Well, in my defense, I think it's fair. There was an example that I gave of, “Okay, I'm going to go ahead and keep—because it's new, I don't trust new object stores. Great. I'm going to do the same experiment twice, keep one the pure AWS story and the other, I'm just going to add Cloudflare R2 to the mix so that I have to transfer out of AWS once.” For a one gigabyte file that gets shared out for a petabyte's worth of bandwidth, on AWS it costs roughly $52,000 to do that. If I go with the R2 solution, it cost me 13 cents, all of which except for a penny-and-a-half are AWS charges. And that just feels—when you're looking at that big of a gap, it's easy to look at that and think, “Okay, someone is trying to swindle me somewhere. And when you can't spot the sucker, it's probably me. What's the catch?”Matthew: I guess it's not really a catch; it's an explanation. We have been able to drive our bandwidth costs down low enough that in that particular use case, we have to store the file, and that, again, that—there's a hard disk in there and we replicate it to make sure that it's available so it's not just one hard disk, but it's multiple hard disks in various places, but that amortized over time, isn't that big a cost. And then bandwidth is effectively zero. And so if we can do that, then that's great.Maybe a different way of framing the question is like, “Why would we do that?” And I think what we see is that there is an opportunity for customers to be able to use the best of various cloud providers and hook the different parts together. So, people talk about multi-cloud all the time, and for a while, the way that I think people thought about that was you take the exact same workload and you run it in Azure and AWS. That turns out not to be—I mean, maybe some people do that, but it's super rare and it's incredibly hard.Corey: It has been a recurring theme of most things I say where, by default, that is one of the dumbest things I can imagine.Matthew: Yeah, that isn't good. But what people do want to do is they want to say, “Listen, there's some really great services that Amazon provides; we want to use those. And there's some really great services that Azure provides, and we want to use those. And Google's got some great machine learning, and so does IBM. And I want to sort of mix and match the various pieces together.”And the challenge in doing that is the egress fees. If everyone just had a detente and said there's going to be no egress fees for us to be able to hook these various [pits 00:14:48] together, then you would be able to take advantage of a lot of the different technologies and we would actually get stronger applications. And so the vision of what we're trying to build is how can we be the fabric that can stitch the various cloud providers together so that you can do that. And when we looked at that, and we said, “Okay, what's the path to getting there?” The big place where there's the just meatiest cost on egress fees is object stores.And so if you could have a centralized object store, and you can say then from that object go use whatever the best service is at Amazon, go use whatever the best service is at Google, go use whatever the best service is at Azure, that then allows, I think, actually people to take advantage of the cloud in a way which is what people really should mean when they talk about multi-cloud. Which is, there should be competition on the various features themselves, and you should be able to pick and choose the best of all of the different bits. And I think we as consumers then benefit from that. And so when we're looking at how we can strategically enable that future, building an object store was a real key part of that, and that's part of what we're doing. Now, how do we make money off of that? Well, there's a little bit off the storage, and again, even [laugh]—Corey: Well, that is the Amazonian answer there. It's like, “Your margin is my opportunity,” is a famous Bezos quote, and I figure you're sitting there saying, “Ah, it would cost $52,000 to do that in Amazon. Ah, we can make a penny-and-a-half.” That's very Amazonian, you could probably get hired over there with that philosophy.Matthew: Yeah. And this is a commodity service, just [laugh] storing data. If you look across the history of what Cloudflare has done, in 2014, we made encryption free because it's absurd to pay for math, right? I mean, it's just crazy right?Corey: Or to pay for security as a value-add. No, that should be baked into whatever you're doing, in an ideal world.Matthew: Domain registration. Like, it's writing something down in a ledger. It's a commodity; of course it should go to whatever the absolute cost is. On the other hand, there are things that we do that aren't commodities where we are able to better protect people because we see so much traffic, and we've built the machine learning models, and we've done those things, and so we charge for those things. So commodities, we think over time, go to effectively, whatever their cost is, and then the value is in the actual intelligent services that are on top of it.But an object store is a commodity and so we should be trying to drive that pricing down. And in the case of bandwidth, it's effectively free for us. And so if we can be that fabric that connects the different class together, I think that makes sense is a strategy for us and that's why R2 made a ton of sense for us to build and to launch.Corey: There seems to be a lack of ability for lots of folks, at least on the internet to imagine a use case other than theirs. I cheated by being a consultant, I get to borrow other people's use cases at a high degree of turnover. But the question I saw raised was, “Well, how many workloads really do that much egress from static objects that don't change? Doesn't sound like there'd be a whole lot of them.” And it's, “Oh, my sweet summer child. Sure, your app doesn't do a lot of that, but let me introduce it to my friends who are hosting videos on their website, for example, or large images that get accessed a whole bunch of times; things that are written once and then read forever by the internet.”Matthew: And we sit in a position where because of the role that Cloudflare plays where we sit in front of a number of these different cloud providers, we could actually look at the use cases and the data, and then build products in order to solve that. And that's why we started with Workers; that's why we then built the KV store that was on top of that; we built object-store next. And so you can see as we're sort of marching through these things, it is very much being informed by the data that we actually see from real customers. And one of the things that I really like about R2 is in exactly the example that you gave where you can keep everything in S3; you can set R2 in front of it and put it in slurp mode, and effectively it just—as those objects get pulled out, it starts storing them there. And so the migration path is super easy; you don't have to actually change anything about your application and will cut your bills substantially.And so I think that's the right thing to enable a multi-cloud world where, again, it's not you're running the exact same workload in different places, but you get to take advantage of the really great tack that all of these companies are building and use that. And then the companies will compete on building that tech well. So, it's not just about how do I get the data in and then kind of underinvest in all of the different services that I provide. It's how can we make sure that on a service-by-service basis, you actually are having real competition over time. And again, I think that's the right thing for customers, and absolutely R2 might not be the right thing for every use case that's out there, but I think that it wi—enabling more competition is going to make the cloud better for everyone.Corey: Oh, yeah. It's always fun hearing it from Amazonians. It's, “You have a service that talks to satellites in orbit. You really think that's a general-purpose thing that every company out there has to deal with?” No. Well, not yet, anyway.It also just feels to me like their transfer approach is antithetical to almost every other aspect of how they have built their cloud. Amazonians have told me repeatedly—I believe them—that their network is effectively magic. The fact that you can get near line rate between any two points without melting various [unintelligible 00:20:14], which shows that there was significant thought, work, effort, planning, technology, et cetera, put into the network. And I don't dispute that. But if I'm trying to build a workload and put it inside of AWS, I can control how it performs tied to budget; I can have a lot of RAM for things that are memory intensive, or I can have a little RAM; I can have great CPU performance or terrible CPU performance.The challenge with data transfer is it is uniformly great. “I want to get that data over there super quickly.” Yeah, awesome. I'm fine paying a premium for that. But I have this pile of data right here. I want to get it over there, ideally by Tuesday. There's no good way to do that, even with their Snowball—or Snow Family devices—when you fill them with data and send them into AWS, yeah, that's great. Then you just pay for the use of the device.Use them to send data out of AWS, they tack on an additional per-gigabyte fee for getting the data out. You're training as a lawyer, you went to the same law school that my wife did, the University of Chicago, which, oh, interesting stories down that path. But if we look at this, my argument is that the way to do an end-run around this is to sue Amazon for something, and then demand access to the data you have living in their environment during discovery. Make them give it to you for free, though, they'd probably find a way to charge it there, too. It's just a complete lack of vision and lack of awareness because it feels like they're milking a cash cow until it dies.Matthew: Yeah, they probably would charge for it and you'd also have to pay a lot of lawyers. So, I'm not sure that's the cost [crosstalk 00:21:44]—Corey: Its only works above certain volumes, I figure.Matthew: I do think that if your pricing strategy is designed to lock people in to prevent competition, then that does create other challenges. And there are certainly some University of Chicago law professors out there that have spent their careers arguing why antitrust laws don't make any sense, but I think that this is definitely one of those areas where you can see very clearly that customers are actually being harmed by the pricing strategy that's there. And the pricing strategy is not tied in any way to the underlying costs which are associated with that. And so I do think that, especially as you see other providers in the space—like Oracle—taking their bandwidth costs to effectively zero, that's the sort of thing that I think will have regulators start to scratch their heads. If tomorrow, AWS took egress costs to zero, and as a result, R2 was not as advantaged as it is today against them, you know, I think there are a lot of people who would say, “Oh, they showed Cloudflare.” I would do a happy dance because that's the best thing [thing they can do 00:22:52] for our customers.Corey: Our long-term goals, it sounds like, are relatively aligned. People think that I want to see AWS reign ascendant; people also say I want to see them burning and crashing into the sea, and neither one of those are true. What I want is, I want someone in a few years from now to be doing a startup and trying to figure out which cloud provider they should pick, and I want that to be a hard decision. Ideally, if you wind up reducing data transfer fees enough, it doesn't even have to be only one. There are stories that starts to turn into an actual realistic multi-cloud story that isn't, at its face, ridiculous. But right now, you have to pick a horse and ride it, for a variety of reasons. And I don't like that.Matthew: It's entirely egress-based. And again, I think that customers are better off if they are able to pick who is the best service at any time. And that is what encourages innovation. And over time, that's even what's good for the various cloud providers because it's what keeps them being valuable and keeps their customers thinking that they're building something which is magical and that they aren't trapped in the decision that they made, which is when we talk to a lot of the customers today, they feel that way. And it's I think part of why something like R2 and something like the Bandwidth Alliance has gotten so much attention because it really touches a nerve on what's frustrating customers today. And if tomorrow Amazon announced that they were eliminating egress fees and going head-to-head with R2, again, I think that's a wonderful outcome. And one that I think is unlikely, but I would celebrate it if it happened.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: My favorite is people who don't do research on this stuff. They wind up saying, “Oh, yeah. Cloudflare is saying that bandwidth is a fixed cost. Of course not. They must be losing their shirt on this.”You are a publicly-traded company. Your gross margins are 76% or 77%, depending upon whether we're talking about GAAP or non-GAAP. Point being, you are clearly not selling this at a loss and hoping to make it up in volume. That's what a VC-backed company does. Is something that is real and as accurate.I want to, on some level, I guess, low-key apologize because I keep viewing Cloudflare through a lens that is increasingly inaccurate, which is as a CDN. But you've had Cloudflare Workers for a while, effectively Functions as a Service that run at the edge, which has this magic aura around it, that do various things, which is fascinating to me. You're launching R2; it feels like you are in some ways aiming at becoming a cloud provider, but instead of taking the traditional approach of building it from the region's outward, you're building it from the outward in. Is that a fair characterization?Matthew: I think that's right. I think fundamentally what Cloudflare is, is a network. And I remember early on in the pandemic, we did a series of fireside chats with people we thought we could learn from. And so was everyone from Andre Iguodala, the basketball player, to Mark Cuban, the entrepreneur, to we had a [unintelligible 00:25:56] governor and all kinds of things. And we these were just internal on off the record.And I got to do one with Eric Schmidt, the former CEO of Google. And I said, “You know, Eric, one of the things that we struggle with is describing what is Cloudflare.” And without hesitation, he said, “Oh, that's easy. You're the network I plug into and don't have to worry about anything else.” And I think that's better than I could say it, myself, and I think that's what it is that we fundamentally are: we're the network that fits together.Now, it turns out that in the process of being that network and enabling that network, we are going to build things like R2, which start to be an object store and starts to sort of step into some of the cloud provider space. And Workers is really just a way of programming that network in order to do that, but it turns out that there are a bunch of workloads that if you move them into the network itself, make sense—not going to be every workload, but a lot of workloads that makes sense there. And again, I think that you can actually be very bullish on all of the big public cloud providers and bullish on Cloudflare at the same time because what we want to do is enable the ability for people to mix and match, and change, and be the fabric that connects all of those things together. And so over time, if Amazon says, “We're going to drop egress fees,” it may be that R2 isn't a product that exists—I don't think they're going to do that, so I think it's something that is going to be successful for us and get a lot of new users to us—but fundamentally, I think that where the traditional public clouds think of themselves as the place you put data and you process data, I think we think of ourselves as the place you move data. And that's somewhat different.That then translates into it as we're building out the different pieces, where it does feel like we're building from the outside in. And it may be that over time, that put versus move distinction becomes narrower and narrower as we build more and more services like R2, and durable objects, and KV, and we're working on a database, and all those things. And it could be that we converge in a similar place.Corey: One thing I really appreciate about your vision because it is so atypical these days, is that you aren't trying to build the multifunction printer of companies. You are not trying to be all things to all people in every scenario. Which is impossible to do, but companies are still trying their level best to do it. You are staking out the bounds of where you were willing to start and where you're willing to stop, in a variety of different ways. I would be—how do I put it?—surprised if you at some point in the next five years come out with, “And this is our own database that we have built out that directly competes with the following open-source project that we basically have implemented their API and gone down that particular path.” It does not sound like it is in your core wheelhouse at that point. You don't need—to my understanding—to write your own database engine in order to do what you do.Matthew: Maybe. I mean, we actually are kind of working on a database because—Corey: Oh, no, here we go again.Matthew: [laugh]—and yeah—in a couple of different ways. So, the first way is, we want to make sure that if you're using Workers, you can connect to whatever database you want to use anywhere in the world. And that's something that's coming and we'll be there. At the same time, the challenge of distributed computing turns out not to be the computing, it turns out to be the data and figuring out how to—CAP theorem is real, right? Consistency, Availability, and Partition tolerance; you can pick any two out of the three, but you can't get all three.And so you there's always going to be some trade-off that's there. And so we don't see a lot of good examples. There's some really cool companies that are working on things in the space, but we don't see a lot of really good examples of who has built a database that can be run on a distributed workload system, like Cloudflare to it do well. And so our team internally needs that, and so we're trying to figure out how to build it for ourselves, and I would imagine that after we build it for ourselves—if it works the way we expect it will—that that will then be something that we open up.Our motivation and the way we think about products is we need to build the tools for our own team. Our team itself is customer zero, and then some of those things are very specific to us, but every once in a while, when there are functions that makes sense for others, then we'll build them as well. And that does maybe risk being the multifunction printer, but again, I think that because the customer for that starts with ourselves, that's how we think about it. And if there's someone else's making a great tool, we'll use that. But in this case, we don't see anyone that's built a multi-tenant, globally-distributed, ACID-compliant relational database.Corey: I can't let it pass on challenge. Sure they have, and you're running it yourself. DNS: the finest database in the world. You stuff whatever you want to text records, and now you have taken a finely crafted wrench and turned it into a barely acceptable hammer, which is what I love about doing that terrible approach. Yeah, relational is not going to quite work that way. But—Matthew: Yes. That's a fancy key-value store, right? So—and we've had that for a long time. As we're trying to build those things up, the good news is that, again, we've run data at scale for quite some time and proven that we can do it efficiently and reliably.Corey: There's a lot that can be said about building the things you need to deliver your product to customers. And maybe a database is a poor example here, but I don't see that your motivation in this space is to step into something completely outside your areas of expertise solely because there's money to be made over there. Well, yeah, fortune passes everywhere. The question is, which are you best positioned to wind up delivering an actual transformative solution to that space, and what parts of it are just rent-seeking where it's okay, we're going to go and wherever the money is, we're chasing that down.Matthew: Yeah, we're still a for-profit business, and we've been able to grow revenue well, but I think it is that what motivates us and what drives us comes back to our mission, which is how do you help build a better internet? And you can look at every single thing that we've done, and we try to be very long-term-oriented. So, for instance, when we in 2014 made encryption free, the number one reason at the time, when people upgraded for the free version of our service, the paid version of our service is they got encryption for that. And so it was super scary to say, “Hey, we're going to take the biggest feature and give it away for free,” but it was clearly the direction of history and we wanted to be on the right side of history. And we considered it a bug that the internet wasn't built in an encrypted way from the beginning.So, of course, that was going to head that direction. And so I think that we and then subsequently Let's Encrypt, and a bunch of others have said, it's absurd that you're charging for math. And again, I think that's a good example of how we think about products. And we want to continue to disrupt ourselves and take the things that once upon a time were reserved for our customers that spend $10 million-plus with us, and we want to keep pushing those things down because, over time, the real opportunity is if you do right by customers, there will be plenty of ways that you can earn some of their budget. And again, we think that is the long-term winning strategy.Corey: I would agree with this. You're not out there making sneakers and selling them because you see people spend a lot of money on that; you're delivering value for customers. I say this as one of your paying customers. I have zero problem paying you every month like clockwork, and it is the least cloud-like experience because I know exactly what the bill is going to be in advance, which is apparently not how things should be done in this industry, yadda, yadda, yadda. It is a refreshingly delightful experience every time.The few times I've had challenges with the service, it has almost always been a—I'll call it a documentation gap, where the way it was explained in the formal documentation was not how I conceptualize things, which, again, explaining what these complex things are to folks who are not steeped in certain areas of them is always going to be a challenge. But I cannot think back to a single customer service failure I've had with you folks. I can't look back at any point where you have failed me as a customer, which is a strange thing to say, given how incredibly efficient I am at stumbling over weird bugs.Matthew: Terrific to have you as a customer. We are hardly perfect and we make mistakes, but one of the things I think that we try to do and one of the core values of Cloudflare is transparency. If I think about, like, the original sins of tech, a lot of it is this bizarre secrecy which pervades the entire industry. When we make mistakes, we talk about them, and we explain them. When there's an error, we don't throw up a white page; we put up a page that has our logo on it because we want to own it.And that sometimes gets blowback because you're in front of it, but again, I think it's the right thing to do for customers. And it's and I think it's incredibly important. One of the things that's interesting is you mentioned that you know what your bill is going to be. If you go back and look at the history of hosting on the internet, in the early days of internet hosting, it looks a lot like AWS.Corey: Oh, 95th percentile transit billing; go for one five minutes segment over and boom, your bill explodes. Oh, I remember those days. Unkindly.Matthew: And it was super complicated. And then what happened is the hosting world switched from this incredibly complicated billing to much more simplified, predictable, unlimited bandwidth with maybe some asterisks, but largely that was in place. And then it's strange that Amazon came along and then has brought us back to the more complicated world that's out there. I would have predicted that that's a sine wave—Corey: It has to be. I mean—Matthew: —and it's going to go back and forth over time. But I would have predicted that we would be more in the direction of coming back toward simplify, everything included. And again, I think that's how we've priced our things from the beginning. I'm surprised that it has held on as long as it has, but I do think that there's going to be an opportunity for—and I don't think Amazon will be the leader here, but I think there will be an opportunity for one of the big clouds.And again, I think Oracle is probably doing this the best of any of them right now—to say, “How can we go away from that complexity? How can we make bills predictable? How can we not nickel and dime everything, but allow you to actually forecast and budget?” And it just seems like that's the natural arc of history, and we will head back toward that. And, again, I think we've done our part to push that along. And I'm excited that other cloud providers seem to be thinking about that now as well.Corey: Oh, yeah. What I do with fixing AWS bills is the same thing folks were doing in the 70s and 80s with long-distance bills for companies. We're definitely hitting that sine wave. I know that if I were at AWS in a leadership role, I would be actively embarrassed that the company that is delivering a better customer experience around financial things is Oracle of all companies, given their history of audits and surprising people and the rest. It is ridiculous to me.One last topic that I want to cover with you before we call it an episode is, back in college, you had a thesis that you have done an excellent job of effectively eliminating from the internet. And the theme of this, to my understanding, was that the internet is a fad. And I am so aligned with that because I'm someone who has said for years that emerging technologies are fads. I've said it about cloud, about virtualization, about containers. And I just skipped Kubernetes. And now I'm all-in on serverless, which means, of course it's going to fail because I'm always wrong on these things. But tell me about that.Matthew: When I was seven years old in 1980, my grandmother gave me an Apple ][+ computer for Christmas. And I took to it like a just absolute duck to water and did things that made me very popular in junior high school, like going to computer camp. And my mom used to sign up for continuing education classes at the local university in computer science, and basically sneak me in, and I'd do all the homework and all that. And I remember when I got to college, there was a small group of students that would come around and help other students set their computer up, and I had it all set up and was involved. And so, got pretty deeply involved in the computer science program at college.And then I remember there was a group of three other students—so they were four of us—and they wanted to start an online digital magazine. And at the time, this was pre-web, or right in the early days of the web; it was sort of nineteen… ninety-three. And we built it originally on old Apple technology called HyperCard. And we used to email out the old HyperCard stacks. And the HyperCard stacks kept getting bigger and bigger and bigger, and we'd send them out to the school so [laugh] that we—so we kept crashing the mail servers.But the college loved this, so they kept buying bigger and bigger mail servers. But they were—at some point, they said, “This won't scale. You got to switch technologies.” And they introduced us to two different groups. One was a printer company based out in San Francisco that had this technology called PDF. And I was a really big fan of PDF. I thought PDF was the future, it was definitely going to be how everything got published.And then the other was this group of dorky graduate students at the University of Illinois that had this thing called a browser, which was super flaky, and crashed all the time, and didn't work. And so of the four of us, I was the one who voted for PDF and the other three were like, “Actually, I think this HTML thing is going to be a hit.” And we built this. We won an award from Wired—which was only a print magazine at the time—that called us the first online-only weekly publication. And it was such a struggle to get anyone to write for it because browsers sucked and, you know, trying to get students on campus, but no one on campus cared.We would get these emails from the other side of the world, where I remember really clearly is this—in broken English—email from Japan saying, “I love the magazine. Please keep writing more for the magazine.” And I remember thinking at the time, “Why do I care if someone in Japan is reading this if the girl down the hall who I have a crush on isn't?” Which is obviously what motivates dorky college students like myself. And at that same time, you saw all of this internet explosion.I remember the moment when Netscape went public and just blew through all the expectations. And it was right around the time I was getting ready to graduate for college, and I was kind of just burned out on the entire thing. And I thought, “If I can't even get anyone to write for this dopey magazine and yet we're winning awards, like, this stuff has to all just be complete garbage.” And so wrote a thesis on—ehh, it was not a very good [laugh] thesis. It's—but one of the things I said was that largely the internet was a fad, and that if it wasn't, that it had some real risks because if you enabled everyone to connect with whatever their weird interests and hobbies were, that you would very quickly fall to the lowest common denominator. And predicted some things that haven't come true. I thought for sure that you would have both a liberal and conservative search engine. And it's a miracle to this day, I think that doesn't exist.Corey: Now, that you said it, of course, it's going to.Matthew: Well, I don't know I've… [sigh] we'll see. But it is pretty amazing that Google has been able to, again, thread that line and stay largely apolitical. I'm surprised there aren't more national search engines; the fact that it only Russia and China have national search engines and France and Germany don't is just strange to me. It seems like if you're controlling the source of truth and how people find it, that seems like something that governments would try and take over. There are some things that in retrospect, look pretty wise, but there were a lot more things that looked really, really stupid. And so I think at some level, I had to build Cloudflare to atone for that stupidity all those years ago.Corey: There's something to be said for looking back and saying, “Yeah, I had an opinion, and with the light of new information, I am changing my opinion.” For some reason, in some circles, it feels like that gets interpreted as a sign of weakness, but I couldn't disagree more, it's, “Well, I had an opinion based upon what I saw at the time. Turns out, I was wrong, and here we are.” I really wish more people were capable of doing that.Matthew: It's one of the things we test for in hiring. And I think the characteristic that describes people who can do that well is really empathy. The understanding that the experiences that you have lead you to have a unique set of insights, but they also create a unique set of blind spots. And it's rare that you find people that are able to do that. And whenever you do—whenever we do we hire them.Corey: To that end, as far as hiring and similar topics go, if people want to learn more about how you view things, and how you see the world, and what you're releasing—maybe even potentially work with you—where can they find you?Matthew: [laugh]. So, the joke, sometimes, internal at Cloudflare is that Cloudflare is a blogging company that runs this global network just to have something to write about. So, I think we're unlike most corporate blogs, which are—if our corporate blog were typical, we'd have articles on, like, “Here are the top six reasons you need a fast website,” which would just be, you know, shoot me. But instead, I think we write about the things that are going on online and our unique view into them. And we have a core value of transparency, so we talk about that. So, if you're interested in Cloudflare, I'd encourage you to—especially if you're of the sort of geekier variety—to check out blog.cloudflare.com, and I think that's a good place to learn about us. And I still write for that occasionally.Corey: You're one of the only non-AWS corporate blogs that I pay attention to, for that exact reason. It is not, “Oh, yay. More content marketing by folks who just feel the need to hit a quota as opposed to talking about something valuable and interesting.” So, it's appreciated.Matthew: The secret to it was we realized at some point that the purpose of the blog wasn't to attract customers, it was to attract potential employees. And it turns out, if you sort of change that focus, then you talk to people like their peers, and it turns out then that the content that you create is much more authentic. And that turns out to be a great way to attract customers as well.Corey: I want to thank you for taking so much time out of your day to speak with me. I really appreciate it.Matthew: Thanks for all you're doing. And we're very aligned, and keep fighting the good fight. And someday, again, we'll eliminate cloud egress fees, and we can share a beer when we do.Corey: I will absolutely be there for it. Matthew, Prince, CEO, and co-founder of Cloudflare. 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 a rambling comment explaining that while data packets into a cloud provider are cheap and crappy, the ones being sent to the internet are beautiful, bespoke, unicorn snowflakes, so of course they cost money.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.

Staying on top of the iOS updates and keeping your marketing edge means understanding things like ATT, API, EMQ, and AEM.    In today's episode, co-hosts Ralph Burns and Kasim Aslam sit down with Ben Pang, Software and Attribution Product Manager for Tier 11, who is feverishly working on iOS solutions in his lab day and night. Ben thoroughly explains all the latest concepts, software, and acronyms in a way that even those whose brains aren't quite so technical can understand.    Listen in for some great tips on ensuring your social marketing stays effective even as things keep changing.     IN THIS EPISODE YOU'LL LEARN: Everything you need to know about ATT, EMQ, and AEM How to use first party data to create your own attribution model What server-side tagging is and what makes it powerful What Facebook's Conversion API Gateway means for you   LINKS AND RESOURCES MENTIONED IN THIS EPISODE: Follow @ralphhb and @kasimaslam on Twitter   OUR PARTNERS: No Limit Creatives gives you unlimited graphics/videos for one low monthly rate.  Clients Online, the go-to Facebook Advertising agency for businesses Keap, an easier way to manage every stage of the customer journey Endless reports and actionable insights from Oribi Get Zero Down (Roland Frasier's new book) FREE. Find out your Leadership Trust Score at Ready to Lead. Register for our free Founders Board workshop   Thanks so much for joining us this week. Want to subscribe to Perpetual Traffic? Have some feedback you'd like to share? Connect with us on iTunes and leave us a review!  

In this episode, we cover: 00:00:00 - Introduction 00:02:45 - Adopting the Cloud 00:08:15 - POC Process  00:12:40 - Infrastructure Team Building 00:17:45 - “Disaster Roleplay”/Communicating to the Non-Technical Side  00:20:20 - Leadership 00:22:45 - Tomas' Horror Story/Dashboard Organziation 00:29:20 - Outro Links: Productboard: https://www.productboard.com Scaling Teams: https://www.amazon.com/Scaling-Teams-Strategies-Successful-Organizations/dp/149195227X Seeking SRE: https://www.amazon.com/Seeking-SRE-Conversations-Running-Production/dp/1491978864/ TranscriptJason: Welcome to Break Things on Purpose, a podcast about failure and reliability. In this episode, we chat with Tomas Fedor, Head of Infrastructure at Productboard. He shares his approach to testing and implementing new technologies, and his experiences in leading and growing technical teams.Today, we've got with us Tomas Fedor, who's joining us all the way from the Czech Republic. Tomas, why don't you say hello and introduce yourself?Tomas: Hello, everyone. Nice to meet you all, and my name is Tomas, or call me Tom. And I've been working for a Productboard for past two-and-a-half year as infrastructure leader. And all the time, my experience was in the areas of DevOps, and recently, three and four years is about management within infrastructure teams. What I'm passionate about, my main technologies-wise in cloud, mostly Amazon Web Services, Kubernetes, Infrastructure as Code such as Terraform, and recently, I also jumped towards security compliances, such as SOC 2 Type 2.Jason: Interesting. So, a lot of passions there, things that we actually love chatting about on the podcast. We've had other guests from HashiCorp, so we've talked plenty about Terraform. And we've talked about Kubernetes with some folks who are involved with the CNCF. I'm curious, with your experience, how did you first dive into these cloud-native technologies and adopting the cloud? Is that something you went straight for, or is that something you transitioned into?Tomas: I actually slow transition to cloud technologies because my first career started at university when I was like, say, half developer and half Unix administrator. And I had experience with building very small data center. So, those times were amazing to understand all the hardware aspects of how it's going to be built. And then later on, I got opportunity to join a very famous startup at Czech Republic [unintelligible 00:02:34] called Kiwi.com [unintelligible 00:02:35]. And that time, I first experienced cloud technologies such as Amazon Web Services.Jason: So, as you adopted Amazon, coming from that background of a university and having physical servers that you had to deal with, what was your biggest surprise in adopting the cloud? Maybe something that you didn't expect?Tomas: So, that's great question, and what comes to my mind first, is switching to completely different [unintelligible 00:03:05] because during my university studies and career there, I mostly focused on networking [unintelligible 00:03:13], but later on, you start actually thinking about not how to build a service, but what service you need to use for your use case. And you don't have, like, one service or one use case, but you have plenty of services that can suit your needs and you need to choose wisely. So, that was very interesting, and it needed—and it take me some time to actually adopt towards new thinking, new mindset, et cetera.Jason: That's an excellent point. And I feel like it's only gotten worse with the, “How do you choose?” If I were to ask you to set up a web service and it needs some sort of data store, at this point you've got, what, a half dozen or more options on Amazon? [laugh].Tomas: Exactly.Jason: So, with so many services on providers like Amazon, how do you go about choosing?Tomas: After a while, we came up with a thing like RFCs. That's like ‘Request For Comments,' where we tried to sum up all the goals, and all the principles, and all the problems and challenges we try to tackle. And with that, we also tried to validate all the alternatives. And once you went through all these information, you tried to sum up all the possible solutions. You typically had either one or two options, and those options were validated with all your team members or the whole engineering organization, and you made the decision then you try to run POC, and you either are confirmed, yeah this is the technology, or this is service you need and we are going to implement it, or you revised your proposal.Jason: I really like that process of starting with the RFC and defining your requirements and really getting those set so that as you're evaluating, you have these really stable ideas of what you need and so you don't get swayed by all of the hype around a certain technology. I'm curious, who is usually involved in the RFC process? Is it a select group in the engineering org? Is it broader? How do you get the perspectives that you need?Tomas: I feel we have very great established process at Productboard about RFCs. It's transparent to the whole organization, that's what I love the most. The first week, there is one or two reporters that are mainly focused on writing and summing up the whole proposal to write down goals, and also non-goals because that is going to define your focus and also define focus of reader. And then you're going just to describe alternatives, possible options, or maybe to sum up, “Hey, okay, I'm still unsure about this specific decision, but I feel this is the right direction.” Maybe I have someone else in the organization who is already familiar with the technology or with my use case, and that person can help me.So, once—or we call it a draft state, and once you feel confident, you are going to change the status of RFC to open. The time is open to feedback to everyone, and they typically geared, like, two weeks or three weeks, so everyone can give a feedback. And you have also option to present it on engineering all-hands. So, many engineers, or everyone else joining the engineering all-hands is aware of this RFC so you can receive a lot of feedback. What else is important to mention there that you can iterate over RFCs.So, you mark it as resolved after through two or three weeks, but then you come up with a new proposal, or you would like to update it slightly with important change. So, you can reopen it and update version there. So, that also gives you a space to update your RFC, improve the proposal, or completely to change the context so it's still up-to-date with what you want to resolve.Jason: I like that idea of presenting at engineering all-hands because, at least in my experience, being at a startup, you're often super busy so you may know that the RFC is available, but you may not have time to actually read through it, spend the time to comment, so having that presentation where it's nicely summarized for you is always nice. Moving from that to the POC, when you've selected a few and you want to try them out, tell me more about that POC process. What does that look like?Tomas: So typically, in my infrastructure team, it's slightly different, I believe, as you have either product teams focus on POCs, or you have more platform teams focusing on those. So, in case of the infrastructure team, we would like to understand what code is actually going to be about because typically the infrastructure team has plenty of services to be responsible for, to be maintained, and we try to first choose, like, one specific use case and small use case that's going to suit the need.For instance, I can share about implementation of HashiCorp Vault, like our adoption. We leveraged firstly only key-value engine for storing secrets. And what was important to understand here, whether we want to spend hours of building the whole cluster, or we can leverage their cloud service and try to integrate it with one of our services. And we need to understand what service we are going to adopt with Vault.So, we picked cloud solution. It was very simple, the experience that were seamless for us, we understood what we needed to validate. So, is developer able to connect to Vault? Is application able to connect to Vault? What roles does it offer? Was the difference for cloud versus on-premise solution?And at the end, it's often the cost. So, in that case, POC, we spin up just cloud service integrated with our system, choose the easiest possible adaptable service, run POC, validate it with developers, and provide all the feedback, all the data, to the rest of the engineering. So, that was for us, some small POC with large service at the end.Jason: Along with validating that it does what you want it to do, do you ever include reliability testing in that POC?Tomas: It is, but it is in, like, let's say, it's in a later stage. For example, I can again mention HashiCorp Vault. Once we made a decision to try to spin up first on-premise cluster, we started just thinking, like, how many master nodes do we need to have? How many availability zones do we need to have? So, you are going to follow quorum?And we are thinking, “Okay, so what's actually the reliability of Amazon Web Services regions and their availability zones? What's the reliability of multi-cross-region? And what actually the expectations that is going to happen? And how often they happen? Or when in the past, it happened?”So, all those aspects were considered, and we ran out that decision. Okay, we are still happy with one region because AWS is pretty stable, and I believe it's going to be. And we are now successfully running with three availability zones, but before we jumped to the conclusion of having three availability zones, we run several tests. So, we make sure that in case one availability zone being down, we are still fully able to run HashiCorp Vault cluster without any issues.Jason: That's such an important test, especially with something like HashiCorp Vault because not being able to log into things because you don't have credentials or keys is definitely problematic.Tomas: Fully agree.Jason: You've adopted that during the POC process, or the extended POC process; do you continue that on with your regular infrastructure work continuing to test for reliability, or maybe any chaos engineering?Tomas: I actually measure something about what we are working on, like, what we have so far improved in terms of post-mortem process that's interesting. So, we started two-and-a-half year ago, and just two of us as infrastructure engineers. At the time, there was only one incident response on-call team, our first iteration within the infrastructure team was with migration from Heroku, where we ran all our services, to Amazon Web Services. And that time, we needed to also start thinking about, okay, the infrastructure team needs to be on call as well. So, that required to update in the process because until then, it works great; you have one team, people know each other, people know the whole stack. Suddenly, you are going to add new people, you're going to add new people a separate team, and that's going to change the way how on-call should be treated, and how the process should look like.You may ask why. You have understanding within the one team, you understand the expectations, but then you have suddenly different skill set of people, and they are going to be responsible for different part of the technical organization, so you need to align the expectation between two teams. And that was great because guys at Productboard are amazing, and they are always helpful. So, we sat down, we made first proposal of how new team is going to work like, what are going to be responsibilities. We took inspirations from the already existing on-call process, and we just updated it slightly.And we started to run with first test scenarios of being on call so we understand the process fully. Later on, it evolved to more complex process, but it's still very simple. What is more complex: we have more teams that's first thing being on call; we have better separation of all the alerts, so you're not going to route every alert to one team, but you are able to route it to every team that's responsible for its service; the team have also prepared a set of runbooks so anyone else can easily follow runbook and fix the incident pretty easily, and then we also added section about post-mortems, so what are our expectations of writing down post-mortem once incident is resolved.Jason: That's a great process of documenting, really—right—documenting the process so that everybody, whether they're on a different team and they're coming over or new hires, particularly, people that know nothing about your established practices can take that runbook and follow along, and achieve the same results that any other engineer would.Tomas: Yeah, I agree. And what was great to see that once my team grew—we are currently five and we started two—we saw excitement of the team members to update the process so everybody else we're going to join the on-call is going to be excited, is going to take it as an opportunity to learn more. So, we added disaster roleplay, and that section talks about you are new person joining on-call team, and we would like to make sure you are going to understand all the processes, all the necessary steps, and you are going to be aligned with all the expectations. But before you will actually going to have your first alerts of on-call, we would like to try to run roleplay. Imagine what a HashiCorp Vault cluster is going down; you should be the one resolving it. So, what are the first steps, et cetera?And that time you're going to realize whatever is being needs to be done, it's not only from a technical perspective, such as check our go to monitoring, check runbook, et cetera, but also communication-wise because you need to communicate not only with your shadowing buddy, but you also need to communicate internally, or to the customers. And that's going to change the perspective of how an incident should be handled.Jason: That disaster roleplay sounds really amazing. Can you chat a little bit more about the details of how that works? Particularly you mentioned engaging the non-technical side—right—of communication with various people. Does the disaster roleplay require coordinating with all those people, or is it just a mock, you would pretend to do, but you don't actually reach out to those people during this roleplay?Tomas: So, we would like to also combine the both aspects. We would like to make sure that person understands all the communication channels that are set within our organization, and what they are used for, and then we would like to make sure that that person understand how to involve other engineers within the organization. For instance, what was there the biggest difference is that you have plenty of options how to configure assigning or creating an alert. And so for those, you may have a different notification settings. And what happened is that some of the people have settings only for newly created alert, but when you made a change of assigned person of already existing alert, someone else, it might happen that that person didn't notice it because the notification setting was wrong. So, we encountered even these kind of issues and we were able to fix it, thanks to disaster roleplay. So, that was amazing to be found out.Jason: That's one of the favorite things that I like to do when we're using chaos engineering to do a similar thing to the disaster roleplay, is to really check those incident response processes, and validating those alerts is huge. There's so many times that I've found that we thought that someone would be alerted for some random thing, and turns out that nobody knew anything was going on. I love that you included that into your disaster roleplay process.Tomas: Yeah, it was also great experience for all the engineers involved. Unfortunately, we run it only within our team, but I hope we are going to have a chance to involve all other engineering on-call teams, so the onboarding experience to the engineering on-call teams is going to rise and is going to be amazing.Jason: So, one of the things that I'm really interested in is, you've gone from being a DevOps engineer, an SRE individual contributor role, and now you're leaving a small team. I think a lot of folks, as they look at their career, and I think more people are starting to become interested in this is, what does that progression look like? This is sort of a change of subject, but I'm interested in hearing your thoughts on what are the skills that you picked up and have used to become an effective technical leader within Productboard? What's some of that advice that our listeners, as individual contributors, can start to gain in order to advance where they're going with their own careers?Tomas: Firstly, it's important to understand what makes you passionate in your career, whether it's working with people, understanding their needs and their future, or you would like to be more on track as individual contributor and you would like to enlarge your scope of responsibilities towards leading more technical complex initiatives, that are going to take a long time to be implemented. In case all the infrastructure, or in case of the platform leaders, I would say the position of manager or technical leader also requires certain technical knowledge so you can be still in close touch with your team or with your most senior engineers, so you can set the goals and set the strategic clearly. But still, it's important to be, let's say, people person and be able to listen because in that case, people are going to be more open to you, and you can start helping them, and you can start making their dreams true and achievable.Jason: Making their dreams true. That's a great take on this idea because I feel like so many times, having done infrastructure work, that you start to get a mindset of maybe that people just are making demands of you, all the time. And it's sometimes hard to keep that perspective of working together as a team and really trying to excel to give them a platform that they can leverage to really get things done. We were talking about disaster roleplaying, and that naturally leads to a question that we like to ask of all of our guests and that's, do you have any horror stories from your career about an incident, some horror story or outage that you experienced and what you've learned from it?Tomas: I have one, and it actually happened at the beginning of my career of DevOps engineer. What is interesting here that it was one of the toughest incidents I experienced. It happened after midnight. So, the time I was still new to a company, and we have received an alert informing about too many 502, 504 errors written from API. At the time API process thousands of requests per second, and the incident had a huge impact on the services we were offering.And as I was shadowing my on-call buddy, I tried to check our main alerting channel, see what's happening, what's going on there, how can I help, and I started with checking monitoring system, reviewing all the reports from the engineers of being on-call, and I initiated the investigation on my own. I realized that something is wrong or something is not right, and I realized I was just confused and I want sleep, so it took me a while to get back on track. So, I made the side note, like, how can I start my brain to be working as during the day? And then I got back to the incident resolution process.So, it was really hard for me to start because I didn't know what [unintelligible 00:24:27] you knew about the channel, you knew about your engineers working on the resolution, but there were plenty of different communication funnels. Like, some of the engineers were deep-focused on their own investigation, and some of them were on call. And we needed to provide regular updates to the customers and internally as well. I had that inner feeling of let's share something, but I realized I just can't drop a random message because the message with all the information should have certain format and should have certain information. But I didn't know what kind of information should be there.So, I tried to ping someone, so, “Hey, can you share something?” And in the meantime, actually, more other people send me direct message. And I saw there are a lot of different tracks of people who tried to solve the incident, who tries to provide the status, but we were not aligned. So, this all showed me how important is to have proper communication funnel set. And we got the lucky to actually end up in one channel, we got lucky to resolve incident pretty quickly.And what else I learned that I would recommend to make sure you know where to work. I know it's pretty obvious sentence, but once your company has plenty of dashboards and you need to find one specific metric, sometime it looks like mission impossible.Jason: That's definitely a good lesson learned and feeds back to that disaster roleplays, practicing how you do those communications, understanding where things need to be communicated. You mentioned that it can be difficult to find a metric within a particular dashboard when you have so many. Do you have any advice for people on how to structure their dashboards, or name their dashboards, or organize them in a certain way to make that easier to find the metric or the information that you're looking for?Tomas: I will have a different approach, and that do have basic dashboard that provides you SLOs of all the services you have in the company. So, we understand firstly what service actually impacts the overall stability or reliability. So, that's my first advice. And then you should be able to either click on the specific service, and that should redirect you to it's dashboard, or you're going to have starred one of your favorite dashboards you have. So, I believe the most important is really have one main dashboard where you have all the services and their stability resourced, then you have option to look.Jason: Yeah, when you have one main dashboard, you're using that as basically the starting point, and from there, you can branch out and dive deeper, I guess, into each of the services.Tomas: Exactly, exactly true.Jason: I like that approach. And I think that a lot of modern dashboarding or monitoring systems now, the nice thing is that they have that ability, right, to go from one particular dashboard or graphic and have links out to the other information, or just click on the graph and it will show you the underlying host dashboard or node dashboard for that metric, which is really, really handy.Tomas: And I love the connection with other monitoring services, such as application monitoring. That gives you so much insight and when it's even connected with your work management tool is amazing so you can have all the important information in one place.Jason: Absolutely. So, oftentimes we talk about—what is it—the three pillars of observability, which I know some of our listeners may hate that, but the idea of having metrics and performance monitoring/APM and logs, and just how they all connect to each other can really help you solve a lot, or uncover a lot of information when you're in the middle of an incident. So Tomas, thanks for being on the show. I wanted to wrap up with one more question, and that's do you have any shoutouts, any plugs, anything that you want to share that our listeners should go take a look at?Tomas: Yeah, sure. So, as we are talking about management, I would like to promote one book that helped make my career, and that's Scaling Teams. It's written by Alexander Grosse and David Loftesness.And another one book is from Google, they have, like, three series, one of those is Seeking SRE, and I believe other parts are also useful to be read in case you would like to understand whether your organization needs SRE team and how to implement it within organization, and also, technically.Jason: Those are two great resources, and we'll have those linked in the show notes on the website. So, for anybody listening, you can find more information about those two books there. Tomas, thanks for joining us today. It's been a pleasure to have you.Tomas: Thanks. Bye.Jason: For links to all the information mentioned, visit our website at gremlin.com/podcast. If you liked this episode, subscribe to the Break Things on Purpose podcast on Spotify, Apple Podcasts, or your favorite podcast platform. Our theme song is called “Battle of Pogs” by Komiku, and it's available on loyaltyfreakmusic.com.

Robert Delwood, a former NASA engineer, sheds light on how technical writers can pivot to API writing. It is a special skill set and mindset. Listen to this exclusive episode to find out how you can acquire this skill and make it in this high-in-demand career. Per the website programmableweb.com, approximately 2000s APIs are added each year. For each API, roughly 2-3 writers are needed. Given this exponential rise in APIs, there is obviously a growing demand for API writers. But, writers are in short supply, while the pay scale is high. If you want to make it in this niche area, you must have the right attitude. What is it?Some key things we touch upon:What is the 30-minute limit test?What are the three strategies to learn API documentation?What are the four easy ways to start building an API portfolio?Also, if you are a hiring manager looking for API writers, this interview provides great tips on how you can find and fill this role with the right talent.Resources:The Programmable WebSearch for articles authored by Robert Delwood on medium.comFind projects on Upwork Guest BioRobert Delwood is a programmer, writer, and programming writer in Chicago's legal community. He strives to produce innovative API documentation. He's been an active writer for more than 20 years, 13 of those with API documentation. He's also been a titled developer, once even writing NASA software that made sure the space station astronauts had clean underwear each day. If the astronauts themselves don't appreciate it, the other crew members did.

Lyn Alden is the founder of Lyn Alden Investment Strategy, which provides market research to hundreds of thousands of individual investors and financial professionals. Lyn's focus is on value investing with a global macro overlay, including currency differentials, shifts in monetary policy, and equity valuations. In this conversation, we discuss inflation, employment, supply chain disruptions, monetary policy, fiscal policy, stocks, bonds, commodities, and bitcoin.  ======================= BlockFi provides financial products for crypto investors. Products include high-yield interest accounts, USD loans, and no fee trading. To start earning today visit: http://www.blockfi.com/Pomp ======================= Choice is a new self-directed IRA product that I'm really excited about. If you are listening to this, you are likely part of the 7.1 million bitcoin owners who have retirement accounts with dollars in them, but not bitcoin. I was in that situation too. Now you can actually buy real Bitcoin in your retirement account. I'm talking about owning your private keys and using tax-advantaged dollars to do it too. Absolute game changer. https://www.retirewithchoice.com/pomp ======================= Circle is a global financial technology firm that enables businesses of all sizes to harness the power of stablecoins and public blockchains for payments, commerce and financial applications worldwide. Circle is also a principal developer of USD Coin (USDC), the fastest growing, fully reserved and regulated dollar stablecoin in the world. The free Circle Account and suite of platform API services bridge the gap between traditional payments and crypto for trading, DeFi, and NFT marketplaces. Create seamless, user-friendly, mainstream customer experiences with crypto-native infrastructure under the hood with Circle. Learn more at circle.com.

Chris Goode is the founder and CEO of Climavision, a Louisville based startup building the infrastructure to offer weather data as a service. In June of 2021, Climavision came out of building in "stealth" to announce that they had raised $100 million from TPG. Through building and operating their own radar systems and partnering with Low Earth Orbit satellite companies, Climavision will be collecting massive amounts of raw weather data, feeding that data into its algorithms, and then providing the data and insights to their clients via API. Our conversation with Chris covers his extensive background in weather technologies, the significance of the data that Climavision is collecting, and the potential impacts that AI will have on the weather data that they're collecting. Learn more about Climavision at Climavision.com Visit us at MiddleTechPod.com Twitter Instagram Facebook LinkedIn Evan's Twitter Logan's Twitter

How do you automate DNS changes? And why would you? Carl and Richard talk to Enrique Comba, the DNSimple Ambassador, about programming against the DNSimple API. Enrique talks about automating migration from other DNS services - in fact, there are community-created products for migrating from various 'popular' DNS providers to DNSimple. The conversation also ranges over other tasks that are difficult to do manually, like certificate generation and renewal. If you're creating multi-tenant applications, configuration of DNS is a normal part of the job, and it should be automated - there are lots of reasons to dive into the API!

Julius Dein is the most popular social media creator in thew world. He has tens of millions of followers across various platforms and earns billions of views per month. Julius is also an incredibly intelligent business man who understands the business behind content better than most.  In this conversation, we discuss growing social channels, earning billions of views per month, making videos go viral, scaling a content team, building an eight-figure business, and why Julius is excited about bitcoin.    ======================= BlockFi provides financial products for crypto investors. Products include high-yield interest accounts, USD loans, and no fee trading. To start earning today visit: http://www.blockfi.com/Pomp ======================= Choice is a new self-directed IRA product that I'm really excited about. If you are listening to this, you are likely part of the 7.1 million bitcoin owners who have retirement accounts with dollars in them, but not bitcoin. I was in that situation too. Now you can actually buy real Bitcoin in your retirement account. I'm talking about owning your private keys and using tax-advantaged dollars to do it too. Absolute game changer. https://www.retirewithchoice.com/pomp ======================= Circle is a global financial technology firm that enables businesses of all sizes to harness the power of stablecoins and public blockchains for payments, commerce and financial applications worldwide. Circle is also a principal developer of USD Coin (USDC), the fastest growing, fully reserved and regulated dollar stablecoin in the world. The free Circle Account and suite of platform API services bridge the gap between traditional payments and crypto for trading, DeFi, and NFT marketplaces. Create seamless, user-friendly, mainstream customer experiences with crypto-native infrastructure under the hood with Circle. Learn more at circle.com.