Ep#103 Developer Tools Designed to Make AWS Easy

November 15, 2022

Episode Summary

Uncomplicate AWS with the right Developer tools that are designed to help you leverage the breadth and depth of services that AWS provides. Isolated developer environments are easy to set up, configure, and share globally. Not to mention the importance of cloud cost optimization that automatically scans your AWS Account(s) to help you identify cost savings opportunities.

Sponsored by our friends at Veeam Software! Make sure to Click here and get the latest and greatest data protection platform for everything from containers to your cloud!

Stephen Barr - Headshot

About the Guest

I have a strong set of skills centered around data engineering and machine learning. As a machine learning engineer, I can manage full machine learning pipelines, from accessing databases, large-scale data manipulation, and feature engineering, to model training, deployment, and management. Key skills include the usage of AWS, Spark, and machine learning platforms.

#jonmyerpodcast #jonmyer #myermedia #podcast #podcasting

Are you looking to sponsor AWS re:invent from "Beyond the Expo"? Sponsorship opportunities are still available here!

If you're interested in learning more check out the AWS WAF Website.
Are you looking to attend AWS re:invent, more information here!

Episode Show Notes & Transcript

Guest: Stephen

One of the things that we talk about a lot is thinking about code being a liability. And so that's where we were so excited about AWS because they're writing and battle-testing all of this code that we don't have to. And in the DevGraph side, we're focusing on developer tooling based on AWS as the platform. So thinking about AWS, you know that they've done that all over the entire computing space. And so we think this is the platform that we want to build on, and so we just want to make that easier to use. We've got CloudFix and at one point we had 40,000 different AWS accounts. And so we had to write some automation and tools to keep costs under control. Our long-run goal think about is wanna be the car talk of AWS where people can just ask questions and we can think, Okay, what's your particular setup? And be able to just give advice that is backed by a lot of hardware experience.

Host: Jon

Please join me in welcoming Stephen Barr, chief evangelist at DevGraph to show Stephen, thank you so much for joining me.

Guest: Stephen

Oh, thank you Jon for having me. Happy to be here.

Host: Jon

Stephen, we got connected through a mutual friend and we started talking about DevGraph and what you guys do, and what you're trying to do throughout the community. Let's first talk about you and then let's dive into DevGraph. Who is Stephen?

Guest: Stephen

All right, well let's see. I am the oldest of five kids. Let's see. My parents, Jeff, and Carmen Let's see, I'm married. I have four beautiful kids. Let's see, I've been in tech for as long as I can remember, and yeah, really enthusiastic about just technology, what it can take us, and the promise of it. My first exposure to science fiction was Arthur C. Clark and my dad's collection o, I started with the 2001 Space Odyssey. He kind of read as much as I could about Arthur C. Clark and just got me so excited about what technology can do, and where it can go.

Host: Jon

I like it. I also like the Lego collection back there.

Guest: Stephen

Oh, thanks. I told you earlier, we used to have the original Lego monorail and that was my favorite set. I enjoyed that one. I, that one has vanished throughout the garage sales of history, but I hope someone's enjoying it somewhere.

Host: Jon

<laugh>, are you sure it vanished or it just isn't hidden? One day it'll come back to you.

Guest: Stephen

I hope I've seen these YouTube videos where people will buy their dad's favorite long-lost car that he sold to propose. I think maybe that'll show up with the monorail.

Host: Jon

Is anybody out there watching this video? If you happen to have bought the monorail from one of the garage sales that happened with Jeff and Carmen, or maybe Stephen was around, and he didn't know it. Please give him a shout-out. He has a little nostalgic for it and he would like to see it again. Maybe

Guest: Stephen

Think Potomac Maryland circa 1992. <laugh>.

Host: Jon

<laugh>. Now that's a good location part <laugh>. Stephen let's dive into it. What is DevGraph?

Guest: Stephen

Let's see, what is DevGraph? Okay, so DevGraph is part of a larger family of companies, a larger company called ESW Capital, and we have DevGraph, we have Aria, we have Dev factory. And those companies that have been about, what they do is they acquire or build other technology companies and then, how do you say, they make them more efficient, more operational, and then package them up into, depending on the client base. So DevGraph, we're focusing on developer tooling. We have the Aria brand, which is all about enterprise IT and cloud adoption. So yeah, on the DevGraph side, we're focusing on developer tooling based on AWS as the platform.

Host: Jon

It’s more geared towards IT and then DevGraph is geared towards a developer and the tooling. When you say developer and tooling, can you be a little more specific? What type of tooling are you talking about?

Guest: Stephen

One that we have called DevSpaces, and is a cloud-based IDE. It will run on the AWS graviton. It's based on GitPod and also it runs vs code. You can go to a GIT repository, click on DevSpaces and it'll launch a web-based development environment from that exact point in your repository say if you're on a certain branch, you just click the DevSpaces button on that branch and it will launch a fresh development environment for you. I think the cool thing is it's isolated from everything else on your system. So instead of trying to manage Docker containers and different bash scripts with different environment variables to set up, okay, I'm working at Dev, or I'm working in prod, or I'm working at tests, you could have that isolated for you that all of the, I guess the ergonomics of doing it without DevSpaces become a bit cumbersome.

Host: Jon

I imagine you'd have to set up your environment, your isolation, and your configuration with DevSpaces. It's more of a virtual but global collaboration environment allowing you to test and play around. Walk me through the process of getting started with DevSpaces. I click the button and it launches in my AWS account. What launches within your environment? How does that work?

Guest: Stephen

Okay, so DevSpaces is hosted on AWS, and the way that you would see it is just as a SaaS platform, but it's good to know that it's running in a US-based AWS region. What I like about that now, is I used to live in rural Australia, We didn't have the best internet connection. So when I was using DevSpaces and say you're doing you launch this development environment, it's running in the cloud and you do an NPM build, right? Well, without that, all of those packages are coming from your internet connection, which can be quite limited especially over there to be able to do that all within AWS and then running on AWS hardware. So, sorry, that was a bit roundabout way of saying it. So you hit the DevSpaces button, it will clone your repository, and it will launch a fresh development environment.

Guest: Stephen

It will start up a web-based VS code and it'll hand you back a web-based vs code in a couple of seconds. And that has your code right there. You have to authorize it with GitHub because you could read you, So it could read your repositories. And you can also set it up to have environment variables built in like your AWS keys. I have different projects in GitHub that have different AWS credentials associated with them. And I know that when I launched that dev space, I know exactly what credentials it was launching with. I know what environment variable it has access to It can't have other, if I'm switching back and forth, doing lots of different projects. It can be very easy to not switch your AWS keys and deploy something into the wrong place. Why can't I see this S3 bucket? Oh, wait, in the wrong context. I

Host: Jon

Didn't specify the profile I'm supposed to use because I was incorrectly in it. I forgot all about it. Throughout the command, I can see that it can be cumbersome and not understanding where you deploy things out <affirmative>.

Guest: Stephen

And then also just not having to manage Docker. Docker would be one way of doing this where you can encapsulate all your dependencies into one place, but then get every developer on board with that, Sometimes it works, sometimes it doesn't. But this will do all of that behind the scenes. So it'll be based on Docker and Kubernetes, but it's all, you start DevSpaces and you're actually inside of a Docker container running on a Kubernetes cluster, but you're not worried about all of that. Mechanics, you could just focus on the project at hand. I guess one example, use case, we've had customers whom they want, they have the whole project to monorepo and they've got maybe an older version of Ruby and they've got one, a lot of different dependencies and they have this whole onboarding process that can be difficult to get set up. And maybe they just want to bring in say, a contract to the designer to modify some CSS. Well, talking them through, okay, how do you get everything set up so you can test their website locally? That can be an honors process. So being able to just say click this button and it's all set up and then they can iterate on it on their own. That's powerful

Host: Jon

Actually. That's cool how quickly you can get set up and deployed. Because if you think about a developer who's coming in, you want, you're hiring a contractor or somebody else and you bring them in and you say, Right, listen, here's what I want to do now it's gonna take 'em two weeks, three weeks just to get set up, get their laptop set up, get everything configured. By the time you onboard 'em, you couldn't have done the work yourself or at least 10 or moose some things around. Now you made it as easy as a click of a button to deploy everything, including all the dependencies, but with the speed and agility utilizing AWS and within the US region, but you're not doing it locally. They can be globally, but everything's doing it locally within us So now you're pulling everything down rather quickly.

Guest: Stephen

Well, you nailed it in terms of that tension inside. I could do this myself and do I want to spend all this time? And that's a dangerous way of thinking because you have to learn how to delegate. That's an important, important skill. But then it's easy to, if there's a huge, fixed cost associated with bringing other people, you're just not gonna do it. So being able to just say, here you go. You click on this button and you're in the repository and you have all the startup scripts and everything's just ready to go. It's really useful. And also just in terms of architecture. So we run on, as I said, we run on x86 or ARM. And that way you don't have to deal with who has access to what. If your developers happen to have a Linux think pad, they're not gonna be able to test arm-specific things.

Guest: Stephen

And then vice versa. A lot of developers have M one max. They won't be able to test 86 things. Funny, it reminds me of, there's one place where I worked a while ago and we spent a bit of time fixing a max-specific bug and it had nothing to do with it, Yeah, we didn't have any max in production. We were also deploying to Amazon Linux too, but it affected the development and enough people had to deal with it. We had to spend time fixing it. And so it's things like that where we don't want to have to be dealing with that.

Host: Jon

It's kind of really made it hardware agnostic. And you're running on either x86 or the ARM technology graviton. Why Graviton or ARM?

Guest: Stephen

We were big proponents of the graviton. Well, it's cheaper. Yeah, it's cheaper. AWS designs Silicon from a power perspective, it's really neat. They run a lot cooler arm-based chips or that's why your iPhone can have great battery life and not burn a hole in your pocket because it doesn't take as much power. So that graviton is AWS design silicon. They've rolled, they're rolling it out quite extensively too, excuse me, all their different regions and we believe in it for most applications. And also Graviton is running a lot of the managed services. Like there's graviton-based RDS and elastic cash. So if you're using a managed service, you really shouldn't care what the underlying architecture should be abstracted away from you.

Host: Jon

This is, you're shifting left utilizing AWS Managed Services, and I hate to use the term, but it's taken the heavy footprint off of you and the burden of managing the environment and just utilizing the available services. How are you making AWS easy?

Guest: Stephen

Well, I guess, okay, that's a lot there. So I'll start with

Host: Jon

It's a loaded question. I know you have so much of anything, but I wanted to, we're gonna get into so much to talk about. That's why I asked for it

Guest: Stephen

<laugh>. Okay, cool. Okay. Well, I guess saying with the development environment for a while, so we don't have to worry about matching your dev environment and your pro-environment. So you're probably deploying to AWS, but then dealing with the difference between, I hope my laptop personal environment matches the environment I'm going to deploy to. But that's a lot of room for error in that. I mean, I think our stacks are getting so enormously big and there's just a difference when a lot of people work on Mac OS or Windows or their flavor of Linux that they're using. It's probably different than where you're deploying to. So if you're deploying to AWS, you might as well work on an environment that's as close to that as you can. And so spaces help you work in an environment that's a lot more similar to your production environment.

Guest: Stephen

So that's way, another way we make AWS easier. We're working on another product called Dev Flows, which is a more no-code, low-code solution for wiring things together. You could have an S3 bucket and say you want to drag that into recognition and say, okay, when a file shows up in this S3 bucket and it has an MP4 extension and drops it into recognition and then take the output of that, filter it and maybe create a ticket in Jira or something like that. So we're making that, that's still in progress and that will go through the Arya brand. And then also we've got our AWS made easy live stream where we just, Raoul and I, we sit and talk about AWS latest announcements and try and just sort through it all. Cause there's so much, and it takes a lot of time to figure out, well, what's relevant, what's important, what should I take from this? And we want it to be a resource, I think. Do you remember the audio show? Car Talk <affirmative>? Yep. I think our long-run goal, as I think about it, I wanna be the car talk of AWS where people can just ask questions and we can think, Okay, what's your particular setup? And be able to just give advice that is backed by a lot of hard work experience.

Host: Jon

I like that. Let's talk about flow and then I wanna talk about what you guys are doing with regards to AWS and how they're releasing and how to filter through some of that data. So with the flow, it sounds like more of maybe a pipeline or rule set or a step function to do certain actions, or is there more to it? How does it work?

Guest: Stephen

Well, I guess one way of comparing it, is that it has a graphical interface and you can drag on these adapters that represent AWS services. And you can think of it as a directed acyclic graph. That's kinda the data model where you have something that will trigger it like an S3 bucket or you can set up a webhook to trigger it, and then you drag and drop these icons that represent different AWS services. And then the links between the icons, the edges, you have an opportunity to do data transforms and also filters. And then we will take care of turning that into deployment on AWS. And so the idea is for teams who may not be comfortable writing a big cloud formation template and writing all the code themselves, here's one way of connecting all these pieces, but it's not a black box. You can see all the different pieces which AWS accounts they're going into. There are no proprietary hidden services under the hood. We're just helping you connect things that are already there.

Host: Jon

Okay, wait, Stephen, we gotta talk after this show. I just had this idea because right now I take a lot of my podcasts and I will convert them to transcripts. I would love to do some drag and drop to me. I don't wanna have to write new code to do things and how transcribe it. I would love to just drop the file, write into S3 and kind of tie everything together, go transcribe, and then it's back into the s3. And this is no code that I had to put together. It's almost like a zapper-type thing. By the way. Zapier's not a sponsor, but I just wanna kind of flow through it, is that you're moving things around and you don't have to write code to it.

Guest: Stephen

So that's the exact That's a great analogy. And I like Zapier a lot and we think about it as that, but with its AWS native.

Host: Jon

Yeah, I think that is awesome. By the way, what you guys are trying to do, I gotta test this out. I know you're still working on it, but I have some ideas for some things that I am doing as not only a podcaster but daily and using AWS, some cost things you can do based on certain functions.

Guest: Stephen

Well definitely we, we'll talk about that. So one of the things that I've got going for our Livestream, is we have a flow that when, and I've tested this out with both the dev flow and just writing it out in code based on a Lambda function. But when we get the transcript and that transcript goes into an S3 bucket, we'll then, okay, run comprehend on it, get the tags, extract the tags that are entities, and then match them up to AWS entities. So now when we go through a show, we know all the different AWS entities that we talked about in that show. And then later I could say, Wow, give me all the episodes where we talked about Dynamo DV

Host: Jon

And I like that. Oh my god. So I can see that in utilizing it and picking out all the AWS services. And now you can filter these off of your website or a library of stuff and like, okay, here are all the tags associated with that service. I wanna learn more. You know what, you should go to DevGraph and take a look and just run this. And now you'll be able to pull out all the information on where the talks they had.

Guest: Stephen

Yeah, I'll have that in the public pretty soon. I'm working on a Livestream automation repository that shows a lot of the different services that we use. We use Comprehend, we use, the other thing that we do with our Livestream is, so when we're planning out the segments, I say, Okay, we're gonna talk about five or six different articles from AWS. Well, I want to generate a little transition video. And so I use this non-AWS API and it can take our generic transition video. It's like an eight-second little jingle and an animation of Raoul and me, and it will inject the title of the article that we wanna talk about. It'll inject it right into that video. And then I have that queued up then. So it's time to talk about that video. I queue that transition, and then within that video, there are a few seconds of no audio and no video and recognition, segment detection API will pick that up. And then later when I drop the final recording into my S3 bucket, it'll trigger some automation which will say, Hey, here's all the time markers of the different segments you talked about, because I found that was time-consuming, but why should I go through when AWS has recognition segment detection? They could do that for me.

Host: Jon

Okay, I'm gonna have to play around with that. I do a lot of that myself.

Guest: Stephen

Well, I found it to be so, well, I guess, what do you call it? Programmers are fundamentally lazy, right? So I thought, I don't enjoy this part of it where I'm going back through and trying to figure out when did we switch from this article to that article? And so now it's all automated where we use segment recognition detection to tell us, okay, when did we switch from this context to that context? And then that will create a bunch of tasks in my task list. Okay, here are all the different highlights that I want to then promote over the coming week.

Host: Jon

Well, Stephen, I wanna jump over to what you're doing around the live streams for AWS and kind of pick things out with a. How are you deciding what to talk about AWS releases so much daily, How do you filter through all the noise of what's relevant and what's not?

Guest: Stephen

Well, I guess that a lot of that comes down to, well, we'll meet before the show and we'll look at all of the different announcements that have happened since the last show. And really, I guess it comes down to experience plus personal interest in terms of, okay, what's the most relevant to a general audience? Sometimes features that will come out, which will only be relevant to a smaller audience. We'll try to pick features that are more generally relevant. And I guess also personal interest. If there's something that comes up about graviton, we're gonna talk about that.

Host: Jon

Are you gonna talk about, oh, grab time was released in this region, that region, or more specifically to enhancements to graviton or a new release or upgrade to it?

Guest: Stephen

Well, it's funny, sometimes

Host: Jon

You have how to pick that out because regions are always announced for new services being released.

Guest: Stephen

Well, I guess sometimes we'll take one of those announcements and say, Okay, this is a, we'll spend about 20% of the time talking about the actual thing, right? Oh yeah, Sao Paulo just got access to this new version of this. Okay, great. Let's talk about the broader context. This is exciting. This thing is growing. We like this. And we'll have a more general discussion for a few minutes and then we'll loop back around and we'll say, Okay, what do we think of this article? And one of the ways we kind of rate the discussions at the end. So we'll give it a five, clouds out, a five or three and a half clouds out of five, and we'll also say, Does this add simplicity or complexity to your life? And so we'll give it a simplicity or complexity tag,

Host: Jon

Wait, you do that life for each of the topics that you do like out of cloud <laugh>. Nice. I was watching one of your live streams on LinkedIn the other day, but I never got to the cloud thing. I was off on another tangent I was commenting on, I'm not sure if it was part of that or not.

Guest: Stephen

Well, that was more of an interview. So when we do interviews sometimes we don't do that as much. So we have two different types of segments. One of them, we call “What's New to Review”, where we're talking about new articles. And then sometimes we interview, In this case, we were interviewing Marcos Ortiz, who just started the Graviton Weekly newsletter. So we just had a more general graviton chat with him. But we did review one article together

Guest: Stephen

He gave it a five, clouds out a five, which Raul is more conservative with his rankings. I'm kind of in the middle

Host: Jon

<laugh>,

Guest: Stephen

But we were all happy about that one.

Host: Jon

You know what, I'm gonna watch that. I'm gonna have to give you a shout-out for the clouds. I like that idea. Little do you pop up little clouds?

Guest: Stephen

We do. We have a little overlay in the stream yard. And so once we come to a discussion, I'll push the button for that little overlay and we'll, it'll pop up on the bottom.

Host: Jon

You should have between the two of you heat pops up, yours, you pop up yours. And it's a discussion like, All right, why did you give it as you holding up the number?

Guest: Stephen

Exactly. And usually what will hurt an article is if they don't have any examples. We always like good examples or screenshots

Host: Jon

<affirmative>.

Guest: Stephen

But that's fun, I guess it anchors the discussion in terms of what we like, and we like things that are simple and relevant, and easy to use.

Host: Jon

Stephen, what else are you doing around Live-Streams? You have a YouTube channel. For those who don't, or are not aware of it, check 'em out on YouTube. You can just type into YouTube and search DevGraph, and you'll find it. His episodes are growing, and the number is increasing, You're doing a great job. I mean, first of all, I love the thumbnails. I'm a big proponent of having fun during a podcast or a live stream, and the thumbnail has to kind of go in with it.

Guest: Stephen

The ones that I like the most. We just started a dev space's hackathon series and of giving that a real kind of cyberpunk vibe. And to check out the intro to that, I like that my designer, Alex, she's good at putting these together, but we have this kind of cyberpunk car and how it's driving in that driving into the distance with the neon grid and it avoiding Kubernetes and avoiding Docker and avoiding local installs that it zooms into the distance with triumphant DevSpaces with the cool eighties cyberpunk music in the background. So I like that.

Host: Jon

<laugh>. Well, a good shout out to, I'll share everybody a link in the description below. Sure. Stephen, talk to me a little bit more about the graph and some of the things you're doing. I know you have something called CodeFix. What's that about?

Guest: Stephen

codex, we're still incubating that, but the idea is for large code bases, we can pull in an enormous amount of code and every function in every commit over time. And then we can do some kind of semantic analysis on it to see where are hotspots in the code, where are things changing what are kind of seams in the code where you'd want to perhaps replace a native service with a managed service, that sort of thing. And that's still pretty early on, but we should update that with more context. But that's coming. And the folks over on the Trilogy University side of the organization, this is all the young folks there who are doing some incredible things, coming up with new ideas and implementing them in this platform.

Host: Jon

With CodeFix, is there an idea of seeing repeatable code and then making it more of a function and minimizing the number of lines in the code, inserting variables when needed suggestions, Is it doing to work for you or just suggesting it?

Guest: Stephen

I think it's just suggesting, but then again, this is still in development in terms of what it'll end up being in its final form. And it's, these things evolve over time and with new ideas and new people looking at it and thinking, Okay, I've got an idea. They're very open to adding new things and trying them out. So when it comes out in its final form, I'm not sure what it'll look like, but I'm excited about it.

Host: Jon

I like that. Stephen, what is your long-term goal for Graph? I know you wanna be to the go-to like you know, AWS person to having a talk show. I think that's admiral to sit down and discuss all those things. But what's your long-term goal for DevGraph and community, involvement?

Guest: Stephen

Well, I guess zooming out, we like AWS as the platform or the operating system of the future. Just almost getting a little bit nostalgic, thinking about the computing we used to do where you're thinking about very low-level things. And I remember my first job, I was working at an email hosting company when I was a teenager, and it was just me and a good mentor of mine who'd retired from Microsoft and was in his mid-thirties, and he started his email hosting company and he said, You need to learn about networking and you have to learn about And so at that point, it was Linux 2.2 kernel when IP chains and at one and my 15-year-old self knew that stuff in and out. But now thinking about it was so complicated and convoluted and not thinking about what you can do with security great would take what you used to spend weeks trying to figure out what you can do in a few minutes with a few clicks.

Guest: Stephen

Thinking about AWS, you know that they've done that all over the entire computing space. And so we think this is the platform that we want to build on. And so we just want to make that easier to use for people and to offer tools that can make it easier. Like I said, on the software development side, that's DevSpaces or dev flows as that matures to be able to do low code cloud native cloud-native deployments and also just offer opinionated guidance and advice. It's the larger organization that's dealt with so much code, both new code bases and also older code bases through acquisition or just over time. I think at one point they had 40,000 AWS accounts under management. And so they've written a lot of automation of how to handle that, how to understand that, and how to comprehend that. And so just being able to offer advice perspective and for our enterprise customers working on cloud integration, how do they even get started? What's the right technology to look at? Should they jump right into serverless to be able to offer some advice that's been, I guess, matured over a lot of time working in the cloud?

Host: Jon

When I got started, was it a lot easier because it had a limited number of services? Now it's like 210 plus and understanding those, but you truly are making it easier for developers and engineers to get their hands on and utilize it and understand it better because there's so much involved. This is kind of simplifying the process.

Guest: Stephen

Yeah, a big part of it is just having that perspective. I used to be in academia and when I was an undergrad, I was asking one of my professors, and I said, How do I know if this paper is good or not? And he said, Well when you know that you are a professor, that's how that, I think about that with AWS. And not to say that we're professors of AWS, but being able to look at everything that's happening and then say, What path should I take? Where am I in my cloud journey and what path should I take that takes some experience and some time? And then DevGraph and then the larger organization, they've had a lot of experience with companies all through their process and can offer hopefully useful advice and good tooling to make it easier to be in the cloud.

Host: Jon

There's a quote that Warner Vos always says, and I'll probably butcher it, but it's somewhere along the, there's no shortcut or compression algorithm for experience and the experience that you guys are, and I probably butchered it, but sorry, Warner. But that's really what you're coming in with. And I think the experience of you working not only at a young age on the mail server and to everything you've done kind of helps you throughout the process of simplifying it for folks. I mean, don't you feel that that knowledge has helped you today?

Guest: Stephen

I have lots of fun stories you could share just about things that have gone right, and things that have gone wrong, and those help to understand it, kind of clarify your purpose and your process. Yeah, I'm happy to share any of those. Yeah,

Host: Jon

Actually, why don't you share one of the stories and you can pick one that didn't go right and what lead you to the right path or solution?

Guest: Stephen

All right. Okay. And I'm withholding names, but this is a long time ago now, but I was working with a very traditional company, and I guess the part of the story is about how you find trusted expertise. And so I was working with this very traditional company and they had this machine learning model that was supposed to predict certain customer needs so they can preemptively fill those needs. It was kind of a hardware and consumable combination. And this organization had purchased this extremely expensive machine learning product, and they had tasked someone with implementing it. And somehow there was this communication breakdown in this process and the person who was supposed to implement it, couldn't figure out that the infrastructure wasn't set up for them to implement it, and their complaints weren't being heard. So they ended up kind of writing their machine learning model, but they wrote it in a way that was a pile of about 1200 stored procedures in SQL because the only tool this person had at their disposal was SQL.

Guest: Stephen

And the greater organization couldn't grasp the fact that he needed access to things that were outside of SQL. So at some point, he just threw up his hands and said, Okay, I'm gonna write this giant pile of stored procedures to implement this machine learning model. And he did. And I was brought in to calibrate the model and tune the model. And it turns out they weren't using that expensive product at all. They were just using this guy's giant stack of store procedures and no one knew about it. And so I guess the point is they didn't have trusted expertise and they didn't have great communication. So it led to this really strange situation were this expensive software they thought they were using, they weren't even using it. And when their database started getting slower and slower and slower, they didn't understand. And I was digging in there as a young consultant trying to figure out, I had to, I'd have some strange phone calls after that one.

Host: Jon

I can imagine the phone call, Yeah, I came to tune the system. It's not being used. It's still brand new out of the box

Guest: Stephen

<laugh>. Yeah, it was a strange one. But I guess what I appreciated in that perspective was it was hard for them to access advice that was useful to them and they didn't know how to screen for it. And so I guess being able to say, Okay, we got a lot of experience with AWS demonstrable experience and we can give you good advice and good guidance and good tooling so you don't go down this garden path, then later will take a lot of work to get out of.

Host: Jon

DevGraph, “AWS trusted developers”, “developers for AWS trusted”, I think I'm trying to come up with a new slogan for you. I think the way you come across, I think you genuinely want to help folks within their environments, within the developers, and create something that makes it easier for them and listen to them, really being customer obsessed. And that's one of AWS's core values and you're following suit with that and creating and working with customers and making things easy for 'em.

Guest: Stephen

Yeah, that's a great summary. We want to make it just make it easier for people to use AWS to build on it. I, I think it's the coolest thing, right? Thinking about it, this sounded kind of funny, but when I think about science fiction and I see some robot who's looking at the world and say, Are they running recognition v3? Is that what's happening in there? You start to think at some point our reality gonna catch up to what we're seeing on this screen and there's gonna be code and functions that are gonna have to make that possible. And maybe we're seeing the beginnings of them right now.

Host: Jon

We are part of it. Yep. No, you guys are a big part of something huge. Stephen, before we wrap things up, is there anything else you'd like to talk about around DevGraph or leave the audience with?

Guest: Stephen

Well, we've got CloudFix and that's exciting about CloudFix. That's, as I said earlier, the organization had at one point 40,000 different AWS accounts. And so we had to write some automation and tools to keep costs under control. We developed CloudFix and the idea is, okay, what are some very simple no impact, and can be deployed to save money? And it's not CloudFix will never say, Oh yeah, re-architect the whole thing. They're saying things like, Switch your EBS volumes from GT two to GT three. There's no reason why you wouldn't want to do that. That's just essentially an arbitrage in terms of cost savings, but it's not the default path. CloudFix can scan your AWS account, we know a bunch of things to look for and then it'll generate a change manager change set for you and say, Okay, here's the change that we think you should do. This is how much we're gonna think, this is how much it'll save you if you do this. Do you wanna click this button and go for it and you can review it And then if you want to, it'll start saving you money.

Host: Jon

I was hoping you'd talk about CloudFix because I was a PSA for cloud management tools at AWS and cost optimization is one of my key things. I kind of geared towards it. In all the things that you're able to do, impossible, going G two to G three to me seems like a no-brainer. I mean it's not only fast or cheaper, but it's just one of the things IO one to I two, there's like just so many things and possibilities that you can do CloudFix. Here's a question for you. CloudFix, can IT scan? And you mentioned they have, 40,000 AWS accounts I want. Can CloudFix all my accounts?

Guest: Stephen

Yeah, you can give it there. There's advice and the kind of credentials give, we'll give a read-only type of credential that won't go in there and change things for you, but it'll generate a change set for you that then you can then look at and say, Okay, do I want to deploy this change? And then you can and it will save you money.

Host: Jon

Talk to me about some of the other capabilities of CloudFix. What are some of the other things that it looks for and how does it come up with, these are manual implementations where you say, I wanna look at one of right-sizing, or this is one thing I wanna look at optimizing my Lambda function.

Guest: Stephen

It will look at certain VPC configurations. And again, I'm not understanding the exact details of this particular part, but there are certain situations where data transfers can be enormously expensive and it can say, Hey, it can alert you to these things and say this is a different way to configure it where you won't accumulate this type of charge.

Host: Jon

Data transfers are huge in a hidden cost for a lot of folks because they can't visually see that or predict it. You can't go to the AWS cost calculator and say, Hmm, let's predict my data transfer cost is gonna happen because your data's gonna grow as quickly as possible. But visualizing it using CloudFix will help you understand where a lot of your cost is going to be, and maybe you can change some of your configurations to optimize the data transfer between VPCs or stay isolated within your AWS account.

Guest: Stephen

Yeah, yeah, exactly. And can, So the people who are making CloudFix, what they do is they're always reading the AWS trusted the advisories and they're looking for, okay, how do we automate finding this? And then how do we automate generating a change set to implement that? And so we're growing that library all the time and we have every incentive to do that.

Host: Jon

Nice. I like the AWS cost portion of it, and I think that's key to being a developer because as a developer you're not focusing on the cost in general. And now this does go into DevOps or cost DevOps, however you wanna kind of put it into a perspective. But looking at visualizing the cost that you're doing per environment and what you're deploying is key where you're working bottom up and the financial person's not coming to you and say, Hey listen, I need to minimize cost. Now you're working in an operational model, not a CapEx model.

Guest: Stephen

Yeah, yeah, exactly. And just zooming out, we're excited about all the things you can build on AWS, but that doesn't happen if you run outta money. So being able to

Host: Jon

<laugh> a good way to put it,

Guest: Stephen

Right? And so we're not gonna be the ones who solve, I don't know all, any one of the numbers of crises that we're facing, but Code's gonna solve that. And we wanna make sure that those people's code can stay running and that those businesses can stay running so that they can do the good things that they're doing. Yeah. Okay. So I guess the name CloudFix is the one that's doing the cost scanning. CodeFix will be looking at actual code bases and that will be coming out. That's still in the experimental phase.

Host: Jon

Yep. That's awesome. So I was thinking about, Go ahead.

Guest: Stephen

I guess one thing that I was thinking about when I was thinking about okay, DevSpaces, was looking at the state of the OC report, the GitHub puts out, and it all comes down to code bases that can quickly merge. Poor requests are the ones that evolve successfully. And so by being able to switch development environments and switch context quickly, that's where you iterate quickly. And so that's where we see spaces fitting in is say if you have to look at a request that changes some dependency and you're hesitant to do that on your local machine because you just got things set up, you finally got virtual M doing what you wanted to and someone says, Hey, on this branch I've changed, I'm working on a changeover from say my Postgres and on this branch, and this happened to me once where I was doing two different code reviews and they were the same code base but branching in two different ways.

Guest: Stephen

I wish I had access to DevSpaces at that time because I could just keep them separate. They're just different browser tabs. I don't have to deal with how I look at the same code base twice on the same machines, but with totally different dependencies kind of underlying them. It felt like a bit of a Rube Goldberg, so I didn't want to be, I'm glad that that's all automated away now. Just start up one tab for this branch, one tab for this branch, and that's all you have to worry about.

Host: Jon

Sounds like your speed to development is going to market for a lot of things where you're deploying it, testing it out, and now you can see kind of a blue-green type model.

Guest: Stephen

And even things like experimenting on graviton. So you can say if you X 86, you could just fire up your code on our Graviton environment and just see if it works. It's not this big difficult thing where you have to spin up an instance by hand and then set up your keys so it has access to your code. You could just try it.

Host: Jon

Nice. I like it. And it kind of simplifies the process. You're not worrying about the underlying infrastructure.

Guest: Stephen

Yeah.

Host: Jon

Nice. Stephen before I wrap it up, is ais anything else you wanna leave with the folks?

Guest: Stephen

I guess one of the things that we talk about a lot is thinking about code being a liability. And so that's where we were so excited about AWS because they're writing and battle-testing all of this code that we don't have to. And so I remember one of my colleagues, he just bought a new Mercedes and he was repeating one of the talking points from the salespeople. He said, There are 18 million lines of code in this car with him. And in my head as a developer, Oh that's a

Guest: Stephen

Go wrong. Yeah, no. And our at the time was completely mechanical. And there's an interesting story over in the Seattle area, there's a certain year of Mazda, I think it's 2014 to 2017, where the local NPR station broadcasts some metadata. But there's something wrong in the metadata parser of the infotainment systems of Mazdas of this year where they can get bricked over the air just, and it's probably some stupid file name parser of the image of the radio station's logo. And just for this brand of this one brand of car and this code that's locked away and can't be replaced and can't be modified. And whoever wrote that, if they had access to some more general string parsing library that was written and battle-tested at 10,000 times the scale, maybe they wouldn't have run into that problem. Cause zooming out, we see AWS as they're doing all of the core utility code that's just annoying to write, annoying to rewrite of putting up API endpoints and securing them and getting data into this place and out of this place. That code's been written a lot of times, but letting AWS do it and then you can just know what's out there and build on it and you can just do things so much faster.

Host: Jon

You can focus on the outcome or the business application because AWS is handling the managed side of it and already doing a lot of that heavy lifting.

Guest: Stephen

Yeah, yeah, exactly. We don't have to think about scaling. And even some of these higher level things like recognition I've built, tried to build image processing things in my machine learning classes and they're really hard to do well, but thinking, okay, recognition is a model that's been trained on more data than I'll ever have access to and validated on more data than I ever have access to. So just use that. Don't try and do it yourself and then focus on what can you do with recognition.

Host: Jon

Also, I did not know that that year could become a brick. I'm gonna make sure I don't purchase it. No, I'm just kidding.

Guest: Stephen

It's just the infotainment system and I guess it's just funny, Yeah, it's just one example of how this code, I don't know how code could be a liability, right? Because every code that you write lives longer than you think it will.

Guest: Stephen

So just we try to minimize the amount of code that gets written and lean on AWS as heavily. And usually, for a given business, the core value is in a really small amount of business logic that ties together things in a unique way. But then there's all these layers and layers and layers on top of it. And it's hard because it was built over a lot of periods. So you feel very attached to it. But at the end of the day, it's better to offload that to AWS and let them do that part. And you can focus on the core value part.

Host: Jon

I think it's a real-world use case on something that happened. Because then you can take that and if they took it and did what you recommend them to do ahead of time, the battle test, they won't have to worry about it. And these examples will be caught before actual production.

Guest: Stephen

Yeah, yeah, exactly.

Host: Jon

All right. Stephen, thank you so much for joining the show. I really, it's been a pleasure having you.

Guest: Stephen

Oh, thank you for having me. And yeah, really appreciate it. Looking forward to seeing you at Reinvent soon. Oh

Host: Jon

Wait, you know what? Before we wrap things up, I gotta shout out. We are gonna be at Reinvent. Stephen’s gonna be joining us in the hospitality suite that's happening, Livestream events, and podcasts. We're gonna be talking about CloudFix and some of all the benefits, but what AWS is releasing. Stephen, I can't wait to see you out there.

Guest: Stephen

Yeah, looking forward to seeing you, meeting you in person, and joining you in the hospitality suite. That's gonna be great.

Host: Jon

Yeah, it's gonna be lots of fun everybody. Stephen Barr, Chief evangelist at DevGraph. As always, my name's Jon Myer. Thank you for joining us. Don't forget to hit that subscribe and notify because guess what, we're outta here.

Comments are closed.