In this episode, Zachary Randall of Chameleon Collective talks about his success using serverless technology to help understaffed technology teams save money on hosting fees, and reduce the complexity of maintaining infrastructure. He also plays the guitar for us.
Solving big problems with small teams
Speaker: Ladies and gentlemen, the Tiny DevOps Guy.
[music]
Jonathan Hall: Hello, and welcome to episode number three of The Tiny DevOps Podcast. I am your host, Jonathan Hall, and today, we're going to talk a little bit about serverless. I have today as a guest Zach Randall. Zach, could you introduce yourself and tell us why you know anything about serverless, for example.
Zachary Randall: Okay. Well, that's a good way to start things. My name is Zachary Randall. I have been a software engineer for, I realized now, over half of my life. I have actually been coding since I was about 10 years old. I am presently a consultant delate engineer and a partner at the consulting firm Chameleon Collective. When I'm not doing that, I'm making heavy metal and guitar pedals as you can guess by looking at the background, I might do something musical.
Jonathan: Those of you watching the video instead of listening to the podcast, you'll see. How many guitars do you have there in the background?
Zachary: 30-ish.
Jonathan: 20, 30, yes, cool.
Zachary: The camera's at an angle where you're missing some of it, but I have 30-ish, let's call it that.
Jonathan: It's an impressive collection to look at, no doubt. Serverless, why should we care about what you had to say about serverless?
Zachary: I find myself, and this is just the nature of consulting, I find myself working for clients that tend to be understaffed. Actually, what I've noticed in my years of consulting is that everybody is understaffed at every position, but technology is one of those places where it really happens. To be fair, that maybe you have an IT guy on staff or maybe you have somebody that does some programming and does some IT on staff, but it's not like most businesses are going to put a full-time DevOps person on staff.
What drew me into serverless was is that I have clients that either, again, don't have big tech staffs or they don't necessarily have the right expertise where I can expect them to maintain and run a server infrastructure. As easy as it is to say, for example, to get a lamp stack up and running or to deploy a .NET app or a Tomcat app, not everybody can do that. Maintaining that can get troublesome really, really fast
Jonathan: Before we dive too far into this, maybe you could define serverless. I know everybody's heard the word, I'm sure there's not a single person listening who hasn't heard the word, but I'll bet there are people who don't really have a good concept of what it is, so can you explain what that concept is?
Zachary: Yes, and I'll do it with an example. Imagine that you're using whatever your favorite cloud provider is, so we'll use AWS as an example. Perhaps you're going to deploy a web application or maybe you need to deploy just a service that needs to run on a cron. What we've always would have done in the past, you would have a server that's running that and probably some other applications, and you have your web server, your web proxy, you'd have a cron job running your service in the background.
Instead of actually having an actual virtual server somewhere that you're owning and maintaining, the serverless architecture obscures that from you. A great example that I do actually all the time for clients is is maybe somebody needs an API of some sort, somebody needs a very simple web app, I just use Lambda for that. The thing is, with Lambda, you build your project and you upload it, and then boom, you have an app. Of course, there's more steps and more involved in that, but are there trade-offs? Absolutely, but for most businesses, it's cheaper and it's easier to maintain.
Jonathan: Just a really high level, so serverless, correct me if I'm wrong about this, it's basically you upload a function, or a micro app maybe if you want to think of it that way, but it's a function that, for example, accepts an HTTP requests and produces a response of some sort. You're not building a whole app with a router and all that stuff, what API you want.
Zachary: No, I actually have done that though. Again, we'll use Lambda as an example because that's where most of my experience is. Lambda could be something very simple like a function that does a task. An example that Amazon might provide is you have an S3 bucket, somebody uploads an image to the S3 bucket, you have an SNS event that the simple notification service that your Lambda function responds to, and then maybe it takes that image, renames it, moves it somewhere else, resizes it.
That's like a really simple example, but you can actually, with a combination of Lambda, and then, say, something like API gateway, you can actually have a full-fledged web application running serverless like that. It's still a similar premise there because there is a function that's running, but the function that's running is basically wrapped around a web app.
Jonathan: I want to talk in a moment about, you mentioned there are some drawbacks, I want to talk about that, but first, I want to really nail home, what is the benefit of this for an understaffed or a small team? Suppose I'm in a small startup or a small business and maybe I'm the only IT guy there, the only DevOps guy, how is this going to make my life easier? Why should I keep listening to the rest of this podcast?
Zachary: Let's talk about a big one first and that's money because, especially if you're at a startup, you're at a small business, your bosses are not going to want to be spending money on technology where they don't have to. You and I have been in this business forever, so you know the first place where they're going to try to cut is tech. It's always viewed as an expense and not as an asset. If you are that startup, you are that small company DevOps guy, firstly, you're not paying for a server that's running 24/7.
A great example is in a web app that I built for one of my longtime clients. You pay for compute time. I think what Amazon measures it is gigabyte seconds or something like that. It's the time that the function runs multiplied by the amount of memory that you use. I have a client that's actually been using. I've had them on several things set up on Lambda and I have been having them use it for years. They're actually a pretty rapidly growing business.
They have never actually broken it through the free threshold because Amazon gives you so many free requests and basically request time every month. They never shattered that ceiling. They're not paying. Are we paying for RDS instances? Yes, we're absolutely playing with paying for RDS instances. Are we paying for storage for an S3? Yes, but we are not paying for a physical server to host these web apps that I set up.
Jonathan: Cost is a big savings of the service itself.
Zachary: Yes.
Jonathan: Of course, every business owner knows that you also have to pay people. What was the old Microsoft saying? Linux is only free if your time is worthless?
Zachary: Yes.
Jonathan: How does that apply here or does it apply here? What's the time involved? What's the investment in learning serverless? What's that going to look like?
Zachary: It's hard to say because I picked it up pretty quickly. Again, I've been doing this basically my entire life at this point, so I don't want to assume how somebody might pick it up faster or slower than me. I picked it up pretty quickly. There's a million good tutorials out there. Amazon provides templates for a multitude of programming languages. There are configuration things that you'll have to worry about, but you just have to worry about with a server.
When your deployment process ends up being a push of a button or a script, a very simple script, it's not that huge of a learning curve and it's not that much management time. If I'm using it in Visual Studio and not everybody uses Visual Studio, but it is a right-click and then a left click to deploy an application.
Jonathan: Just for context here. you said you picked it up quickly, how long have you been doing serverless work?
Zachary: At least since 2018.
Jonathan: How long did it take you from, so you decided, "I'm going to try this serverless thing" till you had something that you felt good about in production?
Zachary: I would say, in this instance, I'm thinking like a couple of weeks because, obviously, there's the unanticipated things that I'm not going to catch on day one. One of the things I ran into was Kora's requests, and it took me forever to figure out how to spend. By forever, I mean a few hours.
Jonathan: Less than two weeks, yes.
Zachary: Yes, less than two weeks. It's just a configuration thing that you have to do. Something else, Lambda is, and again, I'm specific, that's the serverless tech I have the most experience with, you do need to understand how VPC works because there is configuration involved if you want a Lambda function to be accessible to the internet, and also access internal resources like a database. There's some configuration involved there assuming that you're wanting to keep things secure. Some people flippantly don't care about that and pay for it later.
This is just the great part about the internet, the whole of human knowledge is available at the click of a button, and the available Amazon tutorials tend to be pretty good. Then there's a million people writing a medium blog or something like that about this stuff, so there's a wealth of information. If you are skilled or talented in this direction, I feel like it's something that most DevOps or developers should be able to pick up.
Chameleon Collective, we have some internal developers that are building our infrastructure, they don't really do client work, and I got them turned on to server lesson. They were a little iffy about it at first and I'm like, "No, trust me. I know you've got this Node.js app running on an EC2 instance and I know that it works, I know that you're comfortable with this, please just try Lambda."
I think it was like a year later that I finally had a conversation with that dev, and the crux of the conversation was, "Zach, you were so right about Lambda and I converted the entire expression to that."
Jonathan: Nice. What language do you write your stuff in? Are you using JavaScript? What are the options?
Zachary: I'm actually using C-Sharp most of the time. If I have my choice, I use C-Sharp. Off the top of my head, obviously, Node.js is an obvious one, Java, Python. You can do some hacky stuff to make PHP work, but nobody should use PHP ever again.
Jonathan: [laughs] Strong opinions about.
Zachary: I encounter things. As I'm sure you have had in your career, I encounter things and those things are inevitably PHP. They cause me late nights and heartburn. I'm sure that Go is supported as well.
Jonathan: I think you're right.
Zachary: Go almost has to be supported. Again, just guessing, I would bet Ruby is too. It's the standard array of languages that we use today.
Jonathan: As a developer, suppose you've written that Node.js application and it's working, what other changes do I need to have in mind? It's not just the application, right? You have your entire build process and your entire environment and stack. How much of that applies to serverless? I'm talking about things like your code repository, CICD pipelines, can you write automated tests for Lambdas, things like that, or is it a whole new approach in a different toolset?
Zachary: I don't think it's that different of an approach, I just think that the end result, it's where you're pushing your code to is what's different. You do have, leaving a little bit of the CI stuff out for a sec, you have some of the things that you would have in a stack otherwise. Like cloud formation is the way you handle that in AWS, you actually have templates depending on the sort of app that you're using. This is really nice. we'll set the stack up for you entirely. One of the great things about AWS is that you can automate all of that stuff.
I feel like it hasn't changed my development process at all because one of the things that I do when I'm developing is, let's say I'm writing a web app or maybe I'm just writing a function, I'm writing some sort of middleware integration, wherever that's going to end up hosted, as I'm writing, whatever I'm writing isn't dependent upon that. For me, the way I do it, I have a library somewhere, and that way I can run it and test it and do any integration stuff with a separate project versus having to run it inside of Lambda.
You can actually simulate your Lambda functions locally, which I tend not to do. Or if you're doing a web app, and then, again, this applies to Visual Studio, if you're doing a web app, it has a different startup process. It just bootstraps very slightly differently. One thing that I have learned, though, again, this is that I'm speaking to the C-Sharp experience, the .NET experience, but this could apply to other languages too, you need to make sure the libraries that you're using are going to run on Linux.
If you're doing a C-Sharp Lambda function, it's not running in Windows, it's running in Linux when it does run. I built a whole encryption solution using a library that will run in Linux.
Jonathan: I guess that's one of the drawbacks you were alluding to earlier.
Zachary: Yes. Another action since we're mentioning drawbacks, you do need to stay on top of changes that Amazon is making to their services because they will deprecate things, and if you're not on top of stuff that's being deprecated, stuff will end up broken or you won't be able to deploy. It's not quite the same or critical as having a really bad security hole in a Linux server. A great example is Amazon had deprecated a, there's a role that they had deprecated. They basically just renamed it.
I was unaware of that and I deployed an app for a client. Thankfully, this was a development stack, and because that role doesn't exist anymore on deployment, the stack broke. It was broken in such a way that I couldn't roll it back either.
Jonathan: What are some of the other drawbacks from that topic?
Zachary: This is a hard one to explain to clients is if your serverless functions are dormant for a while, if it's something that's responding to a request like you would with a web app, it can take a while to warm up. When I'm demonstrating some functionality that I built for a client, it's making an API call, and that API call takes 20 seconds to complete because that particular function hasn't been called in two weeks, a development stack and nobody's looking at it. If they say, "Why is this taking so long?" well, it's taking so long because nobody uses it.
Jonathan: The lesson there, I guess, is always hit your API endpoints right before a demo?
Zachary: Yes, just go ahead and load up like Postman or Insomnia and just plug it a few times. It's sort of like you imagine Bugs Bunny grabbing somebody and slapping them around to wake them up, do it like that. I made a Bugs Bunny reference, all the kids are going to love that one, right?
Jonathan: Yes.
Zachary: They all know who he is.
Jonathan: Right. Is vendor locking an issue? You talk about Lambda, suppose that, for some reason, I need to migrate off of Lambda, is that even an option, or am I married to Lambda once I'm there?
Zachary: I think you would have to actually try really hard to be stuck with Lambda. When I develop it, I view it as it's a container for my code, and that's it, but my code is its own atomic thing that if I needed to just drop this on a Linux server and run it with a cron job, or if I just wanted to run it behind or put it on a Linux server and run it behind Nginx, that I can do that. When you're using AWS, you obviously become dependent on some of the platform things, but I tried it. I really try to develop as neutrally as possible.
Jonathan: The wrap around your code is AWS flavored, but your functionality, as long as you write it appropriately, you can plug and play that, maybe you have to redo that wrapper like I was talking about, but you could put it on, like you said, a Linux server or any other cloud provider if you need to.
Zachary: Yes, and an example of something I actually end up doing for clients a lot is, they will have two business-critical systems that don't talk to one another. Maybe one of the systems is something that runs their internal operations. The more you can get into some really specific industries where there is this hyper-specialized software, and MailChimp or whomever doesn't have an integration with it, so you have this operation system, and you have an email marketing system, and they don't talk to each other, so how are you going to do that?
It's actually, they're not that big of problems to solve because almost everything has an API now. It's not necessarily everyone's first thought on how to solve that. It's like, "Oh, well, WordPress doesn't already do that," or, "MailChimp doesn't already do that," or whatever, or, Klaviyo, whatever your choice is.
What I end up doing a lot is saying, "Okay, well, so you're just saying you need me to sync all your customers from your operation system over your email system, and then you need me to set it up to send appointment reminders still, and you want to use your email platform because your emails are prettier. Am I getting this right?" That thing, and it's often way more complicated than that, but that's what it comes down to a lot of times. Almost none of that code would ever be platform-specific because, really, I have a set of services that run in Performa to perform tasks.
Whatever I would wrap around that code is I'm going to have a function that it calls and execute. That function can log and return some meaningful output, so whatever the wrapper is knows that the function was successful, but yes, that code should be able to run anywhere.
Jonathan: How do you know if it's appropriate to use serverless or not? I'm certain that there are cases when it's absolutely the wrong tool to use and there are probably others where it's a no-brainer, yes, this is a great application for serverless, there's probably a big gray area in the middle. Can you talk about maybe those two extremes and how do you decide what the gray area is?
Zachary: Cost is going to be a factor. We talked about that earlier? Do you have staff to maintain a tech stack or a web stack or what have you? How often are you going to be updating it? What sort of updates are you going to be making to it? Is this a piece of software that you're going to be keeping for a long time? Performance ends up becoming a big one because one would assume at a certain point that you might need a cluster of web servers and not just a little serverless function running somewhere.
What it always ends up being, the decisions that I end up making with clients, it's generally because of lack of resources or lack of expertise. The goal is, this is the easiest thing possible, I will write this, I will show you how to deploy it, and I will hand it off to you, and then your internal IT staff can handle this. Or if it's a long-term engagement because I do have some clients that I've supported stuff for them for three, four years, well, this makes my life easier because I'm not worried about updating or patching a server.
If I need to make changes, again, my deployment to the click of a button, and it's not costing my client anything to run things serverless versus, again, having a S3 instance that you're paying for every minute that it's running.
Jonathan: What else do you think the audience or even myself should know about serverless or have you told me what I need to get started?
Zachary: I would just say try it. I would take your language of choice, open up an AWS account if you don't have one. Although I have to imagine that some other providers equivalent of AWS, and do the intro-walkthrough. You can build a little function that responds to a notification but build a web app because I actually think a really effective web stack that you can build is, you have Lambda as an API, and then you use S3 and you have a react front end sitting there, and you actually have your front and your back end and you're not dealing with a server at any point. You can drop them, what is it called? CloudFront, I think is the CDN in AWS.
Jonathan: All right, where can listeners go if it wants to learn about this? Obviously, the internet.
Zachary: I would just say use your black belt Google skills. I actually can't think of anything off the top of my head. I usually start with the AWS docs and go from there when I can't solve a problem.
Jonathan: Their documentation is pretty extensive, so that's always a good place to go. Thank you, Zach, for talking about serverless and convincing me that I should try it. If people are interested in getting in touch with you, how can we follow you?
Zachary: Yes, I am on Twitter @thez0rk. That is T-H-E Z-0-R-K. If somebody really wants to know what that means, they can message me and I can explain it, but it's a 15-year old cultural reference that's way down the rabbit hole, and so nobody would get it anyway. You can also check out Chameleon Collective online too. We actually have a pretty massive social media presence. It's really a matter of googling and I work with a lot of smart people that have a lot of smart things to say. Probably a lot more smart things to say than I do.
If your interests tend towards heavy metal or guitars, you can check out my bands on Northern Crown and Miasma Theory where pretty much any place that you can find music. I guess depending on when you hear this podcast, you can also keep your eye out for Iridium Effects, which is my new line of guitar pedals, which is just getting off the ground.
Jonathan: Nice. We'll have all those details in the show notes for those who are interested.
[music]
This episode is Copyright 2021 by Jonathan Hall. All rights reserved. Find me online at jhall.io. Theme music is performed by Riley Day. What are the chances you might play a riff for us?
Zachary: Actually, I do have a guitar in reach, hold on. It's not going to be plugged in, but let me see.
Jonathan: Can we call this bare metal?
Zachary: Huh?
Jonathan: Can we call it bare metal then in contrast to serverless? [chuckles]
Zachary: Yes, bare metal.
[music]