Screaming in the Cloud - Episode 58: The Cloud Is Great, But It Isn’t Perfect

Episode Date: May 1, 2019

About Richard BoydRichard is a Cloud Data Engineer with the iRobot Corporation’s Cloud Data Platform where he builds tools and services to support the world’s most beloved vacuum cleaner.  Before joining iRobot, Richard built discrete event simulators for Amazon’s automated fulfillment centers in Amazon Robotics, ensured your Alexa device had all the skills you could ever want on Amazon’s Alexa team, held test engineering lead roles at BAE, cyber warfare systems analyst roles at MIT, and research roles for the Center for Army Analysis.  He holds advanced degrees in Applied Mathematics & Statistics.Links Referencedhttps://aws.amazon.com/deepracer/https://aws.amazon.com/api-gatewayhttps://aws.amazon.com/lambda/https://aws.amazon.com/cloudformationhttps://twitter.com/cloudtrekau/status/936300151005626368https://twitter.com/rchrdbydhttp://rboyd.devhttps://richardhboyd.comhttps://linkedin.com/in/richard-h-boyd

Hello and welcome to Screaming in the Cloud with your host, cloud economist 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. This episode of Screaming in the Cloud is sponsored by O'Reilly's Velocity 2019 conference. To get ahead today, your organization needs to be cloud native. The 2019 Velocity program in San Jose from June 10th to 13th is going to cover a lot of topics we've already covered on previous episodes of this show, ranging from Kubernetes and site reliability engineering over to observability and performance. The idea here is to help you stay

on top of the rapidly changing landscape of this zany world called cloud. It's a great place to learn new skills, approaches, and of course, technologies. But what's also great about almost any conference is going to be the hallway track. Catch up with people who are solving interesting problems, trade stories, learn from them, and ideally learn a little bit more than you knew going into it. There are going to be some great guests, including at least a few people

who've been previously on this podcast, including Liz Fong-Jones and several more. Listeners to this podcast can get 20% off of most passes with the code CLOUD20. That's C-L-O-U-D-2-0 during registration. To sign up, go to velocityconf.com slash cloud. That's velocityconf.com slash cloud. Thank you to Velocity for sponsoring this podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by cloud data engineer Richard Boyd of iRobot. Welcome to the show, Richard.

Thanks for having me. It's sort of fascinating to be able to talk to you because for the longest time, it felt like the only person that worked at iRobot was Ben Kehoe plus a whole bunch of robots. And the first time I met one of his co-workers, I figured, oh, fine, you can hire guest actors to come in and take care of it and stand there and stand in for people who actually work with me. But no, it's all robots all the way down. Fine, you can hire guest actors to come in and take care of it and stand in for people who actually work with me. But no, it's all robots all the way down.

But having spoken to you a couple of times now, I'm pretty sure that you're a real person who does work on computers. So what's it like to be the second employee? It feels great. And actually, Ben has been taking some Ventriloquist lessons. So it's entirely possible that it's still just Ben. He's an interesting one. There's no doubt about it. Had him on the show before, hoping to get him on again. But let's talk a little bit before we get into what you're doing these days about where you come from. To my understanding, you were at Amazon

previously working in Amazon Robotics. Yeah, so I was at Amazon Robotics. I was on the pod management team, which is a team that owns the inventory and the lifecycle of the pods that the robots in the warehouse drive around and bring to the associates. Specifically, we managed all the items that were on every pod. So we had a bunch of large databases that held all of the information about every item that was in every automated Amazon fulfillment center. at Amazon Fulfillment Center. What's interesting about iRobot is that invariably your architecture in some form or another winds up in a number of different AWS keynotes where it seems that you're trying to almost treat their services like Pokemon

and attempt to catch them all, where every service imaginable winds up on that board. And at some point, it almost looks like iRobot is not satisfied to wind up implementing all of the AWS and Amazon services. Now they're starting to implement Amazon employees, and you almost seem to be an example of that. You were in the robotics group, and now you're

at iRobot. Is there a lot of similarity between those? There is not. And that was actually something that came up when I told my previous manager that I would be pursuing a new opportunity, is that they started asking about the non-compete agreement. And after some back and forth, we realized that the only similarity between the two organizations is the word robot. One makes robots for internal industrial use. And as we all know, iRobot creates the world's most loved vacuum cleaner. Yeah, Roger, the head of the GM for RoboMaker at AWS was a previous guest on this show. And it's fascinating just listening to how different people

in different arenas of robotics tend to contextualize what they're doing. And we're starting to see it emerge in a bunch of different groups. We're seeing it come out of a lot of different companies out there. And I always felt like I was a little behind the curve on this space because I look at my life here in San Francisco and I don't see too many problems that a whole bunch of robots are likely to solve. Maybe that's because I have not a lot of square footage. But there is something to be said for the Roomba that runs around and cleans up after me is awesome. It terrorizes the dog. Double awesome.

But there's also serious uses for this. For example, helping gather things from a warehouse so there's less human toil involved. And there are terrifying things too, like self-driving cars, where the failure mode involves a bunch of people dying. And that also winds up having a whole, a bunch of eyebrow-raising questions.

And now you see the DeepRacer stuff coming out, where it's making effectively robotics accessible to a whole new generation of people who might otherwise not be involved with it in the same way. What's your take on that? Yeah, I keep coming back to this idea of the things that are very easy are still hard to automate with robotics. We don't have a robot that will go and like take out the garbage, take it out of the can and like you know remove the bag and and do that like a custodian would and you also don't have robots capable of operating at like very high levels there's no like ceo robot that you can buy but there's a lot of stuff in the

middle um where it's just like automated things that we've seen like decimated with automated processing that i think we're seeing that kind of like move into like the physical space whereas you used to have people who would be like middle layers in a company that would just process paper according to some rubric that was put out. That was first automated with software. And there was people who, if they were physically doing something that was still very monotonous, the physical equivalent of that, their job was safe. And I think that we're seeing robotics kind of encroached there in the physical world where automation and software encroached in like the intellectual property type world previously, like the late 90s, early 2000s. Something that I don't think I've discussed previously on this show is that I started my career doing very large scale email

systems administration. And it was fun. I enjoyed it because I have mental problems. But past a certain point, it becomes pretty clear about a year in that, huh, it's ballpark 2006, 2007. And it seems to me that there isn't going to be a bright future for that career trajectory where every company needs an email administrator. So I look around and start

trying to find something else that was going to have more staying power. And as it turns out, I picked configuration management. I bet on the wrong horse on that one. But the lesson that I picked up from this was that to some extent, there's always an evolve or die model where you have to wind up uplifting skill sets and learning new things and embracing a new world. And it always seems to me that there have been these widespread fears with every major technological revolution dating back to probably Gutenberg's invention of the printing press in 1437. And every time they have it, it hasn't really come out to anything significant. More jobs are invariably created than are lost.

And sure, if you take a look at the invention of the automobile, and there's an awful lot of people who are in the horse industry that needed to find other things to do. And if they were able to make the jump and retool, then they were set. And if they weren't, they eventually wound up forced out of the market. And how we handle that as a society is a largely separate issue. But from my perspective, I always thought that, oh, okay, this is what you need to know and need to learn to be able to learn new things and be effective in a world of computing. But now I look at people entering the workforce, and they didn't have to go through all of that.

And I think that forcing people to learn to use Microsoft DOS back and work your way forward from that evolutionary step is a giant waste of everyone's time because you don't need to know that. This, of course, sort of brings us around to the idea of serverless, which is something that you've been extremely vocal and passionate about. Yeah, and one thing I'd like to add to that is that I think the only thing that,

you hit the nail right on the head when you said that this problem's been around since Gutenberg, where new technology comes out, it runs the risk of eliminating the livelihoods of sectors of the economy. I think previously that rate of change was slower, so that even if you didn't adapt, your career would end. If you didn't adapt, it took so long that you would just retire, and then nobody would fill

your place like the person who would have filled your place would do something slightly different i think that we're seeing an acceleration and like a shortening of the timelines for when these things happen where someone might have to make that choice like several times throughout their career like i need to adapt otherwise i'm not going to have a job and i think like that acceleration is what's like making this problem unique from previous technological innovations. I don't think the cars went from no cars on the road to everyone having a car in 10 years or 15 years, like we're seeing with serverless eliminating jobs, systems administration and whatnot. And the question, too, becomes how widespread is this serverless paradigm?

And there are a few companies, iRobot is a notable example of this, that are very serverless forward. In a number of companies that don't have the same born-in-the-cloud mentality or don't have the willingness to embrace new technology at the same pace for a variety of reasons, some good, some not, it seems like serverless is still being adopted, but only in very specific use cases or in non-production capacities, or it's still viewed to some extent as a toy. And that's definitionally going to have to change. There's going to be a lot of growth in that space. The question becomes, I think, how quickly does the tide rise?

If you're a network engineer and you are 40 years old today, is there 25 years or so of runway in being a network engineer or not? If you're 22 years old and getting into network engineering, is that that same question applies and it may have a different answer. And of course, if you're 60 years old and getting into this, it's likely a different answer. Again, the question largely becomes as the tide rises and more of the iceberg gets submerged of things you don't have to care about to serve your business. What does that mean in the future? What is that? What is it?

What advice do we give people who are entering the workforce today? That's a very good question. Welcome to the podcast. You're now a thought leader. Yeah. I think that I see two main tracks. So I, what I've often described it,

I'm going to talk about this from an engineering perspective, just because I come from an engineering background, is that I've always described what I call the T-shaped engineer, someone who knows a little bit about a lot of things, and then this one area very, very deeply. And I think that that'll still happen in the future. So we'll need engineers who are broadly trained, but have a specialization.

And I think we'll see more people who are flexible in what that specialization is. So instead of being the thought leader for something for their entire career, someone might be a thought leader in that thing for part of their career, and then they'll go into something else as the tide changes. And they may not make as strong of contributions in there, not to say that their work is any less valuable, and maybe even a third or fourth time throughout their career they'll switch and the depth of that T in their T-shaped engineer

will go deeper, but that'll change throughout the course of their career. And I think going into their career and starting out with this flexibility saying, yes, this is what I'm doing, this is what I think I'm going to do for the rest of my career, but it's very likely that I won't be. And just being accepting of that new reality. The T-shaped engineer is something that we've spoken of at least once or twice on the podcast before. And I think one of the challenges there is figuring out what is that thing you go deep on. And I don't think you can be a systems administrator without being a little bit of a jack of all trades. But being deep in a specialized area is fascinating.

For me, it started off as email, then it was configuration management, then it turned into cloud somehow, and now I'd argue it is cloud billing. But there's going to be a time where everything changes. I think that most of us don't have a job that our grandchildren are likely to recognize when they enter the workforce,

and that can be a scary thing. And there are other folks who think that that's a wonderful opportunity. I think the answer is probably nuanced and it's a combination of both. I'm very cognizant of not wanting to drive people out of the industry. I don't want to automate everyone's job away.

I think that's awful. But I do think that we want to automate the boring parts of people's jobs. I think that we want to make sure that you don't need to have an email administrator to start a company in 2019. And I think we've gotten there by and large. What's fascinating to me about serverless is that the level of what you have to be aware of and what you have to do is almost completely vanishing. Yeah, and I think this was another similarity that I saw between iRobot and Amazon Robotics is that they both were focused on,

we're not eliminating jobs. We're not creating robots to eliminate jobs. We are, in the case of Amazon Robotics, eliminating the parts of the job that don't add value to either the associate or to the company, which is the walking. Walking and carrying stuff is very stressful on your knees, your hips, your ankles.

And inside of iRobot it's the no one wants to clean a dirty room or vacuum I think that this becomes like the mantra of like serverless is that this type of stuff frees you up to focus on like the things that you actually want to do and the things that like provide you value whether it's like intrinsic value of things that you enjoy doing or monetary value for the number of customers that your business is able to capture. One of the things that first brought you to my attention was a series of blog posts you wound up hosting. And I'll throw a link to one of them in the show notes

on your rboyd.dev personal blog. And the one that I really saw that resonated with me was called Mastering API Gateway in 105 Easy Steps. And I thought it was going to be a teardown of the terrible level of complexity and documentation on API Gateway. And I clicked that with an excited, oh, this is going to be good. And it was good, but it wasn't what I thought it was going to be. Why don't you tell us a little bit about what it was? Yeah. So getting into the genesis of what started this is that we have a bunch of data in an S3 bucket and we had Athena sitting on top of it that could do some queries on it, standard use case. And I needed a separate AWS account that we also control

to be able to execute queries on this. There's no cross-account access. So the canonical way of doing this is have API Gateway in front of a Lambda. The Lambda executes the query, takes the data back from Athena, and gives it back to API Gateway. And it felt like the manager who gets laid off in office space, where it's like,

I take the requirements from the engineers. I'm a people person. And I was like, we don't need the Lambda here. In the dropdown menu in API Gateway, it says Athena is an option. I can just click on this and it should just work. I hear from developer advocates from Amazon all the time saying how easy this is. And it'll free you up to do all the things you love doing that's not configuring API Gateway. So I try it. I spent a lot of time on it and it just doesn't work the way I would expect it to work. You are absolutely not alone in that. One of the biggest complaints I have about the evangelists and advocates at AWS is they consistently talk about how easy this stuff is. And spoiler,

the first time you do it, it is absolutely freaking not. And my first lambda function took me two weeks to get working because I'm a terrible developer. And the last one I wrote took me about 15 minutes because I don't write tests because I'm a terrible developer. But there's a heck of a learning curve the first time is nothing behaves quite the way you think it will. And I understand the message they're trying to get across of once you understand a few basic tenets of how this works it does speed development time but there's nothing more off-putting than trying to do something new and start experimenting with it and being told oh well actually it's very simple and then you have trouble with it so the unspoken assumption is oh i must be a mor I never knew. And that's not a great feeling for

anyone who's trying to learn something new. None of which, by the way, is easy. And this is one of those things I try to avoid when I'm showing someone how to use something, or if I'm writing a blog post, I try as much as I can to avoid like two words. One is, oh, that's easy. And the other one is the word just. Because it's never just X, right? It's just X is the only thing people care about. But when you say, like, oh, this is easy, the person, even if it is actually easy, it's easy for me doesn't mean it's easy for someone else.

And it can be very off-putting. And I think that it's a bit deceptive in API Gateway because even if you do understand a lot of their tricks, or I won't say their tricks, even if you do understand a lot of the ways these or I won't say their tricks, even if you do understand a lot of the ways these services tend to communicate with one another, or you understand the ways that information is passed between those two, the thing we keep coming back to with AWS is that their only thing they're consistent in is their level of inconsistency. And this example in API

Gateway is really highlighted. Anytime someone tells me that, oh, it's very easy. All you have to do is just. My immediate response is, okay, you are now assuming everything lives on a whiteboard vacuum. You have no real conception of the constraints that shape what currently is in place.

And you're not very subtly telling people who worked on this previously that they're kind of stupid. And that is just absolutely one of those unforgivable sins from my particular point of view. I do my best to call it out when I see it, but no one's born knowing this stuff

and implying otherwise is frankly terrible. And it strikes me as there's a chart that has like the valley of ignorance where like as someone's proficiency goes up, their perceived efficiency goes up much, or I'm sorry, let me start that over again. As someone's proficiency in a subject goes up, their perceived proficiency goes up much or uh i'm sorry let me start that over again as someone's proficiency in a subject goes up their perceived proficiency goes up like much faster and then like drops off once they realize that they don't know what they're doing so that's where i tend to put

people who say like oh it's super easy you just do x and it's like oh like this is your third week dealing with aws exactly and what's fascinating as well is the level of confidence you espouse does change how people shape you. And that's also very heavily driven by gender and race. And that is a terrible factor of our industry that I don't want to go too far into on this particular episode. There'll be an episode of that one of these days once I figure out the take I want to have on it. But as it turns out, and now a white guy opines on diversity is not generally something I want to dive into immediately. Back to the API gateway project that you have going on. It looks like you're attempting to integrate API gateway with everything that it can integrate with that isn't Lambda. Yes. And I'm trying to take it one step further than that

is I'd like to integrate it with everything that it can integrate with. It's not Lambda lambda as well as make it so that no one else has to go through what I went through yeah so what we are trying to do is make it so the pain that we experienced trying to integrate API gateway doesn't have to be experienced by other people because it'd be very easy for me to say okay here are all the steps you have to do to like learn what I learned which the person still has to do all this learning and just memorize all this with essentially useless information just to do what they want to do. So we were trying to make it so that your CloudFormation template looks just like a Bodo3 SDK call. So you can say, pick a service at random, we'll say Athena, right? So you can say,

Athena, like start query, and then you can look at the documentation and see what parameters that takes and supply those as like native CloudFormation, like YAML constructs in there. And you can go and you can reuse the same documentation that already exists for the REST API. You know what's required, you know what's not, you know what the shape of the objects that it requests are. So I'm working on creating a CloudFormation macro that does that transformation for you. So instead of teaching these people, okay, here's how you decipher the Rosetta Stone of API gateway to other services. Instead, I say, like, use this universal translator that you can wear on your comm badge. And then you don't have

to worry about speaking that language. I'll speak it for you. I think it's a laudable goal. And I think it's absolutely going to be transformative for a number of people. And I have to ask though, because I asked myself the same question from time to time, doesn't it feel slightly weird to effectively be doing what amounts to volunteer work for an almost trillion dollar company? Yes, it does feel weird like doing this

because there are times I was thinking like, Amazon could just do this. We have been in touch with the API Gateway and the CloudFormation teams for this. We've had several meetings with them. And they are picking up the lion's share of this work, like the hard part. The thing that I am building is only connecting some very small parts and creating essentially a rough outline of how I'd like to use this

as a developer. And then they are going and they're building the actual infrastructure behind that that makes that possible. So I won't be building like the whole widget like end to end. I'm just building like the facade on the front of it saying as a developer, like this would be the most zero friction way I could use your service. And this would make me love it more than I already do. And then they're building the stuff on the backside that makes that possible. I think you had mentioned a previous post that Amazon's very good at plumbing and terrible at painting. And so what I'm doing, I'm hoping to do the painting,

or at least like fill in the shape for the color by numbers so that they can do the painting, and then letting them do the plumbing on the other side. To be clear, that was someone else's analogy, not mine. I love it. And I'm probably going to steal it in the future and claim it as my own, but not yet. Yeah, and you're right. It's, it's one of those areas where, to some extent, the teams building these products and services feel almost like they're too close to the problems themselves. And they don't know what it's like to have no idea what this thing is, how it works, how to conceptualize it through a different lens. And that, I think, is one of the most valuable aspects of the larger AWS community. The other side of that, though, is to some extent, it almost feels like certain teams aren't able to get internal traction. So they start turning to the community to develop these things that, to be very direct, probably should come from the cloud providers themselves. And I'm seeing this from all of the major cloud providers except Oracle,

which to the best of my knowledge, does not have a community of which to speak. It's a bit of a held intention thing from my perspective. If a company that wasn't AWS came and asked me to do some of the things I do in the AWS ecosystem for them, I'd quote a price. And it always seems sort of weird to look at it from a perspective now. And how did we get here? The way I justify it to myself is that there is a set amount of pain that I have to pay every time I want to do something with CloudFormation and API Gateway, that if I could do this once like for everyone else, then I don't have to pay that in the future when I'm trying

to do this. And everyone else is also benefiting from that. So my saved time that I have in the future is how I compensate myself for the time that I spend on this. And that's a very good point. It tends to be something that resonates with people. Clearly, I think the, when I linked against this article in my newsletter, it was the most popular link that week. And that's kind of depressing to some extent because I worked super hard on some of the other links that wound up going into there. And I'm kidding, because it's great to see what resonates with the community and what doesn't. The challenge means that, I guess, what I see from that is that everyone is wondering about these things. Everyone is having weird questions raised

about how to address these things. And I don't know what that says about the current state of adoption. I don't have data on this. I have anecdata at best. And being able to take a look at this through a lens of understanding what people are doing, what the use cases look like, and how that winds up manifesting is fascinating to me.

And I'm grateful to have the opportunity to do it. But the more I do this and the more I see people, certain things resonating with folks that I didn't see coming, the more I realize that I don't have a complete view of this industry. And I'm almost positive that no one does. All we see are different glimpses across a wide spectrum of experience. Yeah. And I think that this goes to a previous comment you had made about how serverless is still treated as a toy or a sub-prod type problem

because people are still using the same API gateway to Lambda to the service that you actually want to use. And it's really weird that the same people who are advocating serverless lets you do the thing that you want to do, but by the way, you still have to own this Lambda function in the thing that you want to do. But by the way, you still have to own this lambda function in the middle that you actually don't want

just to do the thing that you want to do. I would expect these people to be much stronger advocates for why is it the commonly accepted approach to just stick this lambda in the middle to make this easier. That also seems to be in line with a tweet I saw a while back, and I'll throw it in the show notes as well, talking about how about how oh the only code we'll write in the future is business logic that's been promised and there was a list of five or six different times that had been promised previously and nothing ever quite got there but oh this time with serverless that's what it's going to turn

into and it feels like it's closer than anything else has been but at the same time it history rhymes there's a question as to whether or not we'll get there, or now it's just a whole other list of things that we have to care about. What I do see is a future where almost all code that gets written is front-end code, and the back-end is generally handled either via configuration

or via some sort of specific defined language that only does configuration rather than running infrastructure in most environments. And there's a whole bunch of on-prem folks and multi-cloud purists, who are wrong by the way, that this is somehow not going to work. But most people aren't trying to make a political statement with their environments. They're trying to get a larger business done. They're trying to solve an actual problem that doesn't involve, well, first, we're going to rack and run a whole bunch of servers. That's not really what people want to be doing unless that is your specific business. And finding a way to wind up doing that intelligently is an ongoing problem emerging in the space.

And I think that that's always trying to get rid of the thing that isn't core and central to a company's business is important. I think serverless gets a lot closer to that than most previous attempts. Yeah, and I see people focusing on this Lambda cold start problem as an analogy to that. And I had a tweet about this where I hear engineers complain every day about Lambda cold starts. I've never heard a customer ever say that they care about a cold start.

Because they don't. A customer cares about user perceived latency and the engineers perhaps inaccurately ascribe all of their cold start latency to this user perceived latency well i think you're absolutely right i wound up using two serverless monitoring products that i'm not going to name in this context. One of them was lightning fast and spat out what I needed. The other one likes to sit and spin as it gathers data. And I reached out talking to the companies about this, and it turns out the fast one was using something that involved servers on the front end, and the other one was trying to itself

be a completely serverless architecture. And my complaint was not, oh, that was a cold starter. Oh, I don't like the architecture behind this. My complaint was the web interface is super slow every time I change views and that's a crappy user experience. Fix it. And I don't have an opinion about the architecture. I don't want to hear the term cold start. What I want to hear is that, oh, we understand what the user perceived latency looks like. And we understand this is irritating you, and we're going to be taking steps to fix it. And I think that in a microcosm is what the industry says.

People don't care about your architecture. They care about their own pain. I don't care what code, what the code looks like. Any service provider I use, in the slightest, I care that it works, and I care that it lets me do the thing that I need to do. And you can optimize your code to make it perfect until you run out of money. Great. The Bay Area is littered with startups that tried that. But you can have terrible code and get to a business point of profitability and then go back and fix things. I mean, the canonical example of that is

Twitter. They don't have, they had horrible code. It was all Ruby on Rails driven, to my understanding. And now their scale is awesome. They don't have reliability problems. They have a Nazi problem, but that's a different topic. So if people like what you've had to say about the world of serverless, about where you see things going, and looking more into the nonsense things that you have going on on an ongoing basis, they can obviously apply to work with you at iRobot, but is there another way people can find you?

I'm active on Twitter, at Richard Boyd with no vowels, but it does include the Y. And I'm active on LinkedIn as well. Perfect. I'll also throw a link to your blog into the show notes, which fired off one more question. You now have the blog living at rboyd.dev

and all the developers i know jumped at the chance to get a dot dev domain and i looked at a few of my own environments where i wrote crappy code and sure enough i'm rerouting all of dot dev to local host so i have to wonder how many uh developers out there are trying to read other people's blogs and realizing, oh, this doesn't work or in terrifying moments. Oh my stars. Somehow he got a copy of my code and put it up at his website. That's a very good point. I hadn't considered that. Yeah. I had like richardhboyd.com was the previous blog, which is still up with some of the older posts. But that was a template that that was an open source template that I'd used from someone else years ago. And I told myself, I think it was early 2017, that I was going to start a blog.

And I made my first post in about March of 2019. And by then, the person who made the original template for it had stopped supporting it to move on with something else. And it just didn't scale very well. So I said, I'm going to do what every good serverless dev does. I'm going to roll my own. It's going to be entirely serverless. Which was a fun learning experience. Let me exercise some of these API gateway integration techniques I've been playing with. Let me exercise some of these API gateway integration techniques.

But still, the bug is not quite ready for production yet. I'm not a front-end person, so my heart kind of skipped a beat when you said in the future everything will be front-end code. Yeah, me too, because I can't code without a paper bag in JavaScript. Exactly, same. That's why I was a big fan of the AWS Cloud Developer Kit, but it was only in JavaScript, TypeScript, and Java.

And I was like, oh, well, this is essentially useless. But I hate all of those things. Exactly. And then they launched Python support. No language bigotry. You can do whatever you want. Just for me personally,

my brain doesn't work in quite that way. Yeah, and that's another thing that I've noticed with the API Gateway service integration is that if you go on Stack Overflow, Reddit, some of the Slack channels, if you look up JavaScript, Lambda, and then just name a service at random, you'll see the same question being asked thousands of times.

I build a client and I made a call to the service and then I returned, but it looks like my Lambda function is returning before I'm getting any data back and I'm not getting response. And that's because it's weird asynchronous nature of the way JavaScript works. And it's doing exactly that. It's firing off a request asynchronously and then saying, oh, it's time to exit and not waiting for the response to come back. And that's another part of the API gateway service integration work that I was doing is that if you have the API Gateway doing the service integration directly, there is no thinking about JavaScript asynchronous and await type conditions for this. And like all

those types of problems would just go away. I'm with you on that. I'm in the process of migrating my own serverless blog over to WordPress, which ironically is a bit of a serverless success story. But that's a tale for another time. Richard, thank you so much for taking the time to join me today. Oh, thanks for having me. No worries. Richard Boyd, cloud data engineer at iRobot. I'm Corey Quinn.

This is Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com or wherever Fine Snark is sold. This has been a humble pod production stay humble