Podcasts about Google Cloud

Explore Stairwell's role in reshaping cybersecurity with advanced strategies, and their collaborative efforts with SADA. Cloud N Clear episode 169 covers their innovative attack detection methods, big data security solutions, and their strategic partnership with SADA.  Find out how Stairwell is making a difference in the cyber insurance space and check out their solutions on the Google Cloud Marketplace Join this engaging episode, and don't forget to LIKE, SHARE, & SUBSCRIBE for more content! ✅

Robert Ross, CEO and Co-Founder at FireHydrant, joins Corey on Screaming in the Cloud to discuss how being an on-call engineer fighting incidents inspired him to start his own company. Robert explains how FireHydrant does more than just notify engineers of an incident, but also helps them to be able to effectively put out the fire. Robert tells the story of how he “accidentally” started a company as a result of a particularly critical late-night incident, and why his end goal at FireHydrant has been and will continue to be solving the problem, not simply choosing an exit strategy. Corey and Robert also discuss the value and pricing models of other incident-reporting solutions and Robert shares why he feels surprised that nobody else has taken the same approach FireHydrant has. About RobertRobert Ross is a recovering on-call engineer, and the CEO and co-founder at FireHydrant. As the co-founder of FireHydrant, Robert plays a central role in optimizing incident response and ensuring software system reliability for customers. Prior to founding FireHydrant, Robert previously contributed his expertise to renowned companies like Namely and Digital Ocean. Links Referenced: FireHydrant: https://firehydrant.com/ Twitter: https://twitter.com/bobbytables 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: Developers are responsible for more than ever these days. Not just the code they write, but also the containers and cloud infrastructure their apps run on. And a big part of that responsibility is app security — from code to cloud. That's where Snyk comes in. Snyk is a frictionless security platform that meets teams where they are, automating application security controls across their existing tools, workflows, and the AWS application stack — including seamless integrations with AWS CodePipeline, Amazon EKS, Amazon Inspector and several others. I'm a customer myself. Deploy on AWS. Secure with Snyk. Learn more at snyk.co/scream. That's S-N-Y-K-dot-C-O/scream.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. And this featured guest episode is brought to us by our friends at FireHydrant and for better or worse, they've also brought us their CEO and co-founder, Robert Ross, better known online as Bobby Tables. Robert, thank you for joining us.Robert: Super happy to be here. Thanks for having me.Corey: Now, this is the problem that I tend to have when I've been tracking companies for a while, where you were one of the only people that I knew of at FireHydrant. And you kind of still are, so it's easy for me to imagine that, oh, it's basically your own side project that turned into a real job, sort of, side hustle that's basically you and maybe a virtual assistant or someone. I have it on good authority—and it was also signaled by your Series B—that there might be more than just you over there now.Robert: Yes, that's true. There's a little over 60 people now at the company, which is a little mind-boggling for me, starting from side projects, building this in Starbucks to actually having people using the thing and being on payroll. So, a little bit of a crazy thing for me. But yes, over 60.Corey: So, I have to ask, what is it you folks do? When you say ‘fire hydrant,' the first thing that I think I was when I was a kid getting yelled at by the firefighter for messing around with something I probably shouldn't have been messing around with.Robert: So, it's actually very similar where I started it because I was messing around with software in ways I probably shouldn't have and needed a fire hydrant to help put out all the fires that I was fighting as an on-call engineer. So, the name kind of comes from what do you need when you're putting out a fire? A fire hydrant. So, what we do is we help people respond to incidents really quickly, manage them from ring to retro. So, the moment you declare an incident, we'll do all the timeline tracking and eventually help you create a retrospective at the very end. And it's been a labor of love because all of that was really painful for me as an engineer.Corey: One of the things that I used to believe was that every company did something like this—and maybe they do, maybe they don't—I'm noticing these days an increasing number of public companies will never admit to an incident that very clearly ruined things for their customers. I'm not sure if they're going to talk privately to customers under NDAs and whatnot, but it feels like we're leaving an era where it was an expectation that when you had a big issue, you would do an entire public postmortem explaining what had happened. Is that just because I'm not paying attention to the right folks anymore, or are you seeing a downturn in that?Robert: I think that people are skittish of talking about how much reliability they—or issues they may have because we're having this weird moment where people want to open more incidents like the engineers actually want to say we have more incidents and officially declare those, and in the past, we had these, like, shadow incidents that we weren't officially going to say it was an incident, but was a pretty big deal, but we're not going to have a retro on it so it's like it didn't happen. And kind of splitting the line between what's a SEV1, when should we actually talk about this publicly, I think companies are still trying to figure that out. And then I think there's also opposing forces. We talk to folks and it's, you know, public relations will sometimes get involved. My general advice is, like, you should be probably talking about it no matter what. That's how you build trust.It's trust, with incidences, lost in buckets and gained back in drops, so you should be more public about it. And I think my favorite example is a major CDN had a major incident and it took down, like, the UK government website. And folks can probably figure out who I'm talking about, but their stock went up the next day. You would think that a major incident taking down a large portion of the internet would cause your stock to go down. Not the case. They were on it like crazy, they communicated about it like crazy, and lo and behold, you know, people were actually pretty okay with it as far as they could be at the end of the day.Corey: The honest thing that really struck me about that was I didn't realize that CDN that you're referencing was as broadly deployed as it was. Amazon.com took some downtime as a result of this.Robert: Yeah.Corey: It's, “Oh, wow. If they're in that many places, I should be taking them more seriously,” was my takeaway. And again, I don't tend to shame folks for incidents because as soon as you do that, they stopped talking about them. They still have them, but then we all lose the ability to learn from them. I couldn't help but notice that the week that we're recording this, so there was an incident report put out by AWS for a Lambda service event in Northern Virginia.It happened back in June, we're recording this late in October. So, it took them a little bit of time to wind up getting it out the door, but it's very thorough, very interesting as far as what it talks about as far as their own approach to things. Because otherwise, I have to say, it is easy as a spectator slash frustrated customer to assume the absolute worst. Like, you're sitting around there and like, “Well, we have a 15-minute SLA on this, so I'm going to sit around for 12 minutes and finish my game of solitaire before I answer the phone.” No, it does not work that way. People are scrambling behind the scenes because as systems get more complicated, understanding the interdependencies of your own system becomes monstrous.I still remember some of the very early production engineering jobs that I had where—to what you said a few minutes ago—oh, yeah, we'll just open an incident for every alert that goes off. Then we dropped a [core switch 00:05:47] and Nagio sent something like 8000 messages inside of two minutes. And we would still, 15 years later, not be done working through that incident backlog had we done such a thing. All of this stuff gets way harder than you would expect as soon as your application or environment becomes somewhat complicated. And that happens before you realize it.Robert: Yeah, much faster. I think that, in my experience, there's a moment that happens for companies where maybe it's the number of customers you have, number of servers you're running in production, that you have this, like, “Oh, we're running a big workload right now in a very complex system that impacts people's lives, frankly.” And the moment that companies realize that is when you start to see, like, oh, process change, you build it, you own it, now we have an SRE team. Like, there's this catalyst that happens in all of these companies that triggers this. And it's—I don't know, from my perspective, it's coming at a faster rate than people probably realize.Corey: From my perspective, I have to ask you this question, and my apologies in advance if it's one of those irreverent ones, but do you consider yourself to be an observability company?Robert: Oh, great question. No. No, actually. We think that we are the baton handoff between an observability tool and our platform. So, for example, we think that that's a good way to kind of, you know, as they say, monitor the system, give reports on that system, and we are the tool that based on that monitor may be going off, you need to do something about it.So, for example, I think of it as like a smoke detector in some cases. Like, in our world, like that's—the smoke detector is the thing that's kind of watching the system and if something's wrong, it's going to tell you. But at that point, it doesn't really do anything that's going to help you in the next phase, which is managing the incident, calling 911, driving to the scene of the fire, whatever analogies you want to use. But I think the value-add for the observability tools and what they're delivering for businesses is different than ours, but we touch each other, like, very much so.Corey: Managing an incident when something happens and diagnosing what is the actual root cause of it, so to speak—quote-unquote, “Root cause.” I know people have very strong opinions on—Robert: Yeah, say the word [laugh].Corey: —that phrase—exactly—it just doesn't sound that hard. It is not that complicated. It's, more or less, a bunch of engineers who don't know what they're actually doing, and why are they running around chasing this stuff down is often the philosophy of a lot of folks who have never been in the trenches dealing with these incidents themselves. I know this because before I was exposed to scale, that's what I thought and then, oh, this is way harder than you would believe. Now, for better or worse, an awful lot of your customers and the executives at those customers did, for some strange reason, not come up through production engineering as the thing that they've done. They are executives, so it feels like it would be a challenging conversation to have with them, but one thing that you've got in your back pocket, which I always love talking to folks about, is before this, you were an engineer and then you became a CEO of a reasonably-sized company. That is a very difficult transition. Tell me about it.Robert: Yeah. Yeah, so a little of that background. I mean, I started writing code—I've been writing code for two-thirds of my life. So, I'm 32 now; I'm relatively young. And my first job out of high school—skipping college entirely—was writing code. I was 18, I was working in a web dev shop, I was making good enough money and I said, you know what? I don't want to go to college. That sounds—I'm making money. Why would I go to college?And I think it was a good decision because I got to be able—I was right kind of in the centerpiece of when a lot of really cool software things were happening. Like, DevOps was becoming a really cool term and we were seeing the cloud kind of emerge at this time and become much more popular. And it was a good opportunity to see all this confluence of technology and people and processes emerge into what is, kind of like, the base plate for a lot of how we build software today, starting in 2008 and 2009. And because I was an on-call engineer during a lot of that, and building the systems as well, that I was on call for, it meant that I had a front-row seat to being an engineer that was building things that was then breaking, and then literally merging on GitHub and then five minutes later [laugh], seeing my phone light up with an alert from our alerting tool. Like, I got to feel the entire process.And I think that that was nice because eventually one day, I snapped. And it was after a major incident, I snapped and I said, “There's no tool that helps me during this incident. There's no tool that kind of helps me run a process for me.” Because the only thing I care about in the middle of the night is going back to bed. I don't have any other priority [laugh] at 2 a.m.So, I wanted to solve the problem of getting to the fire faster and extinguishing it by automating as much as I possibly could. The process that was given to me in an outdated Confluence page or Google Doc, whatever it was, I wanted to automate that part so I could do the thing that I was good at as an engineer: put out the fire, take some notes, and then go back to bed, and then do a retrospective sometime next day or in that week. And it was a good way to kind of feel the problem, try to build a solution for it, tweak a little bit, and then it kind of became a company. I joke and I say on accident, actually.Corey: I'll never forget one of the first big, hairy incidents that I had to deal with in 2009, where my coworker had just finished migrating the production environment over to LDAP on a Thursday afternoon and then stepped out for a three-day weekend, and half an hour later, everything started exploding because LDAP will do that. And I only had the vaguest idea of how LDAP worked at all. This was a year into my first Linux admin job; I'd been a Unix admin before that. And I suddenly have the literal CEO of the company breathing down my neck behind me trying to figure out what's going on and I have no freaking idea of myself. And it was… feels like there's got to be a better way to handle these things.We got through. We wound up getting it back online, no one lost their job over it, but it was definitely a touch-and-go series of hours there. And that was a painful thing. And you and I went in very different directions based upon experiences like that. I took a few more jobs where I had even worse on-call schedules than I would have believed possible until I started this place, which very intentionally is centered around a business problem that only exists during business hours. There is no 2 a.m. AWS billing emergency.There might be a security issue masquerading as one of those, but you don't need to reach me out of business hours because anything that is a billing problem will be solved in Seattle's timeline over a period of weeks. You leaned into it and decided, oh, I'm going to start a company to fix all of this. And okay, on some level, some wit that used to work here, wound up once remarking that when an SRE doesn't have a better idea, they start a monitoring company.Robert: [laugh].Corey: And, on some level, there's some validity to it because this is the problem that I know, and I want to fix it. But you've differentiated yourself in a few key ways. As you said earlier, you're not an observability company. Good for you.Robert: Yeah. That's a funny quote.Corey: Pete Cheslock. He has a certain way with words.Robert: Yeah [laugh]. I think that when we started the company, it was—we kind of accidentally secured funding five years ago. And it was because this genuinely was something I just, I bought a laptop for because I wanted to own the IP. I always made sure I was on a different network, if I was going to work on the company and the tool. And I was just writing code because I just wanted to solve the problem.And then some crazy situation happened where, like, an investor somehow found FireHydrant because they were like, “Oh, this SRE thing is a big space and incidents is a big part of it.” And we got to talking and they were like, “Hey, we think what you're building is valuable and we think you should build a company here.” And I was—like, you know, the Jim Carrey movie, Yes Man? Like, that was kind of me in that moment. I was like, “Sure.” And here we are five years later. But I think the way that we approached the problem was let's just solve our own problem and let's just build a company that we want to work at.And you know, I had two co-founders join me in late 2018 and that's what we told ourselves. We said, like, “Let's build a company that we want to work for, that solves problems that we have had, that we care about solving.” And I think it's worked out, you know? We work with amazing companies that use our tool—much to their chagrin [laugh]—multiple times a day. It's kind of a problem when you build an incident response tool is that it's a good thing when people are using it, but a bad thing for them.Corey: I have to ask of all of the different angles to approach this from, you went with incident management as opposed to focusing on something that is more purely technical. And I don't say that in any way that is intended to be sounding insulting, but it's easier from an engineering mind to—having been one myself—to come up with, “Here's how I make one computer talk to his other computer when the following event happens.” That's a much easier problem by orders of magnitude than here's how I corral the humans interacting with that computer's failure to talk to another computer in just the right way. How did you get onto this path?Robert: Yeah. The problem that we were trying to solve for it was the getting the right people in the room problem. We think that building services that people own is the right way to build applications that are reliable and stable and easier to iterate on. Put the right people that build that software, give them, like, the skin in the game of also being on call. And what that meant for us is that we could build a tool that allowed people to do that a lot easier where allowing people to corral the right people by saying, “This service is broken, which powers this functionality, which means that these are the people that should get involved in this incident as fast as possible.”And the way we approached that is we just built up part of our functionality called Runbooks, where you can say, “When this happens, do this.” And it's catered for incidents. So, there's other tools out there, you can kind of think of as, like, we're a workflow tool, like Zapier, or just things that, like, fire webhooks at services you build and that ends up being your incident process. But for us, we wanted to make it, like, a really easy way that a project manager could help define the process in our tool. And when you click the button and say, “Declare Incident: LDAP is Broken,” and I have a CEO standing behind me, our tool just would corral the people for you.It was kind of like a bat signal in the air, where it was like, “Hey, there's this issue. I've run all the other process. I just need you to arrive at and help solve this problem.” And we think of it as, like, how can FireHydrant be a mech suit for the team that owns incidents and is responsible for resolving them?Corey: There are a few easier ways to make a product sound absolutely ridiculous than to try and pitch it to a problem that it is not designed to scale to. What is the ‘you must be at least this tall to ride' envisioning for FireHydrant? How large slash complex of an organization do you need to be before this starts to make sense? Because I promise, as one person with a single website that gets no hits, that is probably not the best place for—Robert: Probably not.Corey: To imagine your ideal user persona.Robert: Well, I'm sure you get way more hits than that. Come on [laugh].Corey: It depends on how controversial I'm being in a given week.Robert: Yeah [laugh].Corey: Also, I have several ridiculous, nonsense apps out there, but honestly, those are for fun. I don't charge people for them, so they can deal with my downtime till I get around to it. That's the way it works.Robert: Or, like, spite-visiting your website. No it's—for us, we think that the ‘must be this tall' is when do you have, like, sufficiently complicated incidents? We tell folks, like, if you're a ten-person shop and you have incidents, you know, just use our free tier. Like, you need something that opens a Slack channel? Fine. Use our free tier or build something that hits the Slack API [unintelligible 00:18:18] channel. That's fine.But when you start to have a lot of people in the room and multiple pieces of functionality that can break and multiple people on call, that's when you probably need to start to invest in incident management. Because it is a return on investment, but there is, like, a minimum amount of incidents and process challenges that you need to have before that return on investment actually, I would say, comes to fruition. Because if you do think of, like, an incident that takes downtime, or you know, you're a retail company and you go down for, let's say, ten minutes, and your number of sales per hour is X, it's actually relatively simple for that type of company to understand, okay, this is how much impact we would need to have from an incident management tool for it to be valuable. And that waterline is actually way—it's way lower than I think a lot of people realize, but like you said, you know, if you have a few 100 visitors a day, it's probably not worth it. And I'll be honest there, you can use our free tier. That's fine.Corey: Which makes sense. It's challenging to wind up-sizing things appropriately. Whenever I look at a pricing page, there are two things that I look for. And incidentally, when I pull up someone's website, I first make a beeline for pricing because that is the best way I found for a lot of the marketing nonsense words to drop away and it get down to brass tacks. And the two things I want are free tier or zero-dollar trial that I can get started with right now because often it's two in the morning and I'm trying to see if this might solve a problem that I'm having.And I also look for the enterprise tier ‘contact us' because there are big companies that do not do anything that is not custom nor do they know how to sign a check that doesn't have two commas in it. And whatever is between those two, okay, that's good to look at to figure out what dimensions I'm expected to grow on and how to think about it, but those are the two tent poles. And you've got that, but pricing is always going to be a dark art. What I've been seeing across the industry. And if we put it under the broad realm of things that watch your site and alert you and help manage those things, there are an increasing number of, I guess what I want to call component vendors, where you'll wind up bolting together a couple dozen of these things together into an observability pipeline-style thing, and each component seems to be getting extortionately expensive.Most of the wake-up-in-the-middle-of-the-night services that will page you—and there are a number of them out there—at a spot check of these, they all cost more per month per user than Slack, the thing that most of us to end up living within. This stuff gets fiendishly expensive, fiendishly quickly, and at some point, you're looking at this going, “The outage is cheaper than avoiding the outage through all of these things. What are we doing here?” What's going on in the industry, other than ‘money printing machine stopped going brrr' in quite the same way?Robert: Yeah, I think that for alerting specifically, this is a big part of, like, the journey that we wanted to have in FireHydrant was like, we also want to help folks with the alerting piece. So, I'll focus on that, which is, I think that the industry around notifying people for incidents—texts, call, push notifications, emails, there's a bunch of different ways to do it—I think where it gets really crazy expensive as in this per-seat model that most of them seem to have landed on. And we're per-seat for, like, the core platform of FireHydrant—so you know, before people spite-visit FireHydrant, look at our pricing pitch—but we're per-seat there because the value there is, like, we're the full platform for the service catalog retrospectives, Runbooks, like, there's a whole other component of FireHydrant—status pages—but when it comes to alerting, like, in my opinion, that should be active user for a few reasons. I think that if you're going to have people responding to incidents and the value from us is making sure they get to that incident very quickly because we wake them up in the middle of the night, we text them, we call them we make their Hue lights turn red, whatever it is, then that's, like, the value that we're delivering at that moment in time, so that's how we should probably invoice you.And I think that what's happened is that the pricing for these companies, they haven't innovated on the product in a way that allows them to package that any differently. So, what's happened, I think, is that the packaging of these products has been almost restrictive in the way that they could change their pricing models because there's nothing much more to package on. It's like, cool there's an alerting aspect to this, but that's what people want to buy those tools for. They want to buy the tool so it wakes them up. But that tool is getting more expensive.There was even a price increase announced today for a big one [laugh] that I've been publicly critical of. That is crazy expensive for a tool that texts you and call you. And what peo—what's going on now are people are looking, they're looking at the pricing sheet for Twilio and going, “What the heck is going on?” Like, I—to send a text on Twilio in the United States is fractions of a penny and here we are paying $40 a user for that person to receive six texts that month because of a webhook that hit an HCP server and, like, it's supposed to call that person? That's kind of a crazy model if you think about it. Like, engineers are kind of going, “Wait a minute. What's up here?” Like, and when engineers start thinking, “I could build this on a weekend,” like, something's wrong, like, with that model. And I think that people are starting to think that way.Corey: Well engineers, to be fair, will think that about an awful lot of stuff.Robert: Anything. Yeah, they [laugh]—Corey: I've heard it said about Dropbox, Facebook, the internet—Robert: Oh, Dropbox is such a good one.Corey: BGP. Yeah okay, great. Let me know how that works out for you.Robert: What was that Dropbox comment on Hacker News years ago? Like, “Just set up NFS and host it that way and it's easy.” Right?Corey: Or rsync. Yeah—Robert: Yeah, it was rsync.Corey: What are you going to make with that? Like, who's going to buy that? Like, basically everyone for at least a time.Robert: And whether or not the engineers are right, I think is a different point.Corey: It's the condescension dismissal of everything that isn't writing the code that really galls, on some level.Robert: But I think when engineers are thinking about, like, “I could build this on a weekend,” like, that's a moment that you have an opportunity to provide the value in an innovative, maybe consolidated way. We want to be a tool that's your incident management ring to retro, right? You get paged in the middle of the night, we're going to wake you up, and when you open up your laptop, groggy-eyed, and like, you're about to start fighting this fire, FireHydrant's already done a lot of work. That's what we think is, like, the right model do this. And candidly, I have no idea why the other alerting tools in this space haven't done this. I've said that and people tend to nod in agreement and say like, “Yeah, it's been—it's kind of crazy how they haven't approached this problem yet.” And… I don't know, I want to solve that problem for folks.Corey: So, one thing that I have to ask, you've been teasing on the internet for a little bit now is something called Signals where you are expanding your product into the component that wakes people up in the middle of the night, which in isolation, fine, great, awesome. But there was a company whose sole stated purpose was to wake people up in the middle of the night, and then once they started doing some business things such as, oh I don't know, going public, they needed to expand beyond that to do a whole bunch of other things. But as a customer, no, no, no, you are the thing that wakes me up in the middle of the night. I don't want you to sprawl and grow into everything else because if you're going to have to pick a vendor that claims to do everything, well, I'll just stay with AWS because they already do that and it's one less throat to choke. What is that pressure that is driving companies that are spectacular at the one thing to expand into things that frankly, they don't have the chops to pull off? And why is this not you doing the same thing?Robert: Oh, man. The end of that question is such a good one and I like that. I'm not an economist. I'm not—like, that's… I don't know if I have a great comment on, like, why are people expanding into things that they don't know how to do. It seems to be, like, a common thing across the industry at a certain point—Corey: Especially particularly generative AI. “Oh, we've been experts in this for a long time.” “Yeah, I'm not that great at dodgeball, but you also don't see me mouthing off about how I've been great at it and doing it for 30 years, either.”Robert: Yeah. I mean, there was a couple ads during football games I watched. I'm like, “What is this AI thing that you just, like, tacked on the letter X to the end of your product line and now all of a sudden, it's AI?” I have plenty of rants that are good for a cocktail at some point, but as for us, I mean, we knew that we wanted to do alerting a long time ago, but it does have complications. Like, the problem with alerting is that it does have to be able to take a brutal punch to the face the moment that AWS us-east-2 goes down.Because at that moment in time, a lot of webhooks are coming your way to wake somebody up, right, for thousands of different companies. So, you do have to be able to take a very, very sufficient amount of volume instantaneously. So, that was one thing that kind of stopped us. In 2019 even, we wrote a product document about building an alerting tool and we kind of paused. And then we got really deep into incident management, and the thing that makes us feel very qualified now is that people are actually already integrating their alerting tools into FireHydrant today. This is a very common thing.In fact, most people are paying for a FireHydrant and an alerting tool. So, you can imagine that gets a little expensive when you have both. So, we said, well, let's help folks consolidate, let's help folks have a modern version of alerting, and let's build on top of something we've been doing very well already, which is incident management. And we ended up calling it Signals because we think that we should be able to receive a lot of signals in, do something correct with them, and then put a signal out and then transfer you into incident management. And yeah, we're are excited for it actually. It's been really cool to see it come together.Corey: There's something to be said for keeping it in a certain area of expertise. And people find it very strange when they reach out to my business partner and me asking, okay, so are you going to expand into Google Cloud or Azure or—increasingly, lately—Datadog—which has become a Fortune 500 board-level expense concern, which is kind of wild to me, but here we are—and asking if we're going to focus on that, and our answer is no because it's very… well, not very, but it is relatively easy to be the subject matter expert in a very specific, expensive, painful problem, but as soon as you start expanding that your messaging loses focus and it doesn't take long—since we do you view this as an inherent architectural problem—where we're saying, “We're the best cloud engineers and cloud architects in the world,” and then we're competing against basically everyone out there. And it costs more money a year for Accenture or Deloitte's marketing budget than we'll ever earn as a company in our entire lifetime, just because we are not externally boosted, we're not putting hundreds of people into the field. It's a lifestyle business that solves an expensive, painful problem for our customers. And that focus lends clarity. I don't like the current market pressure toward expansion and consolidation at the cost of everything, including it seems, customer trust.Robert: Yeah. That's a good point. I mean, I agree. I mean, when you see a company—and it's almost getting hard to think about what a company does based on their name as well. Like, names don't even mean anything for companies anymore. Like Datadog has expanded into a whole lot of things beyond data and if you think about some of the alerting tools out there that have names of, like, old devices that used to attach to our hips, that's just a different company name than what represents what they do.And I think for us, like, incidents, that's what we care about. That's what I know. I know how to help people manage incidents. I built software that broke—sometimes I was an arsonist—sometimes I was a firefighter, it really depends, but that's the thing that we're going to be good at and we're just going to keep building in that sphere.Corey: I think that there's a tipping point that starts to become pretty clear when companies focus away from innovating and growing and serving customers into revenue protection mode. And I think this is a cyclical force that is very hard to resist. But I can tell even having conversations like this with folks, when the way that a company goes about setting up one of these conversations with me, you came by yourself, not with a squadron of PR people, not with a whole giant list of talking points you wanted to go to, just, “Let's talk about this stuff. I'm interested in it.”As a company grows, that becomes more and more uncommon. Often, I'll see it at companies a third the size of yours, just because there's so much fear around everything we say must be spoken in such a way that it could never be taken in a negative way against us. That's not the failure mode. The failure mode is that no one listens to you or cares what you have to say. At some point, yeah, I get the shift, but damned if it doesn't always feel like it's depressing.Robert: Yeah. This is such great questions because I think that the way I think about it is, I care about the problem and if we solve the problem and we solve it well and people agree with us on our solution being a good way to solve that problem, then the revenue, like, happens because of that. I've gotten asked from, like, from VCs and customers, like, “What's your end goal with FireHydrant as the CEO of the company?” And what they're really asking is, like, “Do you want to IPO or be acquired?” That's always a question every single time.And my answer is, maybe, I don't know, philosophical, but it's, I think if we solve the problem, like, one of those will happen, but that's not the end goal. Because if I aim at that, we're going to come up short. It's like how they tell you to throw a ball, right? Like they don't say, aim at the glove. They say, like, aim behind the person.And that's what we want to do. We just want to aim at solving a problem and then the revenue will come. You have to be smart about it, right? It's not a field of dreams, like, if you build it, like, revenue arrives, but—so you do have to be conscious of the business and the operations and the model that you work within, but it should all be in service of building something that's valuable.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where should they go to find you, other than, you know, to their most recent incident page?Robert: [laugh]. No, thanks for having me. So, to learn more about me, I mean, you can find me on Twitter on—or X. What do we call it now?Corey: I call it Twitter because I don't believe in deadnaming except when it's companies.Robert: Yeah [laugh]. twitter.com/bobbytables if you want to find me there. If you want to learn more about FireHydrant and what we're doing to help folks with incidents and incident response and all the fun things in there, it's firehydrant.com or firehydrant.io, but we'll redirect you to dot com.Corey: And we will, of course, put a link to all of that in the [show notes 00:33:10]. Thank you so much for taking the time to speak with me. It's deeply appreciated.Robert: Thank you for having me.Corey: Robert Ross, CEO and co-founder of FireHydrant. This featured guest episode has been brought to us by our friends at FireHydrant, and I'm Corey Quinn. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that will never see the light of day because that crappy platform you're using is having an incident that they absolutely do not know how to manage effectively.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.

"As long as you continue to progress forward, you don't really run into an issue because the bot is not going to outrun the human in terms of innovation right now." Chris was joined by Sarah Kennedy Ellis, Vice President of Google Cloud, to talk about the current and future impact of AI in Marketing. They highlight the areas where AI can be implemented today, such as content generation, process automation, and data analysis. They also discuss the challenges and considerations in adopting AI in marketing strategies. Then, Sarah turns the conversation back around to Chris to find out how Refine Labs is putting AI into practical applications, and how he feels about the ability to create learning models around thought leaders like himself.  Thanks to our friends at Hatch for producing this episode. Get unlimited podcast editing at www.hatch.fm

The podcast features Sean Emory from Avory & Co discussion with Soren Larson from Crosshatch, a company focused on personalized AI. Larson discusses his background in ad tech and fighting Russian bots, as well as his experience with personalization at Walmart. The mission of Crosshatch is to hyper-personalize the internet in a safe way. 00:03:52 Hyper-personalizing the internet safely. 00:05:27 Hyper-personalization is the future. 00:11:06 Personalization through generative AI. 00:17:14 Data sharing should be contextual. 00:22:49 Identity layer enables personalized experiences. 00:25:42 Unlocking new digital experiences through safe data sharing. 00:34:20 Miami is a place to build. ______ Disclaimer Avory & Co. is a Registered Investment Adviser. This platform is solely for informational purposes. Advisory services are only offered to clients or prospective clients where Avory & Co. and its representatives are properly licensed or exempt from licensure. Past performance is no guarantee of future returns. Investing involves risk and possible loss of principal capital. No advice may be rendered by Avory & Co. unless a client service agreement is in place. Listeners and viewers are encouraged to seek advice from a qualified tax, legal, or investment adviser to determine whether any information presented may be suitable for their specific situation. Past performance is not indicative of future performance. “Likes” are not intended to be endorsements of our firm, our advisors or our services. Please be aware that while we monitor comments and “likes” left on this page, we do not endorse or necessarily share the same opinions expressed by site users. While we appreciate your comments and feedback, please be aware that any form of testimony from current or past clients about their experience with our firm is strictly forbidden under current securities laws. Please honor our request to limit your posts to industry-related educational information and comments. Third-party rankings and recognitions are no guarantee of future investment success and do not ensure that a client or prospective client will experience a higher level of performance or results. These ratings should not be construed as an endorsement of the advisor by any client nor are they representative of any one client's evaluation. Please reach out to Houston Hess our head of Compliance and Operations for any further details. Find more here https://www.avory.xyz/disclaimer-page Keywords investors, Meta, Google, Amazon, Microsoft,Meta, Google, funnel, awareness, performance, digital advertising, growth, tech budgets, Google Cloud, Microsoft Azure, Amazon AWS, revenue, computing platform, infrastructure, growth, stabilization, bookings, analyst estimates, Google Cloud, machine learning, AI, leader, revenue growth, demand, open AI,Microsoft, open AI, generative AI, Azure, training, LLMs, Google, BARD, GPT-4, OpenAI, noun, winner-take-all, players, growing, accelerating growth, buyers, companies, cloud spend, advertising spend, revenue, Amazon, GDP, earnings, S&P 500, deviation, international, U.S., revenue line, 2024.,analyst estimates, growth, consumer, corporations, spending habits

In this episode, Dave Sobel discusses four important updates in the world of technology. First, he explores the next wave of cloud computing and the increasing demand for migrating complex workloads. He then delves into the new SEC cyber incident rules, highlighting how they provide a boost for MSPs and aid in client compliance. Next, he shares insights from an ECB research report that debunks fears of AI job cuts, suggesting that high-skilled employment may actually rise. Lastly, he addresses the controversy surrounding a tech conference's fake diversity efforts, emphasizing the importance of ethical principles. Additionally, Dave discusses the latest Canalys report, which reveals that global spending on cloud infrastructure services has reached $73.5 billion, with AWS, Azure, and Google Cloud leading the market.Four things to know today00:00 Next Wave of Cloud Computing: Migration of Complex Workloads and New Customer Demand04:42 New SEC Cyber Incident Rules: A Boost for MSPs in Client Compliance Assistance08:28 An ECB Research Report Debunks AI Job Cut Fears: High-Skilled Employment May Rise by up to 4.3%10:57 Tech Conference Faces Outrage Over Fake Diversity Efforts: A Lesson in Ethical PracticesSupported by: https://gozynta.com/eureka/Want to take my class? https://www.itspu.com/all-classes/classes/navigating-emerging-technologies-for-msps/Looking for a link from the stories? The entire script of the show, with links to articles, are posted in each story on https://www.businessof.tech/Do you want the show on your podcast app or the written versions of the stories? Subscribe to the Business of Tech: https://www.businessof.tech/subscribe/Support the show on Patreon: https://patreon.com/mspradio/Want our stuff? Cool Merch? Wear “Why Do We Care?” - Visit https://mspradio.myspreadshop.comFollow us on:LinkedIn: https://www.linkedin.com/company/28908079/YouTube: https://youtube.com/mspradio/Facebook: https://www.facebook.com/mspradionews/Instagram: https://www.instagram.com/mspradio/TikTok: https://www.tiktok.com/@businessoftech

Gary Harmson (Principal Customer Engineer @Google) and Ieva Jonaityte (Technical Account Mgr @DoIT) talk about the team dynamics, culture and training that drive FinOps success. SHOW: 775CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT - "CLOUDCAST BASICS"SHOW SPONSORS:Datadog Application Monitoring: Modern Application Performance MonitoringGet started monitoring service dependencies to eliminate latency and errors and enhance your users app experience with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt.CloudZero – Cloud Cost Visibility and Savings​​CloudZero provides immediate and ongoing savings with 100% visibility into your total cloud spendSHOW NOTES:DoIT HomepageSimplifying FinOps for AI Workloads (Eps.719)Leveraging FinOps to Scale a Startup (Eps. 761)DIKW Pyramid - Framework for data classificationTopic 1 - Welcome to the show and back to the show. Gary, tell us about your background and what areas you focus on at Google Cloud these days. Topic 2 - Let's begin by talking about language, specifically the gaps in language (and understanding) between engineering teams and finance teams. What works today and where are the biggest gaps and challenges?Topic 3 - One of the challenges of Cloud billing, and hence FinOps, is the 100s or 1000s or line-items. What are they for? How are they changing? What are some of the things/tools out there to make sense of all of this spend? (e.g. visualization, tagging, etc.)Topic 4 - We're all familiar with budgeting (pre-activity) and complaints about project/cost overruns (post-activity), but what are some of the things happening mid-project, or on-going to avoid the surprises or overruns?Topic 5 - How much of these on-going changes/tracking is done by the engineering teams and how much is being done by finance teams? Topic 6 - Can you share with us examples of how companies have evolved with good FinOps principles and hygiene in place? FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

Rocky Giglio welcomes Ram Varadarajan, founder and CEO of Acalvio, to discuss the cutting-edge world of deceptive technology. Cloud N Clear episode 168 delves into Acalvio's innovative strategies, its integration with Google Cloud, and how deceptive tech is reshaping cybersecurity.  Discover how Acalvio differentiates itself from traditional HoneyPot methods with help from SADA and what the future holds for this dynamic field. Join this engaging episode, and don't forget to LIKE, SHARE, & SUBSCRIBE for more content! ✅  

Segundo um estudo da Catho, 65% dos executivos preferem não contratar pessoas gordas. Essa mesma pesquisa aponta que 50% dessa população sofre com a falta de cadeiras, mobiliários e uniformes adequados no ambiente de trabalho. Onde está a dificuldade em criarmos ambientes mais acolhedores e positivos para todos os tipos de corpos? Para falar um pouco sobre isso, Melina López, gerente de produto e inclusão no Google, bateu um papo com Alexandra Gurgel, Beta Boechat e Caio Revela do Movimento Corpo Livre e com Luana Nazareth, Gerente de Parcerias Estratégicas do YouTube. No episódio eles falam sobre as particularidades de cada corpo, a falta de acesso das pessoas gordas, o julgamento que elas sofrem e sobre repensar o olhar para o próprio corpo. O Ouça Mais Alto é o podcast sobre diversidade do Google Cloud. No programa, Melina recebe especialistas para conversar sobre como implementar iniciativas de diversidade, equidade e inclusão no ambiente corporativo e o impacto positivo que isso pode gerar. Confira os links deste episódio: Quer ouvir essa conversa na íntegra? Acesse no YouTube:  Conheça o Movimento Corpo Livre: www.instagram.com/movimentocorpolivre/ Recomendações da Luana Nazareth para continuar se inteirando sobre gordofobia: Gabriela Menezes, criadora do Saúde Sem Gordofobia (https://www.instagram.com/gabimenezes/) (https://www.instagram.com/saudesemgordofobia/) Ellen Valias do Atleta de Peso (https://www.instagram.com/atleta_de_peso/) Flávia Durante do Moda e Empreendedorismo Gordo (https://www.instagram.com/flaviadurante/?hl=en) Roz Mays, educadora física (https://www.instagram.com/rozthediva/).  Confira a primeira temporada do Ouça Mais Alto: bit.ly/OucaMaisAlto Leia aqui a transcrição do episódio: Em breve Conecte com a Melina López no LinkedIn: linkedin.com/in/lopezmelu Gostou do episódio ou tem alguma sugestão? Compartilha com a gente por e-mail em: googlecloudcast@google.com

On this episode of The Six Five – Insider, hosts Daniel Newman and Patrick Moorhead welcome Jeff Reed, VP Product, Cloud Security at Google Cloud for a conversation on how they are using AI to supercharge Google Cloud Security's unique combination of capabilities, including front line intelligence, security operations, and a secure cloud platform. Their discussion covers: How Generative AI tackles critical issues and how Google and Google Cloud Security adopt a strategic approach to this technology Google's unique stance on Cloud security and Generative AI, encompassing a broader perspective on their comprehensive portfolio Google's emphasis on security in the Generative AI domain, ensuring responsible and trustworthy advancement The latest innovations within Google Cloud and gain insights into the platform's exciting trajectory  

This week, Helen Kelisky, MD at Google Cloud UKI joins Gareth to discuss her leadership journey; from securing a role in juggernaut IBM, marking her entry into the tech space, to joining the powerhouse that is Google Cloud as the Managing Director UKI.  A proud advocate for diversity in tech, Helen has been recognised on Computer Weekly's Most Influential Women in Tech list for the last 6 years, exemplifying both her career successes and her external volunteering in organisations such as Women in Telecoms & Technology (WiTT). Helen gives us insight into her leadership success and how to manage a team in the most effective way possible, ensuring that ‘every day is a learning day', even for leaders. This episode is a must-listen for anyone curious to know more about cloud computing or anyone in need of some stellar leadership advice— we've got you covered. Timestamps What does good leadership mean to Helen? (01:36) Inclusivity in tech (04:42) An introduction to Helen (07:22) Helen's journey into tech (09:30) The workplace cultures of IBM, Salesforce and Google (13:15) What problems are Google Cloud trying to solve? (19:10) Helen's productivity and work-life balance tips (29:26) Advice to her younger self (32:20) Helen's charitable initiatives outside of work (33:44) *Book recommendations: Leadership and Self-Deception: Getting Out of the Box, Arbinger institute Leadership and Self-Deception: Getting... by Arbinger Institute (amazon.co.uk) / The Tipping Point, Malcom Gladwell The Tipping Point: How Little Things Can Make a Big Difference: Amazon.co.uk: Malcolm Gladwell: 9780349113463: Books / Factfulness: Ten Reasons We're Wrong About The World - And Why Things Are Better Than You Think, Hans Rosling & Ola Rosling & Anna Rosling Rönnlund Factfulness: Ten Reasons We're Wrong About... by Rosling, Hans (amazon.co.uk) 

Kathleen Vignos, VP of Software Engineering @ Capital One, shares how to overcome executive leadership gaps that prevent eng leaders from advancing to the next level in their career. She covers how she applies a portfolio approach to career growth, how that helped her build exec skills in a way, and tips for people who are reorienting their approach to career growth. We also cover how to bridge essential executive skill gaps like facilitation, negotiation, and influencing! Plus strategies for exceptional facilitation, balancing option limiting & option exploration, dealing with conflict / reframing, and negotiation strategies to aid in decision making.ABOUT KATHLEEN VIGNOSKathleen Vignos is a VP of software engineering at Capital One. Her organization, Customer Resiliency, builds web, mobile, and backend applications to meet customer needs in times of financial hardship so they can resolve their debt and get back on track. These applications run on a modern stack with ML decisioning and serverless components hosted on AWS. Previously in her 6 years at Twitter, Kathleen worked on promoted tweet review, tweet translation, abuse tooling, and infrastructure automation across on-prem, Google Cloud, and AWS environments. She also ran Twitter's development programs for engineering managers, personally training 300+ managers across the topics of people management, hiring, technical skills development, and project execution/delivery. Outside of strategic technology work, Kathleen is a distance runner and loves travel. She lives with her husband in San Francisco. They have 2 adult children and are working on plans to visit their sixth continent."I was hearing this message, 'You need to be more strategic.' I realized my definition of strategy in my head was not actually strategy and I needed to reframe strategy as being willing to completely blow everything up because there's a bigger, better thing you need to do and I think that if you are very organized and very goal oriented, you don't want to blow up your plan. You want to execute your plan. You're a great executor and that will get you to a certain level. So I think that's inflection point number one, at least it was for me and I think that's true for a lot of people. I see it over and over again.”- Kathleen Vignos   SHOW NOTES:How the career portfolio concept strategically drives career growth (2:33)Surprising discoveries in Kathleen's transition to tech (5:07)Parallels between Kathleen's early work & current eng leadership (7:12)The impact of a career portfolio on acquiring skills in a nonlinear way (10:47)Kathleen's tips for someone reorienting their approach to career growth (15:18)Common gaps / blocks people encounter on their career growth journey (17:08)Understanding your audience & the reach of your influence (20:13)Navigating the shift between being a great executor to a great strategist (22:23)Key principles of influencing & facilitation (24:49)Strategies for option limiting as a facilitator (27:01)How to facilitate to achieve time efficiency & positive option exploration (30:01)Applying facilitation strategies during the candidate hiring process (32:39)Examples of “polite interruption” phrases to use (35:31)Approaches for dealing with conflict & reframing (36:49)Recommendations for negotiating & decision making (39:47)Rapid fire questions (44:13)LINKS AND RESOURCESGetting More: How to Negotiate to Achieve Your Goals in the Real World - Based on Professor Stuart Diamond's award-winning course at the Wharton Business School, Getting More concludes that finding and valuing the other party's emotions and perceptions creates far more value than the conventional wisdom of power and logic. It is intended to provide better agreements for everyone no matter what they negotiate – from jobs to kids to billion-dollar deals to shopping.Playing to Win: How Strategy Really Works - A.G. Lafley, former CEO of Procter & Gamble, in close partnership with strategic adviser Roger Martin, doubled P&G's sales, quadrupled its profits, and increased its market value by more than $100 billion in just ten years. Now, drawn from their years of experience at P&G and the Rotman School of Management, where Martin is dean, this book shows how leaders in organizations of all sizes can guide everyday actions with larger strategic goals built around the clear, essential elements that determine business success— where to play and how to win.The Storyteller: Tales of Life and Music - Dave Grohl's memoir chronicling his early days growing up in the suburbs of Washington, DC, to hitting the road at the age of 18, and all the music that followed.Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts - Annie Duke, a former World Series of Poker champion turned business consultant, draws on examples from business, sports, politics, and (of course) poker to share tools anyone can use to embrace uncertainty and make better decisions.This episode wouldn't have been possible without the help of our incredible production team:Patrick Gallagher - Producer & Co-HostJerry Li - Co-HostNoah Olberding - Associate Producer, Audio & Video Editor https://www.linkedin.com/in/noah-olberding/Dan Overheim - Audio Engineer, Dan's also an avid 3D printer - https://www.bnd3d.com/Ellie Coggins Angus - Copywriter, Check out her other work at https://elliecoggins.com/about/

Google has been building the Cloud Marketplace to become more advantageous through its comprehensive user experience, making software deployment way easier for developers and end users alike. J.R. Lowry talks to the man behind this incredible undertaking: Dai Vu, Managing Director of Google's Cloud Marketplace. He shares how they handle the rapid growth of Google Cloud, particularly now that it has reached more than 1,000 solution partners and 3,000 solution listings. Dai also talks about his situational and collaborative leadership style, detailing how he sets a vision for his team, focuses on employee wellbeing, and gives importance to taking frequent breaks. Check out the full series of "Career Sessions, Career Lessons" podcasts here or visit pathwise.io/podcast/. A full written transcript of this episode is also available at https://pathwise.io/podcasts/dai-vu/

Here's what you need to know from this week in the business of podcasting: The Spoken Word Audio Report 2023YouTube Debuts New AI Content PoliciesSaving TikTok Songs to Spotify With New IntegrationAd Engagement Declines With Lack of RepresentationQuick Hits:Spotify's podcast and audiobook discovery will get a boost from Google Cloud's AI by Amrita Khalid. Google Cloud's Large Language Models will be used to scan all podcasts and audiobooks on Spotify to improve metadata and discoverability. Podcasting Lessons From Dogs by Tom Webster. This week Tom reflects on why podcasts with multiple hosts need an Abbot to their Costello. A traffic cop to direct the flow of conversation when need be.How I got 10x YouTube subscribers by adding video to my podcast by Ashley Hamer. A step-by-step account of Hamer adding video production to her existing podcast Taboo Science and how optimizing her YouTube channel boosted YouTube algorithm attention. Sound You Can See: Podcasting's Video Dilemma. On Wednesday, December 13th, Sounds Profitable will debut their latest study, which dives into consumer perceptions of podcasts on video and how they continue to drive the future of this medium.Global signs exclusive podcast distribution and licensing deal with iHeartMedia by Reem Makari. iHeartMedia podcasts will be distributed on the Global Media app in the UK and Ireland, while Global podcasts will be distributed in the U.S. on iHeartRadio's app, along with iHeartMedia monetization. Triton Podcast Ranker: October 2023. 48 Hours climbs two spots to enter the top 10 in 9th place, pushing Conan Needs a Friend down to #10.

David was the chief software architect and director of engineering at Stitch Fix. He's also the author of a number of books including Sustainable Web Development with Ruby on Rails and most recently Ruby on Rails Background Jobs with Sidekiq. He talks about how he made decisions while working with a medium sized team (~200 developers) at Stitch Fix. The audio quality for the first 19 minutes is not great but the correct microphones turn on right after that. Recorded at RubyConf 2023 in San Diego. A few topics covered: Ruby's origins at Stitch Fix Thoughts on Go Choosing technology and cloud services Moving off heroku Building a platform team Where Ruby and Rails fit in today The role of books and how different people learn Large Language Model's effects on technical content Related Links David's Blog Mastodon Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today. I want to share another conversation from RubyConf San Diego. This time it's with David Copeland. He was a chief software architect and director of engineering at stitch fix. And at the start of the conversation, you're going to hear about why he decided to write the book, sustainable web development with Ruby on rails. Unfortunately, you're also going to notice the sound quality isn't too good. We had some technical difficulties. But once you hit the 20 minute mark of the recording, the mics are going to kick in. It's going to sound way better. So I hope you stick with it. Enjoy. Ruby at Stitch Fix [00:00:35] David: Stitch Fix was a Rails shop. I had done a lot of Rails and learned a lot of things that worked and didn't work, at least in that situation. And so I started writing them down and I was like, I should probably make this more than just a document that I keep, you know, privately on my computer. Uh, so that's, you know, kind of, kind of where the genesis of that came from and just tried to, write everything down that I thought what worked, what didn't work. Uh, if you're in a situation like me. Working on a product, with a medium sized, uh, team, then I think the lessons in there will be useful, at least some of them. Um, and I've been trying to keep it up over, over the years. I think the first version came out a couple years ago, so I've been trying to make sure it's always up to date with the latest stuff and, and Rails and based on my experience and all that. [00:01:20] Jeremy: So it's interesting that you mention, medium sized team because, during the, the keynote, just a few moments ago, Matz the creator of Ruby was talking about how like, Oh, Rails is really suitable for this, this one person team, right? Small, small team. And, uh, he was like, you're not Google. So like, don't worry about, right. Can you scale to that level? Yeah. Um, and, and I wonder like when you talk about medium size or medium scale, like what are, what are we talking? [00:01:49] David: I think probably under 200 developers, I would say. because when I left Stitch Fix, it was closing in on that number of developers. And so it becomes, you know, hard to... You can kind of know who everybody is, or at least the names sound familiar of everybody. But beyond that, it's just, it's just really hard. But a lot of it was like, I don't have experience at like a thousand developer company. I have no idea what that's like, but I definitely know that Rails can work for like... 200 ish people how you can make it work basically. yeah. [00:02:21] Jeremy: The decision to use Rails, I'm assuming that was made before you joined? [00:02:26] David: Yeah, the, um, the CTO of Stitch Fix, he had come in to clean up a mess made by contractors, as often happens. They had used Django, which is like the Python version of Rails. And he, the CTO, he was more familiar with Rails. So the first two developers he hired, also familiar with Rails. There wasn't a lot to maintain with the Django app, so they were like, let's just start fresh, fresh with Rails. yeah, but it's funny because a lot of the code in that Rails app was, like, transliterated from Python. So you could, it would, it looked like the strangest Ruby code in the world because it was basically, there was no test. So they were like, let's just write the Ruby version of this Python just so we know it works. but obviously that didn't, didn't last forever, so. [00:03:07] Jeremy: So, so what's an example of a, of a tell? Where you're looking at the code and you're like, oh, this is clearly, it came from Python. [00:03:15] David: You'd see like, very, very explicit, right? Like Python, there's a lot of like single line things. very like, this sounds like a dig, but it's very simple looking code. Like, like I don't know Python, but I was able to change this Django app. And I had to, I could look at it and you can figure out immediately how it works. Cause there's. Not much to it. There's nothing fancy. So, like, this, this Ruby code, there was nothing fancy. You'd be like, well, maybe they should have memoized that, or maybe they should have taken that into another class, or you could have done this with a hash or something like that. So there was, like, none of that. It was just, like, really basic, plain code like you would see in any beginning programming language kind of thing. Which is at least nice. You can understand it. but you probably wouldn't have written it that way at first in Ruby. Thoughts on Go [00:04:05] Jeremy: Yeah, that's, that's interesting because, uh, people sometimes talk about the Go programming language and how it looks, I don't know if simple is the right word, but it's something where you look at the code and even if you don't necessarily understand Go, it's relatively straightforward. Yeah. I wonder what your thoughts are on that being a strength versus that being, like, [00:04:25] David: Yeah, so at Stitch Fix at one point we had a pro, we were moving off of Heroku and we were going to, basically build a deployment platform using ECS on AWS. And so the deployment platform was a Rails app and we built a command line tool using Ruby. And it was fine, but it was a very complicated command line tool and it was very slow. And so one of the developers was like, I'm going to rewrite it in Go. I was like, ugh, you know, because I just was not a big fan. So he rewrote it in Go. It was a bazillion times faster. And then I was like, okay, I'm going to add, I'll add a feature to it. It was extremely easy. Like, it's just like what you said. I looked at it, like, I don't know anything about Go. I know what is happening here. I can copy and paste this and change things and make it work for what I want to do. And it did work. And it was, it was pretty easy. so there's that, I mean, aesthetically it's pretty ugly and it's, I, I. I can't really defend that as a real reason to not use it, but it is kind of gross. I did do Go, I did a small project in Go after Stitch Fix, and there's this vibe in Go about like, don't create abstractions. I don't know where I got that from, but every Go I look at, I'm like we should make an abstraction for this, but it's just not the vibe. They just don't like doing that. They like it all written out. And I see the value because you can look at the code and know what it does and you don't have to chase abstractions anywhere. But. I felt like I was copying and pasting a lot of, a lot of things. Um, so I don't know. I mean, the, the team at Stitch Fix that did this like command line app in go, they're the platform team. And so their job isn't to write like web apps all day, every day. There's kind of in and out of all kinds of things. They have to try to figure out something that they don't understand quickly to debug a problem. And so I can see the value of something like go if that's your job, right? You want to go in and see what the issue is. Figure it out and be done and you're not going to necessarily develop deep expertise and whatever that thing is that you're kind of jumping into. Day to day though, I don't know. I think it would make me kind of sad. (laughs) [00:06:18] Jeremy: So, so when you say it would make you kind of sad, I mean, what, what about it? Is it, I mean, you mentioned that there's a lot of copy and pasting, so maybe there's code duplication, but are there specific things where you're like, oh, I just don't? [00:06:31] David: Yeah, so I had done a lot of Java in my past life and it felt very much like that. Where like, like the Go library for making an HTTP call for like, I want to call some web service. It's got every feature you could ever want. Everything is tweakable. You can really, you can see why it's designed that way. To dial in some performance issue or solve some really esoteric thing. It's there. But the problem is if you just want to get an JSON, it's just like huge production. And I felt like that's all I really want to do and it's just not making it very easy. And it just felt very, very cumbersome. I think that having to declare types also is a little bit of a weird mindset because, I mean, I like to make types in Ruby, I like to make classes, but I also like to just use hashes and stuff to figure it out. And then maybe I'll make a class if I figure it out, but Go, you can't. You have to have a class, you have to have a type, you have to think all that ahead of time, and it just, I'm not used to working that way, so it felt, I mean, I guess I could get used to it, but I just didn't warm up to that sort of style of working, so it just felt like I was just kind of fighting with the vibe of the language, kind of. Yeah, [00:07:40] Jeremy: so it's more of the vibe or the feel where you're writing it and you're like this seems a little too... Explicit. I feel like I have to be too verbose. It just doesn't feel natural for me to write this. [00:07:53] David: Right, it's not optimized for what in my mind is the obvious case. And maybe that's not the obvious case for the people that write Go programs. But for me, like, I just want to like get this endpoint and get the JSON back as a map. Not any easier than any other case, right? Whereas like in Ruby, right? And you can, I think if you include net HTTP, you can just type get. And it will just return whatever that is. Like, that's amazing. It's optimized for what I think is a very common use case. So it makes me feel really productive. It makes me feel pretty good. And if that doesn't work out long term, I can always use something more complicated. But I'm not required to dig into the NetHttp library just to do what in my mind is something very simple. [00:08:37] Jeremy: Yeah, I think that's something I've noticed myself in working with Ruby. I mean, you have the standard library that's very... Comprehensive and the API surface is such that, like you said there, when you're trying to do common tasks, a lot of times they have a call you make and it kind of does the thing you expected or hoped for. [00:08:56] David: Yeah, yeah. It's kind of, I mean, it's that whole optimized for programmer happiness thing. Like it does. That is the vibe of Ruby and it seems like that is still the way things are. And, you know, I, I suppose if I had a different mindset, I mean, because I work with developers who did not like using Ruby or Rails. They loved using Go or Java. And I, I guess there's probably some psychological analysis we could do about their background and history and mindset that makes that make sense. But, to me, I don't know. It's, it's nice when it's pleasant. And Ruby seems pleasant. (laughs) Choosing Technology [00:09:27] Jeremy: as a... Software Architect, or as a CTO, when, when you're choosing technology, what are some of the things you look at in terms of, you know? [00:09:38] David: Yeah, I mean, I think, like, it's a weird criteria, but I think what is something that the team is capable of executing with? Because, like, most, right, most programming languages all kind of do the same thing. Like, you can kind of get most stuff done in most common popular programming languages. So, it's probably not... It's not true that if you pick the wrong language, you can't build the app. Like, that's probably not really the case. At least for like a web app or something. so it's more like, what is the team that's here to do it? What are they comfortable and capable of doing? I worked on a project with... It was a mix of like junior engineers who knew JavaScript, and then some senior engineers from Google. And for whatever reason someone had chosen a Rails app and none of them were comfortable or really yet competent with doing Ruby on Rails and they just all hated it and like it didn't work very well. Um, and so even though, yes, Rails is a good choice for doing stuff for that team at that moment. Not a good choice. Right. So I think you have to go in and like, what, what are we going to be able to execute on so that when the business wants us to do something, we just do it. And we don't complain and we don't say, Oh, well we can't because this technology that we chose, blah, blah, blah. Like you don't ever want to say that if possible. So I think that's. That's kind of the, the top thing. I think second would be how widely supported is it? Like you don't want to be the cutting edge user that's finding all the bugs in something really. Like you want to use something that's stable. Postgres, MySQL, like those work, those are fine. The bugs have been sorted out for most common use cases. Some super fancy edge database, I don't know if I'd want to be doing, doing that you know? Choosing cloud services [00:11:15] Jeremy: How do you feel about the cloud specific services and databases? Like are you comfortable saying like, oh, I'm going to use... Google Cloud, BigQuery. Yeah. [00:11:27] David: That sort of thing. I think it would kind of fall under the same criteria that I was just, just saying like, so with AWS it's interesting 'cause when we moved from Heroku to AWS by EC2 RDS, their database thing, uh, S3, those have been around for years, probably those are gonna work, but they always introduce new things. Like we, we use RabbitMQ and AWS came out with. Some, I forget what it was, it was a queuing service similar to Rabbit. We were like, Oh, maybe we should switch to that. But it was clear that they weren't really ready to support it. So. Yeah, so we didn't, we didn't switch to that. So I, you gotta try to read the tea leaves of the provider to see are they committed to, to supporting this thing or is this there to get some enterprise client to move into the cloud. And then the idea is to move off of that transitional thing into what they do support. And it's hard to get a clear answer from them too. So it takes a little bit of research to figure out, Are they going to support this or not? Because that's what you don't want. To move everything into some very proprietary cloud system and have them sunset it and say, Oh yeah, now you've got to switch again. Uh, that kind of sucks. So, it's a little trickier. [00:12:41] Jeremy: And what kind of questions or research do you do? Is it purely a function of this thing has existed for X number of years so I feel okay? [00:12:52] David: I mean, it's kind of similar to looking at like some gem you're going to add to your project, right? So you'll, you'll look at how often does it change? Is it being updated? Uh, what is the documentation? Does it look like someone really cared about the documentation? Does the documentation look updated? Are there issues with it that are being addressed or, or not? Um, so those are good signals. I think, talking to other practitioners too can be good. Like if you've got someone who's experienced. You can say, hey, do you know anybody back channeling through, like, everybody knows somebody that works at AWS, you can probably try to get something there. at Stitch Fix, we had an enterprise support contract, and so your account manager will sometimes give you good information if you ask. Again, it's a, they're not going to come out and say, don't use this product that we have, but they might communicate that in a subtle way. So you have to triangulate from all these sources to try to. to try to figure out what, what you want to do. [00:13:50] Jeremy: Yeah, it kind of makes me wish that there was a, a site like, maybe not quite like, can I use, right? Can I use, you can see like, oh, can I use this in my browser? Is there, uh, like an AWS or a Google Cloud? Can I trust this? Can I trust this? Yeah. Is this, is this solid or not? [00:14:04] David: Right, totally. It's like, there's that, that site where you, it has all the Apple products and it says whether or not you should buy it because one may or may not be coming out or they may be getting rid of it. Like, yeah, that would... For cloud services, that would be, that would be nice. [00:14:16] Jeremy: Yeah, yeah. That's like the Mac Buyer's Guide. And then we, we need the, uh, the technology. Yeah. Maybe not buyers. Cloud Provider Buyer's Guide, yeah. I guess we are buyers. [00:14:25] David: Yeah, yeah, totally, totally. [00:14:27] Jeremy: it's interesting that you, you mentioned how you want to see that, okay, this thing is mature. I think it's going to stick around because, I, interviewed, someone who worked on, I believe it was the CloudWatch team. Okay. Daniel Vassalo, yeah. so he left AWS, uh, after I think about 10 years, and then he wrote a book called, uh, The Good Parts of AWS. Oh! And, if you read his book, most of the services he says to use are the ones that are, like, old. Yeah. He's, he's basically saying, like, S3, you know you're good. Yeah. Right? but then all these, if you look at the AWS webpage, they have who knows, I don't know how many hundreds of services. Yeah. He's, he's kind of like I worked there and I would not use, you know, all these new services. 'cause I myself, I don't trust [00:15:14] David: it yet. Right. And so, and they're working there? Yeah, they're working there. Yeah. No. One of the VPs at Stitch Fix had worked on Google Cloud and so when we were doing this transition from Heroku, he was like, we are not using Google Cloud. I was like, really? He's like AWS is far ahead of the game. Do not use Google Cloud. I was like, all right, I don't need any more info. You work there. You said don't. I'm gonna believe you. So [00:15:36] Jeremy: what, what was his did he have like a core point? [00:15:39] David: Um, so he never really had anything bad to say about Google per se. Like I think he enjoyed his time there and I think he thought highly of who he worked with and what he worked on and that sort of thing. But his, where he was coming from was like AWS was so far ahead. of Google on anything that we would use, he was like, there's, there's really no advantage to, to doing it. AWS is a known quantity, right? it's probably still the case. It's like, you know, you've heard the nobody ever got fired for using IBM or using Microsoft or whatever the thing is. Like, I think that's, that was kind of the vibe. And he was like, moving all of our infrastructure right before we're going to go public. This is a serious business. We should just use something that we know will work. And he was like, I know this will work. I'm not confident about. Google, uh, for our use case. So we shouldn't, we shouldn't risk it. So I was like, okay, I trust you because I didn't know anything about any of that stuff at the time. I knew Heroku and that was it. So, yeah. [00:16:34] Jeremy: I don't know if it's good or bad, but like you said, AWS seems to be the default choice. Yeah. And I mean, there's people who use Azure. I assume it's mostly primarily Microsoft. Yeah. And then there's Google Cloud. It's not really clear why you would pick it, unless there was a specific service or something that only they had. [00:16:55] David: Yeah, yeah. Or you're invested in Google, you know, you want to keep everything there. I mean, I don't know. I haven't really been at that level to make that kind of decision, and I would probably choose AWS for the reasons discussed, but, yeah. Moving off Heroku [00:17:10] Jeremy: And then, so at Stitch Fix, you said you moved off of Heroku [00:17:16] David: yeah. Yeah, so we were heavy into Heroku. I think that we were told that at one point we had the biggest Heroku Postgres database on their platform. Not a good place to be, right? You never want to be the biggest customer person, usually. but the problem we were facing was essentially we were going to go public. And to do that, you're under all the scrutiny. about many things, including the IT systems and the security around there. So, like, by default, a Postgres, a Heroku Postgres database is, like, on the internet. It's only secured by the password. all their services are on the internet. So, not, not ideal. they were developing their private cloud service at that time. And so that would have given us, in theory, on paper, it would have solved all of our problems. And we liked Heroku and we liked the developer experience. It was great. but... Heroku private spaces, it was still early. There's a lot of limitations that when they explained why those limitations, they were reasonable. And if we had. started from scratch on Heroku Private Spaces. It probably would have worked great, but we hadn't. So we just couldn't make it work. So we were like, okay, we're going to have to move to AWS so that everything can be basically off the internet. Like our public website needs to be on the internet and that's kind of it. So we need to, so that's basically was the, was the impetus for that. but it's too bad because I love Heroku. It was great. I mean, they were, they were a great partner. They were great. I think if Stitch Fix had started life a year later, Private Spaces. Now it's, it's, it's way different than it was then. Cause it's been, it's a mature product now, so we could have easily done that, but you know, the timing didn't work out, unfortunately. [00:18:50] Jeremy: And that was a compliance thing to, [00:18:53] David: Yeah. And compliance is weird cause they don't tell you what to do, but they give you some parameters that you need to meet. And so one of them is like how you control access. So, so going public, the compliance is around the financial data and. Ensuring that the financial data is accurate. So a lot of the systems at Stichfix were storing the financial data. We, you know, the warehouse management system was custom made. Uh, all the credit card processing was all done, like it was all in some databases that we had running in Heroku. And so those needed to be subject to stricter security than we could achieve with just a single password that we just had to remember to rotate when someone like left the team. So that was, you know, the kind of, the kind of impetus for, for all of that. [00:19:35] Jeremy: when you were using Heroku, Salesforce would have already owned it then. Did you, did you get any sense that you weren't really sure about the future of the platform while you're on it or, [00:19:45] David: At that time, no, it seemed like they were still innovating. So like, Heroku has a Redis product now. They didn't at the time we wish that they did. They told us they're working on it, but it wasn't ready. We didn't like using the third parties. Kafka was not a thing. We very much were interested in that. We would have totally used it if it was there. So they were still. Like doing bigger innovations then, then it seems like they are now. I don't know. It's weird. Like they're still there. They still make money, I assume for Salesforce. So it doesn't feel like they're going away, but they're not innovating at the pace that they were kind of back in the day. [00:20:20] Jeremy: it used to feel like when somebody's asking, I want to host a Rails app. Then you would say like, well, use Heroku because it's basically the easiest to get started. It's a known quantity and it's, it's expensive, but, it seemed for, for most people, it was worth it. and then now if I talk to people, it's like. Not what people suggest anymore. [00:20:40] David: Yeah, because there's, there's actual competitors. It's crazy to me that there was no competitors for years, and now there's like, Render and Fly. io seem to be the two popular alternatives. Um, I doubt they're any cheaper, honestly, but... You get a sense, right, that they're still innovating, still building those platforms, and they can build with, you know, all of the knowledge of what has come before them, and do things differently that might, that might help. So, I still use Heroku for personal things just because I know it, and I, you know, sometimes you don't feel like learning a new thing when you just want to get something done, but, yeah, I, I don't know if we were starting again, I don't know, maybe I'd look into those things. They, they seem like they're getting pretty mature and. Heroku's resting on its laurels, still. [00:21:26] Jeremy: I guess I never quite the mindset, right? Where you You have a platform that's doing really well and people really like it and you acquire it and then it just It seems like you would want to keep it rolling, right? (laughs) [00:21:38] David: Yeah, it's, it is wild, I mean, I guess... Why did you, what was Salesforce thinking they were going to get? Uh, who knows maybe the person at Salesforce that really wanted to purchase it isn't there. And so no one at Salesforce cares about it. I mean, there's all these weird company politics that like, who knows what's going on and you could speculate. all day. What's interesting is like, there's definitely some people in the Ruby community who work there and still are working there. And that's like a little bit of a canary for me. I'm like, all right, well, if that person's still working there, that person seems like they're on the level and, and, and, and seems pretty good. They're still working there. It, it's gotta be still a cool place to be or still doing something, something good. But, yeah, I don't know. I would, I would love to know what was going on in all the Salesforce meetings about acquiring that, how to manage it. What are their plans for it? I would love to know that stuff. [00:22:29] Jeremy: maybe you had some experience with this at Stitch Fix But I've heard with Heroku some of their support staff at least in the past they would, to some extent, actually help you troubleshoot, like, what's going on with your app. Like, if your app is, like, using a whole bunch of memory, and you're out of memory, um, they would actually kind of look into that, for you, which is interesting, because it's like, that's almost like a services thing than it is just a platform. [00:22:50] David: Yeah. I mean, they, their support, you would get, you would get escalated to like an engineer sometimes, like who worked on that stuff and they would help figure out what the problem was. Like you got the sense that everybody there really wanted the platform to be good and that they were all sort of motivated to make sure that everybody. You know, did well and used the platform. And they also were good at, like a thing that trips everybody up about Heroku is that your app restarts every day. And if you don't know anything about anything, you might think that is stupid. Why, why would I want that? That's annoying. And I definitely went through that and I complained to them a lot. And I'm like, if you only could not restart. And they very patiently and politely explained to me why that it needed to do that, they weren't going to remove that, and how to think about my app given that reality, right? Which is great because like, what company does that, right? From the engineers that are working on it, like No, nobody does that. So, yeah, no, I haven't escalated anything to support at Heroku in quite some time, so I don't know if it's still like that. I hope it is, but I'm not really, not really sure. Building a platform team [00:23:55] Jeremy: Yeah, that, uh, that reminds me a little bit of, I think it's Rackspace? There's, there's, like, another hosting provider that was pretty popular before, and they... Used to be famous for that type of support, where like your, your app's having issues and somebody's actually, uh, SSHing into your box and trying to figure out like, okay, what's going on? which if, if that's happening, then I, I can totally see where the, the price is justified. But if the support is kind of like dropping off to where it's just, they don't do that kind of thing, then yeah, I can see why it's not so much of a, yeah, [00:24:27] David: We used to think of Heroku as like they were the platform team before we had our own platform team and they, they acted like it, which was great. [00:24:35] Jeremy: Yeah, I don't have, um, experience with, render, but I, I, I did, talk to someone from there, and it does seem like they're, they're trying to fill that role, um, so, yeah, hopefully, they and, and other companies, I guess like Vercel and things like that, um, they're, they're all trying to fill that space, [00:24:55] David: Yeah, cause, cause building our own internal platform, I mean it was the right thing to do, but it's, it's a, you can't just, you have to have a team on it, it's complicated, getting all the stuff in AWS to work the way you want it to work, to have it be kind of like Heroku, like it's not trivial. if I'm a one person company, I don't want to be messing around with that particularly. I want to just have it, you know, push it up and have it go and I'm willing to pay for that. So it seems logical that there would be competitors in that space. I'm glad there are. Hopefully that'll light a fire under, under everybody. [00:25:26] Jeremy: so in your case, it sounds like you moved to having your own platform team and stuff like that, uh, partly because of the compliance thing where you're like, we need our, we need to be isolated from the internet. We're going to go to AWS. If you didn't have that requirement, do you still think like that would have been the time to, to have your own platform team and manage that all yourself? [00:25:46] David: I don't know. We, we were thinking an issue that we were running into when we got bigger, um, was that, I mean, Heroku, it, It's obviously not as flexible as AWS, but it is still very flexible. And so we had a lot of internal documentation about this is how you use Heroku to do X, Y, and Z. This is how you set up a Stitch Fix app for Heroku. Like there was just the way that we wanted it to be used to sort of. Just make it all manageable. And so we were considering having a team spun up to sort of add some tooling around that to sort of make that a little bit easier for everybody. So I think there may have been something around there. I don't know if it would have been called a platform team. Maybe we call, we thought about calling it like developer happiness or because you got developer experience or something. We, we probably would have had something there, but. I do wonder how easy it would have been to fund that team with developers if we hadn't had these sort of business constraints around there. yeah, um, I don't know. You get to a certain size, you need some kind of manageability and consistency no matter what you're using underneath. So you've got to have, somebody has to own it to make sure that it's, that it's happening. [00:26:50] Jeremy: So even at your, your architect level, you still think it would have been a challenge to, to. Come to the executive team and go like, I need funding to build this team. [00:27:00] David: You know, certainly it's a challenge because everybody, you know, right? Nobody wants to put developers in anything, right? There are, there are a commodity and I mean, that is kind of the job of like, you know, the staff engineer or the architect at a company is you don't have, you don't have the power to put anybody on anything you, you have the power to Schedule a meeting with a VP or the CTO and they will listen to you. And that's basically, you've got to use that power to convince them of what you want done. And they're all reasonable people, but they're balancing 20 other priorities. So it would, I would have had to, it would have been a harder case to make that, Hey, I want to take three engineers. And have them write tooling to make Heroku easier to use. What? Heroku is not easy to use. Why aren't, you know, so you really, I would, it would be a little bit more of a stretch to walk them through it. I think a case could be made, but, definitely would take some more, more convincing than, than what was needed in our case. [00:27:53] Jeremy: Yeah. And I guess if you're able to contrast that with, you were saying, Oh, I need three people to help me make Heroku easier. Your actual platform team on AWS, I imagine was much larger, right? [00:28:03] David: Initially it was, there was, it was three people did the initial move over. And so by the time we went public, we'd been on this new system for, I don't know, six to nine months. I can't remember exactly. And so at that time the platform team was four or five people, and I, I mean, so percentage wise, right, the engineering team was maybe almost 200, 150, 200. So percentage wise, maybe a little small, I don't know. but it kind of gets back to the power of like the rails and the one person framework. Like everything we did was very much the same And so the Rails app that managed the deployment was very simple. The, the command line app, even the Go one with all of its verbosity was very, very simple. so it was pretty easy for that small team to manage. but, Yeah, so it was sort of like for redundancy, we probably needed more than three or four people because you know, somebody goes out sick or takes a vacation. That's a significant part of the team. But in terms of like just managing the complexity and building it and maintaining it, like it worked pretty well with, you know, four or five people. Where Rails fits in vs other technology [00:29:09] Jeremy: So during the Keynote today, they were talking about how companies like GitHub and Shopify and so on, they're, they're using Rails and they're, they're successful and they're fairly large. but I think the thing that was sort of unsaid was the fact that. These companies, while they use Rails, they use a lot of other, technology as well. And, and, and kind of increasing amounts as well. So, I wonder from your perspective, either from your experience at StitchFix or maybe going forward, what is the role that, that Ruby and Rails plays? Like, where does it make sense for that to be used versus like, Okay, we need to go and build something in Java or, you know, or Go, that sort of thing? [00:29:51] David: right. I mean, I think for like your standard database backed web app, it's obviously great. especially if your sort of mindset bought into server side rendering, it's going to be great at that. so like internal tools, like the customer service dashboard or... You know, something for like somebody who works at a company to use. Like, it's really great because you can go super fast. You're not going to be under a lot of performance constraints. So you kind of don't even have to think about it. Don't even have to solve it. You can, but you don't have to, where it wouldn't work, I guess, you know, if you have really strict performance. Requirements, you know, like a, a Go version of some API server is going to use like percentages of what, of what Rails would use. If that's meaningful, if what you're spending on memory or compute is, is meaningful, then, then yeah. That, that becomes worthy of consideration. I guess if you're, you know, if you're making a mobile app, you probably need to make a mobile app and use those platforms. I mean, I guess you can wrap a Rails app sort of, but you're still making, you still need to make a mobile app, that does something. yeah. And then, you know, interestingly, the data science part of Stitch Fix was not part of the engineering team. They were kind of a separate org. I think Ruby and Rails was probably the only thing they didn't use over there. Like all the ML stuff, everything is either Java or Scala or Python. They use all that stuff. And so, yeah, if you want to do AI and ML with Ruby, you, it's, it's hard cause there's just not a lot there. You really probably should use Python. It'll make your life easier. so yeah, those would be some of the considerations, I guess. [00:31:31] Jeremy: Yeah, so I guess in the case of, ML, Python, certainly, just because of the, the ecosystem, for maybe making a command line application, maybe Go, um, Go or Rust, perhaps, [00:31:44] David: Right. Cause you just get a single binary. Like the problem, I mean, I wrote this book on Ruby command line apps and the biggest problem is like, how do I get the Ruby VM to be anywhere so that it can then run my like awesome scripts? Like that's kind of a huge pain. (laughs) So [00:31:59] Jeremy: and then you said, like, if it's Very performance sensitive, which I am kind of curious in, in your experience with the companies you've worked at, when you're taking on a project like that, do you know up front where you're like, Oh, the CPU and memory usage is going to be a problem, or is it's like you build it and you're like, Oh, this isn't working. So now I know. [00:32:18] David: yeah, I mean, I, I don't have a ton of great experience there at Stitch Fix. The biggest expense the company had was the inventory. So like the, the cost of AWS was just de minimis compared to all that. So nobody ever came and said, Hey, you've got to like really save costs on, on that stuff. Cause it just didn't really matter. at the, the mental health startup I was at, it was too early. But again, the labor costs were just far, far exceeded the amount of money I was spending on, on, um, you know, compute and infrastructure and stuff like that. So, Not knowing anything, I would probably just sort of wait and see if it's a problem. But I suppose you always take into account, like, what am I actually building? And like, what does this business have to scale to, to make it worthwhile? And therefore you can kind of do a little bit of planning ahead there. But, I dunno, I think it would kind of have to depend. [00:33:07] Jeremy: There's a sort of, I guess you could call it a meme, where people say like, Oh, it's, it's not, it's not Rails that's slow, it's the, the database that's slow. And, uh, I wonder, is that, is that accurate in your experience, or, [00:33:20] David: I mean, most of the stuff that we had that was slow was the database, because like, it's really easy to write a crappy query in Rails if you're not, if you're not careful, and then it's really easy to design a database that doesn't have any indexes if you're not careful. Like, you, you kind of need to know that, But of course, those are easy to fix too, because you just add the index, especially if it's before the database gets too big where we're adding indexes is problematic. But, I think those are just easy performance mistakes to make. Uh, especially with Rails because you're not, I mean, a lot of the Rails developers at Citrix did not know SQL at all. I mean, they had to learn it eventually, but they didn't know it at all. So they're not even knowing that what they're writing could possibly be problematic. It's just, you're writing it the Rails way and it just kind of works. And at a small scale, it does. And it doesn't matter until, until one day it does. [00:34:06] Jeremy: And then in, in the context of, let's say, using ActiveRecord and instantiating the objects, or, uh, the time it takes to render templates, that kinds of things, to, at least in your experience, that wasn't such of an issue. [00:34:20] David: No, and it was always, I mean, whenever we looked at why something was slow, it was always the database and like, you know, you're iterating over some active records and then, and then, you know, you're going into there and you're just following this object graph. I've got a lot of the, a lot of the software at Stitch Fix was like internal stuff and it was visualizing complicated data out of the database. And so if you didn't think about it, you would just start dereferencing and following those relationships and you have this just massive view and like the HTML is fine. It's just that to render this div, you're. Digging into some active record super deep. and so, you know, that was usually the, the, the problems that we would see and they're usually easy enough to fix by making an index or. Sometimes you do some caching or something like that. and that solved most of the, most of the issues [00:35:09] Jeremy: The different ways people learn [00:35:09] Jeremy: so you're also the author of the book, Sustainable Web Development with Ruby on Rails. And when you talk to people about like how they learn things, a lot of them are going on YouTube, they're going on, uh, you know, looking for blogs and things like that. And so as an author, what do you think the role is of, of books now? Yeah, [00:35:29] David: I have thought about this a lot, because I, when I first got started, I'm pretty old, so books were all you had, really. Um, so they seem very normal and natural to me, but... does someone want to sit down and read a 400 page technical book? I don't know. so Dave Thomas who runs Pragmatic Bookshelf, he was on a podcast and was asked the same question and basically his answer, which is my answer, is like a long form book is where you can really lay out your thinking, really clarify what you mean, really take the time to develop sometimes nuanced, examples or nuanced takes on something that are Pretty hard to do in a short form video or in a blog post. Because the expectation is, you know, someone sends you an hour long YouTube video, you're probably not going to watch that. Two minute YouTube video is sure, but you can't, you can't get into so much, kind of nuanced detail. And so I thought that was, was right. And that was kind of my motivation for writing. I've got some thoughts. They're too detailed. It's, it's too much set up for a blog post. There's too much of a nuanced element to like, really get across. So I need to like, write more. And that means that someone's going to have to read more to kind of get to it. But hopefully it'll be, it'll be valuable. one of the sessions that we're doing later today is Ruby content creators, where it's going to be me and Noel Rappin and Dave Thomas representing the old school dudes that write books and probably a bunch of other people that do, you know, podcasts videos. It'd be interesting to see, I really want to know how do people learn stuff? Because if no one reads books to learn things, then there's not a lot of point in doing it. But if there is value, then, you know. It should be good and should be accessible to people. So, that's why I do it. But I definitely recognize maybe I'm too old and, uh, I'm not hip with the kids or, or whatever, whatever the case is. I don't know. [00:37:20] Jeremy: it's tricky because, I think it depends on where you are in the process of learning that thing. Because, let's say, you know a fair amount about the technology already. And you look at a book, in a lot of cases it's, it's sort of like taking you from nothing to something. And so you're like, well, maybe half of this isn't relevant to me, but then if I don't read it, then I'm probably missing a lot still. And so you're in this weird in be in between zone. Another thing is that a lot of times when people are trying to learn something, they have a specific problem. And, um, I guess with, with books, it's, you kind of don't know for sure if the thing you're looking for is going to be in the book. [00:38:13] David: I mean, so my, so my book, I would not say as a beginner, it's not a book to learn how to do Rails. It's like you already kind of know Rails and you want to like learn some comprehensive practices. That's what my book is for. And so sometimes people will ask me, I don't know Rails, should I get your book? And I'm like, no, you should not. but then you have the opposite thing where like the agile web development with Rails is like the beginner version. And some people are like, Oh, it's being updated for Rails 7. Should I get it? I'm like, probably not because How to go from zero to rails hasn't changed a lot in years. There's not that much that's going to be new. but, how do you know that, right? Hopefully the Table of Contents tells you. I mean, the first book I wrote with Pragmatic, they basically were like, The Table of Contents is the only thing the reader, potential reader is going to have to have any idea what's in the book. So, You need to write the table of contents with that in mind, which may not be how you'd write the subsections of a book, but since you know that it's going to serve these dual purposes of organizing the book, but also being promotional material that people can read, you've got to keep that in mind, because otherwise, how does anybody, like you said, how does anybody know what's, what's going to be in there? And they're not cheap, I mean, these books are 50 bucks sometimes, and That's a lot of money for people in the U. S. People outside the U. S. That's a ton of money. So you want to make sure that they know what they're getting and don't feel ripped off. [00:39:33] Jeremy: Yeah, I think the other challenge is, at least what I've heard, is that... When people see a video course, for whatever reason, they, they set, like, a higher value to it. They go, like, oh, this video course is, 200 dollars and it's, like, seems like a lot of money, but for some people it's, like, okay, I can do that. But then if you say, like, oh, this, this book I've been researching for five years, uh, I want to sell it for a hundred bucks, people are going to be, like no. No way., [00:40:00] David: Yeah. Right. A hundred bucks for a book. There's no way. That's a, that's a lot. Yeah. I mean, producing video, I've thought about doing video content, but it seems so labor intensive. Um, and it's kind of like, It's sort of like a performance. Like I was mentioning before we started that I used to play in bands and like, there's a lot to go into making an even mediocre performance. And so I feel like, you know, video content is the same way. So I get that it like, it does cost more to produce, but, are you getting more information out of it? I, that, I don't know, like maybe not, but who knows? I mean, people learn things in different ways. So, [00:40:35] Jeremy: It's just like this perception thing, I think. And, uh, I'm not sure why that is. Um, [00:40:40] David: Yeah, maybe it's newer, right? Maybe books feel older so they're easier to make and video seems newer. I mean, I don't know. I would love to talk to engineers who are like... young out of college, a few years into their career to see what their perception of this stuff is. Cause I mean, there was no, I mean, like I said, I read books cause that's all there was. There was no, no videos. You, you go to a conference and you read a book and that was, that was all you had. so I get it. It seems a whole video. It's fancier. It's newer. yeah, I don't know. I would love to hear a wide variety of takes on it to see what's actually the, the future, you know? [00:41:15] Jeremy: sure, yeah. I mean, I think it probably can't just be one or the other, right? Like, I think there are... Benefits of each way. Like, if you have the book, you can read it at your own pace without having to, like, scroll through the video, and you can easily copy and paste the, the code segments, [00:41:35] David: Search it. Go back and forth. [00:41:36] Jeremy: yeah, search it. So, I think there's a place for it, but yeah, I think it would be very interesting, like you said, to, to see, like, how are people learning, [00:41:45] David: Right. Right. Yeah. Well, it's the same with blogs and podcasts. Like I, a lot of podcasters I think used to be bloggers and they realized that like they can get out what they need by doing a podcast. And it's way easier because it's more conversational. You don't have to do a bunch of research. You don't have to do a bunch of editing. As long as you're semi coherent, you can just have a conversation with somebody and sort of get at some sort of thing that you want to talk about or have an opinion about. And. So you, you, you see a lot more podcasts and a lot less blogs out there because of that. So it's, that's kind of like the creators I think are kind of driving that a little bit. yeah. So I don't know. [00:42:22] Jeremy: Yeah, I mean, I can, I can say for myself, the thing about podcasts is that it's something that I can listen to while I'm doing something else. And so you sort of passively can hopefully pick something up out of that conversation, but... Like, I think it's maybe not so good at the details, right? Like, if you're talking code, you can talk about it over voice, but can you really visualize it? Yeah, yeah, yeah. I think if you sit down and you try to implement something somebody talked about, you're gonna be like, I don't know what's happening. [00:42:51] David: Yeah. [00:42:52] Jeremy: So, uh, so, so I think there's like these, these different roles I think almost for so like maybe you know the podcast is for you to Maybe get some ideas or get some familiarity with a thing and then when you're ready to go deeper You can go look at a blog post or read a book I think video kind of straddles those two where sometimes video is good if you want to just see, the general concept of a thing, and have somebody explain it to you, maybe do some visuals. that's really good. but then it can also be kind of detailed, where, especially like the people who stream their process, right, you can see them, Oh, let's, let's build this thing together. You can ask me questions, you can see how I think. I think that can be really powerful. at the same time, like you said, it can be hard to say, like, you know, I look at some of the streams and it's like, oh, this is a three hour stream and like, well, I mean, I'm interested. I'm interested, but yeah, it's hard enough for me to sit through a, uh, a three hour movie, [00:43:52] David: Well, then that, and that gets into like, I mean, we're, you know, we're at a conference and they, they're doing something a little, like, there are conference talks at this conference, but there's also like. sort of less defined activities that aren't a conference talk. And I think that could be a reaction to some of this too. It's like I could watch a conference talk on, on video. How different is that going to be than being there in person? maybe it's not that different. Maybe, maybe I don't need to like travel across the country to go. Do something that I could see on video. So there's gotta be something here that, that, that meets that need that I can't meet any other way. So it's all these different, like, I would like to think that's how it is, right? All this media all is a part to play and it's all going to kind of continue and thrive and it's not going to be like, Oh, remember books? Like maybe, but hopefully not. Hopefully it's like, like what you're saying. Like it's all kind of serving different purposes that all kind of work together. Yeah. [00:44:43] Jeremy: I hope that's the case, because, um, I don't want to have to scroll through too many videos. [00:44:48] David: Yeah. The video's not for me. Large Language Models [00:44:50] Jeremy: I, I like, I actually do find it helpful, like, like I said, for the high level thing, or just to see someone's thought process, but it's like, if you want to know a thing, and you have a short amount of time, maybe not the best, um, of course, now you have all the large language model stuff where you like, you feed the video in like, Hey, tell, tell, tell me, uh, what this video is about and give me the code snippets and all that stuff. I don't know how well it works, but it seems [00:45:14] David: It's gotta get better. Cause you go to a support site and they're like, here's how to fix your problem, and it's a video. And I'm like, can you just tell me? But I'd never thought about asking the AI to just look at the video and tell me. So yeah, it's not bad. [00:45:25] Jeremy: I think, that's probably where we're going. So it's, uh, it's a little weird to think about, but, [00:45:29] David: yeah, yeah. I was just updating, uh, you know, like I said, I try to keep the book updated when new versions of Rails come out, so I'm getting ready to update it for Rails 7. 1 and in Amazon's, Kindle Direct Publishing as their sort of backend for where you, you know, publish like a Kindle book and stuff, and so they added a new question, was AI used in the production of this thing or not? And if you answer yes, they want you to say how much, And I don't know what they're gonna do with that exactly, but I thought it was pretty interesting, cause I would be very disappointed to pay 50 for a book that the AI wrote, right? So it's good that they're asking that? Yeah. [00:46:02] Jeremy: I think the problem Amazon is facing is where people wholesale have the AI write the book, and the person either doesn't review it at all, or maybe looks at a little, a little bit. And, I mean, the, the large language model stuff is very impressive, but If you have it generate a technical book for you, it's not going to be good. [00:46:22] David: yeah. And I guess, cause cause like Amazon, I mean, think about like Amazon scale, like they're not looking at the book at all. Like I, I can go click a button and have my book available and no person's going to look at it. they might scan it or something maybe with looking for bad words. I don't know, but there's no curation process there. So I could, yeah. I could see where they could have that, that kind of problem. And like you as the, as the buyer, you don't necessarily, if you want to book on something really esoteric, there are a lot of topics I wish there was a book on that there isn't. And as someone generally want to put it on Amazon, I could see a lot of people buying it, not realizing what they're getting and feeling ripped off when it was not good. [00:47:00] Jeremy: Yeah, I mean, I, I don't know, if it's an issue with the, the technical stuff. It probably is. But I, I know they've definitely had problems where, fiction, they have people just generating hundreds, thousands of books, submitting them all, just flooding it. [00:47:13] David: Seeing what happens. [00:47:14] Jeremy: And, um, I think that's probably... That's probably the main reason why they ask you, cause they want you to say like, uh, yeah, you said it wasn't. And so now we can remove your book. [00:47:24] David: right. Right. Yeah. Yeah. [00:47:26] Jeremy: I mean, it's, it's not quite the same, but it's similar to, I don't know what Stack Overflow's policy is now, but, when the large language model stuff started getting big, they had a lot of people answering the questions that were just. Pasting the question into the model [00:47:41] David: Which because they got it from [00:47:42] Jeremy: and then [00:47:43] David: The Got model got it from Stack Overflow. [00:47:45] Jeremy: and then pasting the answer into Stack Overflow and the person is not checking it. Right. So it's like, could be right, could not be right. Um, cause, cause to me, it's like, if, if you generate it, if you generate the answer and the answer is right, and you checked it, I'm okay with that. [00:48:00] David: Yeah. Yeah. [00:48:01] Jeremy: but if you're just like, I, I need some karma, so I'm gonna, I'm gonna answer these questions with, with this bot, I mean, then maybe [00:48:08] David: I could have done that. You're not adding anything. Yeah, yeah. [00:48:11] Jeremy: it's gonna be a weird, weird world, I think. [00:48:12] David: Yeah, no kidding. No kidding. [00:48:15] Jeremy: that's a, a good place to end it on, but is there anything else you want to mention, [00:48:19] David: No, I think we covered it all just yeah, you could find me online. I'm Davetron5000 on Ruby. social Mastodon, I occasionally post on Twitter, but not that much anymore. So Mastodon's a place to go. [00:48:31] Jeremy: David, thank you so much [00:48:32] David: All right. Well, thanks for having me.

Here's what you need to know from this week in the business of podcasting: The Spoken Word Audio Report 2023YouTube Debuts New AI Content PoliciesSaving TikTok Songs to Spotify With New IntegrationAd Engagement Declines With Lack of RepresentationQuick Hits:Spotify's podcast and audiobook discovery will get a boost from Google Cloud's AI by Amrita Khalid. Google Cloud's Large Language Models will be used to scan all podcasts and audiobooks on Spotify to improve metadata and discoverability. Podcasting Lessons From Dogs by Tom Webster. This week Tom reflects on why podcasts with multiple hosts need an Abbot to their Costello. A traffic cop to direct the flow of conversation when need be.How I got 10x YouTube subscribers by adding video to my podcast by Ashley Hamer. A step-by-step account of Hamer adding video production to her existing podcast Taboo Science and how optimizing her YouTube channel boosted YouTube algorithm attention. Sound You Can See: Podcasting's Video Dilemma. On Wednesday, December 13th, Sounds Profitable will debut their latest study, which dives into consumer perceptions of podcasts on video and how they continue to drive the future of this medium.Global signs exclusive podcast distribution and licensing deal with iHeartMedia by Reem Makari. iHeartMedia podcasts will be distributed on the Global Media app in the UK and Ireland, while Global podcasts will be distributed in the U.S. on iHeartRadio's app, along with iHeartMedia monetization. Triton Podcast Ranker: October 2023. 48 Hours climbs two spots to enter the top 10 in 9th place, pushing Conan Needs a Friend down to #10.

Lo que está cambiando el podcasting y el marketing digital:-Adobe implementa el uso de IA para separar varios sonidos de un mismo audio.-Spotify potencia la búsqueda de contenido con Google Cloud.-YouTube pone a prueba una nueva herramienta impulsada por IA que clona la voz de estrellas pop.-Descript anuncia tres nuevas herramientas de inteligencia artificial.-Buzzsprout lanza Podroll, una herramienta de recomendación de pódcast.Pódcast recomendadoTengo un plan. Un pódcast semanal de emprendimiento y crecimiento personal presentado por Sergio Beguería y Juan Domínguez.Si te gustó esta "newsletter" ¡Suscríbete!Patrocinado por Hindenburg. El Software que usamos para editar nuestro pódcast y Rss.com (compañía de alojamiento de pódcast).

Guests are Marek Siarkowicz , Senior Software Engineer in Google Cloud, Tech Lead of SIG-etcd   AND Wenjia Zhang, Engineering Manager in Google Cloud, Co-Chair of SIG-etcd, Google. We spoke about the project, the recent change to become a Special Interest Group and how to learn etcd.   Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod News of the week Co-host this week is Mofi Rahman [X, LinkedIn]. Cloud Developer Advocate at Google Karpenter graduated to Beta The Kubernetes SIG Network announced release 1.0 of the Gateway API Ingress2gateway new CLI to migrate from Ingress to Gateway The Call for Proposals for KubeCon EU 2024 will close on Nov 26, 2023 Links from the interview etcd Meaning of etcd etcd history from CoreOs Raft paper On the Hunt for Etcd Data Inconsistencies by Marek Siarkowicz - [youtube] Lessons Learned From Etcd the Data Inconsistency Issues by Marek Siarkowicz - [youtube] The first pancake rule etcd as a Kubernetes sig The Case for SIG-ifying etcd CNCF Contributor License Agreements (CLA) Kubernetes Prow Contributor Experience Special Interest Group Kubernetes Watch Go Serialization and Deserialization Cilium with external etcd Certified Kubernetes Administrator etcd mentorship program etcd @kubecon NA 2023 Links from the post-interview chat Kubernetes considerations for large clusters Operating etcd clusters for Kubernetes Kueue etcd on the podcast The Heartbleed Bug XKCD meme about dependency  

On this episode of On The Tape Dan, Guy and Danny discuss what events this week (earnings, Biden-Xi meeting, econ data) are saying about the economy (3:00), expectations of rate cuts next year sparking panic buying (11:30), the promise of a soft landing (18:00), being a market pundit (20:30), the Starbucks walk out (25:00), IPO spinoff talk swirls around SpaceX's Starlink (27:00), and Danny's NFL picks (28:00). Later, CME Group CEO Terry Duffy joins the conversation for his take on risk management in a time of uncertainty (35:00), what investors should be focused on (37:30), innovation for new products/existing products (39:00), his philosophy in regards to risk management (40:00), FTX/regulation (43:50), the importance of rigor (49:00), the market structure (51:30), the retail trader (54:30), what keeps him going as a CEO (59:00), their Google Cloud relationship (1:02:00), his expectations for the stock market in 2024 (1:05:30), and the CME Group Tour Championship (1:08:00). Click here to donate to St. Jude Children's Research. If you do, send a screenshot of your donation to contact@riskreversal.com and we will send you a free “On The Tape” hat. — About the Show: On The Tape is a weekly podcast with CNBC Fast Money's Guy Adami, Dan Nathan and Danny Moses. They're offering takes on the biggest market-moving headlines of the week, trade ideas, in-depth analysis, tips and advice. Each episode, they are joined by prominent Wall Street participants to help viewers make smarter investment decisions. Bear market, bull market, recession, inflation or deflation… we're here to help guide your portfolio into the green. Risk Reversal brings you years of experience from former Wall Street insiders trading stocks to experts in the commodity market. — Check out our show notes here Learn more about Ro body: ro.co/tape See what adding futures can do for you at cmegroup.com/onthetape. — Shoot us an email at OnTheTape@riskreversal.com with any feedback, suggestions, or questions for us to answer on the pod and follow us @OnTheTapePod on Twitter or @riskreversalmedia on Threads — We're on social: Follow @GuyAdami on Twitter Follow Danny Moses @DMoses34 on Twitter Follow Liz Young @LizYoungStrat on Twitter Follow us on Instagram @RiskReversalMedia Subscribe to our YouTube page

This episode came together at ~4 hrs notice since Dylan had just landed in SF and we had to setup quickly; you might notice some small audio issues in some segments, we apologize. We're currently building our own podcast studio for 2024!

Here's what you need to know for today in the business of podcasting:Spotify's podcast and audiobook discovery will get a boost from Google Cloud's AI by Amrita KhalidYouTube intros new AI governance policies. AI helps enforce them by Brad HillThe case for and against brand safety by Seb Joseph and Krystal ScanlonDefining Premium Video - How VAB and Comcast's FreeWheel are Trying to Settle TV Industry Debate by Jack Neff…as for the rest of the news: PodPod covers how to hit the mark with GenZ podcast listeners, and Triton's newest batch of podcast rankers have arrived, including Australia's top 100 showing Hamish & Andy has held its #1 spot for six months running.

In this special episode, we are featuring That Digital Show. In Australia, every employee is required to select their superannuation fund of choice to help them invest a portion of their income. Having celebrated its 40th anniversary recently, UniSuper, one of Australia's largest superannuation funds, is committed to delivering value and efficiency for its members. Started as a fund for the higher education and research sector, it has now opened its platform to all industries across the country. Today, UniSuper invests more than $120 billion on behalf of more than 620,000 members. With the new Treasury Laws Amendment Act 2021, Your Future, Your Super, that aims to improve the outcome of superannuation funds for Australians, UniSuper decided to undergo a data centre transformation, taking on an 80/20 rule on cloud hosting and adopting the right digital technologies to improve its performance and portfolio. In this episode, Angelo talks about how Google Cloud VMware Engine (GCVE) underpins UniSuper's shift to the cloud as it moves existing VMware-based workloads from on-premises data centers to the cloud. This enables the organization to quickly scale up while having the flexibility and agility it needs to drive operational efficiencies as it continues to deliver the best returns for its customers. He also shares how the COVID-19 pandemic presented him with some crucial moments of thought that have resulted in some of the changes in best practices across the organization today. Angelo Furina, Head of Enterprise Infrastructure & Cloud Angelo is the Head of Enterprise  Infrastructure and Cloud at UniSuper and is passionate about business transformation and bridging the gap between technology and business strategy. With more than a decade of industry experience, Angelo has delivered technology solutions across manufacturing, telecommunications, media and finance.  Theo Davies Theo is the Head of Cloud Sales Excellence & Productivity at Google Cloud. He is a record-breaking salesperson, sales leader, coach and speaker with a 20+ year career beginning in sales. Theo is also the President of the Google Public Speaking Academy.  

Here's what you need to know for today in the business of podcasting:Spotify's podcast and audiobook discovery will get a boost from Google Cloud's AI by Amrita KhalidYouTube intros new AI governance policies. AI helps enforce them by Brad HillThe case for and against brand safety by Seb Joseph and Krystal ScanlonDefining Premium Video - How VAB and Comcast's FreeWheel are Trying to Settle TV Industry Debate by Jack Neff…as for the rest of the news: PodPod covers how to hit the mark with GenZ podcast listeners, and Triton's newest batch of podcast rankers have arrived, including Australia's top 100 showing Hamish & Andy has held its #1 spot for six months running.

Injective: Powering Decentralized Financial InfrastructureListen to our latest DeFi by Design Podcast⬇️Discover Union Build a hyper-efficient zero-knowledge infrastructure layer that revolutionizes message passing, asset transfers, NFTs, and DeFi. Learn more here!The First NFL game is available to trade on Overtime – Sports market AMM built on Thalesmarket – $THALES. Try it

A new partnership between Liquid and Google is the focus in this edition of the Business Day Spotlight. Our host Mudiwa Gavaza is joined by Oswald Jumira, CEO of Liquid C2 and Umesh Vemuri, VP of Strategic Pursuits at Google Cloud. The discussion reflects on Liquid and Google's new cloud computing partnership; what it means to operate in a multi-cloud environment; and the place of cloud in a world of artificial intelligence (AI). Business Day Spotlight is a TimesLIVE Production.

As Supercomputing 2023 is held in Denver this week, we're on the lookout for all the latest news. We have a new list of Top-500 supercomputers, more Nvidia announcements, and lots of AI. Perhaps the biggest topic of discussion, though, are the many questions about HPC itself: Will we be able to live in an exascale world? And what does that even mean when AI is the main application? Time Stamps: 0:00 - Welcome to the Rundown 1:41 - US Plans More Spectrum to Commercial Providers for 5G Demand 3:58 - AMD Milan-based Cloud Instances revealed by Google 7:09 - YouTube to Label AI Generated Content 10:42 - Dell and Hugging Face Strike Deal for Open Source GenAI 13:56 - Microsoft Briefly Blocks ChatGPT Access for Employees 17:25 - Comvmault Shift Re-Launch Commvault Cloud 22:12 - Supercomputing 23 Announcements 32:53 - The Weeks Ahead 33:48 - Thanks for Watching Hosts: Stephen Foskett: https://www.twitter.com/SFoskett Tim Bertino: https://www.twitter.com/TimBertino Follow Gestalt IT Website: ⁠⁠https://www.GestaltIT.com/⁠⁠ Twitter: ⁠⁠https://www.twitter.com/GestaltIT⁠⁠ LinkedIn: ⁠⁠https://www.linkedin.com/company/Gestalt-IT Tags: #Rundown, #5G, #AI, #HPC, @GoogleCloud, @Google, @AMD, #GenAI, @DellTech, @HuggingFace, #OpenSource, #Storage, @Microsoft, #ChatGPT, #CommvaultShift, @Commvault, #SC23, #Supercomputing, @GestaltIT, @SFoskett, @TimBertino,

Dive into the depths of Shadow IT and learn how Spin.AI's innovative solutions are safeguarding businesses against the hidden risks of third-party applications. Cloud N Clear episode 167 digs into the story behind SADA SaaS Alliance Partner Spin.AI and their work on mission-critical applications that provide asset & risk management value. Join us in this engaging episode, and don't forget to LIKE, SHARE, & SUBSCRIBE for more enlightening content! ✅  

Amr and I met on a genAI panel and everything he said was both insightful and contrarian. Immediately, I knew I wanted to introduce him to you. Amr is a legend in the search space who, by the way, also founded Cloudera which went public in 2017 at a valuation of over $5B.Dr. Amr Awadallah is a luminary in the world of information retrieval. He's the CEO and cofounder of Vectara, a company that is revolutionizing how we find meaning across all languages of the world using the latest advances in Deep Neural Networks, Large Language Models, and Natural Language Processing. He previously served as VP of Developer Relations for Google Cloud. Prior to joining Google in Nov 2019, Amr co-founded Cloudera in 2008 and as Global CTO. He also served as vice president of product intelligence engineering at Yahoo! from 2000-2008. Amr received his PhD in EE from Stanford University, and his Bachelor and Masters Degrees from Cairo University, Egypt.Listen and learn...How Amr discovered the power of "talking to software" via LLMs while at GoogleAbout the history of new computing modalitiesAbout the current state of generative AIThe technical explanation for hallucination in LLMsHow do we mitigate bias in LLM models and prevent copyright infringementWhy a semantic understanding of queries is the next frontier in searchThe challenge faced by search providers of making money incorporating ads into LLM-based answersHow "grounded search" will fix the hallucination problemWhat is a "fact" in the era of ChatGPT?How long before we have "antivirus sofware for fact-checking" genAI propagandaHow should AI be regulated... and who is responsible for AI regulationThe next big idea in genAI Amr and I are ready to fundAmr's advice to entrepreneurs... and to himselfReferences in this episode...Eric Olson, Consensus CEO, on AI and the Future of WorkD Das, Sorcero CEO, on AI and the Future of WorkSeth Earley, Earley Information Science, on AI and the Future of WorkChatGPT for searching scientific papers

Fei-Fei Li's new book is the story of her journey from China to the U.S., from small business to Big Tech, and from academic research to corporate life, and back again. But more than that, it's the story of the dawn of artificial intelligence, as told through her experience as one of the people summoning this new day and standing there awestruck, excited and concerned about what it will mean for humanity. Dr. Li joins us on this episode to discuss the book, The Worlds I See: Curiosity, Exploration, and Discovery at the Dawn of AI, published by Moment of Lift Books, an imprint from Melinda French Gates and Flatiron Books. Known for her foundational contributions to AI and computer vision, Dr. Li is the inventor of ImageNet, a large-scale dataset of images that enabled rapid advances in deep learning for visual recognition. She is a professor of computer science at Stanford University and a co-director of the Stanford Institute for Human-Centered Artificial Intelligence, who worked as Google Cloud's chief scientist for AI/ML during a 2017-2018 sabbatical. Note: GeekWire's Todd Bishop will be speaking further with Dr. Li on Monday evening Nov. 13 at Town Hall in Seattle. See this site for details and tickets. Edited by Curt Milton.See omnystudio.com/listener for privacy information.

Novembro é tempo de Black Friday, data que mobiliza as empresas de varejo no mundo todo para garantir as melhores ofertas e alavancar as vendas na reta final do ano. E quando falamos de varejo on-line, a preparação para a Black Friday é ainda mais intensa. Garantir escalabilidade para manter as plataformas digitais de vendas estáveis durante esse período de pico de acessos, com um volume imenso de solicitações simultâneas, é só um dos desafios para essas empresas.  Diante dos desafios, a alternativa escolhida por muitos varejistas para garantir a sua presença online em uma plataforma confiável, é fazer parte de um marketplace, modelo de negócio que reúne diversas marcas e lojas em um mesmo e-commerce. Para falar sobre os desafios do varejo on-line em tempos de Black Friday, recebemos o time do Grupo Casas Bahia, representados por Luciano Pinho, Diretor de Data e Analytics do Grupo Casas Bahia, e Marcus Novais, Diretor de Tecnologia do Grupo Casas Bahia. E também Carol Hudson, Account Manager do Google Cloud, e Silvia Somazz, Head de Retail do Google Cloud.

Wendy Wu's motto is: Where there's a will, there's a way. It's taken her far—from Microsoft to Google, and now to software developer SailPoint, where she is the Chief Marketing Officer.Wendy believes that “you have to be the owner of your own career,” and that means defining what you want outside of your current role. She tells us about the time she did just that at Microsoft when her position was eliminated and she had to create a new position for herself.“Oftentimes a job description just tells you the status quo for today,” says Wendy, who grew up in China. “It doesn't tell you what's going to be next for you, so always extend yourself into other areas that may set you up for longer-term success.” We chat about three keys to defining your career and Wendy encourages us to seek help along the way!Theme: Know What You WantEpisode Highlights:Work life blend vs work life balanceAlways give your best effort at work and lifeGo beyond the job descriptionCreate your own opportunitiesTalk to others about their jobsTry out a role and pivoting as necessaryBe aware of how you feel Volunteer to develop new skillsAsk for help along the wayWendy's Bio:Wendy Wu brings over 20 years of experience in B2B enterprise marketing to her role at SailPoint as the company's Chief Marketing Officer. At SailPoint, she's focused on accelerating the company's growth through modern, digital marketing, elevating SailPoint's brand recognition, driving product adoption, and helping to deliver against the company's business goals worldwide.Prior to joining SailPoint, Wendy was Vice President of Marketing at Box, where she led the global demand generation team to fuel the growth of the business as a leading content cloud platform. Before Box, Wendy spent eight years at Google Cloud. While there, she built the demand generation team for the Google Cloud Platform, eventually scaling the global marketing programs to support a multi-billion-dollar business. Before Google, Wendy held various product marketing and marketing leadership roles at Microsoft and other global companies.Wendy received her bachelor's degree in English from Fudan University and her master's degrees in Public Policy and Cultural Anthropology from Duke University.Connect with us on our social media: Instagram and LinkedInJoin our LinkedIn community where we discuss rule-breaking strategies for multicultural women.More from Alisa Manjarrez: Instagram and LinkedInMore from Courtney Copelin: Instagram and LinkedInMore from Dr. Merary Simeon: Instagram and LinkedInLearn more at www.whatrulespodcast.com.