Join Jesse and Amy as they examine the classic build-vs-buy engineering conversation and touch upon why it’s a lot safer to let a professional take the reins for do-it-yourself projects, when it’s appropriate to go to the market and look for something that’s already been build vs. when it makes sense to build something from scratch, how it’s important to understanding license requirements of the SaaS and open source tools you use, how it can be hard to see the proverbial forest for all the silos, why you need to build feedback loops into your internal tools, and more.
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—
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
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 lacework.com
Amy: You also don’t end up trapped by having to make sure the product is appropriately upgraded or patched. And then you also have that nice little space of liability, saying we just bought this off the shelf. They said it was safe, and we trusted them. [laugh].
Jesse: Yeah, again, business risk conversations, there is absolutely that opportunity for third-party liability rather than internal liability in some of those security risks. I also feel like it’s important to add that AWS, for example, has tons of managed services that give you ease of use by removing that administrative overhead. Yes, we’re primarily focused on AWS, obviously, this is an AWS focused podcast, there is definitely going to be a best and worst use case for these products so I’m not saying that you should go out and start using these all immediately without thinking about your overall goal and use case, but in a lot of cases, again, if the solution that you want is not something that you need to manage yourself, that you need to focus on building and running yourself, give it to AWS, they have tons of these managed
solutions available to you built into the ecosystem.
Amy: And that’s true of all the large cloud providers. They have managed services to make the things that you do not have the staffing to be an expert in and do all that work for you. And it’s not as if you are locked into these solutions. When you buy into either a SaaS product or a managed service, you can migrate off if you feel like you can build it better, and you actually have spent the time in R&D, and you spent the time building out a minimum viable product, and you know that this use case works for you, and then you can either clear out overhead or fees, and you can actually come in under what you’re spending right now, then make that move. But do it after you already know what it is you want.
Jesse: Yeah, I think that’s a really great use case example, Amy. One other thing that I want to talk about is that this build versus buy a conversation so far has been focused on your organization thinking about if they want to build something internally, or if they want to buy it from a third-party vendor. But this conversation can also happen internally, in a single organization, between teams. I’m thinking about some organizations that I’ve worked for where I’ve seen one team build and manage a central platform solution, like a central CI/CD pipeline that every other team is going to be using and consuming from. But then, one team decides that the CI/CD platform that everybody’s using doesn’t really do all the things that they want it to do, so they decide to go off and build their own CI/CD platform internally for their team instead, rather than working with the team that is actually owning this sort of centralized CI/CD platform to make sure that everybody is getting the benefits of these additional features, these additional solutions, these additional bug fixes that the team was asking for.
Amy: It’s really hard when you can’t see the forest for all the silos.
Jesse: Yes. Absolutely. It is so, so critical to think about building these feedback loops into your internal tools. Because if your customers are internal to your organization, they’re going to want to provide that feedback in some capacity to help you understand when the service that you’re building is fantastic and when the service that you’re building is awful. And it’s so, so critical to make sure that you have those easy feedback loops so that you can continue to iterate on the things that you choose to build internally and hone them and make them better.
If you’ve got questions that you’d like us to answer go to lastweekinaws.com/QA
. If you’ve enjoyed this podcast, please go to lastweekinaws.com/review
and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review
, give it a five-star rating on your podcast platform of choice and tell us the criteria you think about when considering whether you should build or buy.
Announcer: This has been a HumblePod production. Stay humble.