Serverless Guru with Ryan Jones
Ryan Jones shares his journey from code school to founding Serverless Guru, discussing AWS serverless consulting, enterprise migration challenges, and developer advice.
Episode Description
Ryan Jones shares his journey from code school to founding Serverless Guru, discussing AWS serverless consulting, enterprise migration challenges, and advice for developers.
Episode Summary
Ryan Jones, CEO of Serverless Guru and co-host of the Talking Serverless podcast, traces his unconventional path from attending a code school in Portland in 2017 to running a 22-person serverless consulting company. He describes how early bets on AWS and serverless technologies — including building an Alexa skill and working at Nike — gave him a foundation that most junior developers lacked, eventually leading him to start Serverless Guru in late 2018. The conversation explores what his company actually does for clients, ranging from training and blueprint creation to full greenfield development for enterprises. A substantial portion of the discussion centers on the tension between using high-level abstractions like Amplify or Vercel versus working directly with lower-level AWS services, with Ryan arguing that the right choice depends heavily on team capability, company stage, and long-term vision. He shares a cautionary tale of a company that went all-in on serverless prematurely, burned through capital, and never launched. The episode closes with practical advice for newcomers: build something simple in the AWS console first, then reverse-engineer it into infrastructure as code, resisting the urge to optimize before a working product exists.
Chapters
00:00:00 - Ryan's Journey from Code School to Nike
Ryan Jones introduces his background, starting with enrolling in a code school in Portland, Oregon in 2017 after discovering online programming courses. He describes the early realization that graduating alongside 150 other students with identical skills meant he needed to differentiate himself, which led him to pursue AWS certifications and build projects like an Alexa skill for Portland train arrivals.
His initiative paid off when a recruiter from Nike reached out for a position that matched the skills he had been developing independently. Despite being extremely new to the industry, Ryan landed a role in Nike's Innovation Engineering department doing serverless work daily, which became a formative experience surrounded by accomplished engineers working on machine learning and background processing projects.
00:04:29 - Leaving Nike and Starting Serverless Guru
Ryan explains his decision to leave Nike for a smaller serverless consulting company called Mo2, a move his family questioned given Nike's prestige. At Mo2, he was thrust into a developer coaching role, teaching serverless concepts to experienced Microsoft developers despite having only about eighteen months of experience himself. This exposure to consulting operations gave him the confidence and knowledge to launch Serverless Guru in late 2018.
The company started small with side projects, blogging, and online courses, then snowballed quickly. By early 2022, Serverless Guru had grown to over 22 people, fueled largely by organic inbound traffic and word-of-mouth referrals from satisfied clients. Ryan shares encouraging feedback he received at AWS re:Invent, where community members noted that Serverless Guru was one of the few original serverless consulting companies still operating independently.
00:09:17 - Has the Serverless Bet Paid Off?
Christopher asks whether Ryan's early bet on serverless has delivered returns. Ryan traces his inspiration back to hearing Ryan Kronenberg of A Cloud Guru declare that serverless is the future, and reflects on how much the ecosystem has matured since then. He highlights the evolution of services like AppSync, recalling painful early experiences with undocumented VTL files while building a fintech application.
The discussion covers the growing availability of learning resources, from Jan Kooi's AppSync masterclass to Ryan's own Serverless Zero to Paid Professional course. Ryan confirms the bet has paid off, pointing to the company's rapid growth and its positioning as a go-to provider for Fortune 2000 companies entering the serverless space, with plans to scale sales and partnerships aggressively.
00:13:44 - What Serverless Guru Actually Does for Clients
Anthony asks Ryan to break down the nuts and bolts of the consulting practice. Ryan describes a full spectrum of services: training teams new to serverless, building infrastructure-as-code blueprints and CI/CD pipelines, providing developer support and architecture consulting, and executing greenfield development where the Serverless Guru team essentially runs a client's engineering operations.
A key theme is enablement — the goal is to help clients build independently rather than create permanent dependency. Ryan explains how proof-of-concept projects are built and then handed off to internal developers, allowing companies to jump from zero to a strong foundation quickly. He notes that roughly 98% of their work is AWS serverless, with Serverless Framework powering about 95% of their infrastructure-as-code.
00:17:35 - Abstractions vs. Lower-Level AWS Development
Christopher raises the question of whether developers should use third-party platforms that abstract over AWS or work directly at the lower level. Ryan draws an analogy to his own company's shift from a custom React website to Webflow, illustrating how abstractions serve different needs at different stages. He shares cautionary examples of clients who used Amplify to build products but hit walls when approaching production.
Ryan argues that early-stage projects benefit from abstractions for speed, but established companies with capable teams should invest in lower-level understanding to avoid being boxed in by third-party limitations. He introduces Cloud GTO, a skunkworks product Serverless Guru is developing that auto-generates Serverless Framework templates — aiming to make the low level easier rather than adding another abstraction layer on top of existing ones.
00:22:55 - The Real Costs of Serverless Migration
The conversation shifts to the hidden costs of adopting serverless, particularly for mid-size companies weighing whether to migrate existing infrastructure. Ryan challenges the common narrative that serverless saves money by pointing out that the highest cost is almost always the engineering team, regardless of whether the architecture is serverless, containers, or traditional servers. He emphasizes asking why a migration is happening before committing to one.
Ryan describes scenarios where forcing a serverless transition alienated experienced developers with years of domain knowledge, leading to costly departures. He recounts a project requiring 30,000 requests per second where simply validating whether Lambda could handle the load took two weeks of testing. The takeaway is that technology transitions are never purely technical — they carry organizational and human costs that companies rarely calculate thoroughly enough.
00:33:52 - When Serverless Goes Wrong
Christopher asks directly whether Ryan has seen serverless backfire on a company. Ryan confirms he has, comparing it to how plane crashes result from a chain of compounding errors rather than a single mistake. He describes a company that committed fully to serverless too early, when the ecosystem was immature and the team was pushing new technology for the wrong reasons.
The result was months of delays, burned capital, and competitors launching first. Ryan uses this as a springboard to emphasize that customers don't care about backend architecture — they care about a working product with new features delivered quickly. For small companies still finding product-market fit, the choice between servers and serverless should be secondary to shipping something that works.
00:36:18 - Advice for Developers Getting Started with Serverless
Anthony asks Ryan for recommendations for newcomers entering development or serverless. Ryan's core advice is to build something tangible and learn only what's required to complete it, ignoring the thousands of other AWS services competing for attention. He recommends starting with a simple project like an Alexa skill, deploying Lambda functions manually through the AWS console, and only then reverse-engineering the setup into infrastructure as code.
Ryan outlines a practical learning path: start in the console with no tooling, get something working, then layer in DynamoDB, API Gateway, and a frontend framework one piece at a time. He warns against premature optimization, noting that obsessing over packaging or infrastructure-as-code perfection before having a working product is a common trap in the serverless world. The episode wraps with links to Serverless Guru's blog, podcast, and community resources.
Transcript
00:00:00 - Anthony Campolo
Cool. Yeah. Let's hop right into it. Ryan, welcome to the show.
00:00:13 - Ryan Jones
Hey, thanks for having me.
00:00:14 - Anthony Campolo
You are one of the hosts of the Talking Serverless podcast, along with a previous guest to the show, Josh. You are also the CEO of Serverless Guru. I would love to hear a little bit about yourself and your company.
00:00:30 - Ryan Jones
My background in tech started around 2017. I started doing stuff online and then learned about code schools and thought, oh my gosh, going to a code school is actually a path. In my mind, I was like, if I go to a code school, I'm going to be able to go to Google or Facebook or something like that. And obviously, sometimes ignorance is what motivates you to follow through, right?
I was doing online classes. I was trying to learn Java. I actually made the mistake of trying to learn JavaScript before doing HTML and CSS. Then I had this weird moment where I was like, what the heck does any of this stuff do? I was like, okay, I can do a for loop, but how do I actually build a website? I don't know what any of this stuff means.
Then I did some Java stuff, found an Android track at a code school in Portland, Oregon, moved up there, was there throughout 2017, built an Android app, started working with AWS, and even a little bit of serverless.
[00:01:15] That was kind of interesting because the realization I had during that code school was, there was one floor and there were like 150 people, and we were all learning the exact same topics, right? And then every month another class was graduating. I had to go through this mental exercise of, when I graduate, what's actually going to differentiate me in the marketplace? I couldn't really find anything for that. So I was like, okay, I'm going to need to find extra things on the side.
So I started doing classes through Udemy. I was doing full-time college on the weekend, taking only programming classes. I started learning about a fellow student there who had a brother who was an AWS developer. Then I got a chance to meet with him and talk to him, and I was like, oh wow. He's doing JavaScript and backend development, but he's also doing this AWS piece and it's super sought after. And at that point, early 2017, there weren't a ton of people doing it.
[00:02:02] There was still a lot of AWS development happening, of course, because it had been happening for a while, but it was still pretty early on in terms of utilizing more cloud-native types of services. In that way, we started an AWS group, where we basically studied for certifications.
I then built an Alexa skill for train arrivals in Portland, Oregon. So you could say, "When's the next Green Line train coming to downtown city center?" It would tell you the time back, and it was using Lambda functions, the Alexa SDK, and of course serverless and all that stuff to make that work.
Then I came out of that like, oh, I've learned all these cool skills. Now I want to actually do it. But I saw the typical path people took was going into junior development right out of code school. So I was like, I want to use the stuff that I've just learned and build something. I decided to try to build what would be equivalent, for people listening, to Deno Base.
[00:02:45] If you've heard of Deno Base, it's basically like a web browser where you don't have to have an AWS account or a database account, but you can visualize DynamoDB, which is a NoSQL database offering on AWS. So I basically made a startup to do that.
Then I recruited the other students for their internship, which would be the follow-on to the code school. We started building, and I learned how to do Cognito authentication, went way deep into serverless, all this stuff. Then about a month and a half after I graduated, a recruiter reached out for a position at Nike. The job description for this application developer matched like 80% of what I was doing during that internship when I was building this product. So that never got off the ground, but it did give me the skills to apply for that.
Even though I didn't have the traditional background, I had launched an app to the Android App Store and built an Alexa skill, and I had tried to start a startup thing and understood authentication and so on a little bit better.
[00:03:36] They gave me a shot. I got in there and realized, oh my gosh, I'm so fresh, as much of a newbie as possible in the space. I was surrounded by people who were super accomplished at the time. I entered the Nike Innovation Engineering department and was actually doing serverless and Serverless Framework and AWS stuff every single day.
We did a ton of cool things while I was there. Some machine learning, lots of background processing stuff. Then at one point I got that itch again to do a little bit more. So I went to Portland Community College and asked them if I could build them a job fair chatbot that would help people with directions and event details. They agreed to it because I was going to charge them no money. I just wanted to use it for the portfolio.
I spent about three months building that on the side and finally got it working. Then that ended up being one of the earliest stages of building Serverless Guru, my consulting company later. This was around mid-2018 at that point.
[00:04:29] All of a sudden we started getting toward the end. Something that Nike is notorious for is that all contractors have the potential of going full time. I kind of saw the carrot being dangled there, and I didn't know if I would get it or not. A company named Mo2 reached out to me. They were a serverless consulting company primarily focused just on serverless and AWS. I jumped at that opportunity. I didn't take more money or anything. I was just like, this is the right path for me.
That was obviously kind of crazy to my family and stuff. At the time, they were like, you're leaving Nike? That's one of the best places in the world to work as a software developer. And you're still early and all this stuff. I was thrown again into the deep end. I ended up being a developer coach for a whole bunch of Microsoft employees with 15 years of experience, out of that process of getting closer to the CEO and learning how a consulting company works.
[00:05:13] Towards late 2018, I finally made the jump and started Serverless Guru, and I've been doing Serverless Guru ever since then. From the very beginning, it was a mix of maybe doing online courses and blogging and taking on some side projects, and it just started to snowball very quickly.
I started going, okay, I've got three projects now. I'm working like 12 hours a day. I've got some friends from the code school and a bigger network, and so I started asking if they could help me and went through a bunch of rocky periods. Now we're a little bit over 22 or 23 people here coming into 2022. Yeah, that's been a long-form journey there for the listeners.
00:05:48 - Anthony Campolo
Now, that's such an interesting story. And it's great because it shows that you don't need to take the traditional kind of boot camp path. The traditional path used to be computer science, but now the traditional path is you go to a boot camp, you learn HTML, CSS, JavaScript, you get a junior web development kind of job, and you really dug into more like DevOps because AWS and Lambda and stuff.
It's coding, but it's not really programming in the same sense that most people think of it because it's not necessarily writing lots and lots of logic. It can be, depending on what you're doing with it, but when you're first learning it, you're really just learning what even a Lambda is, how do you use it, and what does it mean to stitch it together with all this other stuff on AWS. Even now, today, as popular as it is, as many people are doing it, I think it would be a skill set that if anyone really kind of hones, there's going to be so many jobs because there's so many people using this tech and it's still so complex and not really well known enough.
[00:06:54] Once you dive into it and you really learn it, then the opportunities open up to you. I was curious, one of the things you said there is that you were a developer coach for a little bit. I don't know if I've ever heard that term before. What is a developer coach?
00:07:06 - Ryan Jones
It surprised me too when it was used on a call. Shout out to my last boss. Back then, we had this contract project where we were going to do some training, although I was still only probably like a year and a half into my career at that point.
The biggest thing was serverless is, like you said, so new, so complex. Even three or six months can feel like you learn so much, so fast, that I was able to actually help them. It was an AppSync, Angular-type project. They were building a proof of concept for it.
I was introduced as a developer coach to basically coach them through how to use serverless and AppSync and Angular and the Amplify framework for the front end to stitch all this stuff together. In the process of hearing that, then prepping slideshows, and then actually going on site, it was kind of a cool project because I was down in a basement, which is kind of interesting in its own right.
[00:07:55] They had like eight people, all former Microsoft, mostly with way more experience, gray in the beard, that type of stuff. They'd been around for a long time doing development, and then here I am, like a year and a half in, coaching them on how to do all this serverless stuff. So yeah, that was a cool experience, but that's what that meant. Yeah, developer coach.
00:08:11 - Christopher Burns
I'm incredibly humbled to hear your story. And it's really exciting to hear somebody that has no development background come into development, has no proper degree, run their own company, start their own company, and even get to 20 people. And my experiences of serverless have always been interesting.
Our initial MVP was built on serverless, and I don't think I have formed opinions of it anymore. As in, is it good? Is it bad? I'm kind of still sitting in the middle. I can't remember because I've tried to just hide all of that past hatred, but that probably wasn't serverless. That was probably my cost of learning, stitching all these things together.
We're now in a time of things like Redwood that make all of that stuff easier. But where I'm going with this is serverless. I still believe it is a massive niche, even though we think that everybody's talking about these things. Everybody's talking about it, but it's literally like 10,000 people on Twitter across the entire world literally saying, yeah, this is awesome.
[00:09:17] It's still quite niche. And then it's that thing of, okay, how do you even do it? When I built serverless, Serverless Framework was still quite new, I think. So there was still quite a big gap.
So my first thing that I want to ask is how far have you seen serverless go forward since betting on it? Because what you've done is you've bet on it. And have you ever got to a point where you've thought this bet has paid off? Has that happened yet, or do you still think the payoff is in the future?
00:09:45 - Ryan Jones
It's been super interesting. And yeah, it was definitely a bet. Going back to that code school moment when I started doing the AWS group, we actually got an A Cloud Guru video, and I heard Ryan Kronenberg say that serverless is the future. I think that's the exact way that he said it. And in the first video, it was like 10,000 feet of AWS, all this stuff, and it was like this new thing, serverless. And for me, just coming in, not knowing anything, being very fresh and being like, I want to be in the future, that's kind of how that kicked off.
Since then, I think we've seen a lot of maturity take place in these services. There's a lot more best practices out there. There's a lot more people from established companies like Shane Bristles from Lego.com, who has done a huge amount of service to the community for just sharing all of his talks and details about what Lego.com is doing through the podcast, the Talking Serverless podcast that I do as well.
[00:10:33] I've been able to talk to people that use serverless, like the Formula One website and the Formula Two websites. And obviously I got to see it happen at Nike too. And then through the consulting practice of seeing them mature, all that stuff's been really interesting.
Now we have more mature services around AppSync. AppSync was super brutal at the very beginning. So shout out to the team for working on that. I had this moment where I was building a fintech app for group payments, and I was using AppSync, and the structure that they use is like these VTL files or static JSON where you can add for loops and stuff inside of it. Oh my gosh. I was like breaking down, sitting on the floor of my apartment going like, what is this? Why does it not work? I have a client deadline that I can't hit and I don't know how to do it, and there's no documentation and there's no materials online.
[00:11:19] There's no courses. Now, we actually just recently, probably like mid-2021, Jan Kooi has actually come out with an AppSync masterclass course. So when I was doing this back in early 2018, there was none of that happening.
I think if you were starting today and you have some of those resources, I even put out a course between then and now. It's at training.com called the Serverless Zero to Paid Professional course. A lot more I want to do with it in the future, but it kind of just walks through manually in the console, then building stuff through Serverless Framework, and just building a REST API-type structure with Node.js Lambdas and just an introduction to that type of stuff.
So I would say that it's matured. Would I say that the bet has paid off yet? I think yes, 100%. Being able to grow to 20 people has been pretty crazy. At the beginning of 2021, we were probably like six or seven, to get up to like 22, 23 people.
[00:12:10] We've just been hiring like crazy, and we've had projects scale out, and most of the time it's been organic inbound traffic and also word of mouth. So we've had people we've worked with at clients bring us into a different client and recommend us and kind of lay some of the foundation for us based on the work that we did for them. So that's been really awesome.
Now, thinking about the future and where does it go from here? I think that we're scaling up our sales. We brought in a VP of engineering. We have Josh Proto that you all mentioned earlier, our CEO, and we've been setting up all these different automation things around sales and templates and blog articles, webinars with joint partnerships. We did maybe four of those in the last quarter of 2021. We're targeting any Fortune 2000 company, mid-size company that's going to step into serverless and needs one full-time person. We want to be that provider.
Going to AWS re:Invent late last year and then being able to talk to Imra from formerly Thundra, now at Serverless Inc.
[00:13:06] He kind of said something like Serverless Guru is monopolizing the serverless consulting space. I also got to hear from a couple other people that have been in the serverless space, like Pharah from Stackery. She was mentioning that Serverless Guru is, out of the companies that existed back in 2018, still one of the only companies around that hasn't been acquired or just stopped.
So that was also really cool to hear because you get so wrapped up in the day-to-day, you never know how people in the community actually perceive you. So I got some of that feedback, and hearing that was super encouraging. And the investments that we've been making late last year, we're just hoping to go full steam ahead. Yeah, maybe we'll have a follow-on episode where I can tell you in a year from now if it's paid off or not.
00:13:44 - Anthony Campolo
You said a bunch of stuff there. I'd love to get into re:Invent. I'd love to get into that question of acquiring. But before we do any of that, I think it would be useful for our listeners to set the stage of what are the actual nuts and bolts of what your company does. When you are consulting and helping people, are you actually building things? Are you starting from the ground up? Are you giving advice on how to migrate or how to fix? Or are you looking at serverless projects that are already created and telling them how to maintain them better? Or is it a little bit of all of that? What is it that you're actually doing on a day-to-day basis?
00:14:20 - Ryan Jones
We have kind of a spectrum. All the things that you've said, we've done those for clients. So it kind of depends. If we had, let's say, and the only companies I'm thinking of right now are already working with serverless, but let's say Pepsi. I don't even know if Pepsi is its own company or if they're owned by Coca-Cola. I have no idea. But let's say Pepsi.
So Pepsi came to us and they were like, hey, we have all this internal stuff. We want to migrate it. We want to start utilizing serverless. We would first start with doing training, and then from there we start building blueprints using all the infrastructure as code best practices and all the DevOps stuff that y'all mentioned previously, CI/CD pipelines and so on. Then from there we would move to developer support.
So we would ideally, what we're trying to do is enable them to build independently of us. We're setting a really strong foundation, letting them build, providing the support. Then what ends up happening from there is they end up bringing us in as architecture consultants.
[00:15:07] So, hey, we're about to build this really high-traffic service. We're thinking about using Kinesis, or we want to use EventBridge or something like that. Which one's the best option? Then we'll go and we'll build a proof of concept for it. We'll test it, and we'll give them a confirmation one way or the other. And then also we get into more of actually building things for them. They end up going, okay, the value proposition of Serverless Guru is yes, they cost more. However, they're more efficient at doing this because this is their sole focus.
So they'll have us basically build out a proof of concept that ends up integrating with their code as well and working with other teams and service owners. Then we'll hand it off to somebody internally at the client. So that individual Pepsi developer would then pick that up from where we laid it. Then they would maintain it and add stuff to it. But that allows them to skip from zero to like, let's say, 50 or something a lot faster.
[00:15:56] So that's a full spectrum service type thing that we might do for a company like Pepsi. We also have companies come in who their CTO already knew about serverless, and they did it at a prior company. They know that this is an option that they want to take to limit the amount of people that they have to manage. They already know the benefits, they already know how it works. They don't have to go through that whole discovery phase, and they've got money to invest.
So in that case, let's say a somewhat early stage startup type of company that's trying to move really quickly. They might just hire four or five of us, and then we basically run their engineering team. So we're going to run the day to day operations of it. We're going to learn the domain of the client. We're going to work directly with their stakeholders, and then we're building everything out from scratch basically. And so that's the greenfield development side.
And so if I gave a spectrum of where does it all work out to?
[00:16:42] We really don't do training in isolation, so that only usually happens when somebody is doing a much larger multi-year type of transition. We do a lot of greenfield development for multiple clients still, and we're actively helping them go from development to production in that way.
We'll also help them take existing serverless things they've built. We get this sometimes too. They might have hired a developer who was doing serverless. They were learning the ropes of it. They started kind of just hacking things together. And then they're like, hey, we actually want to roll this out, or we already rolled it out and we had all these problems happen. Can you come back, review it, optimize it, and then just get us back on track?
And those are a lot smaller projects typically. Yeah, that's kind of the full makeup there. But it's like 98% AWS serverless. And I would say, obviously, we use CloudFormation, as Serverless Framework uses that under the hood. But I would say Serverless Framework, in terms of infrastructure-as-code providers, is probably 95% of all the work that we do.
00:17:35 - Christopher Burns
I have so many questions that I would love to ask, and I'd sit here all day asking them. But one of my biggest questions is everything you seem to be doing sounds like, without the staff side, the automation side. Do you think this is obviously IP that you have learned? You have learned how to really do it well. Do you think that this is knowledge that should be widely available that Amazon just haven't written, if you know what I mean?
00:18:08 - Ryan Jones
Let me make sure I understand. So for instance, we have templates and stuff, and we basically build these templates out. It includes a lot of what we've established as best practices from just falling into holes over and over again. And then we share that out to the community. Is that kind of what you're describing as do you lock that up or do you share it type of thing?
00:18:25 - Christopher Burns
Okay, let me reword my question. We've seen a lot of platforms sit on a third-tier cloud, basically abstractions on AWS, but you seem to be sitting a level lower by saying, you know, we're going to work with you and AWS and show you how to do it instead of using the third-party platforms. They abstract the knowledge. We're going to give you all the best tools to do it directly on AWS.
Do you think there's need in the serverless infrastructure to go higher to that third-tier platform? I think that's what Serverless Framework is doing. Or do you think it always pays dividends to stay lower with the best practices that you've learned and basically building your own templates?
00:19:05 - Ryan Jones
Yeah, for sure. This is a really interesting question. Transparency, we used to build our own website, and now we use Webflow. That transition is somewhat similar to this because when we were building our own website, we were writing everything, the HTML, CSS, we had React, we had all this stuff happening, but then we had to have a full-time React developer to modify it. Then we started adding in Redux and things like that. We didn't have people that knew how to do it necessarily at the time. So that got super complex and messy, and all we wanted to do was have a page.
I think there's a spectrum of where you're at in that, right? Maybe I've seen more of a story arc with myself and my serverless evangelism where I go, if you're early in the process and you don't even have something established, serverless might be the wrong bet, especially if you don't know what you're doing.
[00:19:48] And if you can't hire somebody, because obviously it's a very competitive marketplace that favors people that have investors or already revenue coming in, etc., to hire a team or hire consultants and so on. So in that way, I would say no, you shouldn't use serverless.
Then when it comes to you're already using serverless, do you use a product that abstracts over AWS? Yes and no. And it's getting better. This is my opinion and is somewhat outdated just because I saw the transition take place with a service like Amplify. At one point with Amplify, we actually got projects where people were like, we used Amplify, we built all of our stuff with it, and now we're starting to get to production and we don't know how to modify anything. And we've boxed ourselves in and we need to start from scratch. That's a really huge loss, right? To be able to go to that point using something that abstracts it away and then have to go back and learn the nuts and bolts of it.
[00:20:37] I would say that if you have capable people that already have some AWS experience, or if you just have a long-term vision about why learning this today will pay dividends later, then that's where learning how everything at this lower level makes sense.
If you are earlier on and you want to build a proof of concept, use an abstraction, build something quickly, ship fast, make sure that people actually want to use what you're trying to build. But then if you already have an established product, you're Pepsi, and you know that this stuff's already established, you've got a team of people that are capable, you have a long-term vision about this, and you don't want to potentially run into a situation where you box yourself into this third party.
Will they exist? We've seen that happen with Stackery. I don't know if Stackery is still operational right now. I'm pretty sure they slowed down. They got acquired by AWS.
[00:21:25] So I have no proprietary information there about what's taking place. I just know that they had an abstraction over AWS. They made it a little bit simpler and then they went away.
There's that fear as well of if you're on Stackery and then that happened, or if you're on a different platform and it happened, now you have to go back and you have to do what you could have been doing from the beginning. So it all just depends.
I do think, full transparency, Serverless Guru has a skunkworks arm, right? We've been working on something because we've seen this problem take place where, when you're sharing templates and modifying templates, you end up just building more and more. Our templates repository probably has like 100 different folders in it. We've got templates that do API Gateway like three different ways because of just how time takes place. Oh, I didn't know that existed, so I update the existing template or I made my own. And mine's slightly different, but not too different. So when do you update the one that's existing versus creating a new one? It gets really messy.
[00:22:15] And you know, the product that we're working on right now, the name is like Cloud GTO, allows developers to automatically generate those templates. Because of that automation, it's basically spitting out the way that we might write Serverless Framework infrastructure as code with our best practices in it, in a human-readable, auto-generated way.
And the idea there is that we're not trying to take it all the way to the level where we now have this cloud abstraction that's an abstraction over other abstractions. We're just using that product as a simplified UI way of generating Serverless Framework and CloudFormation, which is a little bit more low-level. So can we make the low level easier? And that's kind of what Cloud GTO is.
00:22:55 - Christopher Burns
You seem to have the market potentially at one end right now of the enterprise, you know, the big fish in the ocean. But serverless also says, you know, this is great for just building a side project. And then it's that thing, serverless says it's great for a side project. And then I watch a talk where big X company now runs on serverless. Yay. And then there's everything in the middle that's just like, do I run on the server? Do I run servers? It's terrible to say, but it depends how you look at things.
What's easier, this massive templating format or going on to DigitalOcean and clicking Ubuntu, Docker, done? It really depends. And if you ask me, do you see a benefit to servers? I would go, I don't know. Do you see a benefit to serverless? I don't know. Do both of them spit out the same API? Yeah. This is the thing where any help in that middle ground is that massive thing.
[00:23:48] When you're going from small to medium, you need that help scaling and understanding why you should make these choices. And then medium to large is like, I've already got a massive problem, probably a massive bill on AWS that they want to reduce without losing performance. And how do you do that? I definitely think you can tackle both ends as you're proving.
I guess the biggest thing is where do you think AWS and Lambdas as a function are now, and where do you think they're going to go in the next few years? Because as you said earlier, you've seen a lot of maturity in the area. Are we going to go through another wave of innovation, or are we going to go through another wave of maturity, do you think?
00:24:29 - Ryan Jones
It's tricky to predict the future. What I would say is that I think people are trying to attack it right now with AWS CDK, and they're trying to create a different way of programmatically creating infrastructure as code and creating these constructs, which allow you to create things easier.
I don't want to go off on a tangent, so I'll dial back to a project that I did back in mid 2018 or something to early 2019 when Serverless Guru was starting. I've been doing serverless. I had worked at Nike at this point, but somehow I found myself in a technical operations team at a large company working on EC2 instances. So that was a weird shift. It was a weird point in my life in this whole journey.
They had 250 servers that were considered black boxes. The people that wrote them, they left, and now they just got this million dollars a year bill or $2.5 million a year bill for all these servers that are running. And nobody really knew how to approach it.
[00:25:18] But other parts of the company started building abstractions to do things easier. Like if they wanted to run a container, then you just had to have a local Docker file, use their little YAML file, and then it would basically do a whole bunch of stuff in the background using their proprietary system. This was internally built there and it wasn't public facing or anything. And then it would basically spit out your entire setup using the guardrails that a specific team, like a Cloud Center of Excellence-type team, defines.
What I ended up doing is helping that team basically identify servers, decommission them, even going as far as doing automation to turn manually created EC2 servers into CloudFormation.
So just saying that full spectrum to say how are things done in the past and is there a wrong way to do it, and can you shoot yourself in the foot like that? Absolutely.
With previous ways of doing things, what we ended up getting into, at least with like let's say we're going to build containers or build a server, but we're going to use infrastructure as code, that's already a huge jump forward in terms of manually setting stuff up.
[00:26:18] And I think there have even been analogies used from Google, where they run like 200,000 or 2 million or however many. They're running a lot of containers, and there's no way for them to be able to go into a container and do something manually. They have to have crazy amounts of automation.
Now moving to the point of where does all this lead, we're coming into no-code as an option as well, where people are starting to, you know, I was just talking about Webflow. Webflow is still that mix between pretty much no code and that click a couple of buttons and I can get my website up and running. I can get my head of marketing to go in and modify the little CMS database, and that'll show up and reflect in the website. And we didn't have to write any of that. And so that's super helpful.
[00:26:58] However, if I was going to take that Webflow app and then try to build a real web application, it breaks down instantly just because it's not its purpose, and you end up finding yourself going into this little corner and writing all this really complex code that's working with some Webflow internal ID stuff. You're going through forums to figure out how they connect and it gets super messy. And then imagine trying to scale that out. That gets really weird.
I think that there's this line with abstractions where it's like, you can go this far and no further, right? And you talked about people that are just starting or small use cases, like side projects, and then much larger things. I think what we're going to see is it diverge.
We're going to see that divergence happen with something like Serverless Inc. Serverless came out with Serverless Cloud, and so that might be an area where people that are building new projects similar to an Amplify or a Vercel or something like that, they're using that. They don't have the people internally that know the nuts and bolts of it.
[00:27:55] They don't need to really draw outside the lines, and they can use this to accomplish what they need for a couple of their use cases. And if they do end up needing to draw outside the lines, then they can leverage the other side, which is like just straight Serverless Framework, AWS SAM, potentially CDK. I think that that's definitely going to keep maturing, whether you have almost raw CloudFormation. Do you understand at the lowest level how this works, and then also the abstraction level, and then is it going to work or not going to work?
That's the part that's tricky about it because I could very easily see somebody going into a situation where they get boxed into a solution, and then they have to rewrite and actually learn the lower level, especially for the next couple of years as all this is maturing right now. If you went into one of those solutions and you tried to build a REST API suite, you can do that. You try to build your own website and host it, great, and you start trying to get into more complex things and you run events through it.
[00:28:48] And your company now has these third party integrations, and it needs to be private. And then you need these environment variables, and all this stuff starts stacking up. And then it's like at that point it breaks down. You have to use a different option.
00:28:59 - Christopher Burns
There's so much there to unpack when we're talking about these abstractions. The two most popular ones we know are like Netlify, Vercel, where they're like, we just do the serverless functions for you, and you just write your Lambda function and everything's golden. You know, everything's handled.
And that was my point that I was saying earlier, like the small to medium. That's what Vercel and Netlify are saying. We've got this. You just write your Hello World function here. Everything is done.
And the larger, like we literally only touch AWS. Nothing else. Like never not talk AWS to me.
So it's like this middle ground, as you're saying, is how do you help people go? Even the hypothesis of, would my platform run cheaper and faster on serverless? How do you go from a point where you go, well, it's all running on PM2, to I can run it all on serverless? How can you even test that? Because it seems like a great hypothesis, but you'll only know the answer once you've committed to actually doing it.
[00:29:56] Or do you?
00:29:57 - Ryan Jones
Yeah. So this is really interesting because there's always the cost calculation stuff, you know, and that's usually the first thing you see posted, like why serverless or something. It's like cost efficiency. It turns off when you're not using it.
But then we have to step back and be like, how did it get there? It didn't just show up. It's not like a magic ball. We just shook it, and now all of our infrastructure is built. We had to pay engineers and people that are helping with DevOps and supporting project managers and all these external things that are all feeding into the cost. The highest cost of your serverless architecture might be your engineers and your entire team. The highest cost for doing Kubernetes might also still be your team. And the highest cost of doing servers could also still be your team.
I think that's an area that's not looked at is what are you actually trying to accomplish? What is the goal of doing this?
[00:30:40] Are you doing it for a resume? Are you doing it to have a press release that you're doing it? Or is there something more core in there? So I guess, imagine that your entire team is, I won't cuss, but super good Java developers, right? And they've been running Spring Boot servers and they've been doing containers with Spring Boot and so on for a while. And they know what they're doing. It's their domain. And they've been using MySQL or Postgres and that's their stuff. And then you have somebody come in that's like, look, we're going to switch everything to serverless. We're going to go from relational to DynamoDB, we're going NoSQL versus relational, and we're going to move everything to this new way of doing things.
I think that it is really important to ask why that's happening, and to look at the real cost factor there too.
[00:31:26] For instance, you could do a reverse calculation of what does a feature mean in terms of revenue, right? Potentially the new feature release is worth more because we've seen projects that run where they're doing a full serverless transition. At first it seems like it's just going to be this small couple of things and it's going to be simple. Then very quickly it's like six months later, eight months later.
Because like any type of fundamental technology transition, just because you can build a REST API in like 15 minutes doesn't mean that you can take your entire company and move it over with hundreds of services in like two months or something without tons of chaos happening.
So as you're making that transition towards it, there's going to be this cost factor of lost revenue because of maybe reduced features being released because you're building an entirely new system. You have to go back to the drawing board and you have to retest everything.
We've seen stuff happen where it needed to run like 30,000 requests per second, like that was their threshold for testing.
[00:32:22] And we had that question of, can we even duplicate that in serverless? The amount of time it took us to figure out if we could do that or not. That stuff, if this was maybe a few years later in the future, right, maybe we'd have more of an abstraction that helps with something like that or a website where we can ask that question. But we ended up taking like two weeks or something just going through testing, figuring out exactly how Lambda scales and so on. If a company was doing that themselves, one, it would be super discouraging because the server side already worked. And so you're now having to replicate it over here.
Yeah, so it's kind of complex. And I would say almost like everything we talked about so far is never black and white. It's never 1 or 0. There's always this really murky gray area.
So if I had a team and I was running the organization and they were really good at Java Spring Boot, and we were already productive and we were already pushing stuff out, then I might look at one layer up and instead of going like, let's go and just slash everything and start over from scratch, because there's another side of things where it's not just purely the technology, it's also the domain knowledge.
[00:33:19] What does your company actually do? I've seen on the ground where, because an initiative is put into place without getting the low-level buy-in of everybody, you end up having people that have like ten years of domain experience leave the company because it feels like they're almost being talked down to. It feels like this is the old legacy past side, and this is the new awesome Ferrari side, and you're not part of that. And then that domain experience, that ten years, that's where you lose a ton of money.
I don't know how deep people actually go into doing these calculations at their organizations, but I wish they would do more of it, to be honest.
00:33:52 - Christopher Burns
My last big question: have you ever seen serverless bite a company in the ass? As in, you know, as you said, it's their number one priority. Make everything serverless. And it just ruined the company.
00:34:06 - Ryan Jones
Yeah, I've seen it happen. It's like, I think someone says it about pilots or something. When a plane crashes, it's not like one mistake. It's like seven or eight or 12. It's like that entire day.
In terms of the company that I saw this happen to, they were building it out with Serverless Framework completely, 100% serverless, but it was very early on. The maturity wasn't there. They were potentially doing it for the wrong reasons. They were trying to use the latest and greatest, and that was being pushed when maybe it shouldn't have been pushed. There was disorganization, things like that.
The result of it was they got delayed like months and months, eight months plus, and they never were able to actually launch something. By the time they were actually getting ready to launch something, they had already burnt through tons of capital. And there were other competitive services that were already on the market at that point because that's the way that the wind was blowing.
That's where time to market with using, let's say, a container, or not even a container, but just a server, and then just having a front end developer and then just manually doing stuff, that was probably the better route.
[00:35:04] Obviously you only see some of that stuff looking backwards, but that's part of the reason why there's always a caveat to what I'm saying, even on this podcast, because I've seen that happen. It's very important to take into consideration where you are today when you're building something.
00:35:17 - Christopher Burns
Exactly. And the thing is, I love to ask all these questions like is serverless worth it, you know, all these things. But at the end of the day, there's a big reason a lot of your clients are big companies, because they have enough money to work out truly what is the best thing they need. When you're small, agile, and really trying to work out the point, deciding if you should be on a server or serverless is probably not your number one priority.
00:35:41 - Ryan Jones
Yeah, and that's the thing. No one cares whether you have a good server or not. Your customers don't care. They don't see it, right? The only thing they interact with is your platform.
Let's say in this example, obviously people build different things, but in this example, a web application. That's the way your customers interact with it. Or a mobile app. They don't see anything that's happening behind the scenes. They just want it to work. They want it to be efficient, they want it to be fast, and they want new features to be released quickly.
If something else in the market is competitive, you have that financial obligation as well, and also to your customers, to get that out as soon as possible, because otherwise people go, okay, these three things have it. Yours doesn't have it. Now I'm going over there.
00:36:18 - Anthony Campolo
So I would like to ask before we close it out here, as someone who has gone through this whole journey and has done it fairly recently, what would you recommend to someone coming in today looking to get into either development or serverless or any of it? Maybe they are starting totally from zero, or they have a little bit of boot camp experience. What are some resources? What are some words of wisdom that you would impart on someone in that area?
00:36:43 - Ryan Jones
Yeah, I love this question as well. That's why I try to start the story all the way back so it gives perspective.
So I would say that if you already had some experience, let's first start toward the more advanced side of that, which is you're a developer at a company. You are looking at serverless. It seems like it could be a good fit, but there's this entire spectrum of things. Or you're just now starting and there's an entire spectrum of stuff that you want to learn.
Build something and learn only what's required to build it and forget everything else like it doesn't exist. There's thousands of services on AWS, and there's always new stuff coming out every single day. I don't have my RSS feed on for AWS. I don't look at the announcements. I'm typically not following that because now I have a team of people that, if something's important, they end up announcing it or something internally. So I only look at what people value, or the Twitter community will shout out, but I'm not following the feed like that.
[00:37:34] I did that for a long time. Also, I'm not trying to go after every service. So if you just want to build, let's say, an Alexa app, that's always a really good way to see something end to end. Use AWS services, mix that in with your Node.js or Python background, or I'm sure there's Java support and C# and so on, Golang.
You can buy an Alexa hockey puck or something, or you can use an emulator online. You write some backend code, you follow a tutorial, you just search like Alexa Node.js tutorial. You create your AWS account. You set only a couple of things up. You download something locally for your code. Maybe you use some packaging thing like Serverless Framework, although I might even recommend not even to do that.
Go into the console, go into Lambda, drop your code in manually like that, and then just hit the deploy button from there. Don't even worry about infrastructure as code at this point, and then just try to get it working as fast as possible with the least amount of friction.
[00:38:25] And that would be no infrastructure as code, no local development, really. Just plug and play these things together. And then from there, once it does work, then reverse engineer it. Okay, now let me go one step back. Let me try to move that Lambda function I put in manually into the console into infrastructure as code. And then let me just try to, like maybe my Alexa skill needs to store some data.
Okay. Then I'll add DynamoDB in and I'll look up Alexa, Lambda, DynamoDB, and I'll find an article there. I'll grab a little bit of code and a little snippet of infrastructure as code for a table. I'll add that into my template. And then from there, now I've got Lambda, I've got Alexa, I've got DynamoDB.
Then it's like, okay, I've got some HTML and CSS experience, so I'm going to write a little front end, or even if I had React or Angular, write a front end, and now I want to connect it to a back end with serverless and AWS.
[00:39:10] Okay, I'm going to look up the Amplify framework. And then I'm going to try to build a REST API. So I'll look up API Gateway, serverless REST API. We've got a lot of articles on it as well at Serverless Guru. So if you just typed in exactly that, AWS REST API Serverless Guru, you'll see a couple of articles from us.
Then you're tackling API Gateway, connect it to a Lambda function with DynamoDB, and you're showing it in your front end using Amplify. That's honestly like 70%. You're really going a long way just being able to do those things. Obviously, you could almost niche down inside DynamoDB or API Gateway or Lambda and go super, super, super deep.
But the point is we're actually trying to build stuff, right? I think sometimes people get too caught up trying to optimize. If you optimize the packaging of a product that doesn't exist, or you're optimizing the infrastructure as code of a product that doesn't exist, or you don't even have a V1 out, that's actually not good.
[00:40:00] I think that's really easy to do with serverless. And I think that's where we see people kind of spin out. It's hard to keep those blinders on and not look at all the cool, shiny stuff around you just to get something deployed.
And that's why in that course that I made, Serverless Zero to Paid Professional, it starts manually in the console and then just slowly adds stuff in, getting the full thing working only in the console, which I'm sure people on Twitter would be yelling at me about. Then taking it locally and then doing a little bit of infrastructure as code to rebuild the exact same thing, but a complete replica of it. So I can compare side by side and say, why doesn't my Lambda function connect when I try to make the API request? Okay, let me look at the one I did manually. Oh, I forgot this permission. So I'll add that into the local one, and I'll just go one by one through each one of those until I have a full thing out.
[00:40:41] I would say just do that. Try to limit the amount of things that you put onto your shoulders. Hopefully that's useful.
00:40:47 - Anthony Campolo
Yeah, that's actually really smart, building something in the console first and then looking at the infrastructure as code, because I'm always kind of bouncing back and forth between the two of trying to do everything with infrastructure as code as much as I can.
But then you are using these abstraction frameworks and then you're running commands and then you're getting all these error messages, like what the heck's going on? So I think that's actually really good advice, even for people who are like, hey, click ops. It's kind of a necessary evil, I think, when you're learning.
Unfortunately, we are all out of time. This has been such a great conversation, and we would love to get some other people from your team on as well. Before we close it out here, go ahead and let our listeners know your social, your website for you personally, your Serverless Guru. Any links you want to direct people towards?
00:41:34 - Ryan Jones
Yeah. You can find me at twitter.com. Pretty simple one there. Ryan Jones is also my LinkedIn. I probably have a personal website, but don't judge me on that. I created it a long time ago, and then serverlessguru.com. That's 100% of my focus day-to-day.
What you can find on there are our blog resources. We're rolling out a lot of stuff right now around EventBridge, API Gateway, Lambda, DynamoDB, Serverless Framework templates, and usually the articles have a template associated to it. So we're trying to do that right now.
We also have a podcast, the Talking Serverless podcast. Look out for our webinars, things like that. So if you want to find all those type of updates, you can find them at twitter.com slash guru and we just blast all the different things we have going on there.
But yeah, I really appreciate being on the show. Thanks for letting me get a chance to kind of self-reflect over the past year. This is super fun.
00:42:24 - Christopher Burns
Thank you for your time today.
00:42:26 - Ryan Jones
Absolutely.