Last Week In AWS Podcast

Last Week In AWS Podcast

Download on the App Store

Last Week In AWS Podcast episodes

  • Build vs. Buy

    Transcript


    Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.


    Jesse: Hello, and welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

    Amy: I’m Amy Negrette.

    Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild. With a healthy dose of complaining about AWS for good measure. Today, we’re going to be talking about build versus buy. I feel like this is really kind of a classic engineering conversation. Amy, what is the build versus buy idea?

    Amy: It’s really the idea of whether you decide to use a managed service or SaaS product versus rolling your own and building yourself. It’s very easy to do these days with a few watches on YouTube, maybe some blog articles. You can also do repairs on my house, which is why I always have to get repairs done on my house. [laugh].

    Jesse: [laugh]. Yeah, I feel like as much as I love the world of HGTV and the DIY network, I think I can do more than I actually can and I feel like it’s probably a lot safer to just let a professional take the reins. I mean, there’s so many certification programs that teach you how to build and manage your own engineering things, your own distributed databases, your own Kubernetes clusters, your own streaming data platform, and it’s really great to understand the fundamental building blocks of these systems, it’s really great to understand how they work so that ultimately if you are consuming from them or managing them, that you understand the ins and the outs of the system. But the question becomes, do you really need to be the one that’s managing that system? Do you really need to be the one spending your time managing that system on top of writing code for your microservices, on top of managing the architecture, the application, all of the components of your service that are critical?

    Amy: So, I guess what we really want to decide is, in what use cases is it okay to build something from scratch, and when is it okay to, essentially, just go to the market and look for something that’s made already?

    Jesse: Yeah. And I think that’s the main question that a lot of folks ask: what is the defining line? What are the questions they should think about as they are choosing to build versus buy?

    Amy: I think if you want to really look at building a product, and really from the ground up—you have this product in mind and you want to do all the architecture, control it end-to-end—unless this is your core product feature or you’re going to package it for either internal or public release, you almost always—you don’t want to build this yourself because someone has probably built it in a way that’s not going to cause your engineers time or money. Unless it is going to directly make you money, then yes. If this is tied to your product income and your product revenue, please build it yourself. It avoids a lot of licensing issues, you do get to control how it works, how you want it to work. But that said a lot of products, just a bunch of assassins in a trench coat anyway, so—

    Jesse: [laugh].

    Amy: —it really depends on what’s important to you.

    Jesse: Yeah, I feel like this is one of the biggest pitfalls that I see in a lot of organizations where they think about how they want to build out an architecture and they choose that a solution like, stateful distributed service is going to be the right thing that they want. And one of the developers says, “Oh, that’s easy. I can build that in a weekend.” And then they go off and build it, and then they’re stuck managing that system for all of eternity when that’s not the primary purpose of the team that they’re working on, that’s not the primary purpose of the product that they’re working on. So, if you’re going to build something that is directly related to your product, directly related to your business use case, directly related to how your company is making money, something that is absolutely your bread and butter, you definitely want to build that rather than buying that off the shelf.

    Because building it will give you that great opportunity to focus on controlling all the ins and outs of the system, understanding all the parts of the system, finding the flexibility when you need flexibility, really fine-tuning and honing all the parts of the system in the way that you need it to work so that ultimately your organization is getting the best bang for their buck out of the system, whereas in a lot of cases, you’re not going to get the same level of flexibility from an off the 
    shelf solution.

    Amy: And especially if you’re going to go in and planning to build your own supporting product, make sure—and I said this before, I’ll say it again—you do check the licenses of any libraries and any SaaS products you use to build it because I reinvented the wheel plenty of times in my career, specifically because I worked in a place where the licensing we were allowed to use would not allow us to use very specific products.

    Jesse: Yeah. That’s such a critical business risk and something that I think not every engineer is fully aware of. And to be clear, I don’t think that’s the engineer’s fault. I think that’s part of best practices that every organization can get better at to make sure that everybody understands, what are our limitations on using modules, using open-source solutions from the internet? How can we make sure that we ultimately aren’t creating additional unnecessary business risk?

    Amy: When do we go shopping?

    Jesse: [laugh]. Yeah, let’s go shopping. Let’s say you’ve decided that the piece of software that you want is not part of your bread and butter, like we were saying. If it’s not part of your organization’s primary product, primary use case, don’t waste engineering time building it for yourself, pay a vendor or a subject matter expert to build it for you—or to manage it for you, even—and then call it a day. It is absolutely worth those trade-offs. The additional cost of paying somebody else to manage it for you is absolutely worthwhile because you then get the opportunity to stay focused on the things that are most important to your team and your business.

    Corey: If your mean time to WTF for a security alert is more than a minute, it’s time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you’re building a secure business on AWS with compliance requirements, you don’t really have time to choose between antivirus or firewall companies to help you secure your stack. That’s why Lacework is built from the ground up for the cloud: low effort, high visibility, and detection. To learn more, visit lac...

    14 min
  • New CEO Onboarding at AWS

    Want to give your ears a break and read this as an article? You’re looking for this link. https://www.lastweekinaws.com/blog/New-CEO-Onboarding-at-AWS



    Never miss an episode

    • Join the Last Week in AWS newsletter
    • Subscribe wherever you get your podcasts



    Help the show

    • Leave a review
    • Share your feedback
    • Subscribe wherever you get your podcasts



    What's Corey up to?

    • Follow Corey on Twitter (@quinnypig)
    • See our recent work at the Duckbill Group
    • Apply to work with Corey and the Duckbill Group to help lower your AWS bill
    8 min
  • Cloud Cost Management Starter Kit

    Transcript
    Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.

    Jesse: Welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

    Amy: I’m Amy Negrette.



    Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure because I mean, who doesn’t love to complain about AWS? I feel like that’s always a good thing that we can talk about, no matter the topic. Today, we’re going to be talking about the ‘cloud cost management starter kit.’ So, the starter kit seems to be a big fad that’s going around. If you’re listening to this episode, you’re probably thinking, “It’s already done. It’s over.”



    But I still want to talk about it. I think that this is a really relevant topic because I think a lot of companies are trying to get started, get their hands started in cloud cost management. So, I think this would be a great thing for us to talk about: what’s in our cloud cost management starter kit?



    Amy: And it really will help answer that question that I get asked a lot on: what is even a cloud economist, and what do you do?



    Jesse: Yeah, I mean, given the current timeframe, I haven’t gone to any parties recently to talk about what I do, but I do feel like anytime I try to explain to somebody what I do, there’s always that moment of, “Okay. Yes, I work with computers, and we’ll just leave it at that.”



    Amy: It’s easier to just think about it as we look at receipts, and we kind of figure things out. But when you try to get into the nuts and bolts of it, it’s a very esoteric idea that we’re trying to explain. And no, I don’t know why this is a real job. And yet it is.



    Jesse: This is one of the things that always fascinates me. I absolutely love the work that I do, and I definitely think that it is important work that needs to be done for any organization, to work on their cloud cost management best practices, but it also boggles my mind that AWS, Azure, GCP, haven’t figured out how to bake this in more clearly and easily to all of their workflows and all their services. It still boggles my mind that this is something that exists as—

    Amy: As a thing we have to do.

    Jesse: As a thing we have to do. Yeah, absolutely.

    Amy: Well, the good news is, they’re going to change their practices once every six weeks, and we’ll have a new thing to figure it out. [laugh].

    Jesse: [laugh]. So, let’s get started with the first item on our cloud cost management starter kit. This one is something that Amy is definitely passionate about; I am definitely passionate about, as well. Amy, what is it?

    Amy: Turn on your CUR. Turn on your CUr. If you don’t know what it is, just Google AWS CUR. Turn it on. It will save you a headache, and it will save anyone you bring in to help you [laugh] [unintelligible 00:02:59] a huge headache. And it keeps us from having to yell at people, even though that’s the thing that if you pay us to do it, we will totally do it for you.

    Jesse: If you take nothing away from this episode, go check out the AWS Cost and Usage Report—otherwise known as CUR—turn it on for your accounts, ideally enable it in Parquet format because that’s going to allow you to get all that sweet, sweet data in an optimized manner, living in your S3 bucket. It is a godsend. It gives you all the data from Cost Explorer, and then some. It allows you to do all sorts of really interesting business intelligence analytics on your billing data. It’s absolutely fantastic.

    Amy: It’s like getting all of those juicy infrastructure metrics, except getting that with a dollar sign attached to it so you know what you actually doing with that money.

    Jesse: Yeah, this definitely is, like, the first step towards doing any kind of showback models, or chargeback models, or even unit economics to figuring out where your spend is going. The Cost and Usage Report is going to be a huge first step in that direction.

    Amy: Now, the reason why we yell at people about this—or at least I do—is because AWS will only show you the data from the time that it is turned on. They do have it for historical periods, but if you enable it at a specific point, all of your reports are going to start there. So, if you’re looking to do forecasting, or you want to be able to know what your usage is going to be looking like from this point on, turn it on as early as possible.

    Jesse: Absolutely. If you are listening to this now and you don’t have the CUR enabled, definitely go pause this episode, enable it now, and come back and listen to the rest of the episode because the sooner you have the CUR enabled, the sooner you’ll be able to get those sweet, sweet metrics for all of your—

    Amy: And it’s free.

    Jesse: [laugh]. Yeah, that’s even the more important part. It’s free. There’s going to be a little bit of data storage costs if you send this data to S3, but overall, the amount of money that you spend on that storage is going to be optimized because you’re saving that CUR data in Parquet format. It’s absolutely worthwhile.

    All right, so number two; the second item on our cloud cost management starter kit, is getting to know your AWS account manager and account team. This one, I feel like a lot of people don’t actually know that they have an AWS account manager. But let me tell you now: if you have an AWS account, you have an AWS account manager. Even if they haven’t reached out to you before they do exist, you have access to them, and you should absolutely start building a rapport with them.

    Amy: Anytime you are paying for a support plan, you also have an account manager. This isn’t just true for AWS; I would be very surprised for any service that charged you for support but did not give you an account manager.

    Jesse: So, for those of you who aren’t familiar with your account manager, they are generally somebody who will be able to help you navigate some of the more complex parts of AWS, especially when you have any kind of questions about your bill or about technical things using AWS. They will help you navigate those resources and make sure that your questions are getting to the teams that can actually answer them, and then make sure that those questions are actually getting answered. They are the best champion for you within AWS.

    If you have more than a certain threshold of spend on AWS, if you’re paying for enterprise support, you likely also have a dedicated technical account manager as well, who will be basically your point person for any technical questions. They are a great resource for any technical questions, making sure that your technical questions are answered, making sure that any conce...

    18 min
  • Security is Someone Else’s Job Zero

    Want to give your ears a break and read this as an article? You’re looking for this link.https://www.lastweekinaws.com/blog/security-is-someone-elses-job-zero 



    Never miss an episode

    • Join the Last Week in AWS newsletter
    • Subscribe wherever you get your podcasts



    Help the show

    • Leave a review
    • Share your feedback
    • Subscribe wherever you get your podcasts



    What's Corey up to?

    • Follow Corey on Twitter (@quinnypig)
    • See our recent work at the Duckbill Group
    • Apply to work with Corey and the Duckbill Group to help lower your AWS bill
    12 min
  • AWS Morning Brief Trailer
    The latest in AWS news, sprinkled with snark. Posts about AWS come out over sixty times a day. We filter through it all to find the hidden gems, the community contributions--the stuff worth hearing about! Then we summarize it with snark and share it with you--minus the nonsense.
    1 min
  • A Very Special Episode

    Transcript

    Corey: This episode is sponsored in part byLaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visitlaunchdarkly.com and tell them Corey sent you, and watch for the wince.


    Jesse: Today, on a very special episode of AWS Morning Brief: Fridays From the Field, we say our goodbyes to Pete Cheslock.

    Amy: Oh, no. Did the ops bus finally get him?

    Jesse: No. Wait, what? What? No. No, he’s not—

    Amy: You know, the ops bus, the one that takes out all of the ops people, which is why you need data recovery plans.

    Jesse: [laugh]. I mean, I have plans for other reasons, but no. No, Pete, Pete’s not dead. He’s just—I mean, he’s dead to me, but he’s just not going to be here anymore.

    Amy: Only on the inside.

    Jesse: Welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

    Amy: I’m Amy Arumbulo Negrette.

    Pete: I am Pete Cheslock. I’m here for one last, beautiful, glorious time.

    Jesse: I feel like this is going to be like Breakfast Club but in the data center server room.

    Pete: Yeah. A little bit. I think so. We will all sit cross-legged on the floor in a circle, share our thoughts and feelings. And maybe some sushi. There were sushi in that movie. And that was, like, really advanced back then in the ’80s.

    Jesse: Yeah, I like that. So Pete, you want to give us a little bit of background about why you will be moving on from this podcast?

    Pete: Moving on to a whole new world. Yes. Sadly, I am not dead. The ops bus did not get me, and I was not eaten by my smoker, my meat smoker.


    Jesse: [laugh]. Although at this point, it’s probably overdue.

    Pete: You know, the odds of all three of those are pretty high out, to be really perfectly honest, given this pandemic and everything else going on in this world.

    Amy: Isn’t that how it works? You eventually become the smoked meat.

    Pete: Yeah, yeah.

    Jesse: [laugh].

    Pete: All the time. You know, you are what you eat. And if you eat junk and whatnot—so I eat smoked meats, eventually, I’m just going to become, you know, smoked meats, I guess. But no, I am moving on from The Duckbill Group. Just bittersweet is the best word I can come up with. Very sad, but also very excited.

    I’m moving on to a new role at a new company that was just kind of an opportunity that I couldn’t pass up. And I’m really excited for something new, but really sad because I don’t get to work with two of my three favorite cloud economists, Jesse, and Amy. Yeah, Corey is one, too, and yes, it’s fun to work with him. But it’s also fun to rag on him a little bit as well.

    Jesse: I’m pretty sure you still have the opportunity to rag on him no matter where you go.

    Pete: Yeah, that’s true. I mean, we’re Twitter connected. So, I can just slide into his DMs as needed. Yeah.

    Amy: And really, what else is Twitter for—

    Pete: Exactly.

    Jesse: [laugh].

    Amy: —than roasting former coworkers and bosses?

    Pete: Yeah, I expect a constant stream of Twitter DMs every time you find something, some little fun nugget that I’ve left behind.

    Jesse: I feel like that’s appropriate. So today, Pete, I have two questions for you now that you will be moving on from Duckbill Group, moving on from this podcast, I want to know, looking back at your time here working with Duckbill Group, what did you learn? What are the things that surprised you, that you didn’t expect? And what would you say to somebody who wanted to start working in this space, maybe start a career in cloud economics on their own?

    Pete: Yeah, so this kind of feels like an exit interview a little bit.

    Jesse: [laugh]. And a very public exit interview at that. So, make sure that we bleep all the swear words.

    Pete: I think it’s in Duckbill fashion to do a public—a very public-facing exit interview, right? That is Duckbill in a nutshell.

    Jesse: I think the only thing more public is if Corey asks you to hold the exit interview on Twitter.

    Amy: Exactly.

    Pete: [laugh]. I mean, we might have to do that, now. I like that idea. Yeah, so I think those are great questions, and I love the opportunity to talk about it. Because Duckbill is a fantastic company, and coming into Duckbill last year was totally by luck.

    Not really—no, not—luck is maybe not the right word. But I had been doing some consulting on my own, and the pandemic and some other forces caused a bunch of my consulting work to dry up really quickly. And I was sitting at home and I’m like, “Wow, I should get a real job.” And I saw a tweet from Mike on Twitter that was like, “Oh, we’re growing The Duckbill Group.” And Mike and Corey and I have known each other for such a long time.

    We’ve always said it’d be great to work together at some point in the future, but it’s so hard [laugh] to do. You know, to kind of work with your friends, and timing, and circumstance, and schedule, and everything else. And so when I saw that, I was like, wow, like that might be a lot of fun working with that crew. And I’ve got a lot of experience in AWS and I’ve—my title at one of my previous companies was Captain COGS—for Cost Of Goods Sold—because I was so diligent with the Amazon bill. So, it’s kind of one of those things where I felt like I could be useful and helpful to the organization, and talking with Mike and Corey, it just made a ton of sense.


    And so, it was a lot of fun to come on board. So, but then once you’re kind of in, and you start doing this type of work—and you know, Amy and Jesse, you’ve both experienced this—I think no matter how much knowledge you have of Amazon, very, very quickly, you realize that you actually don’t know as much as you really think you did, right?


    Jesse: Yeah.

    Pete: Because it’s so—there’s just so much.


    Amy: And it changes once every five minutes.


    Pete: [laugh].


    Jesse: Oh, yeah.


    Amy: Literally if you—well, just keep an eye on that changelog, you can watch your day get ruined as time goes on.


    Jesse: [laugh].


    Pete: [laugh]. It’s—yeah, it’s a real-time day ruining. And that’s the new. It’s like Amazon Kinesis: It’s all real-time.

    Jesse: [laugh].


    Pete: Yeah, it’s so true. And I think the reason behind it is, you know, one...

    21 min
  • Developer Portals are an Anti-Pattern

    Want to give your ears a break and read this as an article? You’re looking for this link. https://www.lastweekinaws.com/blog/Developer-Portals-are-an-Anti-Pattern



    Never miss an episode

    • Join the Last Week in AWS newsletter
    • Subscribe wherever you get your podcasts



    Help the show

    • Leave a review
    • Share your feedback
    • Subscribe wherever you get your podcasts



    What's Corey up to?

    • Follow Corey on Twitter (@quinnypig)
    • See our recent work at the Duckbill Group
    • Apply to work with Corey and the Duckbill Group to help lower your AWS bill
    8 min

About Last Week In AWS Podcast

From the publisher's feed

The latest in AWS news, sprinkled with snark. Posts about AWS come out over sixty times a day. We filter through it all to find the hidden gems, the community contributions--the stuff worth hearing…

More shows like Last Week In AWS Podcast

Hanselminutes with Scott Hanselman by Scott Hanselman

Hanselminutes with Scott Hanselman

379 Listeners

The Changelog: Software Development, Open Source by Changelog Media

The Changelog: Software Development, Open Source

286 Listeners

Software Engineering Daily by Software Engineering Daily

Software Engineering Daily

622 Listeners

The Enterprise AI Show by Massive Studios

The Enterprise AI Show

147 Listeners

Talk Python To Me by Michael Kennedy

Talk Python To Me

582 Listeners

Thoughtworks Technology Podcast by Thoughtworks

Thoughtworks Technology Podcast

43 Listeners

Python Bytes by Michael Kennedy and Calvin Hendryx-Parker

Python Bytes

213 Listeners

Syntax - Tasty Web Development Treats by Wes Bos & Scott Tolinski - Full Stack JavaScript Web Developers

Syntax - Tasty Web Development Treats

985 Listeners

Tech Brew Ride Home by Morning Brew

Tech Brew Ride Home

959 Listeners

Screaming in the Cloud by Corey Quinn

Screaming in the Cloud

92 Listeners

Practical AI by Daniel Whitenack and Chris Benson

Practical AI

204 Listeners

AWS Podcast by Amazon Web Services

AWS Podcast

201 Listeners

The Stack Overflow Podcast by The Stack Overflow Podcast

The Stack Overflow Podcast

62 Listeners

The Real Python Podcast by Real Python

The Real Python Podcast

140 Listeners

The AI Daily Brief: Artificial Intelligence News and Analysis by Nathaniel Whittemore

The AI Daily Brief: Artificial Intelligence News and Analysis

683 Listeners