#44: Real-World Serverless with Ryan Jones

You can find Ryan on Twitter as @ryanjonesirl.

Get in touch with Ryan and the team at ServerlessGuru at https://serverlessguru.com and check out their podcast TalkingServerless.

For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.

Opening theme song:
Cheery Monday by Kevin MacLeod
Link: https://incompetech.filmmusic.io/song/3495-cheery-monday
License: http://creativecommons.org/licenses/by/4.0

Transcript

Copy Transcript Copied

Yan Cui: 00:12  

Hi, welcome back to another episode of Real World Serverless, a podcast where I speak with real world practitioners and get their stories from the trenches. Today, I'm joined by Ryan Jones. Hey, Ryan, good to have you on the show.

Ryan Jone: 00:25  

Hey Yan, thanks for inviting me. And I'm happy to be here.

Yan Cui: 00:28  

So you first started Serverless Guru back in 2018. Is that right?

Ryan Jone: 00:33  

Yes, that's correct.

Yan Cui: 00:35  

From what we discussed before, you guys have done some really good work, helping a number of different customers with adopting serverless technologies. And maybe can we get started by just talking about your experience and how you got into serverless in the first place?

Ryan Jone: 00:51  

Yeah, absolutely. So it was, it was kind of an interesting story for me of how I actually got involved in tech. Started off in Texas, I was trying to figure out what was my career path gonna look like. And then I saw a YouTube video about code school. I was still like in between whether doing like economics or finance, or trying to do programming. I started taking Udemy courses just on random stuff like Android, saw the code school thing, jumped in, you know, both feet. And I basically left all of my stuff in Texas, I moved to Portland, Oregon, was living on a couch and then went to a code school. While I was there, I was just like, really lucky timing. One of the students had a brother who was a cloud developer, I had no idea about cloud, AWS, anything like that. This was in late... This is like late 2016, early 2017. So once, once I got in connection with that person, and they started telling me about cloud development and what their brother does, and the opportunity that was there. We started actually spending time taking AWS certifications and studying as a group after the code school class would be over. So we stayed after hours there. That that kind of snowballed into learning about serverless. And one of the platforms that I actually used to learn about serverless, that it was even a thing was A Cloud Guru. And I heard, I think Ryan Kroonenburg basically say something like serverless is the future. And I was like, great, you know, I'm, I'm starting from scratch. I don't have any preconceptions about how anything should be done. Serverless is the future. I want to be in the future. I want to be on the cutting edge. And so I went that path. And in my group projects and stuff during the code school, I started building out Alexa skills, working with Lambda. At the time, I still wasn't very familiar with servers, and how a lot of the enterprise operational stuff actually happens. That came much later. And I just got my feet wet in it. I was able to make Alexa skill that helped with the collaboration of a couple people on the team as well. That would actually tell the train times and hearing it speak back to me. I didn't have to get into an EC2 instance. I didn't have to configure anything. I just... we wrote some Node.js, we put into a Lambda function, we hooked it up with the Alexa SDK, and I think Amazon Lex as well. And then we had this working voice coming out of this machine telling us when the next Green Line train would show up in Portland. Out of that, I ended up trying to do a startup where I was trying to do basically, I think Dynobase kind of did, where they did it way, way better than my idea was, but it was kind of just, I don't, I don't, the barrier to entry for AWS is, it's getting better. But it's, you kind of have to understand IAM AWS account creation, a lot of different things to even get something very basic, like a database setup with Dynamodb. So the idea was abstracting all those layers away, you can just basically sign up, you can create a Dynamodb table, actually start interacting with data. And that was around like mid 2017. I had no idea what I was doing. But it was really interesting, because I got to go down a rabbit hole of AWS Cognito trying to build out the web app. All that stuff basically gave me the preparation to apply for a job at Nike in their application engineering, or sorry, the Nike Innovation Engineering department. I didn't know at the time, like the exclusivity of that. But once I got in, all I was doing everyday was writing serverless framework, infrastructures, code Node.js, quickly got tagged with like a senior title, which, you know, hindsight, you know, maybe it was a little bit early on that. But ultimately, I worked really hard on the weekends and at nights to kind of catch up to the rest of the team there. And it was just surrounded by people that were really smart, doing incredible things. And that that snowballed for about eight months, and I started realising that serverless is more than what I was doing at code school. There's a whole bunch of best practices around building infrastructures code and building out applications and architectures. And what I started noticing is that although I only had six months or a year of experience at the time, the knowledge of serverless that I had in the knowledge of infrastructures, code, and cloud was actually more advanced than a lot of the people that I was working around that had ten plus years of experience doing other things, 20 years of experience, they were much better at writing application code than I was. But when it came specifically to writing infrastructures code, I found this niche. And the second, I found that, I just wanted to keep diving into it further. Right around that time, about eight months into eight, nine months into being at Nike, someone reached out to me a serverless consulting company, very early on in 2018, I ended up deciding, not going to try to risk going full time with Nike and going through that process, I'm going to make the jump here, I wanted to do a consulting company myself. So this felt like this might be the the ground level entry for me to understand a little bit more about how things actually work, and see if this is something that I actually want to do starting a consulting company or not. And so once I got in there, and we started doing it, it was just I was blown away, because I got thrown into the ocean. And I realised that in situations like that, I think that that's where I thrive the most is when there's a lot of chaos, there's uncertainty, and you have to kind of figure out how to make things work. And so in that process, I went to a company and did training for all these senior Microsoft developers had 10, 15 years of experience, and started teaching them about serverless and working alongside them. And we were doing all this really cool stuff like SQS queue, you know, Lambda functions and Dynamodb and all this stuff. And I was working alongside them writing infrastructures code, doing training with them. And this was still only about a year into my career, or about a year and a couple months into my career. Out of that process, I stayed there for about eight, nine months. And I felt like okay, I'm, I'm ready to kind of take on some projects myself and start learning how to do this a little bit more, I felt like I had potential to take it and turn it into something. Because that time, around mid 2018, serverless was still very new, still is new. And I thought this is a perfect time to just take on whatever projects I can find, trying to build stuff out. And so once I made that switch, ended up doing like two, three projects at a time, which was very crazy. And it's hard to look back now and figure out how I actually got that done. But early days of Serverless Guru started right around September of 2018. And by December, we had like three projects going and I had one person, two people helping me like part time basis, and a lot of support from family and friends. And then once we got into 2019, that's when things started actually picking up a lot more, I ended up doing some talks at a couple Meetups ran into a few more people and just gradually started adding people to the team. That's when I met Joshua Proto, who's now our VP of operations. I met a couple of consultants at the Meetups. And I was just saying yes to whatever came in the door. And out of that grew, you know, kind of an international serverless consulting company that has 16 people in it now. So it's, yeah, it's been a journey.

Yan Cui: 08:01  

That's quite an amazing story, just in terms of how quickly everything since about happened. A lot of people have asked me about how to get into Cloud computing, and what are some of the, I guess the ways to learn about all these different things, and be good at them, because there's just so many things you can do nowadays on AWS alone. And I think what you have managed to achieve is pretty amazing, especially in the sort of the short time span that you have been doing this. And really, really congrats on the success that you've had so far. So I guess there are a couple of things I want to unpack there, which I think there's some of them. Your experience is really inspiring for certainly a lot of people out there who are looking at cloud computing and and want to get into the field. What are some of the most difficult things for you as you were trying to learn about programming and how to get into the cloud?

Ryan Jone: 08:55  

Yeah, good question. So I think what I kind of faced was this huge body of knowledge that already existed and trying to just figure out like you said, what path do you go. There's so many things that you can do with serverless, or cloud. And I think the path that I kind of went down to start learning about it, as I just said, I'm going to build this web app, which was kind of automating the creation of Dynamodb tables, I'm going to try to build it out, I'm going to try to learn everything that I need to learn to basically make it a reality. And in that process, I ended up gaining a lot of things. I like, if you would have asked me like, what services should I work on or something I wouldn't have known the question, or I wouldn't know the answer. But as I got into it, I started learning Okay, for authentication, there's Cognito. And I ran into an issue with Cognito. And so that I found another thing. And I just kind of go... I went like one by one, adding things to that list to try to make something real. And then as that kind of came together, I started realising, Oh, wow, now I fit like 80% of this like, you know, senior Application Engineer developer type of role because it was still so new in 2018. So I think that would be my advice to anybody that's looking to start. Try not to be overwhelmed with like, for instance, we're we're in the, we just came out of the re:Invent rush of AWS. I mean, that overwhelms me as well. And I'm sure it does other people in the community, how many changes are happening constantly. But in reality, it's like, you know, you want to do something like, run something on a timer, you want to have a website that does authentication, you want a back end that does some processing and sends an email. And so focus on that, and in that process, eliminate everything else and work strictly on making that a reality. And then as you do it, then just go to the next thing and make that a reality. And then one by one, just keep doing that. And after you do a few of them, maybe ten, ten different use cases, then you have kind of a this idea, this web of knowledge of how things actually interact. And then past that point, you can then look at how do you increase, you know, your your workflow. And I think that's a really tough question as well as how do you be effective and efficient with cloud development? 

Yan Cui: 11:08  

Yeah, I think learning by doing is probably the best way to learn. And certainly, I think that's been my experience as well, just when I want to learn about new service or how it works, just you know, start working on a, like a proof of concept or some kind of a dummy project, so that I can get my hands dirty with the with the service and really learn its ins and outs. And certainly, as you look at AWS from the outside, it looks like this giant massive thing with 150, maybe 200 different services. But for most application developers, you don't need to know all of them. If you can just focus on specific use cases like you did, you can actually just narrow it down to maybe two or three services at a time, learn those and then gradually to just work on the other use cases and expand your horizon. Even nowadays, I probably don't use, I probably use only about 10, 15 different services max for any given project, even though there are loads of other things that you may touch here and there. But most of the time, you don't need to know them all the time, or at least you don’t need to use them all the time. And in terms of the Serverless Guru, what are some of the challenges that you faced in terms of building up this consulting business? I've kind of gone through a similar journey. But I guess I've been working as an independent, rather than as an agency. So I've not had to worry about things like hiring people and understanding international employment laws and things like that. What do you, what are some of the most challenging things that you face as you're trying to build up and ramp up Serverless Guru?

Ryan Jone: 12:45  

Yeah, it's a great question. One thing that's different from tackling the development side and just tackling a use case, and be like, I'm gonna learn these two, three services, understand them really well, make the use case, having a business is like you get thrown everything. So all 100 services at once, pretty much. And then it's like, which ones do you prioritise? And how do you keep the boat above water while you're trying to figure out how to do all this stuff. So I think the the major challenges have just been knowing, like, knowing what I don't know, I guess, and figuring out what things I didn't know, and then trying to figure out how to tackle that or hire somebody to fill the role, and then doing that in a way that's healthy and balanced. And slow enough that we're not scaling past the amount of revenue we have coming in. And making sure that, you know, I'm not having to take out huge loans from a bank or something to pay for this. Because I'm, I'm mismanaging and I'm trying to, you know, make something happen. That's not not ready for it yet. So I think where Serverless Guru has kind of been great. Looking back on it, as you know, we've never gotten outside funding, it's been completely revenue based, and self self investment on my end, from doing some consulting work prior to Serverless Guru. And then through that, just just learning, tackling things as the pain happened. So for instance, taxes, typically, at least, we're getting better at now. Taxes would get pushed out to the kind of like end date, where you have to file and it was like, Okay, this is super painful now, it has to be done. Okay, let me figure out what I need to do to get it done. Hiring wise, it was just kind of, let me just take my best crack at it and see if that'll work. And I was very accommodating really, really early on because I knew my background. And so I think that I had a, I have an ability to think to see potential in people and understand the skill set that I have, and then how that's worked out in consulting, and then look for that in other people. And so then once I saw that, I was very willing and it was very early on as well to just take a chance on people and see if it would work out. And if it didn't, I didn't really hold anything against myself for making a bad decision on that. And a lot of and it's just the the the messaging of Serverless Guru has been really powerful because while this whole thing was happening, and we were trying to build stuff, I was writing a lot of articles and making a lot of contents and doing Meetup talks. And I think that that's sort of attracting more talent and more talented people. And then as we started growing the team and doing more social media marketing, or doing a training course, and all these things, it started increasing the amount of people that came in. And then as that happened, the actual people that are in the recruiting pipeline, for instance, are much higher quality, and they don't have to be vetted as much. And then we just focused a lot on the processes. So I think people would probably be surprised that if they saw the inner workings of how Serverless Guru actually operates, like, we have processes and CRM for everything that we do, like, you know, emails, or you know, emails were scripted like that, like we, we try to take an approach similar to programming and writing templates and infrastructures code, to try to take that approach on all the processes internally. So now recruiting calls for recruiting sales, how we manage the team, trying to do mentorship for new consultants that are working with clients, managing expectations of clients writing statement works, all that stuff is now scripted to a large degree. And I think it's really cool, because as we focused on that, since the very beginning of Serverless Guru back in like early 2019, all the way to now, we now have enough processes that, you know, if I... This is kind of the very dramatic thing, but if I, you know, if I got hit by a bus, ideally, I don't want 16 people to have to just be, you know, out without a job, all that stuff and, you know, have see this whole thing that's been created over the past two plus years just kind of fall away. And so that's been a really big focus to me is trying to make sure that every like, my whole job and everything that I know or understand and all that knowledge that I've acquired over the past two plus years, is put into documents and notes and videos and internal videos. So that if anything ever happened, obviously, the whole company can move forward. So I guess like that's a really long winded rant, that's probably not completely irrelevant to the question. But yeah, there it is.

Yan Cui: 17:10  

So you mentioned earlier that you're coming into the industry with fresh eyes, you don't have the preconceptions about how things are done. I guess that probably also applies in terms of the interview process, as well, as you're quite curious about how your interview process looks like? Because one of the I guess the baggage that we also we often find in the industry is that interview processes are filled with essentially brain teasers. Because that's the sort of thing that Google and some of the big tech companies, you know, they do. And oftentimes, people just copy practices from those big companies. And oftentimes, I used to interview companies and used and used to get given all these brain teaser questions or dummy questions that have nothing related to what I'm going to be doing at the on the job whatsoever. So and that does seem to be a I guess, like a backlash against that, this kind of this kind of interview process in the industry in the last 12 months or so. How do you guys structure your interview process? And what sort of things do you look out for when you're looking at a candidate?

Ryan Jone: 18:22  

Yeah, so I was actually very fortunate that the Nike interview that I did was actually code challenge based, or sorry, not code challenges of a whiteboard algorithm, but more, build out this REST API, have unit testing, you know, real things that you would actually do on the job. And the reason why with that structure, even though it's Nike was because I was on a small, like two person team at Nike. And so the, the lead developer was like the only person on the team at the time. And so he was trying to evaluate, I want people that can get on the team with limited information and start making things happen to move the project forward. So that that was actually how I got the job as I spent, you know, a lot of time doing that, preparing for it, and then building it out. And that experience, to me, felt like the most fair way to evaluate a candidate. And I've seen that as well, with the algorithms, all that stuff, I actually try to get into AWS at one point when I was in coming out of code school, and it was like a 15 minute interview, there was a timer on it, it was like ten questions, and I was like, solve these algorithms. It was just for an internship. And I was like, you know, I can actually build real stuff. And this felt like, completely irrelevant. I didn't have a CS degree. And and I think it kind of it's one of those things where, what do you really want this person to do when they actually come on. And for bigger companies like AWS, they might have the structure to have really crazy onboarding. And, and, and just mentorship for new developers coming out of college, where they have the CS degree, they have this low level knowledge and they can actually build up the extra skills. But for I think for the larger community, I don't think it makes sense to copy these bigger companies. because realistically, you don't have those same processes. And you don't have that same level of onboarding and mentorship. And so what we see I think, is like, lots of frustration. And I've seen that with a lot of my friends as well that are in the community, and the industry, where they try to go apply for a job, but they have to do a whiteboard challenge or solve an algorithm. And they get burnt out, because every company is sending them like ten different of these type of challenges. And these people have built, you know, full applications, they've they've done the front end, the back end, the services, you know, cron, all that stuff. And so for Serverless Guru specifically, seeing that we have a series of like three to five challenges that we do, where it's based on work that we actually do for clients. And the idea there is like one of them is kind of interesting is to convert AWS SAM to serverless framework, which doesn't seem like it's a like, why would that, you know, why would that be a challenge, but it is actually a challenge because you have to understand CloudFormation in such a way. And you have to break apart the infrastructures code in such a way that it kind of validates if that person has best practice knowledge of serverless framework where they are on that spectrum. And it's very easy to see based on what people send back, you know, because you and I both write, we have courses on this stuff. So like, once we see what comes back, it's very easy to determine if that person is, you know, on the senior side, or are more on the junior side. And then we have other ones for build out an AppSync API that has, you know, CRUD functionality. And then kind of seeing like, do they use VTL templates to take away the Lambda function? What do they add in there? And then we also... Something that we've added recently, which is really awesome and helps a tonne. I would say, anybody that's listening to this, definitely add this to your recruiting pipeline, is have them record a video of them talking over the code, right? So the idea is like, we want to streamline and automate as much of the process as possible. And one of the biggest things that we found is that the communication part is such a key element to successful consulting, if you don't have really strong communication, that can be 80, in my opinion, it could be like 80% of a product going successfully or not. And so we're able to evaluate not only their understanding of the code, because of course, you can find tutorials online and stuff like that and pieces together. And we are looking for people that can do that, right? No experience, learn really fast, put it together. But we're also evaluating, can they describe what they built? And is it convincing? And do they show like signs of confidence in it? And that that gives us a really easy ability to evaluate kind of like the full candidate without having to ever jump on to like an hour call. So we try to keep it focused on Can you do the job that we're actually going to give you? And is your communication strong? And then based on those things, yeah, we've gotten some really good talent through. So.

Yan Cui: 22:59  

Yeah, I really like that idea of someone recording their thinking process as they're working on these challenges that are relevant to what they're going to be doing, if they were to join your company. Because often I find that what they do, well, sorry, why they do something is probably more important than what they actually end up doing in terms of the lines of code. Because what I find is that a lot of the time, people are just repeating what they have been told to do organisational conventions, how they, how they're currently doing things within the organisation, rightly or wrongly, often reflects in the submissions for these coding challenges that we give them as well. And oftentimes, I think, if you listen to, you know, if you are able to talk to, well, see that the thinking behind it, sometimes what may seem like a weird decision may have more merits because of the context that the candidate is coming from. And certainly seeing someone so thinking through the problem, tells me a lot more about what they can, you know, what they will be able to contribute to the team if they were to join the team as well. Let's maybe talk about some of the projects that you guys have been working on. Is there anything that you can sort of discuss publicly interesting challenges that you've come across?

Ryan Jone: 24:17  

Yeah, yeah. So it's a really good timing, we actually wrapped up the end of the year with kind of not really announcing but kind of putting it onto the website that we've been working with Air Canada for a while now. And so we actually have a really great quote on our website, from the director of digital platform architecture at Air Canada that basically says that we've been working with him on a multi year serverless transformation, involving training support for developers consulting on best practices, and implementation on critical projects. And Serverless Guru helped rapidly accelerate Air Canada's serverless journey, and that's been a really big project that we've had kind of secretly happening in the background as working with Air Canada and being involved with their entire team, kind of a global team, and can't get into specifics probably on individual projects happening, but what I can say is that it's been awesome learning experience on the consulting side for us, and having this like stage to perform. And we've been super grateful for, you know, all the opportunities there that's happened. And it's kind of it was kind of interesting, at first it was like, we just need, you know, it's like training. And then it kind of turned into, you know, enterprise architecture. And then it turned into implement implementation development. And that turned into proof of concept stuff. And then it was, you know, support for developers. And so in each one of those, we've kind of learned a little bit more about what it's like to work with enterprises. And out of that process, you know, kind of the long term, you know, vision of Serverless Guru is that if any Fortune 500 plus company wants to do something with serverless, in the future, you know, Serverless Guru wants to be involved in that. And there's also another one, which is like, Serverless Guru wants to help save like $1 billion in operational expenses, you know, by like, 2030, or something. So this is like a ten year goal for Serverless Guru, it's not a short term thing, I'm still going to be around, you know, next summer in the summer after that, and five summers after that. So we're constantly building and off of this Air Canada experience, we're now able to kind of present a unique offering to these enterprise companies that are trying to... They're seeing the value of serverless. But they haven't fully dove into it. Or if they've dove into it, all their developers also need to transition to it, and they need to be efficient with it. And, you know, what infrastructures code framework to use, how to use it properly? How does the team establish best practices and make sure that they're not repeating themselves all over the place? And and how do you not shoot yourself in the foot because I think things that really come up is that, you know, you can build something in a non production system for serverless. But then once you actually have hundreds of thousands of messages flowing through it, or millions of messages flowing through it, that's when you really see things break down. And the problem is, is that you, you sometimes don't learn that until it's too late. So we've had a lot of those types of things happen over the past year, where we've seen these incidents take place, and we've had to figure out how to triage it, figure out how to, you know, basically make it stronger. And now off the back of those types of projects that we've been doing, one of them being Air Canada, I think that you know, Serverless Guru specifically is in a really good spot for 2021 and beyond, to help enterprise companies kind of not only, like learn to pick up serverless and make their developers efficient, but also kind of bring it all the way into production. And that was something that was missing prior to like mid 2019 for Serverless Guru.

Yan Cui: 27:46  

Okay, and with all the different customers that you are working with, have you noticed any adoption trends, or maybe common challenges, or mistakes that customers run into when they want to adopt serverless?

Ryan Jone: 28:01  

Yeah, I think the big one is, it's similar to what we were talking about earlier, which is, there's so many things to understand and know. And also, there's this... So I'll dial back to Meetup that I did back, maybe, like early 2019. And it was at a DevOps Meetup here in Portland. And I got introduced as being someone that's gonna talk about serverless, and hopefully not about how it's gonna take everyone's job away. And I and then it was very awkward after that, but I kind of just took it on the chin. But it was, it was interesting, because that's some somewhat to the existing community, which is the majority of the community for like DevOps, and people are working with Chef, Puppet, EC2 servers, things like that, virtual machines, on-premise things, they might look at serverless as like a kind of taking the job away. And I think the thing is, is like, it's not efficient for a company to let go of all of the people that have all the business context, about what how the business actually operates, how the teams work, you know, it takes so long to even just onboard people into like working with the JIRA system at the new company, and how all the processes work, that the the better solution, the most optimal solution, it's actually to take those people and transition them and give them the skills and the knowledge they need to actually succeed in the new role. And so yeah, I think I think I just lost the question a little bit. Yan, sorry.

Yan Cui: 29:22  

No worries. So my question was around adoption trends and common challenges. But what you talk about is actually very interesting, because I've seen that a lot as well. A lot of pushback from the, I guess the DevOps community to serverless, at least, maybe 12 months ago has been this, potentially, this sort of like a identity crisis that a lot of them see themselves as infrastructure engineers, and, you know, their whole job hangs around being, you know, them being the ones to write those infrastructure templates and whatnot. And a lot of that becomes either irrelevant or not as challenging that requires a specialist in the team to, to do that, to own that piece when using serverless technologies. But I think with the same in the same way that industry industrial revolution happened, some people lost their jobs, but they didn't really lose a job, they got other more interesting work instead. And I think with serverless this is also opportunity for a lot of, I guests, the folks that are focusing on DevOps to maybe move into a different part of the business, and maybe get more involved with building up application features and doing other things, and not just putting your head down and writing those Puppet or Ansible scripts. And there are other things, you could contribute to the business that can create more business value at the end of the day, which makes you more valuable members of the team as well. So yeah, I do think it's easy to get yourself into the mindset where you identify yourself as one thing, and that this new technology coming along that can potentially reduce the need for for that particular set of skills. But at the same time it opens up, I think it lowers the bar of entry for someone to get into building features and developing more, more customer facing stuff where you can create more, a lot more value to the business.

Ryan Jone: 31:23  

Yeah, yeah, absolutely. Yeah. And I think I agree on all fronts, I think the identity crisis thing is real. And, you know, going back to the thing that I said earlier is like, the, when people are actually making that transition, or for businesses like the, it's more efficient to actually take those people and give them the skills they need to actually be effective. And then I think also in that process, like I actually did, I was doing serverless development and doing serverless consulting. And then I actually did consulting for probably like eight months, where I was actually writing Ansible scripts and stuff and working with virtual machines, it was kind of this weird, um, I, I look back on it. And I'm thankful for it, because I got more perspective about how enterprise companies work. But I was building like API gateway and Lambda functions and doing that stuff and building web apps and using Cognito. And then I went all the way back into being in like a legacy environment, trying to clean up AWS and make scripts to handle things like, you know, patching a certain version, because of the exploit thing that happened a while back with, I think it was like spectrum or something, I can't remember what it is now. But one thing that was interesting about that is that a lot of the people that I was working with was that team that has to transition. And I was working in the operations team at the company doing this work. And I think that the the type of work that's being done is, it's very stressful, like people are on, they have like a beeper on them. There, they have to be available, like 24 hours on the weekend, the databases would get maxed out, and they would have to, someone have to be there to actually modify it, EC2 instances, they don't really have a deployment pipeline thing for it, and how they actually make updates to it. And how do you make a good AMI, right? And how do you... All those, all those problems are actually really difficult, and every company has to solve those problems. And the people that are actually solving those problems, they have a, they have a they have skill at writing scripts and writing bash scripts and understanding how this like low level, which would be underneath Lambda actually works. And so I think it's a it's a it's a natural transition for them to actually start doing a little bit more of the development side, which you're, you're kind of hinting at. And I think, in that process, I don't... I think a lot of people, it's going to be weird, at first, maybe a little bit scary with the idea of like, job security, all that stuff. But I think ultimately, if somebody has that background, and then transitions into serverless, they would probably be higher on the list, at least for Serverless Guru, then if somebody came from only doing like, front end maybe, or something like that, and then they didn't have an understanding of how the lower levels work, because for enterprises, you know, you say, Okay, this EC2 instance this on-premises stuff. Yeah, it's legacy. Yes, it's old. Yes, there's, there's more optimal ways to do it now. But it's also making the company hundreds of millions of dollars a year. And so how do you... You can't just turn it off, like, you cannot. Yeah, that was like one thing that I at first, when I first started, I was like, yeah, just turn it off. You know, like, let's just deal with serverless. And now it's like, you need people that understand all the levels of it, and all the organisational complexity, and understand how you can basically map that over. And I think for the people that kind of see that that are on the operations end, I think they're going to have a really, really a lot of opportunity moving into the future, picking up serverless and be extremely valuable on any team that they join. Because nowadays, we're kind of jumping over that. But it's still relevant for a large majority of these large large companies.

Yan Cui: 35:01  

Absolutely, I think those experiences are crucial. A lot of things that we're working on, I guess that we are working on higher and higher levels of abstractions, but the underlying fundamentals, they don't really change. And so if you understand the fundamentals that that put you in a very strong position, in terms of learning about all these other new things that are coming along these services that are managed, managed services, and understand how a lot of technologies that we use day to day works under the hood, I spent most of my career actually doing a lot of those things, as well as developing applications. Because I was working in really small teams, where I was essentially the backend team, and had to do everything. And I used to spend like 70% of my time just configuring servers and doing all this other stuff, and also being on call. And when things just go wrong, it will be peak time in the US, but in the UK, it will be like two o’clock, three o’clock in the morning. So now being woken up in the middle of the night is not exactly great. So nowadays, I can do so much more with less stress, and just less time as well. And certainly, I think nowadays, we've been using serverless components, my work has become a lot easier, at least a lot more enjoyable. To some extent, it's probably a bit more boring now as well, because everything just kind of works. There's not a lot of engineering challenges to do it just Okay, you got to do this, you know, you want to build this app, just pick Lambda, AppSync, DynamoDB tables and a few other things, and then bish bash bosh, and a week later, you've got something working, and you don't have to worry about scaling and configuring launch configurations, all the other stuff. So there's a lot less tinkering you need to do, which is a great thing, because it gets me focused on just delivering the things that actually matter to the end user. And the things don't tend to go wrong. So I don't have to, you know, be waking up in the middle of the night to reboot the server and stuff like that. And certainly, I think like you said, as DevOps engineers who has got those understanding of the underlying building blocks of the AWS infrastructure already learning that other services that are now, you know, Lambda, API gateway, DynamoDB, all these managed services, you can have a lot more insight than someone who's coming in fresh and not understanding some of these low level building blocks, plus all the institutional knowledge that you have about the company, how it works all that as well. So definitely, I think that's, that's a career path. That's an opportunity for a lot of people that they should just, you know, grab with both hands. I guess switching back to the question I actually wanted to ask before was, have you noticed any sort of adoption patterns in terms of amongst your customers and common challenges that people run into?

Ryan Jone: 37:56  

Yeah, so I think we've seen a lot more of EventBridge popping up, and things like trying to use Kafka, basically trying to handle large scale events flowing through serverless architecture, and how to handle that properly. There are a lot like you talked about where it's, you know, it's it's very, it's like, you know, we need a new AppSync API, we need some type of CRUD timer functionality, there are a lot of like use cases, which are pretty, pretty identical. And so I think the, on the on the on that front, I think EventBridge would probably be one that's coming up a lot more, AppSync coming up a lot more. And then I think the thing that's coming up the most probably, which is not completely relevant to the question is, how do you use the things that you already, like how do you make the use case that you already have, like you said, for instance, building the AppSync, it just works, right? So you're able to build in a week with the amount of knowledge that you have, or even less time probably using serverless components. And then how does that scale over 30 people that are in different countries and time zones and have different team structures? And how do you basically make sure that everybody's building it in a way that standardised enough that onboarding processes that are smooth, and the operational side of actually building new services that's known? And there's no kind of just like, edge case things that are being built that no one understands? And, and, and making sure that all those that understanding is centralised, and people can really tap into it across different teams and learn about it? I think that would probably be the thing that we get hired the most to do with Serverless Guru is sometimes people they already know Yes, use a Lambda function for it. Yes, use like CloudWatch rule or the new EventBridge version of that under the hood, or use like Fargate. Potentially, they, they know that they they should do it eventually. But the idea of how do they actually put it into place and how do they make sure that the team understands how to do it on their own, and and they're doing it in a way that's best practices. That's that's one area that we do a lot. And then I think the thing that just kind of spawned in my mind when I said Fargate is which one of the options do you use. And that's probably another one that we spend a lot of time on is, should you.. We hear Fargate. A lot of times people are transitioning from existing stuff, existing knowledge, and then building something new. And so there's kind of a line that you have to draw there. And there's a there's kind of like, if it's greenfield, if it's completely new, you can take, yes, you can use Fargate. Yes, you can take it from maybe having to manage the containers and stuff yourself. You can use something like Fargate, where it kind of turns off and on. But there's also sometimes there's like that extra step, which is like, could this be a Lambda function, could you get rid of a little bit more of the overhead that you're kind of taking, taking on. And so I think the cloud is amazing, because there's a lot of ways to do a lot of things. But it also can be the thing that allows people to shoot themselves in the foot, because they have now ten different options. And, you know, with the Lambda container support that recently came out, or Lambda extensions, or Lambda layers, or using Fargate, or ECS, or EC2 or, like Elastic or Beanstalk, whatever that is, I'll top my head. So using those different options, there's a lot of things you can do and a lot of different ways that people can build out similar things. And then knowing which one won't like which one will actually scale to the team size, and which one will allow them to have the most long term benefit. That's, that's an area that we probably work on the most.

Yan Cui: 41:41  

Okay, and now that we are in the 2021, what's next for Serverless Guru and for you, for yourself, what's the, you know, what's your outlook for 2021?

Ryan Jone: 41:53  

Yeah. Yeah. So it has been on my mind a lot. I think one thing that happens with me is that whenever things turn off I, I start like going through my head like “Is everything okay?”, like “What is this going to look like?'' I think I got I get a lot of personally a lot of self-worth out of the out of the work that I do with Serverless Guru and out of like building things and seeing things go forward and answering emails even. So I think when everything turned off for the holidays, I didn't turn off but I kind of felt like, Yeah, a little bit of like self-doubt around that. But getting back to the question. When it comes to Serverless Guru in 2021, it's you know it's part of a, it's one year out of our eight to ten year vision for the company. And this year we're hoping to shoot for one more enterprise client by June, and then try not to box in the anything past that point right so what that kind of looks like is a lot of times, there can be, there's this, there's this term called sticker shock. And so the idea there is that if something, if there's that if the money is too much or the goal is too, seems too big, you almost will psych yourself out of it. And so one thing I've tried to do since the beginning of Serverless Guru is just leave that out of the door. I don't know what will happen, but I'm just going to shoot for one thing, I'm going to shoot for one step forward. And who knows, after June, maybe we'll have two clients, maybe three more enterprise clients, but I think ultimately to get to the goal of, you know, saving a billion dollars of operational, you know, expenses and and kind of growing to any Fortune 500 company plus that's doing serverless with Serverless Guru involved, you know requires a super big team, so we're gonna be doing a lot of recruiting, requires a lot of sales, requires a lot of giving back to the community through content and media, getting the message out there about what we're doing. And so, a big focus in 2020 was, you know, keeping the wheels on the car as we're going down the track, or on the train. And I think now we've we've got a lot of the wheels you know we've got a lot of areas like accounting and, you know, finance and all this stuff we've kind of got that laid down in 2020. And so in 2021, we're looking at how do we increase, how do we maximise our marketing, how do we maximise the training courses, how do we make new training courses, make new content for the community, increase our sales target enterprise companies and and really grow the amount of kind of network the Serverless Guru has, and then personally I'm looking to get my skydiving licence. So that would be one thing personally for 2021.

Yan Cui: 44:35  

That's exciting. And I guess, best of luck to both your endeavours, personal endeavours, as well as what you're hoping to achieve with Serverless Guru. And, I guess, yeah, thank you so much for taking the time to talk to us today and how... And if anyone who is listening to the podcast wants to consider Serverless Guru as the next step in their career. How can people find you guys on the internet and how can they apply for a role at the Serverless Guru?

Ryan Jone: 45:07  

Yeah, yeah. So, come to serverlessguru.com. We've got contact forums for sales. You can also message us directly on either LinkedIn or Twitter. Both of them are Serverless Guru. If you want to ask questions about serverless or anything like that, definitely I would say Twitter's probably the best route. If you're looking to apply for a job, you can email us at info@serverlessguru.com. And that will get us directly to the hiring people on the team to evaluate and move forward in that process. Same thing if you're looking for your next partner for a serverless initiative, migration, enterprise architecture, advice, things like that. You can also go to info@serverlessguru.com or submit our form. And of course if you're looking to, you know, you're just starting and you're a beginner, we have, we have coupon codes and things like that for our training course, it's called Serverless: zero to paid professional, and it goes through helping newer people based on my background of where you know I came through code school and had to learn about serverless and do things manually and then learn infrastructures code and go from there. So that's how the course is focused and if you do want a coupon code you can get the course for free and you just messaged us on Twitter. We're gonna be doing that probably for a good amount of 2021, that's we're just starting to build out this new initiative training courses and things like that and we don't really know fully how it's going to be received by the community. And then we also have two podcasts as well. We have the Talking Serverless Podcast, which is a great episode with Yan as well if you want to check that out. And then the Serverless Economics podcast which is going to be coming out pretty soon. We already have six episodes but it's not really well marketed at the moment. So.

Yan Cui: 46:46  

Okay, I'll make sure those are included in the show notes so that anyone interested can quickly check them out. So yeah thank you again Ryan for taking the time today and stay safe and let me know when you get your skydiving licence.

Ryan Jone: 47:00  

Yeah, thanks so much Yan. And thanks for having me on the show. I really appreciate it. And best of luck 2021 to you too. 

Yan Cui: 47:06

You too. Take care, man. Bye bye. 

Ryan Jone: 47:08

Take care. Bye.

Yan Cui: 47:22  

So that's it for another episode of Real-World Serverless. To access the show notes, please go to realworldserverless.com. If you want to learn how to build production ready serverless applications, please check out my upcoming courses at productionreadyserverless.com. And I'll see you guys next time.