Serverless Pros & Cons

[00:00:00]
>> Erik Reinert: All right, so let's talk about the pros. As we just mentioned, there's no service management or server management required, right? I can easily just push my code up and run it, and I don't have to worry about, is the server gonna be up, does the server have enough compute power?

[00:00:16]
Does the server have enough network layer, networking, throughput, all that kind of stuff, this taken care of by the cloud provider. Which again, is really, really nice when we're talking about being a small team, right? Or having a little limited amount of resources of working on, you might even be a big team, but maybe only one person can work on this, right?

[00:00:34]
It gives you a lot more flexibility with not having to also consider the management requirements as well. Cost-based usage, right? So there's no pre-purchase capacity, I don't have to pay for a $50 a month database or EC2 instance or things like that, it's based on entirely off of the usage.

[00:00:56]
So again, when you're talking about dev environment, right? One of the challenges that we even had Hippo for a while was that our dev environments almost cost as much as production, because it's still the same infrastructure at the end of the day. It might not scale out the same way, but it still means we have to be running EKS cluster and ECS cluster, we have to have instances sitting there and stuff like that.

[00:01:20]
And so this can be a massive cost saved by just simply saying, hey, we're just gonna focus on usage here rather than pre-purchase capacity, or always running on demand capacity is really what it's called. And then finally, automated scaling, right? We talked about scaling and how difficult it can be and all these things.

[00:01:43]
Well, if you build it pretty much all serverless, that's one of the few things you don't have to worry about. However, and I have to say this as my due-diligence as an architect or whatever. Automated scaling can also hurt you [LAUGH]. Why might saying I'm not gonna care about my scaling might hurt you, can anyone guess?

[00:02:08]
>> Speaker 2: DDoS is expensive [LAUGH].
>> Erik Reinert: Exactly, yeah, at any point where scaling goes way beyond your expectations, you might have a massive cloud bill. I don't know if you guys recently noticed but Amazon actually made a huge change to their S3 buckets. To where anything that is publicly hosted, they're no longer going to charge for errors and things like that.

[00:02:31]
This was a huge problem because people could DDoS S3 buckets and stuff like that and then effectively blow somebody's cloud costs through the roof based off of errors alone. And so I believe it was either they subtracted that cost or they removed it entirely, but now they realize, all right, this is a problem.

[00:02:50]
We need to figure out, meaning Amazon needs to figure out how to fix that so that customers who are using this don't have to worry about that cost incursion. And so that is where you need to be careful, right, with automated scaling because another thing that's very common is Lambdas calling Lambdas.

[00:03:13]
>> Erik Reinert: You can easily scale through the roof if a Lambda calls a Lambda and then it calls itself back, then it'll just skyrocket. So automated scaling is great but it is a bit of a double-edged sword, you have to be prepared of what happens if your throughput goes through the roof and you're not ready for those costs.

[00:03:30]
And there's a lot of different ways that you can deal with it, you can deal with it through like billing alerts, you can deal with like thresholds and like rate limiting, things like that. It's just other ways of solving that problem, so you don't have to deal with those costs.

[00:03:46]
>> Erik Reinert: So let's talk about cons. So we've already kinda mentioned this a few times again, with Quirk architecture and dealing with things like thousands and thousands of requests coming in per second. The architecture can become more expensive for long-term applications. So again, if you're in a scenario where you have thousands of requests per second, right?

[00:04:09]
That means thousands of Lambdas per second being fired, you are being charged per every Lambda that's fired. However, there will be a point and it's pure math, right? There will be a point at the end of the day where the amount of dollars you're incurring per minute is more than the amount of dollars you're incurring per minute in just like an on-demand EC2 instance, right?

[00:04:32]
Because that's a fixed cost, whereas Lambdas and serverless are not a fixed cost, they will go until you tell them to stop, right? And so like I said, there will become a time where when Quirk is needed to connect to much larger content creators, counts or things like that, that we will need to think about that.

[00:04:54]
Will need to go okay, well, we can't process some random streamer who's got like 50,000 viewers just flooding their chat that one person could incur more costs than everyone else on the entire platform. How do you basically handle that? Well, that one component might not need to be serverless anymore.

[00:05:14]
And so that's where you can then say, okay, we're gonna take this component out, we're gonna put a service in its place. And now we're scaling off of a fixed cost of how much that instance costs per day, and that will save you a lot of money. Again, going back to Fossabot in comparison to Quirk and the conversation I had with Aiden, that was, the first thing he said, he was, that's great bro, but I couldn't do that, and that's exactly why.

[00:05:44]
So testing can be difficult on the environments reliance on the Internet, this is exactly what you were talking about earlier, right? How do you test this thing properly without having to have these requirements and you kinda can't, you have to be on the Internet, you have to make sure that your Lambdas are exposed on the Internet as well.

[00:06:02]
Or you might have to have a VPN which connects you into the network so that you can fire internal Lambdas and we do both. For Quirk, we have public API gateways and private API gateways actually. And so sometimes we need to connect to the VPN, so that you can then access the internal gateways and test, database connections or database calls and stuff like that.

[00:06:25]
Versus public connections, which is like, again, the chat messages coming in from Twitch or Discord or whatever else. So there is a difficulty around the environment's reliance on the Internet. Personally, in the year of 2024, it's not that big of a deal to me cuz I'm always on the Internet, but that's a preference.

[00:06:45]
So take that with a grain of salt, it doesn't mean that you feel the same way I do, I know some people who like to be able to go, completely zero access off the Internet and off the grid. That's great, but I like being on, the grid's nice [LAUGH].

[00:06:58]
So for me, it's not that big of a con, but again, it really depends on your requirements. Troubleshooting and debugging is also more complex, can anyone guess why troubleshooting and debugging might be more complex outside of it just needing to be on the Internet? When we're talking about, basses and facets and stuff.

[00:07:20]
>> Speaker 3: You don't know when one or see anything.
>> Erik Reinert: Exactly.
>> Speaker 3: Behind the wall.
>> Erik Reinert: Exactly, yeah, so you don't know how somebody implemented something you don't know if there's actually pre-imposed rate limits that you're not aware of. You don't know if there might be an outage on the service that you're relying on, right?

[00:07:37]
These are all challenges that you have to be aware of when you're talking about relying on other people for that functionality. And if you're not considerate of that, you can easily have outages, downtime and completely unplanned you're not aware of it. You have to stay synchronized with those providers as well.

[00:07:56]
So you have to be aware and say, hey, whenever they announce an outage, you have to announce an outage, right? It becomes a little bit more dependant in that sense as well. So this is where again, a lot more older people in the industry who were around when we just had data centers and stuff like that are, forget cloud architecture.

[00:08:17]
It's a big reason why they normally say that is because they are so used to relying on themselves that they don't wanna rely on anyone else. So it can definitely become more challenging when your intellectual property is dependent on somebody else's intellectual property.