Subscribe
Share
Share
Embed
In the same way that the cloud can be incredibly helpful, it can also be the source of a few headaches. Just like the printing press, technology can help eliminate the arduous parts of our jobs and help create new specialties. But it doesn’t mean that we have the golden ticket.
Today we are talking to Cloud Data Engineer, Richard Boyd, of iRobot about the perils of getting services to talk to each other and keeping your career flexible in the ever-evolving tech world.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: 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.
Corey Quinn: The 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 10 thto 13th is going to cover a lot of topics we’ve already covered in previous episodes of this show. Ranging for 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 some people who have 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/cloud that’s velocityconf.com/cloud. Thank you to Velocity for sponsoring this podcast.
Corey Quinn: 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.
Richard Boyd: Thanks for having me.
Corey Quinn: 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. The first time I met one of his coworkers I figured, "Oh, 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. Having spoken to you a couple of times now, I'm pretty sure that you're a real person who does work on computers. What's it like to be the second employee?
Richard Boyd: It feels great and actually Ben has been taking some ventriloquist lessons, so it's entirely possible that it's still just Ben.
Corey Quinn: He's an interesting one. There's no doubt about it. I had him on the show before, hoping to get him on again. Let's talk a little bit, before we get into what you're doing these days, about where you come from. It's my understanding you were at Amazon previously working in Amazon Robotics.
Richard Boyd: Yes, I was in Amazon Robotics. I was on the pod management team which is a team that owns the inventory and the life cycle 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 the information about every item that was in every automated Amazon fulfillment center.
Corey Quinn: 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 catch them all, where every service imaginable winds up on that board. 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. 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?
Richard Boyd: There is not, and it 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. 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.
Corey Quinn: Roger, 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. 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. 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.
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 it gather things from a warehouse so there's less human toil involved. There are terrifying things too, like self-driving cars, where the failure mode involves a bunch of people dying. That also winds up having a whole bunch of eyebrow-raising questions. 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?
Richard Boyd: 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 take out the garbage, take it out of the can, and remove the bag, and do that like a custodian would. You also don't have robots capable of operating at very high levels. There's no CEO robot that you can buy, but there's a lot of stuff in the middle where it's just automated, things that we've seen decimated with automated processing, that I think we're seeing that move into the physical space.
Whereas you used to have people who would be all these middle layers in a company that would just process paper according to some rubric that was put out. That was first automated with sick software and there was people that if they were physically doing something that was still very monotonous, the physical equivalent of that, their job was safe. I think that we're seeing robotics kind of encroach there in the physical world where automation and software encroached in the intellectual property-type world previously, like the late 90s or early 2000s.
Corey Quinn: 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. 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 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 is 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.
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. Every time they have it, it hasn't really come out to anything as significant. More jobs are invariably created than are lost. Sure, if you take a look at the invention of the automobile, there's an awful lot of people who are in the horse industry that needed to find other things to do. If they were able to make the jump and retool, then they were set. If they weren't, they eventually wound up forced out of the market. How we handle that as a society is a largely separate issue.
From my perspective, I always thought that, okay, this is what you need to know and learn to be able to learn new things and be effective in a world of computing. Now, I look at people entering the workforce, and they didn't have to go through all that. I think that forcing people to learn to use Microsoft DOS 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, brings us around to the idea of serverless, which is something that you've been extremely vocal and passionate about.
Richard Boyd: Yeah, and one thing I'd like to add to that is I think the only thing ... You hit the nail right on the head when you said that this problem's been around since Gutenberg, where a 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. The person who would have filled your place would do something slightly different.
I think that we're seeing an acceleration and a shortening to timelines for when these things happen where someone might have to make that choice several times throughout their career of I need to adapt otherwise I'm not going to have a job. I think that acceleration is what's making this problem unique from previous technological innovations. I don't think that 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 in SCO Systems Administration and what not.
Corey Quinn: The question too becomes how widespread is this serverless paradigm? There are 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. 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, that same question applies and it may have a different answer. 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 advice do we give people who are entering the workforce today?
Richard Boyd: That's a very good question.
Corey Quinn: Welcome to the podcast. You're now a thought leader.
Richard Boyd: I think that I see two main tracks. What I've often described it ... I'm going to talk about this from an engineering perspective just 'cause I come from an engineering background ... is that I always describe what I call the t-shaped engineer who only knows a little bit about a lot of things and then this one area very, very, deeply. I think that will still happen in the future. We'll need engineers who are broadly trained but have a specialization. I think we'll see more people who are flexible in what that specialization is. Instead of being the thought leader or 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.
They may not make as strong of contributions in there, not to say that their work is any less valuable. It may even be a third or fourth time in their career they'll switch and the depth of that T in this t-shaped engineer will go deeper or... But that will change throughout the course of their career. 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." Just being accepting of that new reality where ...
Corey Quinn: The t-shaped engineer is something that we've spoken of at least once or twice on the podcast before. I think one of the challenges there is figuring out what is that thing you go deep on. I don't think you can be a systems administrator without being a little bit of a jack of all trades. 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. Now, I'd argue it is cloud billing. But, there's going to be a time when 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.
That can be a scary thing and there are other folks who think that that's a wonderful opportunity. I think the answer's 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. I think we've gotten there by in large.
What's fascinating to me about serverless is the level of what you have to be aware of and what you have to do is almost completely vanishing.
Richard Boyd: Yeah, 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 getting 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. Inside iRobot it's that no one wants to clean a dirty room or vacuum.
I think that this becomes the mantra of serverless is that this type of stuff frees you up to focus on the things that you actually want to do and the things that provide you value, whether it's intrinsic value of things that you enjoy doing or monetary value for the number of customers that your business is able to capture.
Corey Quinn: One of the things that first brought you to my attention was a series of blog posts you wound up posting. I'll put a link to one of them in the show notes of your rboyd.dev personal blog. The one that I really saw that resonated with me was called Mastering API Gateway in 105 Easy Steps. 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, "Oo, 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?
Richard Boyd: Yeah, 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. 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, gives it back to API Gateway. 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!"
Richard Boyd: 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 will free you up to do all the things you love doing that's not configuring API Gateways. 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.
Corey Quinn: 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. Spoiler, the first time you do it, it is absolutely freaking not. My first Lambda Function took me two weeks to get working because I'm a terrible developer. The last one I wrote took me about 15 minutes because I don't write tests because I'm a terrible developer. There's a heck of a learning curve the first time as nothing behaves quite the way you think it will.
I understand the message they're trying to get across of once you understand a few basic tenants of how this works, it does speed development time. But, there's nothing more off-putting then trying to do something new and start experimenting with it and being told, "Oh, well actually it's very simple." Then, you have trouble with it, so the unspoken assumption is, "Oh, I must be a moron. I never knew." That's not a great feeling for anyone who's trying to learn something new, none of which, by the way, is easy.
Richard Boyd: 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 two words. One is, oh, that's easy, and the other one is the world "just". Because it's never just X. It's just X, so I think people care about... When you say on a call, 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.
Richard Boyd: I think that it's a bit deceptive in API Gateway because even if you do understand a lot of their tricks ... 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 the only thing they're consistent in is their level of inconsistency. This example in API Gateway just really highlighted that.
Corey Quinn: 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 in a whiteboard vacuum. You have no real conception of the constraints that shape what's currently in place and you're not very subtlety telling people who worked on this previously that they're kind of stupid." 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.
Richard Boyd: There's a chart that has the value of ignorance where if someone's proficiency goes up, their perceived efficiency goes up much ... I'm sorry. Let me start that over again. As someone's proficiency on a subject goes up, their perceived proficiency goes up much faster and then drops off once they realize they don't know what they're doing. That's where I tend to put people who say, "Oh, it's super easy, you just do X." Then, it's like, "Oh, this is your third week in dealing with AWS."
Corey Quinn: Exactly. What's fascinating as well is the level of confidence you espouse does change how people shape you. That's also very heavily driven by gender and race. 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 on 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.
Richard Boyd: Yes, and I'm trying to take it one step further than that is that I'd like to integrate with everything that it can integrate with that's not 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 that the pain that we experienced trying to integrate API Gateway doesn't have to be experienced by other people. 'Cause it would be very easy for me to say, "Okay, here are all the steps you have to do to learn what I learned," which the person still has to do all of this learning and just memorize all this, what's essentially useless information just to do what they want to do.
We're trying to make it so that your confirmation template looks just like a Boto 3 SDK goal. So you can say ... Pick a service. Every NM will say Athena. So, you can say, "Athena, start query." Then, you can look at the documentation and see what parameters that takes and supply those as native CloudFormation, like YAML constructs in there. 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 it requests are.
I'm working on creating a CloudFormation macro that does that transformation for you. Instead of teaching these people, "Okay, here's how you decipher the Rosetta Stone of API Gateway to other services," instead I say, "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."
Corey Quinn: I think it's a laudable goal. I think it's absolutely going to be transformative for a number of people. I have to ask though, because I ask 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?
Richard Boyd: Yes. It does feel weird doing this. There are times when I've been thinking like, "Amazon could just do this." We have been in touch with the API Gateway and the CloudFormation teams, or at least we've had several meetings with them, and they're picking up the lion share of this work, the hard part. The thing that I am building is only connecting some various parts and creating essentially a rough outline of how I'd like to use this as a developer. Then, they are going and they're building the actual infrastructure behind that that makes it possible.
I won't be building the whole widget. In the end, I'm just building the façade on the front of it, saying as a developer, 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. Then, they're building the stuff on the backside that makes it possible. I think you mentioned in a previous post that Amazon's very good at plumbing and terrible at painting. So, what I'm doing I'm hoping to do the painting, or at least I can 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.
Corey Quinn: Yeah, 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. You're right, 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. That, I think, is one of the most valuable aspects of the larger AWS community.
The other side to 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. 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 were the most 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 weird to look at it from a perspective now and how did we get here.
Richard Boyd: 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 some with CloudFormation and API Gateway that if I could do this once before 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 how I save time that I have in the future, is how I compensate myself for the time that I spend on this now.
Corey Quinn: That's a very good point. It tends to be something that resonates with people, clearly. When I linked against this article in my newsletter, it was the most popular link that week. That's depressing to some extent because I work super hard on some of the other links that wound up going into there. I'm kidding because it's great to see what resonates with the community and what doesn't. 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. 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.
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. I'm grateful to have the opportunity to do it, but the more I do this and the more I see 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.
Richard Boyd: Yeah, I think that this goes to a previous comment that 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. 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 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 just to stick this Lambda in the middle to make this easier?
Corey Quinn: 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, "Oh, the only code you will 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. Nothing ever quite got there. Oh, this time with serverless, that's what it's going to turn into. It feels like it's closer than anything else has been, but, at the same time, 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. The backend 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. 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 large 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.
Finding a way to wind up doing that intelligently is an ongoing problem emerging in this space. I think that how we're 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.
Richard Boyd: Yeah, I see people focusing on this Lambda cold start problem as an analogy to that where ... 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.
Corey Quinn: 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. I reached out talking to the companies about this and it turns out that 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. My complaint was not, "Oh, that was a cold start," or, "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.
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." 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 of 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.
You can optimize your code to make it perfect until you run out of money, great. The Bay area's 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. The canonical example of that is Twitter. They had horrible code. It was all Ruby on Rails driven to my understanding. 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?
Richard Boyd: I'm active on Twitter @rchrdbyd with no vowels, but it does include the Y. And, I'm active on LinkedIn as well.
Corey Quinn: Perfect. I'll also throw a link to your blog into the show notes, which, before I fire off one more question. You now have the blog living at R-B-O-Y-D .dev and all the developers I know jumped at the chance to get a .dev domain. I looked at a few of my own environments where I wrote crappy code and, sure enough, I'm rerouting all of .dev to localhost. So, I have to wonder how many developers out there are trying to read other people's blogs and realize that, "Oh, this doesn't work," or in terrifying moments, "Oh, my stars, somehow he got a copy of my code and put it up on his website."
Richard Boyd: That's a very good point. I hadn't considered that. Yeah, I had richardhboyd.com was the previous blog, which is still up with some of the older posts, but that was an open source template that I had used from someone else years ago. When 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. By then, the person who made the original template for it had stopped supporting it to move onto 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 that let me exercise some of these API Gateway integration techniques I'd been playing with.
It let me exercise some of these API Gateway integration techniques, but it's still ... The blog is not quite ready for production yet. I'm not a front end person, so my heart skipped a beat when you said, "In the future, everything will be ... My heart skipped a beat when you said, "In the future, everything will be front end code."
Corey Quinn: Yeah, me too because I can't code my way out of a paper bag in JavaScript.
Richard Boyd: 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. I was like, "Oh, well this essentially useless"
Corey Quinn: But I hate all of those things.
Richard Boyd: Exactly. Then, they launched Python support...
Corey Quinn: No language bigotry. You can do whatever you want just for me personally, my brain doesn't work in quite that way.
Richard Boyd: Yeah, and that's another thing that I've noticed with the API Gateway service integration is that if you go on Stack Overflow or 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 built 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 a response. That's because of this 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.
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 in A-weight type conditions for this. All of those types of problems would just go away.
Corey Quinn: 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.
Richard Boyd: Oh, thanks for having me.
Corey Quinn: No worries. Richard Boyd, cloud data engineer at iRobot. I'm Corey Quinn, this is Screaming in the Cloud.
Speaker: This has been this week's episode of Screaming in the Cloud. We can also find more Corey at screaminginthecloud.com or wherever fine snark is sold.