Podcasts about S3

S3/83: Business Credit 101 Business Credit is what Kisha Jo calls the “Secret Sauce” in business. Once your business is established you should definitely start building credit in your business name. Tia Noel launched a new endeavor so We're discussing the basics of building business credit, what's needed and do you get started. To schedule a business credit consultation visit www.thirtygirl.org ……….. SUBSCRIBE & FOLLOW US: @thirtygirlpodcast @magicinthismess @luvherkey Facebook,Twitter, Instagram --- Send in a voice message: https://anchor.fm/thethirtygirl/message

Full Description / Show Notes Steren and Corey talk about how Google Cloud Run got its name (00:49) Corey talks about his experiences using Google Cloud (2:42) Corey and Steven discuss Google Cloud's cloud run custom domains (10:01) Steren talks about Cloud Run's high developer satisfaction and scalability (15:54) Corey and Steven talk about Cloud Run releases at Google I/O (23:21) Steren discusses the majority of developer and customer interest in Google's cloud product (25:33) Steren talks about his 20% projects around sustainability (29:00) About SterenSteren is a Senior Product Manager at Google Cloud. He is part of the serverless team, leading Cloud Run. He is also working on sustainability, leading the Google Cloud Carbon Footprint product.Steren is an engineer from École Centrale (France). Prior to joining Google, he was CTO of a startup building connected objects and multi device solutions.Links Referenced: Google Cloud Run: https://cloud.run sheets-url-shortener: https://github.com/ahmetb/sheets-url-shortener snark.cloud/run: https://snark.cloud/run Twitter: https://twitter.com/steren 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: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by Steren Giannini, who is a senior product manager at Google Cloud, specifically on something called Google Cloud Run. Steren, thank you for joining me today.Steren: Thanks for inviting me, Corey.Corey: So, I want to start at the very beginning of, “Oh, a cloud service. What are we going to call it?” “Well, let's put the word cloud in it.” “Okay, great. Now, it is cloud, so we have to give it a vague and unassuming name. What does it do?” “It runs things.” “Genius. Let's break and go for work.” Now, it's easy to imagine that you spent all of 30 seconds on a name, but it never works that way. How easy was it to get to Cloud Run as a name for the service?Steren: [laugh]. Such a good question because originally it was not named Cloud Run at all. The original name was Google Serverless Engine. But a few people know that because they've been helping us since the beginning, but originally it was Google Serverless Engine. Nobody liked the name internally, and I think at one point, we wondered, “Hey, can we drop the engine structure and let's just think about the name. And what does this thing do?” “It runs things.”We already have Cloud Build. Well, wouldn't it be great to have Cloud Run to pair with Cloud Build so that after you've built your containers, you can run them? And that's how we ended up with this very simple Cloud Run, which today seems so obvious, but it took us a long time to get to that name, and we actually had a lot of renaming to do because we were about to ship with Google Serverless Engine.Corey: That seems like a very interesting last-minute change because it's not just a find and replace at that point, it's—Steren: No.Corey: —“Well, okay, if we call it Cloud Run, which can also be a verb or a noun, depending, is that going to change the meaning of some sentences?” And just doing a find and replace without a proofread pass as well, well, that's how you wind up with funny things on Twitter.Steren: API endpoints needed to be changed, adding weeks of delays to the launch. That is why we—you know, [laugh] announced in 2018 and publicly launched in 2019.Corey: I've been doing a fair bit of work in cloud for a while, and I wound up going down a very interesting path. So, the first native Google Cloud service—not things like WP Engine that ride on top of GCP—but my first native Google Cloud Service was done in service of this podcast, and it is built on Google Cloud Run. I don't think I've told you part of this story yet, but it's one of the reasons I reached out to invite you onto the show. Let me set the stage here with a little bit of backstory that might explain what the hell I'm talking about.As listeners of this show are probably aware, we have sponsors whom we love and adore. In the early days of this show, they would say, “Great, we want to tell people about our product”—which is the point of a sponsorship—“And then send them to a URL.” “Great. What's the URL?” And they would give me something that was three layers deep, then with a bunch of UTM tracking parameters at the end.And it's, “You do realize that no one is going to be sitting there typing all of that into a web browser?” At best, you're going to get three words or so. So, I built myself a URL redirector, snark.cloud. I can wind up redirecting things in there anywhere it needs to go.And for a long time, I did this on top of S3 and then put CloudFront in front of it. And this was all well and good until, you know, things happened in the fullness of time. And now holy crap, I have an operations team involved in things, and maybe I shouldn't be the only person that knows how to work on all of these bits and bobs. So, it was time to come up with something that had a business user-friendly interface that had some level of security, so I don't wind up automatically building out a spam redirect service for anything that wants to, and it needs to be something that's easy to work with. So, I went on an exploration.So, at first it showed that there were—like, I have an article out that I've spoken about before that there are, “17 Ways to Run Containers on AWS,” and then I wrote the sequel, “17 More Ways to Run Containers on AWS.” And I'm keeping a list, I'm almost to the third installation of that series, which is awful. So, great. There's got to be some ways to build some URL redirect stuff with an interface that has an admin panel. And I spent three days on this trying a bunch of different things, and some were running on deprecated versions of Node that wouldn't build properly and others were just such complex nonsense things that had got really bad. I was starting to consider something like just paying for Bitly or whatnot and making it someone else's problem.And then I stumbled upon something on GitHub that really was probably one of the formative things that changed my opinion of Google Cloud for the better. And within half an hour of discovering this thing, it was up and running. I did the entire thing, start to finish, from my iPad in a web browser, and it just worked. It was written by—let me make sure I get his name correct; you know, messing up someone's name is a great way to say that we don't care about them—Ahmet Balkan used to work at Google Cloud; now he's over at Twitter. And he has something up on GitHub that is just absolutely phenomenal about this, called sheets-url-shortener.And this is going to sound wild, but stick with me. The interface is simply a Google Sheet, where you have one column that has the shorthand slug—for example, run; if you go to snark.cloud/run, it will redirect to Google Cloud Run's website. And the second column is where you want it to go. The end.And whenever that gets updated, there's of course some caching issues, which means it can take up to five seconds from finishing that before it will actually work across the entire internet. And as best I can tell, that is fundamentally magic. But what made it particularly useful and magic, from my perspective, was how easy it was to get up and running. There was none of this oh, but then you have to integrate it with Google Sheets and that's a whole ‘nother team so there's no way you're going to be able to figure that out from our Docs. Go talk to them and then come back in the day.They were the get started, click here to proceed. It just worked. And it really brought back some of the magic of cloud for me in a way that I hadn't seen in quite a while. So, all which is to say, amazing service, I continue to use it for all of these sponsored links, and I am still waiting for you folks to bill me, but it fits comfortably in the free tier because it turns out that I don't have hundreds of thousands of people typing it in every week.Steren: I'm glad it went well. And you know, we measure tasks success for Cloud Run. And we do know that most new users are able to deploy their apps very quickly. And that was the case for you. Just so you know, we've put a lot of effort to make sure it was true, and I'll be glad to tell you more about all that.But for that particular service, yes, I suppose Ahmet—who I really enjoyed working with on Cloud Run, he was really helpful designing Cloud Run with us—has open-sourced this side project. And basically, you might even have clicked on a deploy to Cloud Run button on GitHub, right, to deploy it?Corey: That is exactly what I did and it somehow just worked and—Steren: Exactly.Corey: And it knew, even logging into the Google Cloud Console because it understands who I am because I use Google Docs and things, I'm already logged in. None of this, “Oh, which one of these 85 credential sets is it going to be?” Like certain other clouds. It was, “Oh, wow. Wait, cloud can be easy and fun? When did that happen?”Steren: So, what has happened when you click that deploy to Google Cloud button, basically, the GitHub repository was built into a container with Cloud Build and then was deployed to Cloud Run. And once on Cloud Run, well, hopefully, you have forgotten about it because that's what we do, right? We—give us your code, in a container if you know containers if you don't just—we support, you know, many popular languages, and we know how to build them, so don't worry about that. And then we run it. And as you said, when there is low traffic or no traffic, it scales to zero.When there is low traffic, you're likely going to stay under the generous free tier. And if you have more traffic for, you know, Screaming in the Cloud suddenly becoming a high destination URL redirects, well, Cloud Run will scale the number of instances of this container to be able to handle the load. Cloud Run scales automatically and very well, but only—as always—charging you when you are processing some requests.Corey: I had to fork and make a couple of changes myself after I wound up doing some testing. The first was to make the entire thing case insensitive, which is—you know, makes obvious sense. And the other was to change the permanent redirect to a temporary redirect because believe it or not, in the fullness of time, sometimes sponsors want to change the landing page in different ways for different campaigns and that's fine by me. I just wanted to make sure people's browser cache didn't remember it into perpetuity. But it was easy enough to run—that was back in the early days of my exploring Go, which I've been doing this quarter—and in the couple of months this thing has been running it has been effectively flawless.It's set it; it's forget it. The only challenges I had with it are it was a little opaque getting a custom domain set up that—which is still in beta, to be clear—and I've heard some horror stories of people saying it got wedged. In my case, no, I deployed it and I started refreshing it and suddenly, it start throwing an SSL error. And it's like, “Oh, that's not good, but I'm going to break my own lifestyle here and be patient for ten minutes.” And sure enough, it cleared itself and everything started working. And that was the last time I had to think about any of this. And it just worked.Steren: So first, Cloud Run is HTTPS only. Why? Because it's 2020, right? It's 2022, but—Corey: [laugh].Steren: —it's launched in 2020. And so basically, we have made a decision that let's just not accept HTTP traffic; it's only HTTPS. As a consequence, we need to provision a cert for your custom domain. That is something that can take some time. And as you said, we keep it in beta or in preview because we are not yet satisfied with the experience or even the performance of Cloud Run custom domains, so we are actively working on fixing that with a different approach. So, expect some changes, hopefully, this year.Corey: I will say it does take a few seconds when people go to a snark.cloud URL for it to finish resolving, and it feels on some level like it's almost like a cold start problem. But subsequent visits, the same thing also feel a little on the slow and pokey side. And I don't know if that's just me being wildly impatient, if there's an optimization opportunity, or if that's just inherent to the platform that is not under current significant load.Steren: So, it depends. If the Cloud Run service has scaled down to zero, well of course, your service will need to be started. But what we do know, if it's a small Go binary, like something that you mentioned, it should really take less than, let's say, 500 milliseconds to go from zero to one of your container instance. Latency can also be due to the way the code is running. If it occurred is fetching things from Google Sheets at every startup, that is something that could add to the startup latency.So, I would need to take a look, but in general, we are not spinning up a virtual machine anytime we need to scale horizontally. Like, our infrastructure is a multi-tenant, rapidly scalable infrastructure that can materialize a container in literally 300 milliseconds. The rest of the latency comes from what does the container do at startup time?Corey: Yeah, I just ran a quick test of putting time in front of a curl command. It looks like it took 4.83 seconds. So, enough to be perceptive. But again, for just a quick redirect, it's generally not the end of the world and there's probably something I'm doing that is interesting and odd. Again, I did not invite you on the show to file a—Steren: [laugh].Corey: Bug report. Let's be very clear here.Steren: Seems on the very high end of startup latencies. I mean, I would definitely expect under the second. We should deep-dive into the code to take a look. And by the way, building stuff on top of spreadsheets. I've done that a ton in my previous lives as a CTO of a startup because well, that's the best administration interface, right? You just have a CRUD UI—Corey: [unintelligible 00:12:29] world and all business users understand it. If people in Microsoft decided they were going to change Microsoft Excel interface, even a bit, they would revert the change before noon of the same day after an army of business users grabbed pitchforks and torches and marched on their headquarters. It's one of those things that is how the world runs; it is the world's most common IDE. And it's great, but I still think of databases through the lens of thinking about it as a spreadsheet as my default approach to things. I also think of databases as DNS, but that's neither here nor there.Steren: You know, if you have maybe 100 redirects, that's totally fine. And by the way, the beauty of Cloud Run in a spreadsheet, as you mentioned is that Cloud Run services run with a certain identity. And this identity, you can grant it permissions. And in that case, what I would recommend if you haven't done so yet, is to give an identity to your Cloud Run service that has the permission to read that particular spreadsheet. And how you do that you invite the email of the service account as a reader of your spreadsheet, and that's probably what you did.Corey: The click button to the workflow on Google Cloud automatically did that—Steren: Oh, wow.Corey: —and taught me how to do it. “Here's the thing that look at. The end.” It was a flawless user-onboarding experience.Steren: Very nicely done. But indeed, you know, there is this built-in security which is the principle of minimal permission, like each of your Cloud Run service should basically only be able to read and write to the backing resources that they should. And by default, we give you a service account which has a lot of permissions, but our recommendation is to narrow those permissions to basically only look at the cloud storage buckets that the service is supposed to look at. And the same for a spreadsheet.Corey: Yes, on some level, I feel like I'm going to write an analysis of my own security approach. It would be titled, “My God, It's Full Of Stars” as I look at the IAM policies of everything that I've configured. The idea of least privilege is great. What I like about this approach is that it made it easy to do it so I don't have to worry about it. At one point, I want to go back and wind up instrumenting it a bit further, just so I can wind up getting aggregate numbers of all right, how many times if someone visited this particular link? It'll be good to know.And I don't know… if I have to change permissions to do that yet, but that's okay. It's the best kind of problem: future Corey. So, we'll deal with that when the time comes. But across the board, this has just been a phenomenal experience and it's clear that when you were building Google Cloud Run, you understood the assignment. Because I was looking for people saying negative things about it and by and large, all of its seem to come from a perspective of, “Well, this isn't going to be the most cost-effective or best way to run something that is hyperscale, globe-spanning.”It's yes, that's the thing that Kubernetes was originally built to run and for some godforsaken reason people run their blog on it instead now. Okay. For something that is small, scales to zero, and has long periods where no one is visiting it, great, this is a terrific answer and there's absolutely nothing wrong with that. It's clear that you understood who you were aiming at, and the migration strategy to something that is a bit more, I want to say robust, but let's be clear what I mean when I'm saying that if you want something that's a little bit more impressive on your SRE resume as you're trying a multi-year project to get hired by Google or pretend you got hired by Google, yeah, you can migrate to something else in a relatively straightforward way. But that this is up, running, and works without having to think about it, and that is no small thing.Steren: So, there are two things to say here. The first is yes, indeed, we know we have high developer satisfaction. You know, we measure this—in Google Cloud, you might have seen those small satisfaction surveys popping up sometimes on the user interface, and you know, we are above 90% satisfaction score. We hire third parties to help us understand how usable and what satisfaction score would users get out of Cloud Run, and we are constantly getting very, very good results, in absolute but also compared to the competition.Now, the other thing that you said is that, you know, Cloud Run is for small things, and here while it is definitely something that allows you to be productive, something that strives for simplicity, but it also scales a lot. And contrary to other systems, you do not have any pre-provisioning to make. So, we have done demos where we go from zero to 10,000 container instances in ten seconds because of the infrastructure on which Cloud Run runs, which is fully managed and multi-tenant, we can offer you this scale on demand. And many of our biggest customers have actually not switched to something like Kubernetes after starting with Cloud Run because they value the low maintenance, the no infrastructure management that Cloud Run brings them.So, we have like Ikea, ecobee… for example ecobee, you know, the smart thermostats are using Cloud Run to ingest events from the thermostat. I think Ikea is using Cloud Run more and more for more of their websites. You know, those companies scale, right? This is not, like, scale to zero hobby project. This is actually production e-commerce and connected smart objects production systems that have made the choice of being on a fully-managed platform in order to reduce their operational overhead.[midroll 00:17:54]Corey: Let me be clear. When I say scale—I think we might be talking past each other on a small point here. When I say scale, I'm talking less about oh tens or hundreds of thousands of containers running concurrently. I'm talking in a more complicated way of, okay, now we have a whole bunch of different microservices talking to one another and affinity as far as location to each other for data transfer reasons. And as you start beginning to service discovery style areas of things, where we build a really complicated applications because we hired engineers and failed to properly supervise them, and that type of convoluted complex architecture.That's where it feels like Cloud Run increasingly, as you move in that direction, starts to look a little bit less like the tool of choice. Which is fine, I want to be clear on that point. The sense that I've gotten of it is a great way to get started, it's a great way to continue running a thing you don't have to think about because you have a day job that isn't infrastructure management. And it is clear to—as your needs change—to either remain with the service or pivot to a very close service without a whole lot of retooling, which is key. There's not much of a lock-in story to this, which I love.Steren: That was one of the key principles when we started to design Cloud Run was, you know, we realized the industry had agreed that the container image was the standard for the deployment artifact of software. And so, we just made the early choice of focusing on deploying containers. Of course, we are helping users build those containers, you know, we have things called build packs, we can continuously deploy from GitHub, but at the end of the day, the thing that gets auto-scaled on Cloud Run is a container. And that enables portability.As you said. You can literally run the same container, nothing proprietary in it, I want to be clear. Like, you're just listening on a port for some incoming requests. Those requests can be HTTP requests, events, you know, we have products that can push events to Cloud Run like Eventarc or Pub/Sub. And this same container, you can run it on your local machine, you can run it on Kubernetes, you can run it on another cloud. You're not locked in, in terms of API of the compute.We even went even above and beyond by having the Cloud Run API looks like a Kubernetes API. I think that was an extra effort that we made. I'm not sure people care that much, but if you look at the Cloud Run API, it is actually exactly looking like Kubernetes, Even if there is no Kubernetes at all under the hood; we just made it for portability. Because we wanted to address this concern of serverless which was lock-in. Like, when you use a Function as a Service product, you are worried that the architecture that you are going to develop around this product is going to be only working in this particular cloud provider, and you're not in control of the language, the version that this provider has decided to offer you, you're not in control of more of the complexity that can come as you want to scan this code, as you want to move this code between staging and production or test this code.So, containers are really helping with that. So, I think we made the right choice of this new artifact that to build Cloud Run around the container artifact. And you know, at the time when we launched, it was a little bit controversial because back in the day, you know, 2018, 2019, serverless really meant Functions as a Service. So, when we launched, we little bit redefined serverless. And we basically said serverless containers. Which at the time were two worlds that in the same sentence were incompatible. Like, many people, including internally, had concerns around—Corey: Oh, the serverless versus container war was a big thing for a while. Everyone was on a different side of that divide. It's… containers are effectively increasingly—and I know, I'll get email for this, and I don't even slightly care, they're a packaging format—Steren: Exactly.Corey: —where it solves the problem of how do I build this thing to deploy on Debian instances? And Ubuntu instances, and other instances, God forbid, Windows somewhere, you throw a container over the wall. The end. Its DevOps is about breaking down the walls between Dev and Ops. That's why containers are here to make them silos that don't have to talk to each other.Steren: A container image is a glorified zip file. Literally. You have a set of layers with files in them, and basically, we decided to adopt that artifact standard, but not the perceived complexity that existed at the time around containers. And so, we basically merged containers with serverless to make something as easy to use as a Function as a Service product but with the power of bringing your own container. And today, we are seeing—you mentioned, what kind of architecture would you use Cloud Run for?So, I would say now there are three big buckets. The obvious one is anything that is a website or an API, serving public internet traffic, like your URL redirect service, right? This is, you have an API, takes a request and returns a response. It can be a REST API, GraphQL API. We recently added support for WebSockets, which is pretty unique for a service offering to support natively WebSockets.So, what I mean natively is, my client can open a socket connection—a bi-directional socket connection—with a given instance, for up to one hour. This is pretty unique for something that is as fully managed as Cloud Run.Corey: Right. As we're recording this, we are just coming off of Google I/O, and there were a number of announcements around Cloud Run that were touching it because of, you know, strange marketing issues. I only found out that Google I/O was a thing and featured cloud stuff via Twitter at the time it was happening. What did you folks release around Cloud Run?Steren: Good question, actually. Part of the Google I/O Developer keynote, I pitched a story around how Cloud Run helps developers, and the I/O team liked the story, so we decided to include that story as part of the live developer keynote. So, on stage, we announced Cloud Run jobs. So now, I talked to you about Cloud Run services, which can be used to expose an API, but also to do, like, private microservice-to-microservice communication—because cloud services don't have to be public—and in that case, we support GRPC and, you know, a very strong security mechanism where only Service A can invoke Service B, for example, but Cloud Run jobs are about non-request-driven containers. So, today—I mean, before Google I/O a few days ago, the only requirement that we imposed on your container image was that it started to listen for requests, or events, or GRPC—Corey: Web requests—Steren: Exactly—Corey: It speaks [unintelligible 00:24:35] you want as long as it's HTTP. Yes.Steren: That was the only requirement we asked you to have on your container image. And now we've changed that. Now, if you have a container that basically starts and executes to completion, you can deploy it on a Cloud Run job. So, you will use Cloud Run jobs for, like, daily batch jobs. And you have the same infrastructure, so on-demand, you can go from zero to, I think for now, the maximum is a hundred tasks in parallel, for—of course, you can run many tasks in sequence, but in parallel, you can go from zero to a hundred, right away to run your daily batch job, daily admin job, data processing.But this is more in the batch mode than in streaming mode. If you would like to use a more, like, streaming data processing, than a Cloud Run service would still be the best fit because you can literally push events to it, and it will auto-scale to handle any number of events that it receives.Corey: Do you find that the majority of customers are using Cloud Run for one-off jobs that barely will get more than a single container, like my thing, or do you find that they're doing massively parallel jobs? Where's the lion's share of developer and customer interest?Steren: It's both actually. We have both individual developers, small startups—which really value the scale to zero and pay per use model of Cloud Run. Your URL redirect service probably is staying below the free tier, and there are many, many, many users in your case. But at the same time, we have big, big, big customers who value the on-demand scalability of Cloud Run. And for these customers, of course, they will probably very likely not scale to zero, but they value the fact that—you know, we have a media company who uses Cloud Run for TV streaming, and when there is a soccer game somewhere in the world, they have a big spike of usage of requests coming in to their Cloud Run service, and here they can trust the rapid scaling of Cloud Run so they don't have to pre-provision things in advance to be able to serve that sudden traffic spike.But for those customers, Cloud Run is priced in a way so that if you know that you're going to consume a lot of Cloud Run CPU and memory, you can purchase Committed Use Discounts, which will lower your bill overall because you know you are going to spend one dollar per hour on Cloud Run, well purchase a Committed Use Discount because you will only spend 83 cents instead of one dollar. And also, Cloud Run and comes with two pricing model, one which is the default, which is the request-based pricing model, which is basically you only have CPU allocated to your container instances if you are processing at least one request. But as a consequence of that, you are not paying outside of the processing of those requests. Those containers might stay up for you, one, ready to receive new requests, but you're not paying for them. And so, that is—you know, your URL redirect service is probably in that mode where yes when you haven't used it for a while, it will scale down to zero, but if you send one request to it, it will serve that request and then it will stay up for a while until it decides to scale down. But you the user only pays when you are processing these specific requests, a little bit like a Function as a Service product.Corey: Scales to zero is one of the fundamental tenets of serverless that I think that companies calling something serverless, but it always charges you per hour anyway. Yeah, that doesn't work. Storage, let's be clear, is a separate matter entirely. I'm talking about compute. Even if your workflow doesn't scale down to zero ever as a workload, that's fine, but if the workload does, you don't get to keep charging me for it.Steren: Exactly. And so, in that other mode where you decide to always have CPU allocated to your Cloud Run container instances, then you pay for the entire lifecycle of this container instances. You still benefit from the auto-scaling of Cloud Run, but you will pay for the lifecycle and in that case, the price points are lower because you pay for a longer period of time. But that's more the price model that those bigger customers will take because at their scale, they basically always receive requests, so they already to pay always, basically.Corey: I really want to thank you for taking the time to chat with me. Before you go, one last question that we'll be using as a teaser for the next episode that we record together. It seems like this is a full-time job being the product manager on Cloud Run, but no Google, contrary to popular opinion, does in fact, still support 20% projects. What's yours?Steren: So, I've been looking to work on Cloud Run since it was a prototype, and you know, for a long time, we've been iterating privately on Cloud Run, launching it, seeing it grow, seeing it adopted, it's great. It's my full-time job. But on Fridays, I still find the time to have a 20% project, which also had quite a bit of impact. And I work on some sustainability efforts for Google Cloud. And notably, we've released two things last year.The first one is that we are sharing some carbon characteristics of Google Cloud regions. So, if you have seen those small leaves in the Cloud Console next to the regions that are emitting the less carbon, that's something that I helped bring to life. And the second one, which is something quite big, is we are helping customers report and reduce their gross carbon emissions of their Google Cloud usage by providing an out of the box reporting tool called Google Cloud Carbon Footprint. So, that's something that I was able to bootstrap with a team a little bit on the side of my Cloud Run project, but I was very glad to see it launched by our CEO at the last Cloud Next Conference. And now it is a fully-funded project, so we are very glad that we are able to help our customers better meet their sustainability goals themselves.Corey: And we will be talking about it significantly on the next episode. We're giving a teaser, not telling the whole story.Steren: [laugh].Corey: I really want to thank you for being as generous with your time as you are. If people want to learn more, where can they find you?Steren: Well, if they want to learn more about Cloud Run, we talked about how simple was that name. It was obviously not simple to find this simple name, but the domain is https://cloud.run.Corey: We will also accept snark.cloud/run, I will take credit for that service, too.Steren: [laugh]. Exactly.Corey: There we are.Steren: And then, people can find me on Twitter at @steren, S-T-E-R-E-N. I'll be happy—I'm always happy to help developers get started or answer questions about Cloud Run. And, yeah, thank you for having me. As I said, you successfully deployed something in just a few minutes to Cloud Run. I would encourage the audience to—Corey: In spite of myself. I know, I'm as surprised as anyone.Steren: [laugh].Corey: The only snag I really hit was the fact that I was riding shotgun when we picked up my daughter from school and went through a dead zone. It's like, why is this thing not loading in the Google Cloud Console? Yeah, fix the cell network in my area, please.Steren: I'm impressed that you did all of that from an iPad. But yeah, to the audience give Cloud Run the try. You can really get started connecting your GitHub repository or deploy your favorite container image. And we've worked very hard to ensure that usability was here, and we know we have pretty strong usability scores. Because that was a lot of work to simplicity, and product excellence and developer experience is a lot of work to get right, and we are very proud of what we've achieved with Cloud Run and proud to see that the developer community has been very supportive and likes this product.Corey: I'm a big fan of what you've built. And well, of course, it links to all of that in the show notes. I just want to thank you again for being so generous with your time. And thanks again for building something that I think in many ways showcases the best of what Google Cloud has to offer.Steren: Thanks for the invite.Corey: We'll talk again soon. Steren Giannini is a senior product manager at Google Cloud, on Cloud Run. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. If it's on YouTube, put the thumbs up and the subscribe buttons as well, but in the event that you hated it also include an angry comment explaining why your 20% project is being a shithead on the internet.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Between the shapeless curtains of idle chatter and the ripples of water in a bathhouse, two debut novels by English homosexuals: Ronald Firbank's VAINGLORY (1915) + Allen Hollinghurst's THE SWIMMING POOL LIBRARY (1988). Fused together, these two beautifully uppity books communicate a private sublimity in the homosexual shadow over the world through a stained glass window, gay cruising, beautiful men on the train, OnlyFans, real sexuality, porn theaters, blood on the bedsheets... Follow the endlessly charming Yeerk on twitter: twitter.com/pyeerk And the I'M SO POPULAR Twitter: twitter.com/imsopopularpod And if you're not listening to SIRENS on Patreon, you're only getting half the story: patreon.com/imsopopular (S3.E06 セックスと水と悲劇の時代)

Are you building Empowered bridges? "Powered Dynamic always suggest that I can take something from you or I can give something to you and that you are inherently worth less because you do not have these things." Listen in for more, as we invite you to practice using an Empowered Dynamic & building bridges ❤️ Get ready to:

Full Description / Show Notes Gafnit explains how she found a vulnerability in RDS, an Amazon database service (1:40) Gafnit and Corey discuss the concept of not being able to win in cloud security (7:20) Gafnit talks about transparency around security breaches (11:02) Corey and Gafnit discuss effectively communicating with customers about security (13:00) Gafnit answers the question “Did you come at the RDS vulnerability exploration from a perspective of being deeper on the Postgres side or deeper on the AWS side? (18:10) Corey and Gafnit talk about the risk of taking a pre-existing open source solution and offering it as a managed service (19:07) Security measures in cloud-native approaches versus cloud-hosted (22:41) Gafnit and Corey discuss the security community (25:04) About GafnitGafnit Amiga is the Director of Security Research at Lightspin. Gafnit has 7 years of experience in Application Security and Cloud Security Research. Gafnit leads the Security Research Group at Lightspin, focused on developing new methods to conduct research for new cloud native services and Kubernetes. Previously, Gafnit was a lead product security engineer at Salesforce focused on their core platform and a security researcher at GE Digital. Gafnit holds a Bs.c in Computer Science from IDC Herzliya and a student for Ms.c in Data Science.Links Referenced: Lightspin: https://www.lightspin.io/ Twitter: https://twitter.com/gafnitav LinkedIn: https://www.linkedin.com/in/gafnit-amiga-b1357b125/ 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: Welcome to Screaming in the Cloud. I'm Corey Quinn. We've taken a bit of a security bent to the conversations that we've been having on this show and over the past year or so and, well, today's episode is no different. In fact, we're going a little bit deeper than we normally tend to. My guest today is Gafnit Amiga, who's the Director of Security Research at Lightspin. Gafnit, thank you for joining me.Gafnit: Hey, Corey. Thank you for inviting me to the show.Corey: You sort of burst onto the scene—and by ‘scene,' I of course mean the cloud space, at least to the level of community awareness—back, I want to say in April of 2022 when you posted a very in-depth blog post about exploiting RDS and some misconfigurations on AWS's side to effectively display internal service credentials for the RDS service itself. Now, that sounds like it's one of those incredibly deep, incredibly murky things because it is, let's be clear. At a high level, can you explain to me exactly what it is that you found and how you did it? Gafnit: Yes, so, RDS is database service of Amazon. It's a managed service where you can choose the engine that you prefer. One of them is Postgres. There, I found the vulnerability. The vulnerability was in the extension in the log_fdw—so it's for—like, stands for Foreign Data Wrapper—where this extension is, therefore reading the logs directly of the engine, and then you can query it using SQL queries, which should be simpler and easy to use.And this extension enables you to provide a path. And there was a path traversal, but the traversal happened only when you dropped a validation of the wrapper. And this is how I managed to read local files from the database EC2 machine, which shouldn't happen because this is a managed service and you shouldn't have any access to the underlying host.Corey: It's always odd when the abstraction starts leaking, from an AWS perspective. I know that a friend of mine was on Aurora during the beta and was doing some high-performance work and suddenly started seeing SQL errors about /var/temp filling up, which is, for those who are not well versed in SQL, and even for those who are, that's not the sort of thing you tend to expect to show up on there. It feels like the underlying system tends to leak in—particularly in RDS sense—into what is otherwise at least imagined to be a fully-managed service.Gafnit: Yes because sometimes they want to give you an informative error so you will be able to realize what happened and what caused to the error, and sometimes they prefer not to give you too many information because they don't want you to get to the underlying machine. This is why, for example, you don't get a regular superuser; you have an RDS superuser in the database.Corey: It seems to me that this is sort of a problem of layering different security models on top of each other. If you take a cloud-native database that they designed, start to finish, themselves, like DynamoDB, the entire security model for Dynamo, as best I can determine, is wrapped up within IAM. So, if you know IAM—spoiler, nobody knows IAM completely, it seems—but if you have that on lock you've got it; there's nothing else you need to think about. Whereas with RDS, you have to layer on IAM to get access to the database and what you're allowed to do with it.But then there's an entirely separate user management system, in many respects, of local users for other Postgres or MySQL or any other systems that were using, to a point where even when they started supporting IRM for authentication to RDS at the database user level. It was flagged in the documentation with a bunch of warnings of, “Don't do this for high-volume stuff; only do this in development style environments.” So, it's clear that it has been a difficult marriage, for lack of a better term. And then you have to layer on all the other stuff that if God forbid, you're in a multi-cloud style environment or working with Kubernetes on top of all of this, and it seems like you're having to pick and choose between four or five different levels of security modeling, as well as understand how all of those things interplay together. How come we don't see things like this happening four times a day as a result?Gafnit: Well, I guess that there are more issues being found, but not always published but I think that this is what makes it more complex for both sides. Creating managed services with resources and third parties that everybody knows. To make it easy for them to use requires a deep understanding of the existing permission models of the service where you want to integrate it with your permission model and how the combination works. So, you actually need to understand how every change is going to affect the restrictions that you want to have. So, for example, if you don't want the database users to be able to read-write or do a network activity, so you really need to understand the permission model of the Postgres itself. So, it makes it more complicated for development, but it's also good for researchers because they already know Postgres and they have a good starting point.Corey: My philosophy has always been when you're trying to secure something, you need to have at least a topical level of understanding of the entire system, start to finish. One of the problems I've had with the idea of microservices as is frequently envisioned is that there's separation, but not real separation, so you have to hand-wave over a whole bunch of the security model. If you don't understand something, I believe it's very difficult to secure it. And let's be honest, even if you do understand [laugh] something, it can be very difficult to secure it. And the cloud vendors with IAM and similar systems don't seem to be doing themselves any favors, given the sheer complexity and the capabilities that they're demanding of themselves, even for having one AWS service talk to another one, but in the right way.And it's finicky, and it's nuanced, and debugging it becomes a colossal pain. And finally, at least those of us who are bad at these things, finally say, “The hell with it,” and they just grant full access from Service A to Service B—in the confines of a test environment. I'm not quite that nuts myself, most days. And then it's the biggest lie we always tell ourselves is once we have something overscoped like that, usually for CI/CD, it's, “Oh, todo: I'll go back and fix that later.” Yeah, I'm looking back five years ago and that's still on my todo list.For some reason, it's never been the number one priority. And in all likelihood, it won't be until right after it really should have been my number one priority. It feels like in cloud security particularly, you can't win, you can only not lose. I always found that to be something of a depressing perspective and I didn't accept it for the longest time. But increasingly, these days, it started to feel like that is the state of the world. Am I wrong on that? Am I just being too dour?Gafnit: What do you mean by you cannot lose?Corey: There's no winning in security from my perspective because no one is going to say, “All right. We won the security. Problem solved. The end.” Companies don't view security as a value-add. It is only about a downside risk mitigation play.It's, “Yay, another day of not getting breached.” And the failure mode from there is, “Okay, well, we got breached, but we found out about it ourselves immediately internally, rather than reading about it in The New York Times in two weeks.” The winning is just the steady-state, the status quo. It's just all different flavors of losing beyond that.Gafnit: So, I don't think it's quite the case because I can tell that they do do always an active work on securing the services and their structure because I went over other extensions before reaching to the log foreign data wrapper, and they actually excluded high-risk functionalities that could help me to achieve privileged access to the underlying host. And they do it with other services as well because they do always do the security review before having it integrated externally. But you know, it's an endless zone. You can always have something. Security vulnerabilities are always [arrays 00:09:06]. So everyone, whenever they can help and to search and to give their value, it's appreciated.Corey: I feel like I need to clarify a bit of nuance. When your blog post first came out talking about this, I was, well let's say a little irritated toward AWS on Twitter and other places. And Twitter is not a place for nuance, it is easy to look at that and think, “Oh, I was upset at AWS for having a vulnerability.” I am not, I want to be very clear on that. Now, it's certainly not good, but these are computers; that is the nature of how they work.If you want to completely secure computer, cut the power to it, sink it in concrete and then drop it in the ocean. And even then, there are exceptions to all of that. So, it's always a question of not blocking all risk; it's about trade-offs and what risk is acceptable. And to AWS is credit, they do say that they practice defense-in-depth. Being able to access the credentials for the running RDS service on top of the instance that it was running on, while that's certainly not good, isn't as if you'd suddenly had keys to everything inside of AWS and all their security model crumbles away before you.They do the right thing and the people working on these things are incredibly good. And they work very hard at these things. My concern and my complaint is, as much as I enjoy the work that you do and reading these blog posts talking about how you did it, it bothers me that I have to learn about a vulnerability in a service for which I pay not small amounts of money—RDS is the number one largest charge in my AWS bill every month—and I have to hear about it from a third-party rather than the vendor themselves. In this case, it was a full day later, where after your blog post went up, and they finally had a small security disclosure on AWS's site talking about it. And that pattern feels to me like it leads nowhere good.Gafnit: So, transparency is a key word here. And when I wrote the post, I asked if they want to add anything from their side, and they told that they already reached out to the vulnerable customers and they helped them to migrate to their fixed version. So, from their side, it didn't felt it's necessary to add it over there. But I did mention the fact that I did the investigation and no customer data was hurt. Yeah, but I think that if there will be maybe a more organized process for any submission of any vulnerability that where all the steps are aligned, it will help everyone and anyone can be informed with everything that happens.Corey: I have always been extraordinarily impressed by people who work at AWS and handle a lot of the triaging of vulnerability reports. Zack Glick, before he left, was doing an awful lot of that Dan [Erson 00:12:05] continues to be a one of the bright lights of AWS, from my perspective, just as far as customer communication and understanding exactly what the customer perspective is. And as individuals, I see nothing but stars over at AWS. To be clear, ‘Nothing but Stars' is also the name of most of my IAM policies, but that's neither here nor there.It seems like, on some level, there's a communications and policy misalignment, on some level, because I look at this and every conversation I ever have with AWS's security folks, they are eminently reasonable, they're incredibly intelligent, and they care. There's no mistaking that they legitimately care. But somewhere at the scale of company they're at, incentives get crossed, and everyone has a different position they're looking at these things from, and it feels like that disjointedness leads to almost a misalignment as far as how to effectively communicate things like this to customers.Gafnit: Yes, it looks like this is the case, but if more things will be discovered and published, I think that they will have eventually an organized process for that. Because I guess the researchers do find things over there, but they're not always being published for several reasons. But yes, they should work on that. [laugh].Corey: And that is part of the challenge as well, where AWS does not have a public vulnerability disclosure program. [unintelligible 00:13:30] hacker one, they don't have a public bug bounty program. They have a vulnerability disclosure email address, and the people working behind that are some of the hardest working folks in tech, but there is no unified way of building a community of researchers around the idea of exploring this. And that is a challenge because you have reported vulnerabilities, I have reported significantly fewer vulnerabilities, but it always feels like it's a hurry up and wait scenario where the communication is not always immediate and clear. And at best, it feels like we often get a begrudging, “Thank you.”Versus all right, if we just throw ethics completely out the window and decide instead that now we're going to wind up focusing on just effectively selling it to the highest bidder, the value of, for example, a hypervisor escape on EC2 for example, is incalculable. There is no amount of money that a bug bounty program could offer for something like that compared to what it is worth to the right bad actor at the right time. So, the vulnerabilities that we hear about are already we're starting from a basis of people who have a functioning sense of ethics, people who are not deeply compromised trying to do something truly nefarious. What worries me is the story of—what are the stories that we aren't seeing? What are the things that are being found where instead of fighting against the bureaucracy around disclosure and the rest, people just use them for their own ends? And I'm gratified by the level of response I see from AWS on the things that they do find out about, but I always have to wonder, what aren't we seeing?Gafnit: That's a good question. And it really depends on their side if they choose to expose it or not.Corey: Part of the challenge too, is the messaging and the communication around it and who gets credit and the rest. And it's weird, whenever they release some additional feature to one of their big headline services, there are blog posts, there are keynote speeches, there are customer references, they go on speaking tours, and the emails, oh, God, they never stopped the emails talking about how amazing all of these things are. But whenever there's a security vulnerability or a disclosure like this—and to be fair, AWS's response to this speaks very well of them—it's like you have to go sneak down into the dark sub-basement, with the filing cabinet behind the leopard sign and the rest, to even find out that these things exist. And I feel like they're not doing themselves any favors by developing that reputation for lack of transparency around these things. “Well, while there was no customer impact, so why would we talk about it?”Because otherwise, you're setting up a myth that there never is a vulnerability on the side of—what is it that you're building as a cloud provider. And when there is a problem down the road—because there always is going to be; nothing is perfect—people are going to say, “Hey, wait a minute. You didn't talk about this. What else haven't you talked about?”And it rebounds on them with sometimes really unfortunate side effects. With Azure as a counterexample here, we see a number of Azure exploits where, “Yeah, turned out that we had access to other customers' data and Azure had no idea until we told them.” And Azure does it statements about, “Oh, we have no evidence of any of this stuff being used improperly.” Okay, that can mean that you've either check your logs and things are great or you don't have logging. I don't know that necessarily is something I trust.Conversely, AWS has said in the past, “We have looked at the audit logs for this service dating back to its launch years ago, and have validated that none of that has never been used like this.” One of those responses breeds an awful lot of customer trust. The other one doesn't. And I just wish AWS knew a little bit more how good crisis communication around vulnerabilities can improve customer trust rather than erode it.Gafnit: Yes, and I think that, as you said, there will always be vulnerabilities. And I think that we are expecting to find more, so being able to communicate as clearly as you can and to expose things about maybe the fakes and how the investigation is being done, even in a high level, for all the vulnerabilities can gain more trust from the customer side.Corey: DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, confidence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud slash C-H-R-O-N-O-S-P-H-E-R-E.Corey: You have experience in your background specifically around application security and cloud security research. You've been doing this for seven years at this point. When you started looking into this, did you come at the RDS vulnerability exploration from a perspective of being deeper on the Postgres side or deeper on the AWS side of things?Gafnit: So, it was both. I actually came to the RDS lead from another service where there was something [about 00:18:21] in the application level. But then I reached to an RDS and thought, well, it will be really nice to find thing over here and to reach the underlying machine. And when I entered to the RDS zone, I started to look at it from the application security eyes, but you have to know the cloud as well because there are integrations with S3, you need to understand the IAM model. So, you need a mix of both to exploit specifically this kind of issue. But you can also be database experts because the payload is a pure SQL.Corey: It always seems to me that this is an inherent risk in trying to take something that is pre-existing is an open-source solution—Postgres is one example but there are many more—and offer it as a managed service. Because I think one of the big misunderstandings is that when—well, AWS is just going to take something like Redis and offer that as a managed service, it's okay, I accept that they will offer a thing that respects the endpoints and then acts as if it were Redis, but under the hood, there is so much in all of these open-source projects that is built for optionality of wherever you want to run this thing, it will run there; whatever type of workload you want to throw at it, it can work. Whereas when you have a cloud provider converting these things into a managed service, they are going to strip out an awful lot of those things. An easy example might be okay, there's this thing that winds up having to calculate for the way the hard drives on a computer work and from a storage perspective.Well, all the big cloud providers already have interesting ways that they have solved storage. Every team does not reimplement that particular wheel; they use in-house services. Chubby's file locking, for example, over on Google side is a classic example of this that they've talked about an awful lot so every team building something doesn't have to rediscover all of that. So, the idea that, oh, we're just going to take up this open-source thing, clone it off a GitHub, fork it, and then just throw it into production as a managed service seems more than a little naive. What's your experience around seeing, as you get more [laugh] into the weeds of these things than most customers are allowed to get, what's your take on this?Do you find that this looks an awful lot like the open-source version that we all use? Or is it something that looks like it has been heavily customized to take advantage of what AWS is offering internally as underlying bedrock services?Gafnit: So, from what I saw until now, they do want to save the functionality so you will have the same experience as you're working with the same service that not on AWS because you're you are used to that. So, they are not doing dramatic changes, but they do want to reduce the risk in the security space. So, there will be some functionalities that they will not let you to do. And this is because of the managed party in areas where the full workload is deployed in your account and you can access it anyway, so they will not have the same security restrictions because you can access the workload anyway. But when it's managed, they need to prevent you from accessing the underlying host, for example. And they do the changes, but they're really picked to the specific actions that can lead you to that.Corey: It also feels like RDS is something of a, I don't want to call it a legacy service because it is clearly still very much actively developed, but it's what we'll call it a ‘classic service.' When I look at a new AWS launch, I tend to mentally bucket them into two things. There's the cloud-native approach, and we've already talked about DynamoDB. That would be one example of this. And there's the cloud-hosted model where you have to worry about things like instances and security groups and the networking stuff, and so on and so forth, where it's basically feels like they're running their thing on top of a pile of EC2 instances, and that abstraction starts leaking.Part of me wonders if looking at some of these older services like RDS, they made decisions in the design and build out of these things that they might not if they were to go ahead and build it out today. I mean, Aurora is an example of what that might look like. Have you found as you start looking around the various security foibles of different cloud services, that the security posture of some of the more cloud-native approaches is better or worse or the same as the cloud-hosted world?Gafnit: Well, so for example, in the several issues that were found, and also here in the RDS where you can see credentials in a file, this is not a best practice in security space. And so, definitely there are things to improve, even if it's developed on the provider side. But it's really hard to answer this question because in a managed area where you don't have any access, it's hard to tell how it's configured and if it's configured properly. So, you need to have some certification from their side.Corey: This is, on some level, part of the great security challenge, especially for something that is not itself open-source, where they obviously have terrific security teams, don't get me wrong. At no point do I want to ever come across a saying, “Oh, those AWS people don't know how security works.” That is provably untrue. But there is something to be said for the value of having a strong community in the security space focusing on this from the outside of looking at these things, of even helping other people contextualize these things. And I'm a little disheartened that none of the major cloud providers seem to have really embraced the idea of a cloud security community, to the point where the one that I'm most familiar with, the cloud security forum Slack team seems to be my default place where I go for context on things.Because I dabble. I keep my hand in when it comes to security, but I'm certainly no expert. That's what people like you are for. I make fun of clouds and I work on the billing parts of it and that's about as far as it goes for me. But being able to get context around is this a big deal? Is this description that a company is giving, is it accurate?For example, when your post came out, I had not heard of Lightspin in this context. So, reaching out to a few people I trusted, is this legitimate? The answer was, “Yes. It's legitimate and it's brilliant. That's a company that keep your eye on.” Great. That's useful context and there's no way to buy that. It has to come from having those conversations with people in the [broader 00:24:57] sense of the community. What's your experience been looking at the community side of the world of security?Gafnit: Well, so I think that the cloud security has a great community, and this is one of the things that we at Lightspin really want to increase and push forward. And we see ourselves as a security-driven company. We always do the best to publish a post, even detailed posts, not about vulnerabilities, about how things works in the cloud and how things are being evaluated, to release open-source tools where you can use them to check your environment even if you're not a customer. And I think that the community is always willing to explain and to investigate together. And it's a welcome effort, but I think that the messaging should be also for all layers, you know, also for the DevOps and the developers because it can really help if it will start from this point from their side, as well.Corey: It needs to be baked in, from start to finish.Gafnit: Yeah, exactly.Corey: I really want to thank you for taking the time out of your day to speak with me today. If people want to learn more about what you're up to, where's the best place for them to find you?Gafnit: So, you can find me on Twitter and on LinkedIn, and feel free to reach out.Corey: We will, of course, put links to that in the [show notes 00:26:25]. Thank you so much for being so generous with your time today. I appreciate it.Gafnit: Thank you, Corey.Corey: Gafnit Amiga, Director of Security Research at Lightspin. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, and if it's on the YouTubes, smash the like and subscribe buttons, which I'm told are there. Whereas if you've hated this podcast, same story, like and subscribe and the buttons, leave a five-star review on a various platform, but also leave an insulting, angry comment about how my observation that our IAM policies are all full of stars is inaccurate. And then I will go ahead and delete that comment later because you didn't set a strong password.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

S3, E16: The Brewers abruptly cut ties with one of the recent franchise greats, the lovable center fielder Lorenzo Cain. We give him the respect and honor he deserves for a fantastic career, recall his greatest moments, and discuss his biggest achievements. With midsummer coming up, we're coming up on All-Star and trade season. Who might be the Brewers' All-Stars beyond Burnes and Hader? Willy? Devin? And where should the Brewers target upgrades on the roster? The relief corps has had their fair share of struggles, but the offense has still struggled as of late. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/bleedingblueandyellow/message Support this podcast: https://anchor.fm/bleedingblueandyellow/support

'Uh, um, miss, seems that the strap has fallen off of your shoulder. I'd offer to put it back for you, but as a delivery guy, I don't know if it's my place.'In our latest episode, Paul imagines someone telling him that 3 episode of this series would focus on bathroom renovation, Carla wants to start middle finger waving, and we both scroll to the bottom of our ranking lists at the end of this one. Don't forget to feed those Tamagatchis, take that mirror off your ceiling if company's coming over, and join us as we struggle to find the funny in the 10th episode of season 5, Roadkill!Consider supporting the show on PatreonFollow and interact with us on FacebookFollow us on InstagramTop 10 Rankings so far:Carla1. S2, Ep. 1: Finding David2. S1, Ep. 1: Our Cup Runneth Over3. S2, Ep. 13: Happy Anniversary4. S4, Ep. 6: Open Mic5. S3, Ep. 13: Grad Night6. S1, Ep. 13: Town For Sale7. S4, Ep. 9: The Olive Branch8. S4, Ep 12: Singles Week9. S5, Ep. 9: The M.V.P.10. S1, Ep. 6: Wine And RosesPaul1. S1, Ep. 1: Our Cup Runneth Over2. S2, Ep 13: Happy Anniversary3. S2, Ep. 1: Finding David4. S3, Ep. 12: Friends & Family5. S3, Ep. 13: Grad Night6. S4, Ep. 13: Merry Christmas, Johnny Rose7. S5, Ep. 9: The M.V.P.8. S1, Ep. 9: Carl's Funeral9. S1, Ep. 13: Town For Sale10. S5, Ep. 8: The Hospies

WinSCP is an open source free SFTP client, FTP client, WebDAV client, S3 client and SCP client for Windows. Its main function is file transfer between a local and a remote computer.

S3, E6: Oakton Community College in Illinois recently received a $1.5 million grant to help support its Asian American and Pacific Islander (AAPI) students, who make up about 23% of Oakton's student population. Dear Aunaetitrakul, the grant's senior program manager, shares how Oakton promotes the grant and supports Oakton's large AAPI population – including some thoughts about why it might be time to start a subject-specific podcast at your own institution.

War and suffering: between the gloom of World War I in the poetry of Siegfried Sassoon and the laser glare of MOBILE SUIT GUNDAM.... Cuteness Unit and Chi Chi bash their helmets against impossible to talk about soap opera until some kind of meaning pierces through. Long silences. Women floating through space. Newtypes and empathy and the battle between futurism and humanism."Brutal." Tragedies so real and punishing they bleed into the post apocalyptic twilight of I'M SO POPULAR. Chi Chi sheds real tears; You Will See the Tears of Time. Follow the Cuteness Unit girls on Patreon: patreon.com/cutenessunit And the I'M SO POPULAR Twitter: twitter.com/imsopopularpod And if you're not listening to SIRENS, you're only getting half the story... listen now on the I'M SO POPULAR Patreon: patreon.com/imsopopularpod (S3.E05 苦悩の世紀から涙)

On Shaun's 50th birthday, it's business as usual, so here's a bite of the S3 finale coming next week! Learn more about your ad choices. Visit megaphone.fm/adchoices

S3, E15: The Brewers snapped their losing streak yesterday, but things don't look as promising as they did a few weeks ago. Can the Brewers right their ship before the All-Star break? With the lack of production from Yelich, Cutch, and Cain, it seems they might not have the pieces to make a deep run in October. Congratulations to Craig Counsell for becoming the Brewers all-time wins leader as a manager, so we look at who the 5 best managers are in franchise history. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/bleedingblueandyellow/message Support this podcast: https://anchor.fm/bleedingblueandyellow/support

Reboots/Remixes/Recycled Content...We love it...we hate it....we love to hate it! Bringing back Cinema bunday monday for season 3 with a chat with my wife, Kim, about non original content in film & TV. Is there any merit in recycling content? Is it always a cheap cash grab? Can something be great if it's based on something else? And why haven't I been posting for 6 months? I'll get into all that and more =) Good to be back! (sort of back anywho...I reserve the right to stretch S3 out for quite awhile!) Thank for listening Cinema Bunnies -Meow

Experts say there isn't enough being done to improve energy efficiency - so naturally we find out what Dale thinks about it.  Ian can't believe what he's hearing when Dale reveals he's off to meet Arnold Schwarzenegger in Vienna, but he'll be back.  We talk about what the government could do (or not do) with the rising price of our energy bills. New Zealand's also proposed a fart tax - sensible idea, right?  Lots of your questions too. 

S3. Ep 10 - Who Should Be Paying The Bills? by Millennial Mayhem

Got bias? You're not alone. "I have a bias here...that I had not really been invited to realize until this moment..." Listen in for more, as we invite you to hold yourself accountable, and own your truth in playful ways ❤️ Lean in to hear Nina's personal experience of being triggered by a particular idea - only to realize she needed to own her truth in order to move beyond her discomfort.Get ready to:

2 Black Nerds return to Twitter Spaces to share our immediate reactions to the three-episode premiere of Amazon Prime Video's ‘THE BOYS.' We begin by discussing the state of the series' main antagonist, Homelander (10:09), and the absolutely shocking opening 15 minutes of the premiere episode (24:22). Also, we address Butcher's role thus far and the connection that The Boys have to Victoria Neuman and the Federal Bureau of Superhuman Affairs (32:30). Then we address the introduction of Soldier Boy, and what his presence could mean for The Boys and The Seven as the season progresses (56:16). Listen to our in-depth review to 'The Boys' S3, Episodes 1-3 | Episode 116 (Timestamp: 2:02:16) Apple: apple.co/3mqTbrO Spotify: spoti.fi/3O1JuMa

About AlyssaAlyssa Miller, Business Information Security Officer (BISO) for S&P Global, is the global executive leader for cyber security across the Ratings division, connecting corporate security objectives to business initiatives. She blends a unique mix of technical expertise and executive presence to bridge the gap that can often form between security practitioners and business leaders. Her goal is to change how security professionals of all levels work with our non-security partners throughout the business.A life-long hacker, Alyssa has a passion for technology and security. She bought her first computer herself at age 12 and quickly learned techniques for hacking modem communications and software. Her serendipitous career journey began as a software developer which enabled her to pivot into security roles. Beginning as a penetration tester, her last 16 years have seen her grow as a security leader with experience across a variety of organizations. She regularly advocates for improved security practices and shares her research with business leaders and industry audiences through her international public speaking engagements, online content, and other media appearances.Links Referenced: Cybersecurity Career Guide: https://alyssa.link/book A-L-Y-S-S-A dot link—L-I-N-K slash book: https://alyssa.link/book Twitter: https://twitter.com/AlyssaM_InfoSec alyssasec.com: https://alyssasec.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning-fast processing power, courtesy of third-gen AMD EPYC processors without the IO or hardware limitations of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general-purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. Screaming in the Cloud listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G-E-T-V-U-L-T-R dot com slash screaming. My thanks to them for sponsoring this ridiculous podcast.Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate. Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other; which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io/screaminginthecloud. Observability: it's more than just hipster monitoring.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the problems that many folks experience in the course of their career, regardless of what direction they're in, is the curse of high expectations. And there's no escaping for that. Think about CISOs for example, the C-I-S-O, the Chief Information Security Officer.It's generally a C-level role. Well, what's better than a C in the academic world? That's right, a B. My guest today is breaking that mold. Alyssa Miller is the BISO—B-I-S-O—at S&P Global. Alyssa, thank you for joining me to suffer my slings and arrows—Alyssa: [laugh].Corey: —as we go through a conversation that is certain to be no less ridiculous than it has begun to be already.Alyssa: I mean, I'm good with ridiculous, but thanks for having me on. This is awesome. I'm really excited to be here.Corey: Great. What the heck's BISO?Alyssa: [laugh]. I never get that question. So, this is—Corey: “No one's ever asked me that before.” [crosstalk 00:03:38]—Alyssa: Right?Corey: —the same thing as, “Do you know you're really tall?” “No, you're kidding.” Same type of story. But I wasn't clear. That means I'm really the only person left wondering.Alyssa: Exactly. I mean, I wrote a whole blog on it the day I got the job, right? So, Business Information Security Officer, Basically what it means is I am like the CISO but for my division, the Ratings Division at S&P Global. So, I lead our cyber security efforts within that division, work closely with our information security teams, our corporate IT teams, whatever, but I don't report to them; I report into the business line.I'm in the divisional CTO's org structure. And so, I'm the one bridging that gap between that business side where hey, we make all the money and that corporate InfoSec side where hey, we're trying to protect all the things, and there's usually that little bit of a gap where they don't always connect. That's me building the bridge across that.Corey: Someone who speaks both security and business is honestly in a bit of rare supply these days. I mean, when I started my Thursday newsletter podcast nonsense Last Week in AWS: Security, the problem I kept smacking into was everything I saw was on one side of that divide or the other. There was the folks who have the word security in their job title, and there tends to be this hidden language of corporate speak. It's a dialect I don't fully understand. And then you have the community side of actual security practitioners who are doing amazing work, but also have a cultural problem that more or less distills down to being an awful lot of shitheads in them there waters.And I wanted something that was neither of those and also wasn't vendor captured, which is why I decided to start storytelling in that space. But increasingly, I'm seeing that there's a significant problem with people who are able to contextualize security in the context of business. Because if you're secure enough, you can stop all work from ever happening, whereas if you're pure business side and only care about feature velocity and the rest, like, “Well, what happens if we get breached?” It's, “Oh, don't worry, I have my resume up to date.” Not the most reassuring answer to give people. You have to be able to figure out where that line lies. And it seems like that figuring out where that line is, is more or less your entire stock-in-trade.Alyssa: Oh absolutely, yeah. I mean, I can remember my earliest days as a developer, my cynical attitude towards security myself was, you know, their Utopia would be an impenetrable room full of servers that have no connections to anything, right? Like that would be wildly secure, yet completely useless. And so yeah, then I got into security and now I was one of them. And, you know, it's one of those things, you sit in, say a board meeting sometime and you listen to a CISO, a typical CISO talk to the board, and they just don't get it.Like, there's so much, “Hey, we're implementing this technology and we're doing this thing, and here's our vulnerability counts, and here's how many are overdue.” And none of that means anything. I mean, I actually had a board member ask me once, “What is a CISO?” I kid you not. Like, that's where they're at.Like, so don't tell them what you're doing, but tell them why connected back to, like, “Hey, the business needs this and this, and in order to do it, we've got to make sure it's secure, so we're going to implement these couple of things. And here's the roadmap of how we get from where we are right now to where we need to be so they can launch that new service or product,” or whatever the hell it is that they're going to do.Corey: It feels like security is right up there with accounting, in the sense of fields of endeavor where you don't want someone with too much personality involved. Because if the CISO's sitting there talking to the board, it's like, “So, what do you do here, exactly?” And the answer is the honest, “Hey, remember last month how we were in The New York Times for that giant data breach?” And they do a split take, “No, no, I don't.” “Exactly. You're welcome.” On some level, it is kind of honest, but it also does not instill confidence when you're that cavalier with the description of what it is you do here.Alyssa: Oh there's—Corey: At least there's some corners. I prefer—Alyssa: —there's so much—Corey: —places where that goes over well, but that's me.Alyssa: Yeah. But there's so much of that too, right? Like, here's the one I love. “Well, you know, it's not if you get breached, it's when. Oh, by the way, give me millions and millions of dollars, so I can make sure we don't get breached.”But wait, you just told me we're going to get breached no matter what we do. [laugh]. We do that in security. Like, and then you wonder why they don't give you funding for the initiative. Like, “Hello?” You know?And that's the thing that gets me it's like, can we just sit back and understand, like, how do you message to these people? Yeah I mean, you bring up the accounting thing; the funny thing is, at least all of them understand some level of accounting because most of them have MBAs and business degrees where they had to do some accounting. They didn't go through cyber security in their MBA program.So, one of my favorite questions on Twitter once was somebody asked me, you know, if I want to get into cyber security leadership, what is the one thing that I should focus on or what skills should I study? I said, “Go study MBA concepts.” Like, forget all the cyber security stuff. You probably have plenty of that technolog—go understand what they learn in MBA programs. And if you can start to speak that language, that's going to pay dividends for bridging that gap.Corey: So, you don't look like the traditional slovenly computer geek showing up at those meetings who does not know how to sound as if they belong in the room. Like, it's unfair, on some level, and I used to have bitter angst about that. Like, “Why should how I dress matter how people perceive me?” Yeah, in an absolute sense you're absolutely right, however, I can talk about the way the world is or the way I wish it were and there has to be a bit of a divide there.Alyssa: Oh, for sure. Yeah. I mean, you can't deny that you have to be prepared for the audience you're walking into. Now, I work in big conservative financial services on Wall Street. You know, and I had this conversation with a prominent member of our community when I started the job.I'm like, “Boy, I guess I can't really put stickers on my laptop. I'm going to have to get, you know, a protector or something to put stickers on.” Because the last thing I want to do is go into a boardroom with my laptop and whip out a bunch of hacker stickers on the backside of my laptop. Like, in a lot of spaces that will work, but you can't really do that when you're, you know, at, you know, the executive level and you're in a conservative, financial [unintelligible 00:10:16]. It just, I would love to say they should deal with that, I should be able to have pink hair, and you know, face tattoos and everything else, but the reality is, yeah, I can do all that, but these are still human beings who are going to react to that.And it's the same when talking about cyber security, then. Like, I have to understand as a security practitioner that all they know about cyber security is it's big and scary. It's the thing that keeps them up at night. I've had board members tell me exactly that. And so, how do I make it a little less scary, or at least get them to have some confidence in me that I'll, like, carry the shield in front of them and protect them. Like, that's my job. That's why I'm there.Corey: When I was starting my consultancy five years ago, I was trying to make a choice between something in the security cloud direction or the cost cloud direction. And one of the things that absolutely tipped the balance for me was the fact that the AWS bill is very much a business-hours-only problem. No one calls me at two in the morning screaming their head off. Usually. But there's a lot of alignment between those two directions in that you can spend all your time and energy fixing security issues and/or reducing the bill, but past a certain point, knock it off and go do the thing that your company is actually there to do.And you want to be responsible to a point on those things, but you don't want it to be the end-all-be-all because the logical outcome of all of that, if you keep going, is your company runs out of money and dies because you're not going to either cost optimize or security optimize your business to its next milestone. And weighing those things is challenging. Now, too many people hear that and think, “See, I don't have to worry about those things at all.” It's, “Oh, you will sooner or later. I promise.”Alyssa: So, here's the fallacy in that. There is this assumption that everything we do in security is going to hamper the business in some way and so we have to temper that, right? Like, you're not wrong. And we talked about before, right? You know, security in a traditional sense, like, we could do all of the puristic things and end up just, like, screeching the world to a halt.But the reality is, we can do security in a way that actually grows the business, that actually creates revenue, or I should say enables the creation of revenue in that, you know, we can empower the business to do more things and to be more innovative by how we approach security in the organization. And that's the big thing that we miss in security is, like, look, yes, we will always be a quote-unquote, “Cost center,” right? I mean, we in security don't—unless you work for a security organization—we're not getting revenue attributed to us, we're not creating revenue. But we are enabling those people who can if we approach it right.Corey: Well, the Red Team might if they go a little off-script, but that's neither here nor there.Alyssa: I—yeah, I mean, I've had that question. “Like, couldn't we just sell resell our Red Team services?” No. No. That's not our core [crosstalk 00:13:14]Corey: Oh, I was going the other direction. Like, oh, we're just going to start extorting other businesses because we got bored this week. I'm kidding. I'm kidding. Please don't do an investigation, any law enforcement—Alyssa: I was going to say, I think my [crosstalk 00:13:22]—Corey: —folks that happen to be listening to this.Alyssa: [crosstalk 00:13:24] is calling me right now. They're want to know what I'm [laugh] talking about. But no—Corey: They have some inquiries they would like you to assist them with and they're not really asking.Alyssa: Yeah, yeah, they're good at that. No, I love them, though. They're great. [laugh]. But no, seriously, like, I mean, we always think about it that way because—and then we wonder why do we have the reputation of, you know, the Department of No.Well, because we kind of look at it that way ourselves; we don't really look at, like how can we be a part of the answer? Like, when we look at, like, DevSecOps, for instance. Okay, I want to bring security into my pipeline. So, what do we say? “Oh, shared responsibility. That's a DevOps thing.” So, that means security is everybody's responsibility. Full stop.Corey: Right. It's a—Alyssa: Well—Corey: And there, I agree with you wholeheartedly. Cost is—Alyssa: But—Corey: —aligned with this. It has to be easier to do it the right way than to just go off half-baked and do it yourself off the blessed path. And that—Alyssa: So there—Corey: —means there's that you cannot make it harder to do the right thing; you have to make it easier because you will not win against human psychology. Depending on someone when they're done with an experiment to manually go in and turn things off. It will not happen. And my argument has been that security and cost are aligned constantly because the best way to secure something and save money on at the same time is to turn that shit off. You wouldn't think it would be that simple, but yet here we are.Alyssa: But see, here's the thing. This is what kills me. It's so arrogant of security people to look at it and say that right? Because shared responsibility means shared. Okay, that means we have responsibilities we're going to share. Everybody is responsible for security, yes.Our developers have responsibilities now that we have to take a share in as well, which is get that shit to production fast. Period. That is their goal. How fast can I pop user stories off the backlog and get them to deployment? My SRE is on the ops side. They're, like, “We just got to keep that stuff running. That's all we that's our primary focus.”So, the whole point of DevOps and DevSecOps was everybody's responsible for every part of that, so if I'm bringing security into that message, I, as security, have to be responsible for site's stability; I, in security, have to be responsible for efficient deployment and the speed of that pipeline. And that's the part that we miss.Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: I think you might be the first person I've ever spoken to that has that particular take on the shared responsibility model. Normally, when I hear it, it's on stage from an AWS employee doing a 45-minute song-and-dance about what the secured responsibility model is, and generally, that is interpreted as, “If you get breached, it's your fault, not ours.”Alyssa: [laugh].Corey: Now, you can't necessarily say it that directly to someone who has just suffered a security incident, which is why it takes 45 minutes and slides and diagrams and excel sheets and the rest. But that is what it fundamentally distills down to, and then you wind up pointing out security things that they've had that [unintelligible 00:17:11] security researchers have pointed out and they are very tight-lipped about those things. And it's, “Oh, it's not that you're otherworldly good at security; it's that you're great at getting people to shut up.” You know, not me, for whatever reason because I'm noisy and obnoxious, but most people who actually care about not getting fired from their jobs, generally don't want to go out there making big cloud companies look bad. Meanwhile, that's kind of my entire brand.Alyssa: I mean, it's all about lines of liability, right?Corey: Oh yeah.Alyssa: I mean, where am I liable, where am I not? And yeah, well, if I tell you you're responsible for security on all these things, and I can point to any part of that was part of the breach, well, hey, then it's out of my hands. I'm not liable. I did what I said I would; you didn't secure your stuff. Yeah, it's—and I mean, and some of that is to be fair.Like, I mean, okay, I'm going to host my stuff on your computer—the whole cloud is just somebody else's computer model is still ultimately true—but, yeah, I mean, I'm expecting you to provide me a stable and secure environment and then I'm going to deploy stuff on it, and you are expecting me to deploy things that are stable and secure as well. And so, when they say shared model or shared responsibility model, but it—really if you listen to that message, it's the exact opposite. They're telling you why it's a separate responsibility model. Here's our responsibilities; here's yours. Boom. It's not about shared; it's about separated.Corey: One of the most formative, I guess, contributors to my worldview was 13 years ago, I went on a date and met someone lovely. We got married. We've been together ever since, and she's an attorney. And it is been life-changing to understand a lot of that perspective, where it turns out when you're dealing with legal, they are not—and everyone says, “Oh, and the lawyers insisted on these things.”No, they didn't. A lawyer's entire role in a company is to identify risk, and then it is up to the business to make a decision around what is acceptable and what is not. If your lawyers ever insist on something, what that actually means in my experience is, you have said something profoundly ignorant that is one of those, like—that is—they're doing the legal equivalent of slapping the gun out of the toddler's hand of, “No, you cannot go and tweet that because you'll go to prison,” level of ridiculous nonsense where it is, “That will violate the law.” Everything else is different shades of the same answer: it depends. Here's what to consider.Alyssa: Yes.Corey: And then you choose—and the business chooses its own direction. So, when you have companies doing what appeared to be ridiculous things, like Oracle, for example, loves to begin every keynote with a disclaimer about how nothing they're about to say is true, the lawyers didn't insist on that—though they are the world's largest law firm, Kirkland Ellison. But instead, it's this entire story of given the risk and everything that we know about how we say things onstage and people gunning for us, yeah, we are going to [unintelligible 00:20:16] this disclaimer first. Most other tech companies do not do that exact thing, which I've got to say when you're sitting in the audience ready to see the new hotness that's about to get rolled out and it starts with a disclaimer, that is more or less corporate-speak for, “You are about to hear some bullshit,” in my experience.Alyssa: [laugh]. Yes. I mean and that's the thing, like, [clear throat], you know, we do deride legal teams a lot. And you know, I can find you plenty of security people who hate the fact that when you're breached, who's the first call you make? Well, it's your legal team.Why? Because they're the ones who are going to do everything in their power to limit the amount that you can get sued on the back-end for anything that got exposed, that you know, didn't meet service levels, whatever the heck else. And that all starts with legal privilege.Corey: They're reporting responsibilities. Guess who keeps up on what those regulatory requirements are? Spoiler, it's probably not you, whoever's listening to this, unless you're an attorney because that is their entire job.Alyssa: Yes, exactly. And, you know, work in a highly regulated environment—like mine—and you realize just how critical that is. Like, how do I know—I mean, there are times there's this whole discussion of how do you determine if something is a material impact or not? I don't want to be the one making that, and I'm glad I don't have to make that decision. Like, I'll tell you all the information, but yes, you lawyers, you compliance people, I want you to make the decision of if it's a material impact or not because as much as I understand about the business, y'all know way more about that stuff than I do.I can't say. I can only say, “Look, this is what it impacted. This is the data that was impacted. These are the potential exposures that occurred here. Please take that information now and figure out what that means, and is there any materiality to that that now we have to report that to the street.”Corey: Right, right. You can take my guesses on this or you can get it take an attorney's. I am a loud, confident-sounding white guy. Attorneys are regulated professionals who carry malpractice insurance. If they give wrong advice that is wrong enough in these scenarios, they can be sanctioned for it; they can lose their license to practice law.And there are challenges with the legal profession and how much of a gatekeeper the Bar Association is and the rest, but this is what it is [done 00:22:49] for itself. That is a regulated industry where they have continuing education requirements they need to certify in a test that certain things are true when they say it, whereas it turns out that I don't usually get people even following up on a tweet that didn't come true very often. There's a different level of scrutiny, there's a different level of professional bar it raises to, and it turns out that if you're going to be legally held to account for things you say, yeah, turns out a lot of your answers to are going to be flavors of, “It depends.”Alyssa: [laugh].Corey: Imagine that.Alyssa: Don't we do that all the time? I mean, “How critical is this?” “Well, you know, it depends on what kind of data, it depends on who the attacker is. It depends.” Yeah, I mean, that's our favorite word because no one wants to commit to an absolute, and nor should we, I mean, if we're speaking in hyperbole and absolutes, boy, we're doing all the things wrong in cyber.We got to understand, like, hey, there is nuance here. That's how you run—no business runs on absolutes and hyperbole. Well, maybe marketing sometimes, but that's a whole other story.Corey: Depends on if it's done well or terribly.Alyssa: [laugh]. Right. Exactly. “Hey, you can be unhackable. You can be breached-proof.” Oh, God.Corey: Like, what's your market strategy? We're going to paint a big freaking target in the front of the building. Like, I still don't know how Target the company was ever surprised by a data breach that they had when they have a frickin' bullseye as their logo.Alyssa: “Come get us.”Corey: It's, like, talk about poking the bear. But there we are.Alyssa: [unintelligible 00:24:21] no. I mean, hey, [unintelligible 00:24:23] like that was so long ago.Corey: It still casts a shadow.Alyssa: I know.Corey: People point to that as a great example of, like, “Well, what's going to happen if we get breached?” It's like, well look at Target because they wound up—like, their stock price a year later was above where it had been before and it seemed to have no lasting impact. Yeah, but they effectively replaced all of the execs, so you know, let's have some self-interest going on here by named officers of the company. It's, “Yeah, the company will be fine. Would you like to still be here what it is?”Alyssa: And how many lawsuits do you think happened that you never heard about because they got settled before they were filed?Corey: Oh, yes. There's a whole world of that.Alyssa: That's what's really interesting when people talk about, like, the cost of breach and stuff, it's like, we don't even know. We can't know because there is so much of that. I mean, think about it, any organization that gets breached, the first thing they're trying to do is keep as much of it out of the news as they can, and that includes the lawsuits. And so, you know, it's like, all right, well, “Hey, let's settle this before you ever file.”Okay, good. No one will ever know about that. That will never show up anywhere. It is going to show up on a balance sheet anywhere, right? I mean, it's there, but it's buried in big categories of lots of other things, and how are you ever going to track that back without, you know, like, a full-on audit of all of their accounting for that year? Yeah, it's—so I always kind of laugh when people start talking about that and they want to know, what's the average cost of a breach. I'm like, “There's no way to measure that. There is none.”Corey: It's not cheap, and the reputational damage gets annoying. I still give companies grief for these things all the time because it's—again, the breach is often about information of mine that I did not consciously choose to give to you and the, “Oh, I'm going to blame a third-party process.” No, no, you can outsource work, but not responsibility. You can't share that one.Alyssa: Ah, third-party diligence, uh, that seems to be a thing. You know, I think we're supposed to make sure our third parties are trustworthy and doing the right things too, right? I mean, it's—Corey: Best example I ever saw that was an article in the Wall Street Journal about the Pokemon company where they didn't name the vendor, but they said they declined to do business with them in part based upon their lax security policy around S3 buckets. That is the first and so far only time I have had an S3 Bucket Responsibility Award engraved and sent to their security director. Usually, it's the ignoble prize of the S3 Bucket Negligence Award, and there are oh so many of those.Alyssa: Oh, and it's hard, right? Because you're standing—I mean, I'm in that position a lot, right? You know, you're looking at a vendor and you've got the business saying, “God, we want to use this vendor. All their product is great.” And I'm sitting there saying, but, “Oh, my God, look at what they're doing. It's a mess. It's horrible. How do I how do we get around this?”And that's where, you know, you just have to kind of—I wish I could say no more, but at the end of the day, I know what that does. That just—okay, well, we'll go file an exception and we'll use it anyway. So, maybe instead, we sit and work on how to do this, or maybe there is an alternative vendor, but let's sort it out together. So yeah, I mean, I do applaud them. Like that's great to, like, be able to look at a vendor and say, “No, we ain't touching you because what you're doing over there is nuts.” And I think we're learning more and more how important that is, with a lot of the supply chain attacks.Corey: Actually, I'm worried about having emailed you, you're going to leak my email address when your inbox inevitably gets popped. Come on. It's awful stuff.Alyssa: Yeah, exactly. So, I mean, it's we there's—but like everything, it's a balance again, right? Like, how can we keep that business going and also make sure that their vendors—so that's where it just comes down to, like, okay, let's talk contracts now. So, now we're back to legal.Corey: We are. And if you talk to a lawyer and say, “I'm thinking about going to law school,” the answer is always the same. “No… don't do it.” Making it clear that is apparently a terrible life and professional decision, which of course, brings us to your most recent terrible life and professional decision. As we record this, we are reportedly weeks away from you having a physical copy in your hands of a book.And the segue there is because no one wants to write a book. Everyone wants to have written a book, but apparently—unless you start doing dodgy things and ghost-writing and exploiting people in the rest—one is a necessary prerequisite for the other. So, you've written a book. Tell me about it.Alyssa: Oof, well, first of all, spot on. I mean, I think there are people who really do, like, enjoy the act of writing a book—Corey: Oh, I don't have the attention span to write a tweet. People say, “Oh, you should write a book, Corey,” which I think is code for them saying, “You should shut up and go away for 18 months.” Like, yeah, I wish.Alyssa: Writing a book has been the most eye-opening experience of my life. And yeah, I'm not a hundred percent sure it's one I'll ever—I've joked with people already, like, I'll probably—if I ever want another book, I'll probably hire a ghostwriter. But no, I do have a book coming out: Cybersecurity Career Guide. You know, I looked at this cyber skills gap, blah, blah, blah, blah, blah, we hear about it, 4 million jobs are going to be left open.Whatever, great. Well, then how come none of these college grads can get hired? Why is there this glut of people who are trying to start careers in cyber security and we can't get them in?Corey: We don't have six months to train you, so we're going to spend nine months trying to fill the role with someone experienced?Alyssa: Exactly. So, 2020 I did a bunch of research into that because I'm like, I got to figure this out. Like, this is bizarre. How is this disconnect happening? I did some surveys. I did some interviews. I did some open-source research. Ended up doing a TED Talk based off of that—or TEDx Talk based off of that—and ultimately that led into this book. And so yeah, I mean, I just heard from the publisher yesterday, in fact that we're, like, in that last stage before they kick it out to the printers, and then it's like three weeks and I should have physical copies in my hands.Corey: I will be getting one when it finally comes out. I have an almost, I believe, perfect track record of having bought every book that a guest on this show has written.Alyssa: Well, I appreciate that.Corey: Although, God help me if I ever have someone, like, “So, what have you done?” “I've written 80 books.” Like, “Well, thank you, Stephen King. I'm about to go to have a big—you're going to see this number of the company revenue from orbit at this point with that many.” But yeah, it's impressive having written a book. It's—Alyssa: I mean, for me, it's the reward is already because there are a lot of people have—so my publisher does really cool thing they call it early acc—or electronic access program, and where there are people who bought the book almost a year ago now—which is kind of, I feel bad about that, but that's as much my publisher as it is me—but where they bought it a year ago and they've been able to read the draft copy of the book as I've been finishing the book. And I'm already hearing from them, like, you know, I'm hearing from people who really found some value from it and who, you know, have been recommending it other people who are trying to start careers and whatever. And it's like, that's where the reward is, right?Like, it was, it's hell writing a book. It was ten times worse during Covid. You know, my publisher even confirmed that for me that, like, look, yeah, you know, authors around the globe are having problems right now because this is not a good environment conducive to writing. But, yeah, I mean, it's rewarding to know that, like, all right, there's going to be this thing out there, that, you know, these pages that I wrote that are helping people get started in their careers, that are helping bring to light some of the real challenges of how we hire in cyber security and in tech in general. And so, that's the thing that's going to make it worthwhile. And so yeah, I'm super excited that it's looking like we're mere weeks now from this thing being shipped to people who have bought it.Corey: So, now it's racing, whether this gets published before the book does. So, we'll see. There is a bit of a production lag here because, you know, we have to make me look pretty and that takes a tremendous amount of effort.Alyssa: Oh, stop. Come on now. But it will be interesting to see. Like, that would actually be really cool if they came out at about the same time. Like, you know, I'm just saying.Corey: Yeah. We'll see how it goes. Where's the best place for people to find you if they want to learn more?Alyssa: About the book or in general?Corey: Both.Alyssa: So—Corey: Links will of course be in the [show notes 00:32:49]. Let's not kid ourselves here.Alyssa: The book is real easy. Go to Alyssa—A-L-Y-S-S-A, back here behind me for those of you seeing the video. Um—I can't point the right direction. There we go. That one. A-L-Y-S-S-A dot link—L-I-N-K slash book. It's that simple. It'll take you right to Manning's site, you can get in.Still in that early access program, so if you bought it today, you would still be able to start reading the draft versions of it. If you want to know more about me, honestly, the easiest way is to find me on Twitter. You can hear all the ridiculousness of flight school and barbecue and some security topics, too, once in a while. But at @alyssam_infosec. Or if you want to check out the website where I blog, every rare occasion, it's alyssasec.com.Corey: And all of that will be in the [show notes 00:33:41]. Thank you—Alyssa: There's a lot. [laugh].Corey: I'm looking forward to seeing it, too. Thank you so much for taking the time to deal with my nonsense today. I really appreciate it.Alyssa: Oh, that was nonsense? Are you kidding me? This was a great discussion. I really appreciate it.Corey: As have I. Thanks again for your time. It is always great to talk to people smarter than I am—which is, let's be clear, most people—Alyssa Miller, BISO at S&P Global. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice—or smash the like and subscribe button if this is on the YouTubes—whereas if you've hated the podcast, same thing, five-star review, platform of choice, smash both of the buttons, but also leave an angry comment, either on the YouTube video or on the podcast platform, saying that this was a waste of your time and what you didn't like about it because you don't need to read Alyssa's book; you're going to get a job the tried and true way, by printing out a copy of your resume and leaving it on the hiring manager's pillow in their home.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

In this Hasty Treat, Scott and Wes talk about ways to prevent malicious people from using or abusing your app. Linode - Sponsor Whether you're working on a personal project or managing enterprise infrastructure, you deserve simple, affordable, and accessible cloud computing solutions that allow you to take your project to the next level. Simplify your cloud infrastructure with Linode's Linux virtual machines and develop, deploy, and scale your modern applications faster and easier. Get started on Linode today with a $100 in free credit for listeners of Syntax. You can find all the details at linode.com/syntax. Linode has 11 global data centers and provides 24/7/365 human support with no tiers or hand-offs regardless of your plan size. In addition to shared and dedicated compute instances, you can use your $100 in credit on S3-compatible object storage, Managed Kubernetes, and more. Visit linode.com/syntax and click on the “Create Free Account” button to get started. Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Show Notes 00:26 Welcome 01:04 Sponsor: Linode 02:06 Sponsor: Sentry 02:59 What kind of bad things can happen to your application? 06:24 How do you stop bad actors? 12:20 Nonce tokens 14:10 CSRF CSRF Explained 14:50 Captcha hCaptcha 17:06 DDOS Cloudlfare DDOS 17:38 Ban known bad ASNS Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

'Roland, the rules say that we can't play if we don't have nine players! And I can't stomach the thought of Patrick's team winning by default. The man looks like a thumb!'In our latest episode, Carla starts out by discussing a 90210 podcast, Paul gets derailed thinking about The Naked Gun, but neither of us get too distracted as we kinda just want to sing the praises of this episode. Put on your 'tap shoes', knock on that fake door, and join us for our discussion of the 9th episode of season 5, The M.V.P.!Consider supporting the show on PatreonFollow and interact with us on FacebookFollow us on InstagramTop 10 Rankings so far:Carla1. S2, Ep. 1: Finding David2. S1, Ep. 1: Our Cup Runneth Over3. S2, Ep. 13: Happy Anniversary4. S4, Ep. 6: Open Mic5. S3, Ep. 13: Grad Night6. S1, Ep. 13: Town For Sale7. S4, Ep. 9: The Olive Branch8. S4, Ep 12: Singles Week9. S5, Ep. 9: The M.V.P.10. S1, Ep. 6: Wine And RosesPaul1. S1, Ep. 1: Our Cup Runneth Over2. S2, Ep 13: Happy Anniversary3. S2, Ep. 1: Finding David4. S3, Ep. 12: Friends & Family5. S3, Ep. 13: Grad Night6. S4, Ep. 13: Merry Christmas, Johnny Rose7. S5, Ep. 9: The M.V.P.8. S1, Ep. 9: Carl's Funeral9. S1, Ep. 13: Town For Sale10. S5, Ep. 8: The Hospies

Episode 353: We decided that we wanted to start looking at the sequel shows more in-depth than how we usually do on Seasonal reviews or first impressions. This week we talk about Komi Cant Communicate S2, Tiger and Bunny 2, Demon Girl Next Door S2, Shield Hero S2, Kaguya-sama S3, and Ascendance of a Bookworm S3 --- Send in a voice message: https://anchor.fm/anime-summit/message

It's Jubilee Weekend in the UK - and Dale's pondering what you need to do for your country to get recognised. We talk about our big green gas news - and why so many people seem to be in love with heat pumps.  We also discover that tobacco isn't just bad for people - it's bad for the planet too. We answer your questions too, as Dale breaks out his stereo to play God Save The Queen.

S3. Episode 9 - You Talk Too Much by Millennial Mayhem

We're coming in for a landing after a wild ride with 'Top Gun: Maverick,' plus Bruce has three words to describe the first few episodes of 'The Boys' S3 ("...dirty, dirty, dirty!"), David Cronenberg returns to form this weekend with his old school brand of body horror, and we end things with a chat between Bruce and Craig Pearce & Thomas Brodie-Sangster the writer and star (respectively) of 'Pistol' on Hulu. They also talk about the new 'Elvis' movie coming out in a few weeks that Pearce wrote the screenplay for, connecting some of the dots between the king of rock and roll and Johnny Rotten's snot-nosed crew. More from Bruce Miller: 'Top Gun: Maverick' sets a course for big-screen blockbusters How did the Sex Pistols rattle society? Miniseries 'Pistol' explains Pandemic stalls third season of Bill Hader's 'Barry,' but it's still surprising Where to watch: Top Gun (official site) Crimes of the Future (official site) The Bob's Burgers Movie (official site) Obi-Wan Kenobi (Disney+; May 27) Pistol (Hulu; May 31) The Boys Season 3 (Amazon) Floor is Lava (Netflix) Links to other fun stuff we talked about in this episode: Star Wars: The Rebellion Will Be Televised Follow the show: Twitter: https://twitter.com/StreamdNScreend Instagram:https://www.instagram.com/streamedandscreened Facebook: https://www.facebook.com/StreamedAndScreened Streamed & Screened is a podcast about movies and TV hosted by Bruce Miller, an entertainment reporter for multiple decades who is now the editor of the Sioux City Journal, Jared McNett, a reporter for the Sioux City Journal, and Chris Lay, the podcast operations manager for Lee Enterprises. See omnystudio.com/listener for privacy information.

How do you deal with a trigger that's years - maybe even decades - old? Ann Hince shared how a moment thinking “I was this fearful mother and they told me I had done something wrong..." led to an onslaught of emotions regarding her childhood. In this episode - we're inviting you to play with freeing your emotions ❤️ Lean in to listen to Ann's story about how she found emotional freedom.Get ready to:

In this episode of Syntax, Wes and Scott talk all about how they use Git inside of VS Code, extensions they use, and the various ways to interact with Git in VS Code. Linode - Sponsor Whether you're working on a personal project or managing enterprise infrastructure, you deserve simple, affordable, and accessible cloud computing solutions that allow you to take your project to the next level. Simplify your cloud infrastructure with Linode's Linux virtual machines and develop, deploy, and scale your modern applications faster and easier. Get started on Linode today with a $100 in free credit for listeners of Syntax. You can find all the details at linode.com/syntax. Linode has 11 global data centers and provides 24/7/365 human support with no tiers or hand-offs regardless of your plan size. In addition to shared and dedicated compute instances, you can use your $100 in credit on S3-compatible object storage, Managed Kubernetes, and more. Visit linode.com/syntax and click on the “Create Free Account” button to get started. SPONSOR - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. SPONSOR - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax Show Notes 00:21 Recording Syntax in Riverside Riverside 01:22 Welcome 04:57 CLI vs VS Code VS Code 07:27 Git Jargon 11:50 UI tools we've used Git Tower Git Kraken GitHub for Desktop iTerm Warp Git SCM 14:09 Ways to interact with Git in VS Code 19:41 Source control tab 26:28 Sponsor: Linode 27:47 File History 30:29 Diffing or Compare 36:24 Conflict resolution 42:56 Automation with post-commit commands 46:10 Sponsor: LogRocket 47:14 Extensions GitLens Git History Git Graph Conventional Commits 53:59 Git config tip 55:24 Sponsor: Freshbooks 56:02 ××× SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Scott: Espanso Wes: AirPod cleaning kit Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

S3, E14: The Brewers suffered a number of major injuries including Brandon Woodruff and Freddy Peralta on the pitching staff, along with Renfroe in the offense. The Brewers may or may not have enough depth to cover for this, so we discuss whether or not we think they will. Ethan Small debuted on Monday, the top pitching prospect in the organization. Will he make an immediate impact on the club? Finally, the Brewers keep bringing up arms that seemingly come out of nowhere so we get you up to speed on these players. Peter Strzelecki, Luke Barker, Jason Alexander, Trevor Kelley, and others. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/bleedingblueandyellow/message Support this podcast: https://anchor.fm/bleedingblueandyellow/support

Au programme de ce 73ème épisode de Netflixers, le podcast francophone dédié à Netflix et à la SVOD en général : 00:02:20 : Actus du secteur SVOD français et mondial. On revient sur les nouvelles conséquences du mois horrible de Netflix, de nouveaux tests en préparation, des infos venant de Disney+, le lancement de Gaumont Classique mais aussi les renouvellements, annulations et renouvannulations du mois chez Netflix ainsi que notre sélection des meilleurs projets annoncés chez Netflix. 00:43:30 : Nos recommandations de mai : On y parle de En route pour l'avenir, Un accord parfait, "F*ck l'amour, toujours !", A.X.L., Two Distant Strangers, Senior Year, "Moi, apprivoisée ?", Toujours plus beau, Notre père à tous, Qui a tué Sara ? (S3), Heartstopper (S1), Bienvenidos a Edén (s1), Insiders (S1), The Circle US (S4), le Stranger Things Festival Chip 'n Dale: Rescue Rangers, Sneakerella, Stranger Things S4 P1, Better Call Saul, Love death and robots S3, Tu ne tueras point, The Wilds S2, Obi Wan, Le Flambeau, "Yakamoz S-245", "Saturday Morning All Star Hits", "Grace & Frankie" (S7)... 02:06:00 : Les ajouts Netflix Originals du mois de juin 2022. Notre sélection des ajouts Netflix Originals du mois de juin 2022. Vous pouvez retrouver la liste complète mise à jour dans cet article : https://medium.com/@filmsdelover/tous-les-ajouts-netflix-originals-de-2022-sur-netflix-france-61ab1a1c4996 Pour vous les Netflixos : Le devoir du mois prochain choisi par Tom23 du Discord est "Le haut du panier" qui sera dispo le 8 juin. N'hésitez pas à nous donner votre avis dessus en nous mentionnant sur Twitter @filmsdelover, ou sur le Discord de l'émission dont l'adresse est ci-dessous. Nous avons un Discord avec toutes les dernières infos sur Netflix, des conversations, des débats sur Netflix mais aussi sur les autres services SVOD dispos en France : https://discord.gg/N4Vmd5n (Merci Kris_Mery de l'administrer et de l'avoir créé et merci à tous ceux qui le font vivre chaque jour avec des infos, des recos etc.) Si vous avez envie de vous abonner ou de consulter la newsletter "Netflix & Chiffres", c'est ici que ça se passe : https://netflixandchiffres.substack.com/ Intermèdes audio :"Resident Evil" S1, dispo en juillet / "En route vers l'avenir", déjà dispo / "Money Heist : Korea" dispo fin juin. Intervenants : Hélène (https://www.twitter.com/nivrae) Damien (https://www.twitter.com/Damien_SRSLY) Présenté par Frédéric (https://www.twitter.com/filmsdelover).

Ben Johnson explains his project Litestream.io, an OpenSource tool that replicates SQLite databases to remote servers and to backup locations like S3 for durability. We talk about how moving data out to the user creates true edge applications. We discuss what types of problems this helps solve, the architectures that become possible, and how a globally distributed Phoenix application could use this. He shares how Fly.io acquired the project and brought him on full-time to continue his work on it. Fascinating discussion that challenges many of the assumptions about how we've been building “web” systems for years. Show Notes online - http://podcast.thinkingelixir.com/101 (http://podcast.thinkingelixir.com/101) Elixir Community News - https://www.erlang.org/blog/my-otp-25-highlights/ (https://www.erlang.org/blog/my-otp-25-highlights/) – OTP 25 was officially released - https://www.erlang.org/eeps/eep-0049 (https://www.erlang.org/eeps/eep-0049) – EEP document discussing the “maybe” expression - https://www.erlang.org/doc/reference_manual/expressions.html#maybe (https://www.erlang.org/doc/reference_manual/expressions.html#maybe) – Official docs for “maybe” feature - https://www.erlang.org/blog/faster-rand/ (https://www.erlang.org/blog/faster-rand/) – A new fast Pseudo Random Generator - https://jobs.ericsson.com/job/Stockholm-Open-SourceErlang-Developer-Stoc/746811902/ (https://jobs.ericsson.com/job/Stockholm-Open-SourceErlang-Developer-Stoc/746811902/) – Ericsson, the company behind Erlang, is hiring for an OpenSource developer to join the Erlang team. - https://www.bbc.com/news/business-61562651 (https://www.bbc.com/news/business-61562651) – Klarna layoffs - https://hexdocs.pm/elixir/main/PartitionSupervisor.html (https://hexdocs.pm/elixir/main/PartitionSupervisor.html) – PartitionManager feature coming in Elixir v1.14 has docs online so you can learn about it early. - https://twitter.com/DNAutics/status/1528434291872505856 (https://twitter.com/DNAutics/status/1528434291872505856) – Isaac Yonemoto made the JavaScript engine in Zig accessible through Zigler and therefore Elixir - https://podcast.thinkingelixir.com/98 (https://podcast.thinkingelixir.com/98) – Follow-up from episode 98 with Dominic Letz about writing an Elixir application that runs on mobile devices and can be installed from the iOS AppStore. - https://ionicframework.com/ (https://ionicframework.com/) - https://twitter.com/ElixirConf/status/1526654041626923008 (https://twitter.com/ElixirConf/status/1526654041626923008) – ElixirConf 2022 in Colorado - CFP is open - https://2022.elixirconf.com/speaker-cfp (https://2022.elixirconf.com/speaker-cfp) – Where to submit your talk proposal - https://www.elixirconf.eu/ (https://www.elixirconf.eu/) – ElixirConf EU in London on June 9-10 - https://elixirconf.com/events (https://elixirconf.com/events) – ElixirConf US in Colorado on August 30-Sep2 Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources - https://litestream.io/ (https://litestream.io/) - https://fly.io/blog/all-in-on-sqlite-litestream/ (https://fly.io/blog/all-in-on-sqlite-litestream/) - https://github.com/benbjohnson/litestream (https://github.com/benbjohnson/litestream) – Project on Github - https://sqlite.org/index.html (https://sqlite.org/index.html) - https://sqlite.org/whentouse.html (https://sqlite.org/whentouse.html) – SQLite guide on "when to use" it - https://github.com/elixir-sqlite/ecto_sqlite3 (https://github.com/elixir-sqlite/ecto_sqlite3) - https://github.com/boltdb/bolt (https://github.com/boltdb/bolt) - https://en.wikipedia.org/wiki/Write-ahead_logging (https://en.wikipedia.org/wiki/Write-ahead_logging) - https://raft.github.io/ (https://raft.github.io/) - https://en.wikipedia.org/wiki/Conflict-freereplicateddata_type (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) - https://litestream.io/tips/ (https://litestream.io/tips/) – Page covers tips - https://www.kernel.org/doc/html/latest/filesystems/fuse.html (https://www.kernel.org/doc/html/latest/filesystems/fuse.html) – Understanding what a FUSE filesystem is Guest Information - https://twitter.com/benbjohnson (https://twitter.com/benbjohnson) – on Twitter - https://github.com/benbjohnson/ (https://github.com/benbjohnson/) – on Github - https://github.com/benbjohnson/litestream (https://github.com/benbjohnson/litestream) – Project on Github Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - Cade Ward - @cadebward (https://twitter.com/cadebward)

About RafalRafal is Serverless Engineer at Stedi by day, and Dynobase founder by night - a modern DynamoDB UI client. When he is not coding or answering support tickets, he loves climbing and tasting whiskey (not simultaneously).Links Referenced:Company Website: https://dynobase.dev TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: The company 0x4447 builds products to increase standardization and security in AWS organizations. They do this with automated pipelines that use well-structured projects to create secure, easy-to-maintain and fail-tolerant solutions, one of which is their VPN product built on top of the popular OpenVPN project which has no license restrictions; you are only limited by the network card in the instance. To learn more visit: snark.cloud/deployandgoCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. It's not too often that I wind up building an episode here out of a desktop application. I've done it once or twice, and I'm sure that the folks at Microsoft Excel are continually hoping for an invite to talk about things. But we're going in a bit of a different direction today. Rafal Wilinski is a serverless engineer at Stedi and, in apparently what is the job requirement at Stedi, he also has a side project that manifests itself as a desktop app. Rafal, thank you for joining me today. I appreciate it.Rafal: Yeah. Hi, everyone. Thanks for having me, Corey.Corey: I first heard about you when you launched Dynobase, which is awesome. It sounds evocative of dinosaurs unless you read it, then it's D-Y-N-O, and it's, “Ah, this sounds a lot like DynamoDB. Let me see what it is.” And sure enough, it was. As much as I love misusing things as databases, DynamoDB is actually a database that is decent and good at what it does.And please correct me if I get any of this wrong, but Dynobase is effectively an Electron app that you install, at least on a Mac, in my case; I don't generally use other desktops, that's other people's problems. And it provides a user-friendly interface to DynamoDB that is not actively hostile to the customer.Rafal: Yeah, exactly. That was the goal. That's how I envisioned it, and I hope I executed correctly.Corey: It was almost prescient in some ways because they recently redid the DynamoDB console in AWS to actively make it worse, to wind up working with individual items, to modify things. It feels like they are validating your market for you by, “Oh, we really like Dynobase. How do we drive more traffic to it? We're going to make this thing worse.” But back then when you first created this, the console was his previous version. What was it that inspired you to say, “You know what I'm going to build? A desktop application for a cloud service.” Because on the surface, it seems relatively close to psychotic, but it's brilliant.Rafal: [laugh]. Yeah, sure. So, a few years ago, I was freelancing on AWS. I was jumping between clients and my side projects. That also involved jumping between regions, and AWS doesn't have a good out-of-the-box solution for switching your accounts and switching your regions, so when you want it to work on your client table in Australia and simultaneously on my side project in Europe, there was no other solution than to have two browser windows open or to, even, browsers open.And it was super frustrating. So, I was like, hey, “DynamoDB has SDK. Electron is this thing that allows you to make a desktop application using HTML and JS and some CSS, so maybe I can do something with it.” And I was so naive to think that it's going to be a trivial task because it's going to be—come on, it's like, a couple of SDK calls, displaying some lists and tables, and that's pretty much it, right?Corey: Right. I use Retool as my system to build my newsletter every week, and that is the front-end I use to interact with DynamoDB. And it's great. It has a table component that just—I run a query that, believe it or not, is a query, not a scan—I know, imagine that, I did something slightly right this one time—and it populates things for the current issue into it, and then I basically built a CRUD API around it and have components that let me update, delete, remove, the usual stuff. And it's great, it works for my purposes, and it's fine.And that's what I use most of the time until I, you know, hit an edge case or a corner case—because it turns out, surprise everyone, I'm bad at programming—and I need to go in and tweak the table myself manually. And that's where Dynobase, at least for my use case, really comes into its own.Rafal: Good to hear. Good to hear. Yeah, that was exactly same case why I built it because yeah, I was also, a few years ago, I started working on some project which was really crazy. It was before AppSync times. We wanted to have GraphQL serverless API using single table design and testing principles [unintelligible 00:04:38] there.So, we've been verifying many things by just looking at the contents of the table, and sometimes fixing them manually. So, that was also the thing that motivated me to make the editing experience a little bit better.Corey: One thing I appreciate about the application is that it does things right. I mean, there's no real other way to frame that. When I fire up the application myself and I go to the account that I've been using it with—because in this case, there's really only one account that I have that contains the data that I spent that my time working with—and I get access to it on my machine via Granted, which because it's a federated SSO login. And it says, “Ah, this is an SSL account. Click here to open the browser tab and do the thing.”I didn't have to configure Dynobase. It is automatically reading my AWS config file in my user directory. It does a lot of things right. There's no duplication of work. From my perspective. It doesn't freak out because it doesn't know how SSO works. It doesn't have run into these obnoxious edge case problems that so many early generation desktop interfaces for AWS things seem to.Rafal: Wow, it seems like it works for you even better than for me. [laugh].Corey: Oh, well again, how I get into accounts has always been a little weird. I've ranted before about Granted, which is something that Common Fate puts out. It is a binary utility that winds up logging into different federated SSO accounts, opens them in Firefox containers so you could have you know, two accounts open, side-by-side. It's some nice affordances like that. But it still uses the standard AWS profile syntax which Dynobase does as well.There are a bunch of different ways I've logged into things, and I've never experienced friction [unintelligible 00:06:23] using Dynobase for this. To be clear, you haven't paid me a dime. In fact, just the opposite. I wind up paying my monthly Dynobase subscription with a smile on my face. It is worth every penny, just because on those rare moments when I have to work with something odd in DynamoDB, it's great having the tool.I want to be very clear here. I don't recall what the current cost on this is, but I know for a fact it is more than I spend every month on DynamoDB itself, which is fine. You pay for utility, not for the actual raw cost of the underlying resources on it. Some people tend to have issues with that and I think it's the wrong direction to go in.Rafal: Yeah, exactly. So, my logic was that it's a productivity improvement. And a lot of programmers are simply obsessed with productivity, right? We tend to write those obnoxious nasty Bash and Python scripts to automate boring tasks in our day jobs. So, if you can eliminate this chore of logging to different AWS accounts and trying to find them, and even if it takes, like, five or ten seconds, if I can shave that five or ten seconds every time you try to do something, that over time accumulates into a big number and it's a huge time investment. So, even if you save, like, I don't know, maybe one hour a month or one hour a quarter, I think it's still a fair price.Corey: Your pricing is very interesting, and the reason I say that is you do not have a free tier as such, you have a free seven-day trial, which is great. That is the way to do it. You can sign up with no credit card, grab the thing, and it's awesome. Dynobase.dev for folks who are wondering.And you have a solo yearly plan, which is what I'm on, which is $9 a month. Which means that you end up, I think, charging me $108 a year billed annually. You have a solo lifetime option for 200 bucks—and I'm going to fight with you about that one in a second; we're going to come back to it—then you have a team plan that is for I think for ten licenses at 79 bucks a month, and for 20 licenses it's 150 bucks a month. Great. And then you have an enterprise option for 250 a month, the end. Billed annually. And I have problems with that, too.So, I like arguing with pricing, I [unintelligible 00:08:43] about pricing with people just because I find that is one of those underappreciated aspects of things. Let's start with my own decisions on this, if I may. The reason that I go for the solo yearly plan instead of a lifetime subscription of I buy this and I get to use it forever in perpetuity. I like the tool but, like, the AWS service that underlies it, it's going to have to evolve in the fullness of time. It is going to have to continue to support new DynamoDB functionality, like the fact that they have infrequent access storage classes now, for tables, as an example. I'm sure they're coming up with other things as well, like, I don't know, maybe a sane query syntax someday. That might be nice if they ever built one of those.Some people don't like the idea of a subscription software. I do just because I like the fact that it is a continual source of revenue. It's not the, “Well, five years ago, you paid me that one-off thing and now you expect feature enhancements for the rest of time.” How do you think about that?Rafal: So, there are a couple of things here. First thing is that the lifetime support, it doesn't mean that I will be always implementing to my death all the features that are going to appear in DynamoDB. Maybe there is going to be a some feature and I'm not going to implement it. For instance, it's not possible to create the global tables via Dynobase right now, and it won't be possible because we think that majority of people dealing with cloud are using infrastructure as a code, and creating tables via Dynobase is not a super useful feature. And we also believe that it's not going to break even without support. [laugh]. I know it sounds bad; it sounds like I'm not going to support it at some point, but don't worry, there are no plans to discontinue support [crosstalk 00:10:28]—Corey: We all get hit by buses from time to time, let's be clear.Rafal: [laugh].Corey: And I want to also point out as well that this is a graphical tool that is a front-end for an underlying AWS service. It is extremely convenient, there is tremendous value in it, but it is not critical path as if suddenly I cannot use Dynobase, my production app is down. It doesn't work that way, in the sense—Rafal: Yes.Corey: Of a SaaS product. It is a desktop application. And huge fan of that as well. So, please continue.Rafal: Yeah, exactly—Corey: I just want to make sure that I'm not misleading people into thinking it's something it's not here. It's, “Oh, that sounds dangerous if that's critical pa”—yeah, it's not designed to be. I imagine, at least. If so it seems like a very strange use case.Rafal: Yeah. Also, you have to keep in mind that AWS isn't basically introducing breaking changes, especially in a service that is so popular as DynamoDB. I cannot imagine them, like, announcing, like, “Hey, in a month, we are going to deprecate this API, so you'd better start, you know, using this new API because this one is going to be removed.” I think that's not going to happen because of the millions of clients using DynamoDB actively. So, I think that makes Dynobase safe. It's built on a rock-solid foundation that is going to change only additively. No features are going to be just being removed.Corey: I think that there's a direction in a number of at least consumer offerings where people are upset at the idea of software subscriptions, the idea of why should I pay in perpetuity for a thing? And I want to call out my own bias here. For something like this, where you're charging $9 a month, I do not care about the price, truly I don't. I am a price inflexible customer. It could go and probably as high as 50 bucks a month and I would neither notice nor care.That is probably not the common case customer, and it's certainly not over in consumer-land. I understand that I am significantly in a privileged position when it comes to being able to acquire the tools that I need. It turns out compared to the AWS bill I have to deal with, I don't have to worry about the small stuff, comparatively. Not everyone is in that position, so I am very sympathetic to that. Which is why I want to deviate here a little bit because somewhat recently, Dynobase showed up on the AWS Marketplace.And I can go into the Marketplace now and get a yearly subscription for a single seat for $129. It is slightly more than buying it directly through your website, but there are some advantages for many folks in getting it on the Marketplace. AWS is an approved vendor, for example, so there's no procurement dance. It counts toward your committed spend on contracts if someone is trying to wind up hitting certain levels of spend on their EDP. It provides a centralized place to manage things, as far as those licenses go when people are purchasing it. What was it that made you decide to put this on the Marketplace?Rafal: So, this decision was pretty straightforward. It's just, you know, yet another distribution channel for us. So, imagine you're a software engineer that works for a really, really big company and it's super hard to approve some kind of expense using traditional credit card. You basically cannot go to my site and check out with a company credit card because of the processes, or maybe it takes two years. But maybe it's super easy to click this subscribe on your AWS account. So yeah, we thought that, hey, maybe it's going to unlock some engineers working at those big corporations, and maybe this is the way that they are going to start using Dynobase.Corey: Are you seeing significant adoption yet? Or is it more or less a—it's something that's still too early to say? And beyond that, are you finding that people are discovering the product via the AWS Marketplace, or is it strictly just a means of purchasing it?Rafal: So, when it comes to discovering, I think we don't have any data about it yet, which is supported by the fact that we also have zero subscriptions from the Marketplace yet. But it's also our fault because we haven't actually actively promoted the fact, apart from me sending just a tweet on Twitter, which is in [crosstalk 00:14:51]—Corey: Which did not include a link to it as well, which means that Google was our friend for this because let's face it, AWS Marketplace search is bad.Rafal: Well, maybe. I didn't know. [laugh]. I was just, you know, super relieved to see—Corey: No, I—you don't need to agree with that statement. I'm stating it as a fact. I am not a fan of Marketplace search. It irks me because for whatever reason whenever I'm in there looking for something, it does not show me the things I'm looking for, it shows me the biggest partners first that AWS has and it seems like the incentives are misaligned. I'm sure someone is going to come on the show to yell about me. I'm waiting for your call.Rafal: [laugh].Corey: Do you find that if someone is going to purchase it, do you have a preference that they go directly, that they go through the Marketplace? Is there any direction for you that makes more sense than another?Rafal: So ideally, would like to continue all the customers to purchase the software using the classical way, using the subscriptions for our website because it's just one flow, one system, it's simpler, it's cleaner, but we want it to give that option and to have more adoption. We'll see if that's going to work.Corey: I was going to say there were two issues I had with the pricing. That was one of them. The other is at the high end, the enterprise pricing being $250 a month for unlimited licenses, that doesn't feel like it is the right direction, and the reason I say that is a 50-person company would wind up being able to spend 250 bucks a month to get this for their entire team, and that's great and they're happy. So, could AWS or Coca-Cola, and at that very high level, it becomes something that you are signing up for significant amount of support work, in theory, or a bunch of other directions.I've always found that from where I stand, especially dealing with those very large companies with very specific SLA requirements and the rest, the pricing for enterprise that I always look for as the right answer for my mind is ‘click here to contact us.' Because procurement departments, for example, we want this, this, this, this, and this around data guarantees and indemnities and all the rest. And well, yeah, that's going to be expensive. And well, yeah. We're a procurement company at a Fortune 50. We don't sign contracts that don't have two commas in them.So, it feels like there's a dialing it in with some custom optionality that feels like it is signaling to the quote-unquote, ‘sophisticated buyer,' as patio11 likes to say on Twitter from time to time, that might be the right direction.Rafal: That's really good feedback. I haven't thought about it this way, but you really opened my eyes on this issue.Corey: I'm glad it was helpful. The reason I think about it this way is that more and more I'm realizing that pricing is one of the most key parts of marketing and messaging around something, and that is not really well understood, even by larger companies with significant staff and full marketing teams. I still see the pricing often feels like an afterthought, but personally, when I'm trying to figure out is this tool for me, the first thing I do is—I don't even read the marketing copy of the landing page; I look for the pricing tab and click because if the only prices ‘call for details,' I know, A, it's going to be expensive, be it's going to be a pain in the neck to get to use it because it's two in the morning; I'm trying to get something done. I want to use it right now. If I had to have a conversation with your sales team first, that's not going to be cheap and it's not going to be something I'm going to be able to solve my problem this week. And that is the other end of it. I yell at people on both sides on that one.Rafal: Okay.Corey: Again, none of this stuff is intuitive; all of this stuff is complicated, and the way that I tend to see the world is, granted, a little bit different than the way that most folks who are kicking around databases and whatnots tend to view the world. Do you have plans in the future to extend Dynobase beyond strictly DynamoDB, looking to explore other fine database options like Redis, or MongoDB, or my personal favorite Route 53 TXT records?Rafal: [laugh]. Yeah. So, we had plans. Oh, we had really big plans. We felt that we are going to create a second JetBrains company. We started analyzing the market when it comes to MongoDB, when it comes to Cassandra, when it comes to Redis. And our first pick was Cassandra because it seemed, like, to have really, really similar structure of the table.I mean, it's also no secret it also has a primary index, secondary global indexes, and things like that. But as always, reality surprises us over the amount of detail that we cannot see from the very top. And it isn't as simple as just an install AWS SDK and install Cassandra Connector on—or Cassandra SDK and just roll with that. It requires a really big and significant investment. And we decided to focus just on one thing and nail this one thing and do this properly.It's like, if you go into the cloud, you can try to build a service that is agnostic, it's not using the best features of the cloud. And you can move your containers, for instance, across the clouds and say, “Hey, I'm cloud-agnostic,” but at the same time, you're missing out all the best features. And this is the same way we thought about Dynabase. Hey, we can provide an agnostic core, but then the agnostic application isn't going to be as good and as sophisticated as something tailored specifically for the needs of this database and user using this exact database.Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on premises, private cloud, and they just announced a fully managed service on AWS and Azure called BigAnimal, all one word.Don't leave managing your database to your cloud vendor because they're too busy launching another half dozen manage databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications, including Oracle, to the cloud.To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: Some of the things that you do just make so much sense that I get actively annoyed that there aren't better ways to do it and other places for other things. For example, when I fire up a table in a particular region within Dynobase, first it does a scan, which, okay, that's not terrible. But on some big tables, that can get really expensive. But you cap it automatically to a thousand items. And okay, great.Then it tells me, how long did it take? In this case because, you know, I am using on-demand and the rest and it's a little bit of a pokey table, that scan took about a second-and-a-half. Okay. You scanned a thousand items. Well, there's a lot more than a thousand items in this table. Ah, you limited it, so you didn't wind up taking all that time.It also says that it took 51-and-a-half RCUs—or Read Credit Units—because you know, why use normal numbers when you're AWS and doing pricing dimensions on this stuff.Rafal: [laugh].Corey: And to be clear, I forget the exact numbers for reads, but it's something like a million read RCUs cost me a dollar or something like that. It is trivial; it does not matter, but because it is consumption-based pricing, I always live in a little bit of a concern that, okay, if I screw up and just, like, scan the entire 10-megabyte table every time I want to make an operation here, and I make a lot of operations in the course of a week, that's going to start showing up in the bill in some really unfortunate ways. This sort of tells me as an ongoing basis of what it is that I'm going to wind up encountering.And these things are all configurable, too. The initial stream limit that you have configured as a thousand. I can set that to any number I want if I think that's too many or too few. You have a bunch of pagination options around it. And you also help people build out intelligent queries, [unintelligible 00:22:11] can export that to code. It's not just about the graphical interface clickety and done—because I do love my ClickOps but there are limits to it—it helps formulate what kind of queries I want to build and then wind up implementing in code. And that is no small thing.Rafal: Yeah, exactly. This is how we also envision that. The language syntax in DynamoDB is really… hard.Corey: Awful. The term is awful.Rafal: [laugh]. Yeah, especially for people—Corey: I know, people are going to be mad at me, but they're wrong. It is not intuitive, it took a fair bit of wrapping my head around. And more than once, what I found myself doing is basically just writing a thin CRUD API in Lambda in front of it just so I can query it in a way that I think about it as opposed to—now I'm not even talking changing the query modeling; I just want better syntax. That's all it is.Rafal: Yeah. You also touch on modeling; that's also very important thing, especially—or maybe even scan or query. Suppose I'm an engineer with tens years of experience. I come to the DynamoDB, I jump straight into the action without reading any of the documentation—at least that's my way of working—and I have no idea what's the difference between a scan and query. So, in Dynobase, when I'm going to enter all those filtering parameters into the UI, I'm going to hit scan, Dynobase is automatically going to figure out for you what's the best way to query—or to scan if query is not possible—and also give you the code that actually was behind that operation so you can just, like, copy and paste that straight to your code or service or API and have exactly the same result.So yeah, we want to abstract away some of the weird things about DynamoDB. Like, you know, scan versus query, expression attribute names, expression attribute values, filter, filtering conditions, all sorts of that stuff. Also the DynamoDB JSON, that's also, like, a bizarre thing. This JSON-type thing we should get out of the box, we also take care of that. So, yeah. Yeah, that's also our mission to make the DynamoDB as approachable as possible. Because it's a great database, but to truly embrace it and to truly use it, it's hard.Corey: I want to be clear, just for folks who are not seeing some of the benefits of it the way that I've described it thus far. Yes, on some level, it basically just provides a attractive, usable interface to wind up looking at items in a DynamoDB table. You can also use it to wind up refining queries to look at very specific things. You can export either a selection or an entire table either to a local file—or to S3, which is convenient—but it goes beyond on that because once you have the query dialed in and you're seeing the things you want to see, there's a generate code button that spits it out in—for Python, for JavaScript, for Golang.And there are a few things that the AWS CLI is coming soon, according to the drop-down itself. Java; ooh, you do like pain. And Golang for example, it effectively exports the thing you have done by clicking around as code, which is, for some godforsaken reason, anathema to most AWS services. “Oh, you clicked around to the console to do a thing. Good job. Now, throw it all away and figure out how to do it in code.” As opposed to, “Here's how to do what you just did programmatically.” My God, the console could be the best IDE in the world, except that they don't do it for some reason.Rafal: Yeah, yeah.Corey: And I love the fact that Dynobase does.Rafal: Thank you.Corey: I'm a big fan of this. You can also import data from a variety of formats, export data, as well. And one of the more obnoxious—you talk about weird problems I have with DynamoDB that I wish to fix: I would love to move this table to a table in a different AWS account. Great, to do that, I effectively have to pause the service that is in front of this because I need to stop all writes—great—export the table, take the table to the new account, import the table, repoint the code to talk to that thing, and then get started again. Now, there are ways to do it without that, and they all suck because you have to either write a shim for it or you have to wind up doing a stream that winds up feeding from one to the other.And in many cases, well okay, I want to take the table here, I do a knife-edge cutover so that new rights go to the new thing, and then I just want to backfill this old table data into it. How do I do that? The official answer is not what you would expect it to be, the DynamoDB console of ‘import this data.' Instead, it's, “Oh, use AWS Glue to wind up writing an ETL function to do all of this.” And it's… what? How is that the way to do these things?There are import and export buttons in Dynobase that solve this problem beautifully without having to do all of that. It really is such a different approach to thinking about this, and I am stunned that this had to be done as a third party. It feels like you were using the native tooling and the native console the same way the rest of us do, grousing about it the same way the rest of us do, and then set out to fix it like none of us do. What was it that finally made you say, “You know, I think there's a better way and I'm going to prove it.” What pushed you over the edge?Rafal: Oh, I think I was spending, just, hours in the console, and I didn't have a really sophisticated suite of tests, which forced me [unintelligible 00:27:43] time to look at the data a lot and import data a lot and edit it a lot. And it was just too much. I don't know, at some point I realized, like, hey, there's got to be a better way. I browsed for the solutions on the internet; I realized that there is nothing on the market, so I asked a couple of my friends saying like, “Hey, do you also have this problem? Is this also a problem for you? Do you see the same challenges?”And basically, every engineer I talked to said, “Yeah. I mean, this really sucks. You should do something about it.” And that was the moment I realized that I'm really onto something and this is a pain that I'm not alone. And so… yeah, that gave me a lot of motivation. So, there was a lot of frustration, but there was also a lot of motivation to push me to create a first product in my life.Corey: It's your first product, but it does follow an interesting pattern that seems to be emerging, Cloudash—Tomasz and Maciej—wound up doing that as well. They're also working at Stedi and they have their side project which is an Electron-based desktop application that winds up, we're interfacing with AWS services. And it's. What are your job requirements over at Stedi, exactly?People could be forgiven for seeing these things and not knowing what the hell EDI is—which guilty—and figure, “Ah, it's just a very fancy term for a DevRels company because they're doing serverless DevRel as a company.” It increasingly feels an awful lot like that.j, what's going on over there where that culture just seems to be an emergent property?Rafal: So, I feel like Stedi just attracts a lot of people that like challenges and the people that have a really strong sense of ownership and like to just create things. And this is also how it feels inside. There is plenty of individuals that basically have tons of energy and motivation to solve so many problems not only in Stedi, but as you can see also outside of Stedi, which is a result—Cloudash is a result, the mapping tool from Zack Charles is also a result, and Michael Barr created a scheduling service. So, yeah, I think the principles that we have at Stedi basically attract top-notch builders.Corey: It certainly seems so. I'm going to have to do a little more digging and see what some of those projects are because they're new to me. I really want to thank you for taking so much time to speak with me about what you're building. If people want to learn more or try to kick the tires on Dynobase which I heartily recommend, where should they go?Rafal: Go to dynobase.dev, and there's a big download button that you cannot miss. You download the software, you start it. No email, no credit card required. You just run it. It scans your credentials, profiles, SSOs, whatever, and you can play with it. And that's pretty much it.Corey: Excellent. And we will put a link to that in the [show notes 00:30:48]. Thank you so much for your time. I really appreciate it.Rafal: Yeah. Thanks for having me.Corey: Rafal Wilinski, serverless engineer at Stedi and creator of Dynobase. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice—or a thumbs up and like and subscribe buttons on the YouTubes if that's where you're watching it—whereas if you've hated this podcast, same thing—five-star review, hit the buttons and such—but also leave an angry, bitter comment that you're not going to be able to find once you write it because no one knows how to put it into DynamoDB by hand.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

This week Superhero Slate is recapping Star Wars Celebration 2022 announcements, the Thor trailer flicks too hard, Netflix kicks off their Geeked week soon, and more! What We're Doing: Elden Ring, Fortnite S2 ending & S3 leaks, Stranger Things 3 and 4 News Thor: Love and Thunder (15:35) Thor: Love and Thunder Trailer Jane Foster, […]

It's here! The trailer for S3 dropped today. New episodes will begin airing on June 13th; that's just two weeks away! While you're listening on Apple Podcasts or Spotify, rate and review the show! It helps us reach even more people that need to hear the voices of those working to promote peace and equity in their networks. Interested in learning more about PeacePlayers mission to build a more peaceful and equitable world? Visit our website https://peaceplayers.org/playitforwardpodcast/ and check out our social handles. Twitter: @peaceplayers Instagram: @peaceplayersintl and @playitforwardpodcast Facebook: @peaceplayersintl LinkedIn: PeacePlayers International YouTube: PeacePlayers The Play It Forward podcast is produced by: Chinny Nwagbo Emmett Shepard Leif Frymire The Play It Forward podcast audio engineering and editing LeBaron Leath Animation and music created and designed by LeBaron Leath Podcast Cover Art by: Adam Hawkins Marketing by: Gabriella Mora Leif Frymire

Old-time Radio Essentials continues its 3rd season with an episode of the Lux Radio Theatre – their adaptation of the Western film "Red River", starring John Wayne! This one's Pete's pick, and there's action a-plenty in the selection, followed by fast-paced discussion of its merits by the three co-hosts. Will Pete and Paul have a Walter Brennan voice-off, reluctantly judged by Dave? Tune in and find out!! And since we're on the subject of finding things out, while you listen you'll learn if we feel this entry meets the following criteria: 1. Is it truly representative of that series? (Can anyone point to it and say, "Yes, that is what [NAME OF SERIES] was all about.") 2. Is it an episode worthy of inclusion in any and every OTR aficionado's private collection? So with this in mind, we three bring you, as our thirty-second number (but 7th official episode of S3), this episode of Lux Radio Theatre, from 3/3/49. We'll introduce the show, play it in its entirety, then discuss it at length. Thanks for joining us, and we hope you enjoy it!  Please show your support of the podcast by doing any of the following! To comment on how we might improve OTR-E, or give suggestions for future discussions, please write to us at f6point3@gmail.com . Put the word "Essentials" in the subject line. Your feedback means a lot to us! A review at iTunes or at your usual podcatcher would be appreciated. Next Time: Dave's pick, and all he'll tell us is that it's in the Sci-Fi genre!

'I mean, we did spend all that money flying in Barbra Streisand's vocal coach that summer Alexis wanted to be the next Jessica Simpson.'In our latest episode, Paul wonders if a garbage bag full of clothes is considered a carry-on, Carla isn't sure where Darlene ends and her cousin begins, and we're both delighted that Ronnie puts Patrick in his place. Dig a floral dress out of the laundry, put Hampton's Hoes on repeat, and join us for our discussion of the 8th episode of season 5, The Hospies!Consider supporting the show on PatreonFollow and interact with us on FacebookFollow us on InstagramTop 10 Rankings so far:Carla1. S2, Ep. 1: Finding David2. S1, Ep. 1: Our Cup Runneth Over3. S2, Ep. 13: Happy Anniversary4. S4, Ep. 6: Open Mic5. S3, Ep. 13: Grad Night6. S1, Ep. 13: Town For Sale7. S4, Ep. 9: The Olive Branch8. S1, Ep. 6: Wine And Roses9. S1, Ep. 2: The Drip10. S2, Ep. 2: Family DinnerPaul1. S1, Ep. 1: Our Cup Runneth Over2. S2, Ep 13: Happy Anniversary3. S2, Ep. 1: Finding David4. S3, Ep. 12: Friends & Family5. S3, Ep. 13: Grad Night6. S4, Ep. 13: Merry Christmas, Johnny Rose7. S1, Ep. 9: Carl's Funeral8. S1, Ep. 13: Town For Sale9. S5, Ep. 8: The Hospies10. S4, Ep 6: Open Mic

Big week for Dale and Ecotricity - there's a new gas field in Britain, Dale explains more about why the grass under our feet is the answer to all of our heating related questions. Why haven't government embraced it - and is this really something that could go mainstream?  Our friends in Australia could be turning a corner when it comes to the climate. There's a few of your questions too. 

Chi Chi's first friend in Tokyo arrives out of the neon circuits of Harajuku and Shinjuku and Kabukicho, Tokyo, to fuse together three pieces of film concerning beautiful white foreign women in Japan: LOST IN TRANSLATION, HBO GIRLS and THE RAMEN GIRL. The vision they piece together is a lonely trial of the soul, video game texture mexaplexes, cat cafes, a creation of the self via exposure to the exterior, Pocari Sweat, reckless collage of stereotype, atomic bombs and -- I DON'T UNDERSTAND! WHY AM I HERE?! Follow I'M SO POPULAR on Twitter: twitter.com/imsopopularpod And listen to the exclusive bonus show SIRENS only on Patreon, this week discussing how to perform in drag, phone games, Johnny Depp, racism and more: https://www.patreon.com/posts/66879644 (S3.E02 異境にいる美人たち)

“This is a human thing...Resilient, strong, badass people can also struggle with suicidality." And in this episode - we're inviting you to play with normalizing conversations around mental health and wellness when some part of you is so triggered it affects You as a whole ❤️  Lean in to listen to Nina's story about how suicidality crept in during her divorce - and how she got her whole Self back.Get ready to:

S3. Episode 8 - Are You A Square Or What? by Millennial Mayhem

About SimonFounder and CEO of SnapShooter a backup company Links Referenced: SnapShooter.com: https://SnapShooter.com MrSimonBennett: https://twitter.com/MrSimonBennett 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: Finding skilled DevOps engineers is a pain in the neck! And if you need to deploy a secure and compliant application to AWS, forgettaboutit! But that's where DuploCloud can help. Their comprehensive no-code/low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks, while automating the full DevSecOps lifestyle. Get started with DevOps-as-a-Service from DuploCloud so that your cloud configurations are done right the first time. Tell them I sent you and your first two months are free. To learn more visit: snark.cloud/duplo. Thats's snark.cloud/D-U-P-L-O-C-L-O-U-D.Corey: What if there were a single place to get an inventory of what you're running in the cloud that wasn't "the monthly bill?" Further, what if there were a way to compare that inventory to what you were already managing via Terraform, Pulumi, or CloudFormation, but then automatically add the missing unmanaged or drifted parts to it? And what if there were a policy engine to immediately flag and remediate a wide variety of misconfigurations? Well, stop dreaming and start doing; visit snark.cloud/firefly to learn more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the things that I learned early on in my career as a grumpy Unix systems administrator is that there are two kinds of people out there: those who care about backups an awful lot, and people who haven't lost data yet. I lost a bunch of data once upon a time and then I too fell on the side of backups are super important. Here to talk with me about them a bit today is Simon Bennett, founder and CEO of SnapShooter.com. Simon, thanks for joining me.Simon: Thanks for having me. Thank you very much.Corey: It's fun to be able to talk to people who are doing business in the cloud space—in this sense too—that is not venture-backed, that is not, “Well, we have 600 people here that are building this thing out.” And similar to the way that I handle things at The Duckbill Group, you are effectively one of those legacy things known as a profitable business that self-funds. What made you decide to pursue that model as opposed to, well, whatever the polite version of bilking venture capitalists out of enormous piles of money for [unintelligible 00:01:32]?Simon: I think I always liked the idea of being self-sufficient and running a business, so I always wanted to start a physical business when I was younger, but when I got into software, I realized that that's a really easy way, no capital needed, to get started. And I tried for years and years to build products, all of which failed until finally SnapShooter actually gained a customer. [laugh].Corey: “Oh, wait, someone finally is paying money for this, I guess I'm onto something.”Simon: Yeah.Corey: And it's sort of progressed from there. How long have you been in business?Simon: We started in 2017, as… it was an internal project for a company I was working at who had problems with DigitalOcean backups, or they had problems with their servers getting compromised. So, I looked at DigitalOcean API and realized I could build something. And it took less than a week to build a product [with billing 00:02:20]. And I put that online and people started using it. So, that was how it worked.Every other product I tried before, I'd spent months and months developing it and never getting a customer. And the one time I spent less than [laugh] less than a week's worth of evenings, someone started paying. I mean, admittedly, the first person was only paying a couple of dollars a month, but it was something.Corey: There's a huge turning point where you just validate the ability and willingness for someone to transfer one dollar from their bank account to yours. It speaks to validation in a way that social media nonsense generally doesn't. It's the oh, someone is actually willing to pay because I'm adding value to what they do. That's no small thing.Simon: Yeah. There's definitely a big difference between people saying they're going to and they'd love it, and actually doing it. So.Corey: I first heard about you when Patrick McKenzie—or @patio11, as he goes by on Twitter—wound up doing a mini-thread on you about, “I've now used SnapShooter.com for real, and it was such a joy, including making a server migration easier than it would otherwise have been. Now, I have automatically monitored backups to my own S3 account for a bunch of things, which already had a fairly remote risk of failure.” And he keeps talking about the awesome aspects of it. And okay, when Patrick says, “This is neat,” that usually means it's time for me to at least click the link and see what's going on.And the thing that jumped out at me was a few things about what it is that you offer. You talk about making sure that people can sleep well at night, that it's about why backups are important, about—you obviously check the boxes and talk about how you do things and why you do them the way that you do, but it resonates around the idea of helping people sleep well at night. Because no one wants to think about backups. Because no one cares about backups; they just care an awful lot about restores, usually right after they should have cared about the backups.Simon: Yeah. This is actually a big problem with getting customers because I don't think it's on a lot of people's minds, getting backups set up until, as you said in the intro, something's gone wrong. [laugh]. And then they're happy to be a customer for life.Corey: I started clicking around and looking at your testimonials, for example, on your website. And the first one I saw was from the CEO of Transistor.fm. For those who aren't familiar with what they do, they are the company that hosts this podcast. I pay them as a vendor for all the back issues and whatnot.Whenever you download the show. It's routing through their stuff. So yeah, I kind of want them to have backups of these things because I really don't want to have all these conversations [laugh] again with everyone. That's an important thing. But Transistor's business is not making sure that the data is safe and secure; it's making podcasts available, making it easy to publish to them.And in your case, you're handling the backup portion of it so they can pay their money and they set it up effectively once—set it and forget it—and then they can go back to doing the thing that they do, and not having to fuss with it constantly. I think a lot of companies get it wrong, where they seem to think that people are going to make sustained, engaged efforts in whatever platform or tool or service they build. People have bigger fish to fry; they just want the thing to work and not take up brain sweat.Simon: Yeah. Customers hardly ever log in. I think it's probably a good sign when they don't have to log in. So, they get their report emails, and that's that. And they obviously come back when they got new stuff to set up, but from a support point of view is pretty, pretty easy, really, people don't—[laugh] constantly on there.Corey: From where I sit, the large cloud providers—and some of the small ones, too—they all have backup functionality built into the offering that they've got. And some are great, some are terrible. I assume—perhaps naively—that all of them do what it says on the tin and actually back up the data. If that were sufficient, you wouldn't have any customers. You clearly have customers. What is it that makes those things not work super well?Simon: Some of them are inflexible. So, some of the providers have built-in server backups that only happen weekly, and six days of no backups can be a big problem when you've made a mistake. So, we offer a lot of flexibility around how often you backup your data. And then another key part is that we let you store your data where you want. A lot of the providers have either vendor lock-in, or they only store it in themselves. So… we let you take your data from one side of the globe to the other if you want.Corey: As anyone who has listened to the show is aware, I'm not a huge advocate for multi-cloud for a variety of excellent reasons. And I mean that on a per-workload basis, not, “Oh, we're going to go with one company called Amazon,” and you use everything that they do, including their WorkMail product. Yeah, even Amazon doesn't use WorkMail; they use Exchange like a real company would. And great, pick the thing that works best for you, but backups have always been one of those areas.I know that AWS has great region separation—most of the time. I know that it is unheard of for there to be a catastrophic data loss story that transcends multiple regions, so the story from their side is very often, oh, just back it up to a different region. Problem solved. Ignoring the data transfer aspect of that from a pricing perspective, okay. But there's also a risk element here where everyone talks about the single point of failure with the AWS account that it's there, people don't talk about as much: it's your payment instrument; if they suspend your account, you're not getting into any region.There's also the story of if someone gets access to your account, how do you back that up? If you're going to be doing backups, from my perspective, that is the perfect use case, to put it on a different provider. Because if I'm backing up from, I don't know, Amazon to Google Cloud or vice versa, I have a hard time envisioning a scenario in which both of those companies simultaneously have lost my data and I still care about computers. It is very hard for me to imagine that kind of failure mode, it's way out of scope for any disaster recovery or business continuity plan that I'm coming up with.Simon: Yeah, that's right. Yeah, I haven't—[laugh] I don't have that in my disaster recovery plan, to be honest about going to a different cloud, as in, we'll solve that problem when it happens. But the data is, as you say, in two different places, or more. But yeah, the security one is a key one because, you know, there's quite a lot of surface area on your AWS account for compromising, but if you're using either—even a separate AWS account or a different provider purely for storage, that can be very tightly controlled.Corey: I also appreciate the idea that when you're backing stuff up between different providers, the idea of owning both sides of it—I know you offer a solution where you wind up hosting the data as well, and that has its value, don't get me wrong, but there are also times, particularly for regulated industries, where yeah, I kind of don't want my backup data just hanging out with someone else's account with whatever they choose to do with it. There's also the verification question, which again, I'm not accusing you of in any way, shape, or form of being nefarious, but it's also one of those when I have to report to a board of directors of like, “Are you sure that they're doing what they say they're doing?” It's a, “Well, he seemed trustworthy,” is not the greatest answer. And the boards ask questions like that all the time. Netflix has talked about this where they backup a rehydrate-the-business level of data to Google Cloud from AWS, not because they think Amazon is going to disappear off the face of the earth, but because it's easier to do that and explain it than having to say, “Well, it's extremely unlikely and here's why,” and not get torn to pieces by auditors, shareholders, et cetera. It's the path of least resistance, and there is some validity to it.Simon: Yeah, when you see those big companies who've been with ransomware attacks and they've had to either pay the ransom or they've literally got to build the business from scratch, like, the cost associated with that is almost business-ending. So, just one backup for their data, off-site [laugh] they could have saved themselves millions and millions of pounds. So.Corey: It's one of those things where an ounce of prevention is worth a pound of cure. And we're still seeing that stuff continue to evolve and continue to exist out in the ecosystem. There's a whole host of things that I think about like, “Ooh, if I lost, that would be annoying but not disastrous.” When I was going through some contractual stuff when we were first setting up The Duckbill Group and talking to clients about this, they would periodically ask questions about, “Well, what's your DR policy for these things?” It's, “Well, we have a number of employees; no more than two are located in the same city anywhere, and we all work from laptops because it is the 21st century, so if someone's internet goes out, they'll go to a coffee shop. If everyone's internet goes out, do you really care about the AWS bill that month?”It's a very different use case and [unintelligible 00:11:02] with these things. Now, let's be clear, we are a consultancy that fixes AWS bills; we're not a hospital. There's a big difference in the use case and what is acceptable in different ways. But what I like is that you have really build something out that lets people choose their own adventure in how managed they want it to be, what the source is, what the target should be. And it gives people enough control but without having to worry about the finicky parts of aligning a bunch of scripts that wind up firing off in cron jobs.Simon: Yeah. I'd say a fair few people run into issues running scripts or, you know, they silently fail and then you realize you haven't actually been running backups for the last six months until you're trying to pull them, even if you were trying to—Corey: Bold of you to think that I would notice it that quickly.Simon: [laugh]. Yeah, right. True. Yeah, that's presuming you have a disaster recovery plan that you actually test. Lots of small businesses have never even heard of that as a thing. So, having as us, kind of, manage backups sort of enables us to very easily tell people that backups of, like—we couldn't take the backup. Like, you need to address this.Also, to your previous point about the control, you can decide completely where data flows between. So, when people ask us about what's GDPR policies around data and stuff, we can say, “Well, we don't actually handle your data in that sense. It goes directly from your source through almost a proxy that you control to your storage.” So.Corey: The best answer: GDPR is out of scope. Please come again. And [laugh] yeah, just pass that off to someone else.Simon: In a way, you've already approved those two: you've approved the person that you're managing servers with and you've already approved the people that are doing storage with. You kind of… you do need to approve us, but we're not handling the data. So, we're handling your data, like your actual customer; we're not handling your customer's customer's data.Corey: Oh, yeah. Now, it's a valuable thing. One of my famous personal backup issues was okay, “I'm going to back this up onto the shared drive,” and I sort of might have screwed up the backup script—in the better way, given the two possible directions this can go—but it was backing up all of its data and all the existing backup data, so you know, exponential growth of your backups. Now, my storage vendor was about to buy a boat and name it after me when I caught that. “Oh, yeah, let's go ahead and fix that.”But this stuff is finicky, it's annoying, and in most cases, it fails in silent ways that only show up as a giant bill in one form or another. And not having to think about that is valuable. I'm willing to spend a few hours setting up a backup strategy and the rest; I'm not willing to tend it on an ongoing basis, just because I have other things I care about and things I need to get done.Simon: Yeah. It's such a kind of simple and trivial thing that can quickly become a nightmare [laugh] when you've made a mistake. So, not doing it yourself is a good [laugh] solution.Corey: So, it wouldn't have been a @patio11 recommendation to look at what you do without having some insight into the rest of the nuts and bolts of the business and the rest. Your plans are interesting. You have a free tier of course, which is a single daily backup job and half a gig of storage—or bring your own to that it's unlimited storage—Simon: Yep. Yeah.Corey: Unlimited: the only limits are your budget. Yeah. Zombo.com got it slightly wrong. It's not your mind, it's your budget. And then it goes from Light to Startup to Business to Agency at the high end.A question I have for you is at the high end, what I've found has been sort of the SaaS approach. The top end is always been a ‘Contact Us' form where it's the enterprise scope of folks where they tend to have procurement departments looking at this, and they're going to have a whole bunch of custom contract stuff, but they're also not used to signing checks with fewer than two commas in them. So, it's the signaling and the messaging of, “Reach out and talk to us.” Have you experimented with that at all, yet? Is it something you haven't gotten to yet or do you not have interest in serving that particular market segment?Simon: I'd say we've been gearing the business from starting off very small with one solution to, you know, last—and two years ago, we added the ability to store data from one provider to a different provider. So, we're sort of stair-stepping our way up to enterprise. For example, at the end of last year, we went and got certificates for ISO 27001 and… one other one, I can't remember the name of them, and we're probably going to get SOC 2 at some point this year. And then yes, we will be pushing more towards enterprises. We add, like, APIs as well so people can set up backups on the fly, or so they can put it as part of their provisioning.That's hopefully where I'm seeing the business go, as in we'll become under-the-hood backup provider for, like, a managed hosting solution or something where their customers won't even realize it's us, but we're taking the backups away from—responsibility away from businesses.Corey: For those listeners who are fortunate enough to not have to have spent as long as I have in the woods of corporate governance, the correct answer to, “Well, how do we know that vendor is doing what they say that they're doing,” because the, “Well, he seemed like a nice guy,” is not going to carry water, well, here are the certifications that they have attested to. Here's copies under NDA, if their audit reports that call out what controls they claim to have and it validates that they are in fact doing what they say that they're doing. That is corporate-speak that attests that you're doing the right things. Now, you're going to, in most cases, find yourself spending all your time doing work for no real money if you start making those things available to every customer spending 50 cents a year with you. So generally, the, “Oh, we're going to go through the compliance, get you the reports,” is one of the higher, more expensive tiers where you must spend at least this much for us to start engaging down this rabbit hole of various nonsense.And I don't blame you in the least for not going down that path. One of these years, I'm going to wind up going through at least one of those certification approaches myself, but historically, we don't handle anything except your billing data, and here's how we do it has so far been sufficient for our contractual needs. But the world's evolving; sophistication of enterprise buyers is at varying places and at some point, it'll just be easier to go down that path.Simon: Yeah, to be honest, we haven't had many, many of those customers. Sometimes we have people who come in well over the plan limits, and that's where we do a custom plan for them, but we've not had too many requests for certification. But obviously, we have the certification now, so if anyone ever [laugh] did want to see it under NDA, we could add some commas to any price. [laugh].Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on premises, private cloud, and they just announced a fully managed service on AWS and Azure called BigAnimal, all one word.Don't leave managing your database to your cloud vendor because they're too busy launching another half dozen manage databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications, including Oracle, to the cloud.To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: What I like as well is that you offer backups for a bunch of different things. You can do snapshots from, effectively, every provider. I'm sorry, I'm just going to call out because I love this: AWS and Amazon LightSail are called out as two distinct things. And Amazonians will say, “Oh, well, under the hood, they're really the same thing, et cetera.” Yeah, the user experience is wildly different, so yeah, calling those things out as separate things make sense.But it goes beyond that because it's not just, “Well, I took a disk image. There we go. Come again.” You also offer backup recipes for specific things where you could, for example, back things up to a local file and external storage where someone is. Great, you also backup WordPress and MongoDB and MySQL and a whole bunch of other things.A unified cloud controller, which is something I have in my house, and I keep thinking I should find a way to back that up. Yeah, this is great. It's not just about the big server thing; it's about having data living in managed services. It's about making sure that the application data is backed up in a reasonable, responsible way. I really liked that approach. Was that an evolution or is that something you wound up focusing on almost from the beginning?Simon: It was an evolution. So, we started with the snapshots, which got the business quite far to be honest and it was very simple. It was just DigitalOcean to start with, actually, for the first two years. Pretty easy to market in a way because it's just focused on one thing. Then the other solutions came in, like the other providers and, you know, once you add one, it was easy to add many.And then came database backups and file backups. And I just had those two solutions because that was what people were asking for. Like, they wanted to make sure their whole server snapshot, if you have a whole server snapshot, the point in time data for MySQL could be corrupt. Like, there could be stuff in RAM that a MySQL dump would have pulled out, for example. Like… there's a possibility that the database could be corrupt from a snapshot, so people were asking for a bit of, more, peace of mind with doing proper backups of MySQL.So, that's what we added. And it soon became apparent when more customers were asking for more solutions that we really needed to, like, step back and think about what we're actually offering. So, we rebuilt this whole, kind of like, database engine, then that allowed us to consume data from anywhere. So, we can easily add more backup types. So, the reason you can see all the ones you've listed there is because that's kind of what people have been asking for. And every time someone comes up with a new, [laugh], like, a new open-source project or database or whatever, we'll add support, even ones I've never heard of before. When people ask for some weird file—Corey: All it takes is just waiting for someone to reach out and say, hey, can you back this thing up, please?Simon: Yeah, exactly, some weird file-based database system that I've never ever heard of. Yeah, sure. Just give us [laugh] a test server to mess around with and we'll build, essentially, like, we use bash in the background for doing the backups; if you can stream the data from a command, we can then deal with the whole management process. So, that's the reason why. And then, I was seeing in, like, the Laravel space, for example, people were doing MySQL backups and they'd have a script, and then for whatever reason, someone rotated the passwords on the database and the backup script… was forgotten about.So, there it is, not working for months. So, we thought we could build a backup where you could just point it at where the Laravel project is. We can get all the config we need at the runtime because it's all there with the project anyway, and then thus, you never need to tell us the password for your database and that problem goes away. And it's the same with WordPress.Corey: I'm looking at this now just as you go through this, and I'm a big believer in disclaiming my biases, conflicts of interest, et cetera. And until this point, neither of us have traded a penny in either direction between us that I'm ever aware of—maybe you bought a t-shirt or something once upon a time—but great, I'm about to become a customer of this because I already have backup solutions for a lot of the things that you currently support, but again, when you're a grumpy admin who's lost data in the past, it's, “Huh, you know what I would really like? That's right, another backup.” And if that costs me a few hundred bucks a year for the peace of mind is money well spent because the failure mode is I get to rewrite a whole lot of blog posts and re-record all podcasts and pay for a whole bunch of custom development again. And it's just not something that I particularly want to have to deal with. There's something to be said for a holistic backup solution. I wish that more people thought about these things.Simon: Can you imagine having to pull all the blog posts off [unintelligible 00:22:19]? [laugh]—Corey: Oh, my got—Simon: —to try and rebuild it.Corey: That is called the crappiest summer internship someone has ever had.Simon: Yeah.Corey: And that is just painful. I can't quite fathom having to do that as a strategy. Every once in a while some big site will have a data loss incident or go out of business or something, and there's a frantic archiving endeavor that happens where people are trying to copy the content out of the Google Search Engine's cache before it expires at whatever timeline that is. And that looks like the worst possible situation for any sort of giant backup.Simon: At least that's one you can fix. I mean, if you were to lose all the payment information, then you've got to restitch all that together, or anything else. Like, that's a fixable solution, but a lot of these other ones, if you lose the data, yeah, there's no two ways around it, you're screwed. So.Corey: Yeah, it's a challenging thing. And it's also—the question also becomes one of, “Well, hang on. I know about backups on this because I have this data, but it's used to working in an AWS environment. What possible good would it do me sitting somewhere else?” It's, yeah, the point is, it's sitting somewhere else, at least in my experience. You can copy it back to that sort of environment.I'm not suggesting this is a way that you can run your AWS serverless environment on DigitalOcean, but it's a matter of if everything turns against you, you can rebuild from those backups. That's the approach that I've usually taken. Do you find that your customers understand that going in or is there an education process?Simon: I'd say people come for all sorts of reasons for why they want backup. So, having your data in two places for that is one of the reasons but, you know, I think there's a lot of reasons why people want peace of mind: for either developer mistakes or migration mistakes or hacking, all these things. So, I guess the big one we come up with a lot is people talking about databases and they don't need backups because they've got replication. And trying to explain that replication between two databases isn't the same as a backup. Like, you make a mistake you drop—[laugh] you run your delete query wrong on the first database, it's gone, replicated or not.Corey: Right, the odds of me fat-fingering an S3 bucket command are incredibly likelier than the odds of AWS losing an entire region's S3 data irretrievably. I make mistakes a lot more than they tend to architecturally, but let's also be clear, they're one of the best. My impression has always been the big three mostly do a decent job of this. The jury's still out, in my opinion, on other third-party clouds that are not, I guess, tier one. What's your take?Simon: I have to be careful. I've got quite good relationships with some of these. [laugh].Corey: Oh, of course. Of course. Of course.Simon: But yes, I would say most customers do end up using S3 as their storage option, and I think that is because it is, I think, the best. Like, is in terms of reliability and performance, some storage can be a little slow at times for pulling data in, which could or could not be a problem depending on what your use case is. But there are some trade-offs. Obviously, S3, if you're trying to get your data back out, is expensive. If you were to look at Backblaze, for example, as well, that's considerably cheaper than S3, especially, like, when you're talking in the petabyte-scale, there can be huge savings there. So… they all sort of bring their own thing to the table. Personally, I store the backups in S3 and in Backblaze, and in one other provider. [laugh].Corey: Oh, yeah. Like—Simon: I like to have them spread.Corey: Like, every once in a while in the industry, there's something that happens that's sort of a watershed moment where it reminds everyone, “Oh, right. That's why we do backups.” I think the most recent one—and again, love to them; this stuff is never fun—was when that OVH data center burned down. And OVH is a somewhat more traditional hosting provider, in some respects. Like, their pricing is great, but they wind up giving you what amounts to here as a server in a rack. You get to build all this stuff yourself.And that backup story is one of those. Oh, okay. Well, I just got two of them and I'll copy backups to each other. Yeah, but they're in the same building and that building just burned down. Now, what? And a lot of people learned a very painful lesson. And oh, right, that's why we have to do that.Simon: Yeah. The other big lesson from that was that even if the people with data in a different region—like, they'd had cross-regional backups—because of the demand at the time for accessing backups, if you wanted to get your data quickly, you're in a queue because so many other people were in the same boat as you're trying to restore stored backups. So, being off-site with a different provider would have made that a little easier. [laugh].Corey: It's a herd of elephants problem. You test your DR strategy on a scheduled basis; great, you're the only person doing it—give or take—at that time, as opposed to a large provider has lost a region and everyone is hitting their backup service simultaneously. It generally isn't built for that type of scale and provisioning. One other question I have for you is when I make mistakes, for better or worse, they're usually relatively small-scale. I want to restore a certain file or I will want to, “Ooh, that one item I just dropped out of that database really should not have been dropped.” Do you currently offer things that go beyond the entire restore everything or nothing? Or right now are you still approaching this from the perspective of this is for the catastrophic case where you're in some pain already?Simon: Mostly the catastrophic stage. So, we have MySQL [bin logs 00:27:57] as an option. So, if you wanted to do, like, a point-in-time of store, which… may be more applicable to what you're saying, but generally, its whole, whole website recovery. For example, like, we have a WordPress backup that'll go through all the WordPress websites on the server and we'll back them up individually so you can restore just one. There are ways that we have helped customers in the past just pull one table, for example, from a backup.But yeah, we geared towards, kind of, the set and the forget. And people don't often restore backups, to be honest. They don't. But when they do, it's obviously [laugh] very crucial that they work, so I prefer to back up the whole thing and then help people, like, if you need to extract ten megabytes out of an entire gig backup, that's a bit wasteful, but at least, you know, you've got the data there. So.Corey: Yeah. I'm a big believer in having backups in a variety of different levels. Because I don't really want to do a whole server restore when I remove a file. And let's be clear, I still have that grumpy old Unix admin of before I start making changes to a file, yeah, my editor can undo things and remembers that persistently and all. But I have a disturbing number of files and directories whose names end in ‘.bac' with then, like, a date or something on it, just because it's—you know, like, “Oh, I have to fix something in Git. How do I do this?”Step one, I'm going to copy the entire directory so when I make a pig's breakfast out of this and I lose things that I care about, rather than having to play Git surgeon for two more days, I can just copy it back over and try again. Disk space is cheap for those things. But that's also not a holistic backup strategy because I have to remember to do it every time and the whole point of what you're building and the value you're adding, from my perspective, is people don't have to think about it.Simon: Yes. Yeah yeah yeah. Once it's there, it's there. It's running. It's as you say, it's not the most efficient thing if you wanted to restore one file—not to say you couldn't—but at least you didn't have to think about doing the backup first.Corey: I really want to thank you for taking the time out of your day to talk to me about all this. If people want to learn more for themselves, where can they find you?Simon: So, SnapShooter.com is a great place, or on Twitter, if you want to follow me. I am @MrSimonBennett.Corey: And we will, of course, put links to that in the [show notes 00:30:11]. Thank you once again. I really appreciate it.Simon: Thank you. Thank you very much for having me.Corey: Simon Bennett, founder and CEO of SnapShooter.com. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this episode, please leave a five-star review on your podcast platform of choice, whereas if you've hated this episode, please leave a five-star review on your podcast platform of choice, along with an angry insulting comment that, just like your backup strategy, you haven't put enough thought into.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Welcome to Episode 189 Like the song says, it's been a while. Biyt after a month off we're back and ready to entertain you. However before we get into any reviews here's what we discuss: Dan poses a personal question Porn Stars are great podcasters. Steve's Paul Mccartney experience A different mindset  We also have listener mail from Johnny Bucks and longtime listener Shannon As far as reviews go: We spend the most time talking about Doctor Strange in the Multiverse of Madness so we can hear Steve's thoughts Quick Reviews from Dan: The Offer (Paramount+) Star Trek Strange New Worlds (Paramount+) The Pentaverate (Netflix) Chip n Dale Rescue Rangers (Disney+) Night Sky (Prime Video) More thoughts on S3 of Atlanta That's pretty much the show this week. But be on the lookout for a bonus episode that will drop into your feeds on Friday 5/27. On this episode we chat with MCU Stuntman Preshas Jenkins. We had a great time talking with him and we think you'll enjoy listening. This episode is already out on Patreon. Speaking of that... Join us on Patreon  You can help support the show , get exclusive podcast episodes, videos, and early access to special episodes by becoming a Patron  Click here to find out how. Heroes of Noise Podcast Contact and Show Info: Website: www.heroesofnoise.com Email: HeroesofNoisePodcast@gmail.com Show Twitter: @HeroesofNoise Facebook: Heroes of Noise Podcast Instagram: @heroesofnoisepodcast If you're into the AMC series "PREACHER", listen to our other podcast : The Word: The Unofficial PREACHER Podcast Contact Info: Email: askthewordpodcast@gmail.com Twitter: @Word_Podcast Hosts Twitter: @DanQPublic, @SE_Hudsonmusic Facebook: The Word Podcast Website: www.heroesofnoise.com  

Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec. Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure! Page transitions Overview (https://youtu.be/JCJUPJ_zDQ4) Using yield_self for composable ActiveRecord relations (https://thoughtbot.com/blog/using-yieldself-for-composable-activerecord-relations) A Case for Query Objects in Rails (https://thoughtbot.com/blog/a-case-for-query-objects-in-rails) Customer.io (https://customer.io/) Turning the database inside-out with Apache Samza | Confluent (https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/) Datomic (https://www.datomic.com/) About CRDTs • Conflict-free Replicated Data Types (https://crdt.tech/) Apache Kafka (https://kafka.apache.org/) Resilient Management | A book for new managers in tech (https://resilient-management.com/) Mixpanel: Product Analytics for Mobile, Web, & More (https://mixpanel.com/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Golden roads are golden. Okay, everybody's got golden roads. You have golden roads, yes? That is what we're -- STEPH: Oh, I have golden roads, yes. [laughter] CHRIS: You might should inform that you've got golden roads, yeah. STEPH: Yeah, I don't know if I say might should as much but might could. I have been called out for that one a lot; I might could do that. CHRIS: [laughs] STEPH: That one just feels so natural to me than normal. Anytime someone calls it out, I'm like, yeah, what about it? [laughter] CHRIS: Do you want to fight? STEPH: Yeah, are we going to fight? CHRIS: I might could fight you. STEPH: I might could. I might should. [laughter] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. I have a couple of fun updates. I have a baby Viccari update, so little baby weighs about two pounds now, two pounds. I'm 25 weeks along. So not that I actually know the exact weight, I'm using all those apps that estimate based on how far along you are, so around two pounds, which is novel. Oh, and then the other thing I'm excited to tell you about...I'm not sure how I should feel that I just got more excited about this other thing. I'm very excited about baby Viccari. But the other thing is there's a new Jurassic Park movie coming out, and I'm very excited. I think it's June 10th is when it comes out. And given how much we have sung that theme song to each other and make references to what a clever girl, I needed to share that with you. Maybe you already know, maybe you're already in the loop, but if you don't, it's coming. CHRIS: Yeah, the internet likes to yell things like that. Have you watched all of the most recent ones? There are like two, and I think this will be the third in the revisiting or whatever, the Jurassic World version or something like that. But have you watched the others? STEPH: I haven't seen all of them. So I've, of course, seen the first one. I saw the one that Chris Pratt was in, and now he's in the latest one. But I think I've missed...maybe there's like two in the middle there. I have not watched those. CHRIS: There are three in the original trilogy, and then there are three now in the new trilogy, which now it's ending, and they got everybody. STEPH: Oh, I'm behind. CHRIS: They got people from the first one, and they got the people from the second trilogy. They just got everybody, and that's exciting. You know, it's that thing where they tap into nostalgia, and they take advantage of us via it. But I'm fine. I'm here for it. STEPH: I'm here for it, especially for Jurassic Park. But then there's also a new Top Gun movie coming out, which, I'll be honest, I'm totally going to watch. But I really didn't remember the first one. I don't know that I've really ever watched the first Top Gun. So Tim, my partner, and I watched that recently, and it's such a bad movie. I'm going to say it; [laughs] it's a bad movie. CHRIS: I mean, I don't want to disagree, but the volleyball scene, come on, come on, the volleyball scene. [laughter] STEPH: I mean, I totally had a good time watching the movie. But the one part that I finally kept complaining about is because every time they showed the lead female character, I can't think of her character name or the actress's name, but they kept playing that song, Take My Breath Away. And I was like, can we just get past the song? [laughs] Because if you go back and watch that movie, I swear they play it like six different times. It was a lot. It was too much. So I moved it into bad movie category but bad movie totally worth watching, whatever category that is. CHRIS: Now I kind of want to revisit it. I feel like the drinking game writes itself. But at a minimum, anytime Take My Breath Away plays, yeah. Well, all right, good to know. [laughs] STEPH: Well, if you do that, let me know how many shots or beers you drink because I think it will be a fair amount. I think it will be more than five. CHRIS: Yeah, it involves a delicate calibration to get that right. I don't think it's the sort of thing you just freehand. It writes itself but also, you want someone who's tried it before you so that you're not like, oh no, it's every time they show a jet. That was too many. You can't drink that much while watching this movie. STEPH: Yeah, that would be death by Top Gun. CHRIS: But not the normal way, the different, indirect death by Top Gun. STEPH: I don't know what the normal way is. [laughs] CHRIS: Like getting shot down by a Top Gun pilot. [laughter] STEPH: Yeah, that makes sense. [laughs] CHRIS: You know, the dogfighting in the plane. STEPH: The actual, yeah, going to war away. Just sitting on your couch and you drink too much poison away, yeah, that one. All right, that got weird. Moving on, [laughs] there's a new Jurassic Park movie. We're going to land on that note. And in the more technical world, I've got a couple of things on my mind. One of them is I have a question for you. I'm very excited to run this by you because I could use a friend in helping me decide what to do. So I am still on that journey where I am migrating Test::Unit test over to RSpec. And as I'm going through, it's going pretty well, but it's a little complicated because some of the Test::Unit tests have different setup than, say, the RSpec do. They might run different scripts beforehand where they're loading data. That's perhaps a different topic, but that's happening. And so that has changed a few things. But then overall, I've just been really just porting everything over, like, hey, if it exists in the Test::Unit, let's just bring it to RSpec, and then I'm going to change these asserts to expects and really not make any changes from there. But as I'm doing that, I'm seeing areas that I want to improve and things that I want to clear up, even if it's just extracting a variable name. Or, as I'm moving some of these over in Test::Unit, it's not clear to me exactly what the test is about. Like, it looks more like a method name in the way that the test is being described, but the actual behavior isn't clear to me as if I were writing this in RSpec, I think it would have more of a clear description. Maybe that's not specific to the actual testing framework. That might just be how these tests are set up. But I'm at that point where I'm questioning should I keep going in terms of where I am just copying everything over from Test::Unit and then moving it over to RSpec? Because ultimately, that is the goal, to migrate over. Or should I also include some time to then go back and clean up and try to add some clarity, maybe extract some variable names, see if I can reduce some lets, maybe even reduce some of the test helpers that I'm bringing over? How much cleanup should be involved, zero, lots? I don't know. I don't know what that...[laughs] I'm sure there's a middle ground in there somewhere. But I'm having trouble discerning for myself what's the right amount because this feels like one of those areas where if I don't do any cleanup, I'm not coming back to it, like, that's just the truth. So it's either now, or I have no idea when and maybe never. CHRIS: I'll be honest, the first thing that came to mind in this most recent time that you mentioned this is, did we consider just deleting these tests entirely? Is that on...like, there are very few of them, right? Like, are they even providing enough value? So that was question one, which let me pause to see what your thoughts there were. [chuckles] STEPH: I don't know if we specifically talked about that on the mic, but yes, that has been considered. And the team that owns those tests has said, "No, please don't delete them. We do get value from them." So we can port them over to RSpec, but we don't have time to port them over to RSpec. So we just need to keep letting them go on. But yet, not porting them conflicts with my goal of then trying to speed up CI. And so it'd be nice to collapse these Test::Unit tests over to RSpec because then that would bring our CI build down by several meaningful minutes. And also, it would reduce some of the complexity in the CI setup. CHRIS: Gotcha. Okay, so now, having set that aside, I always ask the first question of like, can you just put Derek Prior's phone number on the webpage and call it an app? Is that the MVP of this app? No? Okay, all right, we have to build more. But yeah, I think to answer it and in a general way of trying to answer a broader set of questions here... I think this falls into a category of like if you find yourself having to move around some code, if that code is just comfortably running and the main thing you need to do is just to get it ported over to RSpec, I would probably do as little other work as possible. With the one consideration that if you find yourself needing to deeply load up the context of these tests like actually understand them in order to do the porting, then I would probably take advantage of that context because it's hard to get your head into a given piece of code, test or otherwise. And so if you're in there and you're like, well, now that I'm here, I can definitely see that we could rearrange some stuff and just definitively make it better, if you get to that place, I would consider it. But if this ends up being mostly a pretty rote transformation like you said, asserts become expects, and lets get switched around, you know, that sort of stuff, if it's a very mechanical process of getting done, I would probably say very minimal. But again, if there is that, like, you know what? I had to understand the test in order to port them anyway, so while I'm here, let me take advantage of that, that's probably the thing that I would consider. But if not that, then I would say even though it's messy and whatnot and your inclination would be to clean it, I would say leave it roughly as is. That's my guess or how I would approach it. STEPH: Yeah, I love that. I love how you pointed out, like, did you build up the context? Because you're right, in a lot of these test cases, I'm not, or I'm trying really hard to not build up context. I'm trying very hard to just move them over and, if I have to, mainly to find test descriptions. That's the main area I'm struggling to...how can I more explicitly state what this test does so the next person reading this will have more comprehension than I do? But otherwise, I'm trying hard to not have any real context around it. And that's such a good point because that's often...when someone else is in the middle of something, and they're deciding whether to include that cleanup or refactor or improvement, one of my suggestions is like, hey, we've got the context now. Let's go with it. But if you've built up very little context, then that's not a really good catalyst or reason to then dig in deeper and apply that cleanup. That's super helpful. Thank you. That will help reinforce what I'm going to do, which is exactly let's migrate RSpec and not worry about cleanup, which feels terrible; I'm just going to say that into the world. But it also feels like the right thing to do. CHRIS: Well, I'm happy to have helped. And I share the like, and it feels terrible. I want to do the right thing, but sometimes you got to pick a battle sort of thing. STEPH: Cool. Well, that's a huge help to me. What's going on in your world? CHRIS: What's going on in my world? I watched a great video the other day from the Google I/O. I think it's an event; I'm not actually sure, conference or something like that. But it was some Google Chrome developers talking about a new feature that's coming to the platform called Page Transitions. And I've kept an eye on this for a while, but it seems like it's more real. Like, I think they put out an RFC or an initial sort of set of ideas a while back. And the web community was like, "Oh, that's not going to work out so well." So they went back to the drawing board, revisited. I've actually implemented in Chrome Canary a version of the API. And then, in the video that I watched, which we'll include a show notes link to, they demoed the functionality of the Page Transitions API and showed what you can do. And it's super cool. It allows for the sort of animations that you see in a lot of native mobile apps where you're looking at a ListView, you click on one of the items, and it grows to fill the whole screen. And now you're on the detail screen for that item that you were looking at. But there was this very continuous animated transition that allows you to keep context in your head and all of those sorts of nice things. And this just really helps to bridge that gap between, like, the web often lags behind the native mobile platforms in terms of the experiences that we can build. So it was really interesting to see what they've been able to pull off. The demo is a pretty short video, but it shows a couple of different variations of what you can build with it. And I was like, yeah, these look like cool native app transitions, really nifty. One thing that's very interesting is the actual implementation of this. So it's like you have one version of the page, and then you transition to a new version of the page, and in doing so, you want to animate between them. And the way that they do it is they have the first version of the page. They take a screenshot of it like the browser engine takes a screenshot of it. And then they put that picture on top of the actual browser page. Then they do the same thing with the next version of the page that they're going to transition to. And then they crossfade, like, change the opacity and size and whatnot between the two different images, and then you're there. And in the back of my mind, I'm like, I'm sorry, what now? You did which? I'm like, is this the genius solution that actually makes this work and is performant? And I wonder if there are trade-offs. Like, do you lose interactivity between those because you've got some images that are just on the screen? And what is that like? But as they were going through it, I was just like, wait, I'm sorry, you did what? This is either the best idea I've ever heard, or I'm not so sure about this. STEPH: That's fascinating. You had me with the first part in terms of they take a screenshot of the page that you're leaving. I'm like, yeah, that's a great idea. And then talking about taking a picture of the other page because then you have to load it but not show it to the user that it's loaded. And then take a picture of it, and then show them the picture of the loaded page. But then actually, like you said, then crossfade and then bring in the real functionality. I am...what am I? [laughter] CHRIS: What am I actually? STEPH: [laughs] What am I? I'm shocked. I'm surprised that that is so performant. Because yeah, I also wouldn't have thought of that, or I would have immediately have thought like, there's no way that's going to be performant enough. But that's fascinating. CHRIS: For me, performance seems more manageable, but it's the like, what are you trading off for that? Because that sounds like a hack. That sounds like the sort of thing I would recommend if we need to get an MVP out next week. And I'm like, what if we just tried this? Listen, it's got some trade-offs. So I'm really interested to see are those trade-offs present? Because it's the browser engine. It's, you know, the low-level platform that's actually managing this. And there are some nice hooks that allow you to control it. And at a CSS level, you can manage it and use keyframe animations to control the transition more directly. There's a JavaScript API to instrument the sequencing of things. And so it's giving you the right primitives and the right hooks. And the fact that the implementation happens to use pictures or screenshots, to use a slightly different word, it's like, okey dokey, that's what we're doing. Sounds fun. So I'm super interested because the functionality is deeply, deeply interesting to me. Svelte actually has a version of this, the crossfade utility, but you have to still really think about how do you sequence between the two pages and how do you do the connective tissue there? And then Svelte will manage it for you if you do all the right stuff. But the wiring up is somewhat complicated. So having this in the browser engine is really interesting to me. But yeah, pictures. STEPH: This is one of those ideas where I can't decide if this was someone who is very new to the team and new to the idea and was like, "Have we considered screenshots? Have we considered pictures?" Or if this is like the uber senior person on the team that was like, "Yeah, this will totally work with screenshots." I can't decide where in that range this idea falls, which I think makes me love it even more. Because it's very straightforward of like, hey, what if we just tried this? And it's working, so cool, cool, cool. CHRIS: There's a fantastic meme that's been making the rounds where it's a bell curve, and it's like, early in your career, middle of your career, late in your career. And so early in your career, you're like, everything in one file, all lines of code that's just where they go. And then in the middle of your career, you're like, no, no, no, we need different concerns, and files, and organizational structures. And then end of your career...and this was coming up in reference to the TypeScript team seems to have just thrown everything into one file. And it's the thing that they've migrated to over time. And so they have this many, many line file that is basically the TypeScript engine all in one file. And so it was a joke of like, they definitely know what they're doing with programming. They're not just starting last week sort of thing. And so it's this funny arc that certain things can go through. So I think that's an excellent summary there [laughs] of like, I think it was folks who have thought about this really hard. But I kind of hope it was someone who was just like, "I'm new here. But have we thought about pictures? What about pictures?" I also am a little worried that I just deeply misunderstood [laughs] the representation but glossed over it in the video, and I'm like, that sounds interesting. So hopefully, I'm not just wildly off base here. [laughs] But nonetheless, the functionality looks very interesting. STEPH: That would be a hilarious tweet. You know, I've been waiting for that moment where I've said something that I understood into the mic and someone on Twitter just being like, well, good try, but... [laughs] CHRIS: We had a couple of minutes where we tried to figure out what the opposite of ranting was, and we came up with pranting and made up a word instead of going with praising or raving. No, that's what it is, raving. [laughs] STEPH: No, raving. I will never forget now, raving. [laughs] CHRIS: So, I mean, we've done this before. STEPH: That's true. Although they were nice, I don't think they tweeted. I think they sent in an email. They were like, "Hey, friends." [laughter] CHRIS: Actually, we got a handful of emails on that. [laughter] STEPH: Did you know the English language? CHRIS: Thank you, kind Bikeshed audience, for not shaming us in public. I mean, feel free if you feel like it. [laughs] But one other thing that came up in this video, though, is the speaker was describing single-page apps are very common, and you want to have animated transitions and this and that. And I was like, single-page app, okay, fine. I don't like the terminology but whatever. I would like us to call it the client-side app or client-side routing or something else. But the fact that it's a single page is just a technical consideration that no user would call it that. Users are like; I go to the web app. I like that it has URLs. Those seem different to me. Anyway, this is my hill. I'm going to die on it. But then the speaker in the video, in contrast to single-page app referenced multi-page app, and I was like, oh, come on, come on. I get it. Like, yes, there are just balls of JavaScript that you can download on the internet and have a dynamic graphics editor. But I think almost all good things on the web should have URLs, and that's what I would call the multiple pages. But again, that's just me griping about some stuff. And to name it, I don't think I'm just griping for griping sake. Like, again, I like to think about things from the user perspective, and the URL being so important. And having worked with plenty of apps that are implemented in JavaScript and don't take the URL or the idea that we can have different routable resources seriously and everything is just one URL, that's a failure mode in my mind. We missed an opportunity here. So I think I'm saying a useful thing here and not just complaining on the internet. But with that, I will stop complaining on the internet and send it back over to you. What else is new in your world, Steph? STEPH: I do remember the first time that you griped about it, and you were griping about URLs. And there was a part of me that was like, what is he talking about? [laughter] And then over time, I was like, oh, I get it now as I started actually working more in that world. But it took me a little bit to really appreciate that gripe and where you're coming from. And I agree; I think you're coming from a reasonable place, not that I'm biased at all as your co-host, but you know. CHRIS: I really like the honest summary that you're giving of, like, honestly, the first time you said this, I let you go for a while, but I did not know what you were talking about. [laughs] And I was like, okay, good data point. I'm going to store that one away and think about it a bunch. But that's fine. I'm glad you're now hanging out with me still. [laughter] STEPH: Don't do that. Don't think about it a bunch. [laughs] Let's see, oh, something else that's going on in my world. I had a really fun pairing session with another thoughtboter where we were digging into query objects and essentially extracting some logic out of an ActiveRecord model and then giving that behavior its own space and elevated namespace in a query object. And one of the questions or one of the things that came up that we needed to incorporate was optional filters. So say if you are searching for a pizza place that's nearby and you provide a city, but you don't provide what's the optional zip code, then we want to make sure that we don't apply the zip code in the where clause because then you would return all the pizza places that have a nil zip code, and that's just not what you want. So we need to respect the fact that not all the filters need to be applied. And there are a couple of ways to go about it. And it was a fun journey to see the different ways that we could structure it. So one of the really good starting points is captured in a blog post by Derek Prior, which we'll include a link to in the show notes, and it's using yield_self for composable ActiveRecord relations. But essentially, it starts out with an example where it shows that you're assigning a value to then the result of an if statement. So it's like, hey, if the zip code is present, then let's filter by zip code; if not, then just give us back the original relation. And then you can just keep building on it from there. And then there's a really nice implementation that Derek built on that then uses yield_self to pass the relation through, which then provides a really nice readability for as you are then stepping through each filter and which one should and shouldn't be applied. And now there's another blog post, and this one's written by Thiago Silva, A Case for Query Objects in Rails. And this one highlighted an approach that I haven't used before. And I initially had some mixed feelings about it. But this approach uses the extending method, which is a method that's on ActiveRecord query methods. And it's used to extend the scope with additional methods. You can either do this by providing the name of a module or by providing a block. It's only going to apply to that instance or to that specific scope when you're using it. So it's not going to be like you're running an include or something like that where all instances are going to now have access to these methods. So by using that method, extending, then you can create a module that says, "Hey, I want to create this by zip code filter that will then check if we have a zip code, let's apply it, if not, return the relation. And it also creates a really pretty chaining experience of like, here's my original class name. Let's extend with these specific scopes, and then we can say by zip code, by pizza topping, whatever else it is that we're looking to filter by. And I was initially...I saw the extending, and it made me nervous because I was like, oh, what all does this apply to? And is it going to impact anything outside of this class? But the more I've looked at it, the more I really like it. So I think you've seen this blog post too. And I'm curious, what are your thoughts about this? CHRIS: I did see this blog post come through. I follow that thoughtbot blog real close because it turns out some of the best writing on the internet is on there. But I saw this...also, as an aside, I like that we've got two Derek Prior references in one episode. Let's see if we can go for three before the end. But one thing that did stand out to me in it is I have historically avoided scopes using scope like ActiveRecord macro thing. It's a class method, but like, it's magic. It does magic. And a while ago, class methods and scopes became roughly equivalent, not exactly equivalent, but close enough. And for me, I want to use methods because I know stuff about methods. I know about default arguments. And I know about all of these different subtleties because they're just methods at the end of the day, whereas scopes are special; they have certain behavior. And I've never really known of the behavior beyond the fact that they get implemented in a different way. And so I was never really sold on them. And they're different enough from methods, and I know methods well. So I'm like, let's use the normal stuff where we can. The one thing that's really interesting, though, is the returning nil that was mentioned in this blog post. If you return nil in a scope, it will handle that for you. Whereas all of my query objects have a like, well, if this thing applies, then scope dot or relation dot where blah, blah, blah, else return relation unchanged. And the fact that that natively exists within scope is interesting enough to make me reconsider my stance on scopes versus class methods. I think I'm still doing class method. But it is an interesting consideration that I was unaware of before. STEPH: Yeah, it's an interesting point. I hadn't really considered as much whether I'm defining a class-level method versus a scope in this particular case. And I also didn't realize that scopes handle that nil case for you. That was one of the other things that I learned by reading through this blog post. I was like, oh, that is a nicety. Like, that is something that I get for free. So I agree. I think this is one of those things that I like enough that I'd really like to try it out more and then see how it goes and start to incorporate it into my process. Because this feels like one of those common areas of where I get to it, and I'm like, how do I do this again? And yield_self was just complicated enough in terms of then using the fancy method method to then be able to call the method that I want that I was like, I don't remember how to do this. I had to look it up each time. But including this module with extending and then being able to use scopes that way feels like something that would be intuitive for me that then I could just pick up and run with each time. CHRIS: If it helps, you can use then instead of yield_self because we did upgrade our Ruby a while back to have that change. But I don't think that actually solves the thing that you're describing. I'd have liked the ampersand method and then simple method name magic incantation that is part of the thing that Derek wrote up. I do use it when I write query objects, but I have to think about it or look it up each time and be like, how do I do that? All right, that's how I do that. STEPH: Yeah, that's one of the things that I really appreciate is how often folks will go back and update blog posts, or they will add an addition to them to say, "Hey, there's something new that came out that then is still relevant to this topic." So then you can read through it and see the latest and the greatest. It's a really nice touch to a number of our blog posts. But yeah, that's what was on my mind regarding query objects. What else is going on in your world? CHRIS: I have this growing feeling that I don't quite know what to do with. I think I've talked about it across some of our conversations in the world of observability. But broadly, I'm starting to like...I feel like my brain has shifted, and I now see the world slightly differently, and I can't go back. But I also don't know how to stick the landing and complete this transition in my brain. So it's basically everything's an event stream; this feels true. That's life. The arrow of time goes in one direction as far as I understand it. And I'm now starting to see it manifest in the code that we're writing. Like, we have code to log things, and we have places where we want to log more intentionally. Then occasionally, we send stuff off to Sentry. And Sentry tells us when there are errors, that's great. But in a lot of places, we have both. Like, we will warn about something happening, and we'll send that to the logs because we want to have that in the logs, which is basically the whole history of what's happened. But we also have it in Sentry, but Sentry's version is just this expanded version that has a bunch more data about the user, and things, and the browser that they were in. But they're two variations on the same event. And then similarly, analytics is this, like, third leg of well, this thing happened, and we want to know about it in the context. And what's been really interesting is we're working with a tool called Customer.io, which is an omnichannel communication whiz-bang adventure. For us, it does email, SMS, and push notifications. And it's integrated into our segment pipeline, so events flow in, events and users essentially. So we have those two different primitives within it. And then within it, we can say like, when a user does X, then send them an email with this copy. As an aside, Customer.io is a fantastic platform. I'm super-duper impressed. We went through a search for a tool like it, and we ended up on a lot of sales demos with folks that were like, hey, so yeah, starting point is $25,000 per year. And, you know, we can talk about it, but it's only going to go up from there when we talk about it, just to be clear. And it's a year minimum contract, and you're going to love it. And we're like, you do have impressive platforms, but okay, that's a bunch. And then, we found Customer.io, and it's month-by-month pricing. And it had a surprisingly complete feature set. So overall, I've been super impressed with Customer.io and everything that they've afforded. But now that I'm seeing it, I kind of want to move everything into that world where like, Customer.io allows non-engineer team members to interact with that event stream and then make things happen. And that's what we're doing all the time. But I'm at that point where I think I see the thing that I want, but I have no idea how to get there. And it might not even be tractable either. There's the wonderful Turning the Database Inside Out talk, which describes how everything is an event stream. And what if we actually were to structure things that way and do materialized views on top of it? And the actual UI that you're looking at is a materialized view on top of the database, which is a materialized view on top of that event stream. So I'm mostly in this, like, I want to figure this out. I want to start to unify all this stuff. And analytics pipes to one tool that gets a version of this event stream, and our logs are just another, and our error system is another variation on it. But they're all sort of sampling from that one event stream. But I have no idea how to do that. And then when you have a database, then you're like, well, that's also just a static representation of a point in time, which is the opposite of an event stream. So what do you do there? So there are folks out there that are doing good thinking on this. So I'm going to keep my ear to the ground and try and see what's everybody thinking on this front? But I can't shake the feeling that there's something here that I'm missing that I want to stitch together. STEPH: I'm intrigued on how to take this further because everything you're saying resonates in terms of having these event streams that you're working with. But yet, I can't mentally replace that with the existing model that I have in my mind of where there are still certain ideas of records or things that exist in the world. And I want to encapsulate the data and store that in the database. And maybe I look it up based on when it happens; maybe I don't. Maybe I'm looking it up by something completely different. So yeah, I'm also intrigued by your thoughts, but I'm also not sure where to take it. Who are some of the folks that are doing some of the thinking in this area that you're interested in, or where might you look next? CHRIS: There's the Kafka world of we have an event log, and then we're processing on top of that, and we're building stream processing engines as the core. They seem to be closest to the Turning the Database Inside Out talk that I was thinking or that I mentioned earlier. There's also the idea of CRDTs, which are Conflict-free Replicated Data Types, which are really interesting. I see them used particularly in real-time application. So it's this other tool, but they are basically event logs. And then you can communicate them well and have two different people working on something collaboratively. And these event logs then have a natural way to come together and produce a common version of the document on either end. That's at least my loose understanding of it, but it seems like a variation on this theme. So I've been looking at that a little bit. But again, I can't see how to map that to like, but I know how to make a Rails app with a Postgres database. And I think I'm reasonably capable at it, or at least I've been able to produce things that are useful to humans using it. And so it feels like there is this pretty large gap. Because what makes sense in my head is if you follow this all the way, it fundamentally re-architects everything. And so that's A, scary, and B; I have no idea how to get there, but I am intrigued. Like, I feel like there's something there. There's also Datomic is the other thing that comes to mind, which is a database engine in the Clojure world that stores the versions of things over time; that idea of the user is active. It's like, well, yeah, but when were they not? That's an event. That transition is an event that Postgres does not maintain at this point. And so, all I know is that the user is active. Maybe I store a timestamp because I'm thinking proactively about this. But Datomic is like no, no, fundamentally, as a primitive in this database; that's how we organize and think about stuff. And I know I've talked about Datomic on here before. So I've circled around these ideas before. And I'm pretty sure I'm just going to spend a couple of minutes circling and then stop because I have no idea how to connect the dots. [laughs] But I want to figure this out. STEPH: I have not worked with Kafka. But one of the main benefits I understand with Kafka is that by storing everything as a stream, you're never going to lose like a message. So if you are sending a message to another system and then that message gets lost in transit, you don't actually know if it got acknowledged or what happened with it, and replaying is really hard. Where do you pick up again? While using something like Kafka, you know exactly what you sent last, and then you're not going to have that uncertainty as to what messages went through and which ones didn't. And then the ability to replay is so important. I'm curious, as you continue to explore this, do you have a particular pain point in mind that you'd like to see improve? Or is it more just like, this seems like a really cool, novel idea; how can I incorporate more of this into my world? CHRIS: I think it's the latter. But I think the thing that I keep feeling is we keep going back and re-instrumenting versions of this. We're adding more logging or more analytics events over the wire or other things. But then, as I send these analytics events over the wire, we have Mixpanel downstream as an analytics visualization and workflow tool or Customer.io. At this point, those applications, I think, have a richer understanding of our users than our core Rails app. And something about that feels wrong to me. We're also streaming everything that goes through segment to S3 because I had a realization of this a while back. I'm like, that event stream is very interesting. I don't want to lose it. I'm going to put it somewhere that I get to keep it. So even if we move off of either Mixpanel or Customer.io or any of those other platforms, we still have our data. That's our data, and we're going to hold on to it. But interestingly, Customer.io, when it sends a message, will push an event back into segments. So it's like doubly connected to segment, which is managing this sort of event bus of data. And so Mixpanel then gets an even richer set there, and the Rails app is like, I'm cool. I'm still hanging out, and I'm doing stuff; it's fine. But the fact that the Rails app is fundamentally less aware of the things that have happened is really interesting to me. And I am not running into issues with it, but I do feel odd about it. STEPH: That touched on a theme that is interesting to me, the idea that I hadn't really considered it in those terms. But yeah, our application provides the tool in which people can interact with. But then we outsource the behavior analysis of our users and understanding what that flow is and what they're going through. I hadn't really thought about those concrete terms and where someone else owns the behavior of our users, but yet we own all the interaction points. And then we really need both to then make decisions about features and things that we're building next. But that also feels like building a whole new product, that behavior analysis portion of it, so it's interesting. My consulting brain is going wild at the moment between like, yeah, it