Ep 42: Talking Serverless LIVE!

Talking Serverless with Joshua Proto and Ryan Jones

Welcome everyone to a special episode of the Talking Serverless Podcast! We have both co-hosts on today. I am Serverless Guru’s COO, Joshua Proto, joined today by the founder of Serverless Guru, Ryan Jones. We always have new people join us on the podcast and this episode with Ryan is a great entry point. Ryan has made a name for himself in the serverless computing and cloud computing space by helping enterprise clients identify, reduce, optimize, and kill inefficiencies.

Journey into Serverless

Joshua: How did you get into Serverless? What were you doing beforehand, and where are you going right now? What sort of exciting things are keeping you up at night around serverless?
Ryan: I have been working on a Skunk Works project for building serverless applications and making progress on it. We are not entirely at a public release on any of that stuff, but we're planning on doing internal testing within serverless guru, getting all of the developers at the company to use it, try it out, and get their feedback. We are in one of the arguably best positions to build a product like this because we have people on the ground that are leading world-class people from around the world working on serverless guru that do this stuff every day. So if we're going to build a product, we have people that can give feedback that almost any other startup wouldn't have the ability to tap into. We have client access as well. So I'm super excited about it.

It's been rattling around in my head for quite a while, at a high level. It's just going to make the development process of serverless applications easier, smoother, and get to that fascinating point where it's; we do a lot of repetition when we're building things out. So the idea is, let's skip over some of that, and let's get to the cool stuff, the new stuff, let's rework on the edge cases back into the platform, and then grow it from there. So, that's probably the worst product development side, and I have been surfing quite a bit. In the past three and a half months, I've been here in Puerto Rico, and I've served the past four days, around like 5 pm until sunset. It's been amazing.

Background story and Learning stages

Joshua Proto: Do you just one day decide that you're going to be working on a state-of-the-art skunkworks serverless application that serverless product? How did you get to the point that if you're building a product, you can see a need, or even sometimes our most innovative people can foresee a need and be able to sort of catch the market before it’s fully matured? Was serverless always something that you were interested in?

Ryan Jones: Yes, specifically for this product, it was rattling around in my head for quite a while. I believe this is a two-part question. But at least the internal product was right around my head for a while because I kept building the same thing. Whenever we get asked by a client to make some serverless application, I always do the same few steps. If I didn't have access to those templates, that's part of the reason why serverless guru has a gigantic templates repository. It was the precursor to kind of what this product is. So, when I would be asked to build this API, build another API, and then integrate like a user pool and Cognito, and all these services, I get asked to keep repeating that process. I'm sure this is not a unique idea. I'm sure everyone who works in space has this kind of thought about why you should increase the automation of all of it. I think that this is precisely how I'm almost like putting my brain into automation. Even though there are existing products on the market for it, I think this one will be a bit more unique in terms of functionality and stuff mentioned earlier.

I am getting to the second part of the question about Serverless in general. It was an exciting story. When I was eight years old, I would carry a fishing tackle box to elementary school. I would get my dog and my parents to take me to a beauty supply store. Then, I would get a bunch of colored rubber bands and bobby pins. I would then put them into the tackle fishing box in a nice color to order with, like the bobby pins. I would go to school on the playground, and I would open it up. Then I would sell rubber band bracelets of different colors to people on the playground for $1. So, I was able to sell these to kids. I use that money to buy candy from the gas station.

Similarly, this is a unique thing that I was able to create something, have someone buy it, see value in it, and then get something that I wanted out of that using that right. So, that was probably the actual start of all this. So from rubber bands, selling that on the playground went into just thinking about skill acquisition. I don't like the times when you're operating, but you don't know the vocabulary about why you're doing what you're doing. So, if I get good at this thing, then something good will come out of that.
I started going to school, and I started trying to build a professional gaming team. I just found people in my gym class. I would say, "Hey, do you play Halo three? Great, let's like form a team; let's go pro at this". No one took it as seriously as I took it, and hence it didn't fully work out. But, I tried to build teams back then as well. I ended up going to MLG events, and then I got into World of Warcraft which was a fantastic experience. I played it for four years, a sophomore in high school; it's like graduating and eventually turning it into a business. There were like Twitch streamers that popped up during that period. I just started getting better at it. And then I saw someone spamming saying, hey, all I'm selling is v2 with Karis, and just messaged me about it. So I messaged that guy; "I was like, hey, teach me how to do it. I'll work for free for you".

I want to know how to do this, and understand what the process is. You just basically get paid through PayPal, and it's not complex or anything. But for me being like a 14-year-old to like an 18-year-old kid with no outside world experience, the idea of getting paid to play a video game was tough to wrap my head around. We got on Skype calls. He was from Australia, and he became like a good friend of mine at the time, and I started doing these carries and stuff, and then he made me like a bit of a pamphlet. I always make enough money to pay for rent and all that stuff. I was working 12 hours a day. I would split and span across four different World of Warcraft accounts, which is not looked at very fondly from Blizzard. But I did that, and I would spam in the chat, and then somebody messaged me; I would send them a big message about how they could pay me and how we could start working. That was probably the first time that I dipped my toe in consulting, and it's cool. This was my first experience in consulting, customer service, and also programming because one thing that I was doing in World Warcraft to switch between these accounts is that I was starting to become technically savvy at that point. So I would write key bindings and spit out messages using macros. That's how that developed. I did that for a while and then it kind of dried up because they ruined it. They started introducing buying gold using your credit card. I just was not ready to adapt to it. So I ended up getting a job at a fast-food restaurant. I worked in a fast-food restaurant for like eight months. It was awful.

That's where I started to see even in that environment; I tried to get better at the stuff I was doing. I found enjoyment in some of the more trivial things. The movements were very organized, and I got better at those movements over and over again. That was also like a precursor to the type of way I operate now, finding little efficiencies in places from their left. I went to Portland, Oregon, where eventually serverless guru was founded, but it took longer. So I went there, started doing data entry, and was now typing faster from the World of Warcraft days. So I started to get into that whole tech-savvy part. I did that for a while, I went back to school, I started going to a community college, and I ended up moving back to Texas. Then I saw a YouTube video where the guy was talking about a code school and how that immediately clicked. I was already starting to take some Android classes through Udemy at that point. I was going heavy Java, and I didn't even know how HTML worked at that point. But I was doing Java, but I didn't know how Java even connects to anything else. I watched that video, where he says that if I go to Code School, I'll get a job at Google.

After I saw that video, I went outside; first off, I emailed them. I went to Code School. That's where I ended up meeting you, Josh. I was doing Udemy courses; I was doing full-time college on the weekend for programming. I was still working out entries on the weekend as well. So it's like a super jam-packed schedule there. Then it got to a point in the later stages of the code school where I did the entire week of the program on Saturday or Sunday. I would show up to code school on Monday. I was working on whatever I wanted to work on because I already did the course at that point. I started getting interested from one of the people there. One of the people in the code school with me was named Clifford; his brother was an AWS cloud engineer. What does Cloud engineer mean and I looked up the salaries for it. It was like six figures. From there, I met with him, got some more info about it, and then learned about AWS certifications. We started a study group inside of the Code School. One of the first videos that Ryan Cronenberg from a cloud guru said was serverless is the future, and that's really where this all kicked off. Because the second I heard serverless is the future, I'm looking for my ticket into the faster track of stuff. I was like, Okay, let's figure out what that means.

I learned about Alexa development, and I built an Alexa skill that allowed for Portland train arrivals. I was using lambda serverless, AWS. So a lot of the stuff that we have now didn't exist, then, including something like a comparable application now is dyno based, an application found on Twitter. So I love what he's done with it, about making a hosted UI of dynamo DB, making that process way more accessible. I tried to do it out of Coatesville in mid-2017, I didn't have the knowledge or the skill set to pull the thing off. But I did try, and I worked hard to understand Cognito authentication flows and all this stuff back in Doc when there wasn't much documentation around it. And then, through that process of doing this, I matched like 80% of a job description for Nike for the animation engineering department. But eventually, I was able to catch up with the people that are and do well at it.

Nike was like a dream come true. It was a standing whiteboard desk at a massive company at the world headquarters. I was surrounded by peers that were off the charts like they had five iOS apps, or like number one in the store, and like all these things. We built out all this cool machine learning stuff. I built like a chatbot, and all of it was server lists, the back-end stuff supporting machine learning. As the saying goes, whatever is like in a machine learning application, like 5% or less as machine learning, and the rest of it is just usual development stuff. So, I helped with all those everyday development things, and somebody else handled machine learning. I started to branch out, and I talked to Portland Community College about creating a chatbot. I told my grandpa that I wanted to start a business in 2017. But I didn't know what I wanted to do. I just knew that if I could get good at AWS, then people would pay me for that and that supported my long-term goal of control of my time.

I wanted to be able to control what I did daily from any location. I didn't know what business would support that. But, going back to the story, I talked to PCC, they approved me doing a chatbot with serverless, all these things for the job fair, build all that out, do the machine learning side of that as well and was not fully released. But it was an incredible product and it was my first customer even though they didn't pay me. A week later, I got a message on LinkedIn from a cert, one of the first service consulting companies around and they said, "Hey, Ryan, we'd love for you to join our services consulting company." And I was like, wow, that's exactly what I wanted to do. I was about eight months old at Nike, and we had to build everything. And so the thoughts started to go around in my head, like, Am I just going to be maintaining this stuff or will I be building new things? I was not ready to sit in the same position. I immediately step into this new role, in which Ryan is the developer coach of developers that I believe have worked at Microsoft for 15 years. About one and half years of my career, I taught them about serverless, framework, and serverless development, amplifying all these different technologies. From there, I started to get a more concrete understanding of a consulting company. It is a real thing that I can do. There were some gaps that I had to fill. It's just me at that point. Soon after, I think probably around December; we met Josh. And then I think we started talking about Gary Vee and LinkedIn marketing and all that stuff. And you're like, I do marketing. I was like, Great, let's do this. Then, different people reached out once the business was a thing. Then I was like, "oh, I'm interested in that."

We are trying to do something around cloud development. I was overwhelmed with it like 12 hours a day type of thing and working the weekends, until it got to the point where it's like, "Okay, I've got three projects." I'm going to lose my mind, and so I need to add someone in. I just slowly tried that with different people and eventually found it like a fit. I started scaling it out through 2019, and we were probably around five people in the company. At the end of 2019, we got a break, our first enterprise client. When they offered the opportunity, we've been working since the very beginning for this one moment in time to deliver this project to this client because it was apparent that if we did that successfully. We proved that we were the best at doing this, and then it's not. So we get that project, and that's one of our longest-running clients. We've been working with them for quite a while and worked with them throughout the entire pandemic 2020. We're in 2021 is still a thing, but the first half of the pandemic, and then around like late 2020. The economy had reset, came back a little bit, and people were starting to be a bit riskier; we got our second enterprise client, primarily based on our first enterprise client's work. Currently, we are like 23 people and we're still growing. That is the entire journey.

Mainstream Developers and Blockchain Development

Joshua: I'd love to share with you the first question that we have from the audience. Is it from a rich buggy from Twitter? How do we get mainstream developers into serverless?

Ryan: There's something that's like; I'll draw a parallel to blockchain development. I will try not to lose my train of thought about why I'm doing that. So with blockchain development, I struggle with this as well, which is, how does my skill apply to this new field? Is everything new, or is it partially the same? What is the difference there? I feel like we probably have a similar thing happening with serverless, as well, which is how does a regular Node JS developer or something transition to serverless? Or how does someone that's working the cloud, but with virtual machines, or even outside of the current AWS, cloud providers, all that stuff? How do they transition to something like serverless and do their skills align or not? The answer to that is like they do align, and even to the blockchain side, right? A lot of stuff that we're still doing is functions, writing code. There are services that we're using API integrations and vocabulary; it's just jargon. So, if you spend enough time just looking at the jargon and tutorials, everything will click together from your existing knowledge to your new knowledge. I think that the easier that we make that bridge, the better we're going to get mainstream people into Serverless. If you were an individual contributor, what you could do to help bridge that gap for people. You could make tutorials through blog articles that have been successful or online courses. What I want to flag is that a lot of times, when I hear about articles, I think somebody already wrote something about that. I think part of the reason I did that long intro is that everything you've had happened in your entire life makes your perspective unique. Because of that unique perspective, you're going to communicate to someone out there in a way that will click with them that everything else existing won't connect. Even though there are many articles about doing certain things, I want to encourage everyone to write those articles to engage with the community because your unique perspective will have a considerable impact. Your writing style and how you talk, and all those things will have a significant difference on people.

Joshua: I think there's tons of value in the projects that we've worked with inside these large companies. Sometimes they have hundreds or 1000s of employees. If they have a column like eternal champions or just someone willing to say "No," I think serverless is the best choice for our organization. It would be able to demonstrate it with the use case, having a PLC, or having something to show this is helping us solve our problem. I was at a conference once, and there is a well-known futurist there. He puts up a slide, and it's just like this human-robot sitting in the chair. People tell me that this is what people think the future is like; they think it’s super high-tech. It is familiar but also unknown. Whenever we're talking about future technology, that's a certain kind of fear we do and have seen in specific organizations. However, he says, this is actually what the future is going to look like. He goes to the next slide; the future is just tools, there's going to be new tools for us to utilize, and we're going to be the ones to use the tools at the end of the day. There are problems that real organizations and real people around the world are facing. Serverless is simply another tool that can help us fix those problems, and the same thing is with blockchain. If you know how to use that and implement it, you'll find that it fixes it even faster than the legacy solution or the typical way of doing things for some problems. A great way to communicate that is by sharing perspectives; we each have an individual perspective that will be essential for the adoption of serverless technologies, regardless of where you are at.

Ryan: I think that's a perfect analogy because a lot of times, that was the same problem with the blockchain. How is my knowledge of all these things just entirely out the window and has no impact at all? Am I starting from scratch as well, or do my skills transitioned at all? You're coming from this perspective, and you see all this jargon about decentralized networks, constellation networks. These tokens interact, and there are nodes. They're optimizing based on machine learning and how much buzzwords do, how accurate, and what is not. I can start matching the vocabulary together with my current understanding until I eventually have a complete picture. If I'm struggling to find out information, I know for a fact everyone probably is struggling with that. Hence, I think there needs to be a lot of those types of materials happening. It needs to be from the people who have the least amount of experience transitioning because their perspective and transitions will be the closest to what other people are experiencing than mine. This is because I've been doing this for three or four years. For somebody that's transitioning, if they're documenting that entire process or sharing that, it can be very intimidating because maybe I get something wrong. But at the same time, you are communicating in a very tangible way.

Cost-efficiency

Joshua: Zach Neubauer from Twitter is curious to know how serverless stacks up cost-wise compared to dedicated servers. How do you respond to that? What about the cost efficiency?
Ryan: When we think about raw compute costs, how much does it cost when this lambda function runs and depending on what you're trying to accomplish with the serverless architecture, it might cost more. Hence, at the surface level, it costs more. Now, I have my argument and do not use serverless. But when we go a couple of layers deeper, we start thinking about the core costs of a business building applications in 2021. It's the software developers; it's the engineering time. So, when we think about ways to save costs, it should be around lowering somebody that I worked with recently, or in the past, even a serverless Guru, Gary would say, it's about Gary Jennings, it's about lowering the feedback loop. So, you want that feedback loop to be as fast as possible. Because the less time that the developer spends debugging, the less time that operation spends trying to increase the database count, so that it's not like maxing out the database, the less of all of those different aspects, and the smoother that the whole system starts running. That's where those actual cost savings come in. Because then we can redirect all that engineering time for something else.

From a macro business perspective, what's making money is the product when we think about it. The more time that we spend investing into those engineering hours that we're saving into building out new product features, the more potential money that the business is making, and the more impact with the developers on a day to day basis feel like they're having because I know when I run into a bug. I'm sitting there spending two hours trying to debug it because there's some weird nested loop thing. I'm trying to figure out what the heck is going on. At this point, many people are still focused on the infrastructure so that in a serverless world, we're not doing. That means creating serverless architectures now; it is a kind of a first-class citizen, which is infrastructure as code; you have these blueprints for the thing you're going to create.

I'm going to create a REST API, and I've got this REST API blueprint. It wasn't built to build these things. So, once we start getting into the serverless realm, we start removing a lot of the overhead that we had previously with virtual machines, containers. We started moving into something that matters to me; what matters to the business is building good products and running good servers. The only thing that matters is performance. Maybe, there are a couple of other aspects. Does the customer have a good experience using our APIs, and maybe behind that API, it's serverless. So it's a lambda function, and to be managed by us, maybe behind it is a manually spun up thing, or even an automated spin up cloud virtual machine that doesn't scale properly. Or if it does scale, there's been tons and tons of engineering hours, which, again, is the highest cost in the whole equation.

When we take that level of what matters to the customer, which is actually what the business is entirely about the customer experience, then running a suitable server or making a good server is one of the last priorities that we have, even though that's a vast field of people that are doing that currently. If we talk at the service level or the surface level, it's about the cost of computing and storage. But then we got a couple of layers deeper; how much time does it take for engineers to build those things, interact with those things, and maintain those things? And then what is the total cost of all of that together? So you take the accumulation of all those different aspects. Serverless is cheaper than doing things in the cloud virtual machine, and then often, something like Kubernetes, with containers. So time to market automation, overhead goes down, automation goes up, time to market goes, it's much faster. We get all those benefits. If somebody was willing to sit down and do some intense math about how long does it take for a new feature to be released? How much does that feature potentially give new revenue and start calculating? So it takes developers two weeks to do it; they're paid at x hourly rate. If you were doing that calculation, and you compare it to serverless, it's apparent equations, and serverless wins not out, all day long.

Serverless linked to Company size

Joshua: I think some of the most valuable things that I've seen are that I was able to accomplish, in business, when you can lower the feedback loop, or when you can shorten the amount of time to have operational excellence, it's hard to find a way to replicate that. Our skills are valuable; therefore, the time spent is also beneficial. But there could be a reality where, you know, you didn't have to spend two hours, only took you 10 minutes or no. I have this fear of robots going to replace our jobs. If we figure out how we don't need virtual or hardware infrastructure, your expertise will still be valued. You can contribute more and add more value to the business and the creative process as you're so skilled. So I think it's something that people don't need to be as afraid of.

Ryan: I gave a talk in Portland, Oregon, back in 2019. I was introduced as Ryan is talking about serverless and hopefully not how it will take everyone's job away or something. It was like a joke. But it was also partially like an actual thing that everyone was feeling, right. People still have feelings today. You even have blockchain come in web 3.0. All web 2.0 is going out the window. So I feel like we're constantly in that spot; the field we've chosen is not static. Our job as professionals is to be on that front line, understand the new things coming out, and then use the skills and knowledge that we've acquired to make those transitions. If your company is familiar with servers, you only have two people, and you already have something released, and you don't have many customers, it may not make sense to switch to serverless as it doesn't outweigh the cost. But if you're a larger company, you have ten people or 1000s of people, and if you're running a much bigger thing with millions of customers in that equation, it is effortless. I've seen companies try to make that transition without having something that's like a real product. They end up almost just spinning their wheels and never really getting something out. In that situation, this is also where I'll fly back to like; I like the serverless guru website, for instance, a bill with web flow.

For those who don't know, web flow is drag and drop, where you can customize some HTML and all those things. But it makes CSS and HTML easy. We are capable of wiring CSS and HTML. But it is a good time investment, making the marketing site from scratch and the best use of time. Then, I look for tools that allowed me to get the 99% of what I wanted: web flow. It took us a little bit of coding to do some extra automation to make that work. But each one of those sites, or each of those pages, we can now spin up new pages very quickly and release it and do all those things. It all depends on the use case there. When I use web flow for a more complex application involving serverless, I do not use it for a marketing site that I need to have spun up quickly and be able to make it so that almost everyone in the organization can make changes to this see those swiftly reflected. Serverless makes sense in nearly all categories, but it also depends on the context of where you are in that total business journey.

Joshua: An inner fortune 100 plus companies have product-market fit, and they've demonstrated it for many years. I've always seen serverless as having a role in a very defined use case, but if that use case isn't yet formed, it's like, it's a potential risk. But I wouldn't say it's a risk associated with serverless itself, and it is a risk associated with the product, which is just like a general business risk. Serverless may be costing you more in those situations.

Ryan: When I was in Portland, I was at an incubator at work labs, and I was around many other founders and people that were starting businesses. I learned about building things, and it was groundbreaking, But I know that it's probably the way that I shouldn't be doing it; what they did is they just made a slideshow. They just took that feedback; they modified the slideshow, it took them to make those new features. Then, they did a drag and drop UI type of solution. They've been using that since then. They are establishing their product market. They went from a v1 to v2 to like v3; I think they're out like v10. They would sit down with people and watch the reaction as they were using the UI. Once they have an established thing that's fully working, then they're going to build an actual product out of it. They would start evaluating using serverless. They're a Portland company that allows for getting fresh food from different farms.

Future of Serverless

Joshua: Where do you see serverless in five to 10 years from now? Like, how do you think it will develop in the context of blockchain, the serverless killer?

Ryan: I've been trying to wrap my head around the blockchain serverless side and how that fits in. We are ten years or a decade away from this being like a common thing that's happening. We're not going to wake up tomorrow and web 3.0 is here, and everything is blockchain now. It is a prolonged process, and that needs a ton of maturity beyond. Blockchain is coming, and it's going to take a bit to have, like mass adoption. For serverless, we've gone through that process since 2017. When lambda came out, then API gateway wasn't a thing. Now, we have app sync, Event Bridge, and all these other services have increased the maturity of what it means to build serverless applications.

So in 2021, it feels like we have enough tools to accomplish pretty much anything. We are at the early stages of mainstream adoption. Thus, we will see this model of people moving away from managing their things to this fully managed paradigm. A lot of the things that end up happening in that space, and there are a lot of fully managed things where you can use this service, and it'll build out this network for you. It will give you this token that you can use within the network. You don't have to spin up all those things yourself. I think the happy bridge between all the serverless stuff that's happening. I have also seen a lot of stuff in the blockchain community. I have witnessed JVM usage, Java, Scala, and more like traditional virtual machines. So in those cases, there is a little bit of that overhead. I don't know how some of those companies running their networks will compete with someone like Amazon. I believe that we're in the early stages of mainstream adoption. More and more companies will start prioritizing, reducing all of these manual processes to kill inefficiencies, and spending more time focused on their product. They want people to do it from the beginning, and we have good exposure to education. In 2022, I think more of these large companies are going to start getting on board. I believe new applications will be built with a lot more priority towards serverless from the beginning, and it's an upward growth.

I talked to the CEO of a product whose name I cannot remember now. He said that he imagined serverless being a hockey stick. I believe that was his exact quote from that podcast episode. I think that is where we're headed. And so all the skills and knowledge that you can gain right now to understand this space, and understand things like the usage of event bridge, the use of app sync, API, gateway, lambda, how you build cloud watch things, how do you build secure cloud applications, and just getting hands-on practical experience, is going to serve well in the future. I just see things expanding and becoming more mature, abstractions being built up over the top of them. The same thing that's happening with cloud virtual machines, to containers to Cloud Functions, is that you have enough maturity that an abstraction is created. We are in that process right now. If that makes sense it's much easier for you to transition to whatever that new state is.

Serverless Technologies and other services

Joshua: There are different serverless technologies, services, and skills, like lambda API, gateway, app sync. Are these technologies going to be iterated and developed more upon for someone or an organization? Should I learn serverless? Is it too late to either start considering serverless? Do I need to wait for this next abstraction or is there still value from learning these technologies right now?
Ryan: You're not too late. I tried to find a serverless developer job back in, like, mid-2017. I searched for a serverless developer then. Now, I get hit with recruiters with serverless, senior serverless developers, senior AWS cloud developers with lambda and API gateway and app sync, and all this stuff. I have random tech recruiters that probably aren't aware of the space completely, that are messaging me with asking to do something like lambda and all the stuff. So I feel like that hasn't happened until probably a couple of months ago. I think the exponential growth is perhaps close to accurate and the maturity of all the surfaces.

Joshua: How many LinkedIn requests you're getting from people like, Hey, I have, you want to help me out with this position, or that sort of thing? Before, no recruiters were asking for serverless engineers, and there were no job postings about it. But now you can go on LinkedIn, engineering serverless developer job posts appear and like the four other cloud consulting companies in the world that exists. It's really interesting. We can even switch to industries potentially.

Ryan: I'm fascinated by application code automation. Hence, I think that our ability to stitch together very complex application logic that we know for a fact won't have bugs in it while we're developing it. If I can write an async, JavaScript, functional map, or something over an array, I just type it, generate it, or there's some interface thing that makes sense to the developer. I think that that's going to be huge, because if it's for a generic purpose, and it allows for developers to write this stuff faster, I think there's going to be a market for that, because ultimately, it's about speed, it's about being able to build things.

If doing a service proxy with REST API, we go straight from the API gateway straight to the actual service instead of having a lambda function behind the API gateway. That allows us to build much more robust applications and reduce the code to zero. Thus, we're saving all this other time. But the process to create those things is more complicated. I think that's probably going to be that abstraction layer that happens in the future, simplifying the building of these complex architectures into something that's still manageable. That doesn't turn into a black box but does simplify the past because right now. If you go to the Lambda console, you look at all the different things you can do. There are all these screens, tabs; there are extensions, layers, timeouts, and memory, like what is the optimal point of all these things, knowing that stuff, implementing those things, and knowing the nuances of all that is, is complex.

I think that all of these are building blocks. We need those foundational building blocks to be able to build anything we want, based on the use case. But then we need to have abstractions over the top of that to make that process simpler and more accessible, because at the end of the day, building a perfect REST API doesn't matter to the consumer if they're having a good experience with AR if it's performance on the front end. They can use the application to do what they need to do, and it's a good customer experience. There may be a world where abstractions exist, and there are also the low-level things that exist, and there might be a bridge between those things. Hence, understanding how to do serverless development today and the knowledge that abstraction may come in the future won't take away your job; you'll still have to do those things as well.

Conclusion

Josh: Ryan, you can go from rubber band bracelets and tackle bugs to serverless engineering and serverless development and running a serverless consulting company. So that is interesting and exciting to hear and all your perspective and the answers to these questions. Thank you so much for listening to talking serverless today, and you know, this is your host signing off for the day.