Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: Hello everyone and welcome to another episode of AWS Bites. AWS Bites is the weekly show with bitesized episodes where we try to answer your questions about AWS. My name is Luciano and today I'm joined by Eoin. So before we get started, let me kindly ask you to give us a follow and subscribe so you can be up to date with our latest news and every time we have a new episode. And the question for today is actually one I really, really like and I'm really excited about and it's, is serverless good or bad if you are a startup? So I will probably ask you Eoin, first of all, to explain briefly what do we mean by serverless? What do you think?
Eoin: That's a really good place to start because it means different things for almost everybody. And we could probably divide it down into two categories. There's the mindset that serverless is all about using off the shelf managed services and offloading whatever effort you can to a third party provider. Now that could be AWS, but it could also be a provider of a specific service. So it could be like using DynamoDB as an example of a serverless approach, but also using Auth0 to manage your user accounts, authentication and authorization is serverless or using Algolia as a search service or even using something like Firebase is an example of a serverless approach.
So that's one part, right? It's the mindset of just doing the simplest thing possible and getting rid of all the maintenance effort. But the other perspective on it is serverless is about using Lambda and API gateway and step functions and in order to take that approach, I mean, that is definitely a serverless approach because you're not managing any servers, but there's a trade offs there, right?
You still have to understand how they work together. What are their limits? What are the failure modes and how do you fit them all together to make a coherent system that you can sustain and is going to be robust? So then in that case, thank you so much to think about like, how do you do deployment? How do you do security and identity and access management? How are you going to do local development? What about observability? What about infrastructure as code? Where do you store your secrets? You know, you get the idea where there's a lot of considerations. That's not everything that you have to think about. So it's not necessarily, depending on your perspective on serverless, I guess the answer is going to be different, right? And I think it also depends what kind of startup you are and what kind of mode you're in and what your goals are. So that's the first thing.
Luciano: Yeah, I would say maybe we'll talk a little bit more about this later on during the episode, but I will say there is also a little bit of perspective of cost where to be serverless, it needs to scale to zero. So that can be another thing that might be advantageous depending on the circumstances.
Eoin: Yeah, that's a good point because some of these approaches, like with the third party services, sometimes you have higher cost considerations with Auth0 and other, they can be quite expensive in certain cases. So you do have to think about that. And unfortunately, it's a dilemma that startups will find themselves in where they feel they have, they might have no budget and they might have time, but do you want to spend your precious time assembling lots of disparate AWS services or do you want to be focusing on your business and product market fit? Yeah, exactly.
Luciano: So I suppose we can summarize what you just said from the opposite perspective, like when it's not good. So if we reiterate over what you just said, basically, I think if you are trying to build everything on AWS using the serverless services like Lambdas, the function, DynamoDB and so on, of course there is a learning curve there. So if you're starting from scratch, that's something that you're not going to acquire magically the next day.
Like it's going to take you some time to build up the knowledge and the experience with these particular systems. And maybe you're coming from, I don't know, that type of company that has been using something like Django or Laravel or Express for a long time. And you already have a set of tools and practices where you can be very, very productive with these tools. Maybe it can be good for you to stick with the tools. Like if you're building a new product and you already have all that knowledge, you can focus on the business logic and get the product delivered very, very quickly. So in that case, if you are that kind of a startup, maybe serverless is not good for you. Yeah, I agree with that, Luciano.
Eoin: I would also say, if you're coming from like that Django Laravel world and you know exactly what scale you're going to reach. So if you've got a situation where you're not going to have bursty scale, you've got a fixed limited number of users and the load is going to be pretty even, then that's fine. Serverless isn't, there's a lot of benefits there, but it's not necessarily simple out of the box.
You don't get simplicity for free. And sometimes people on the serverless side of these debates presented as, oh, it's so easy to get started with. And all you have to do to create a Lambda function is follow these quick steps. And then you already have a complete RESTful API up and running. But the getting started costs and the getting started simplicity factor is just one part of it. What you really need to think about is what is the long-term cost of developing, changing and maintaining a system like that. So while we were true believers in the world of serverless, we try not to oversell it because you certainly can. And you have to understand that there is a cost to understanding how to build services on AWS. Absolutely.
Luciano: And I have seen many companies that they are already struggling to move Monoliths to the cloud because even just doing that, it's an effort on its own. So going to serverless is like an additional gear, right? So you need to change even more. And sometimes you fail to account what is the cost for the company to do that. And it gets of course more risky, the more far away from your starting point it is that particular target. I agree.
Eoin: Yeah. I mean, it's a trade off. So once you understand that and you're happy to make that investment as you migrate, there's definitely long-term benefits, but you should go into it with your eyes open.
Luciano: And maybe with a more gradual approach. But yeah, let's maybe explore some of the goods, I guess. Let's say that you are in a position where it makes sense for you to go with serverless. What kind of benefits do we think as a user of serverless you are going to get? We already mentioned briefly that the cost can scale to zero, which basically means that you provision a bunch of infrastructure. Maybe you are doing an MVP so you don't really have a lot of traffic. Maybe you have test users that you are onboarding and they will be using the system only for a little while and give you feedback and that's it. I think that it's great to use serverless because you are only going to pay for that short period of time where you're actually using the system. So you can even afford to try a bunch of different things without being concerned of a very big upfront investment. So that's definitely an advantage. What do you think? Is there anything else worth mentioning? Yeah, cost is definitely a good one.
Eoin: Also in cost, I would say what we really see with serverless is that it gives you a mechanism to have a low cost for innovation, which is really, really important for startups. The ability to create complex systems pretty quickly once you understand how the services work and then refactor them, remove them. Everything you create is like this immutable infrastructure approach. So you can create massively scalable systems without having to provision lots of infrastructure.
So you don't have all that upfront racking and stacking costs that you would have with instances, machines or Kubernetes clusters. You can really get event-driven systems or web-based systems up and running pretty quickly once you understand how these things work, but then remove them if they don't work. And that's really important for startups to be able to iterate quickly. So that's a really, really big one.
So if you have the skills, you understand how these things work, it's definitely a good approach to take. But there's also, I suppose, going back to our first perspective, when we talked about the definition of serverless, we talked about the two perspectives and the first one wasn't necessarily AWS focused. It's like find the cheapest way you can build, you can get up and running. So if you're using a higher level of abstraction, that can also make it a very good choice for startups because you're not necessarily going all in on AWS and understanding all how things work together, but you can use something a bit more with a higher level of abstraction. And I know in the last episode, we talked a lot about Amplify. So that's one way. If you understand the things that Amplify is a good fit for, then why not use that? There's also other systems like Arc, which is like a simple kind of well thought out developer experience that hides a lot of the complexity for you and makes the developer experience a lot more seamless and kind of removes all these moving parts from you.
Luciano: Yeah, I think this is something we mentioned even in the previous episode that we have seen that AWS is recognizing that there is a need of a lower barrier to entry to all this ecosystem. Like AWS has always been a lot like it gives you a lot of control. If you understand the details, you can do a lot of things that are actually very... Give you a lot of powers, but it takes a while to get to that level of understanding. And with Amplify, I think AWS is recognizing that not everyone wants to start at that point. Maybe they need an easier way to get started. Maybe they need to be productive very quickly, but then they also give you ways to go back to the roots of every single system and get that control back after you have started. So maybe Amplify is a good trade off. If you don't have all the skills, you can get started. And then later on, when you feel you are more confident, you can start to use other things or export Amplify to CDK and work with the services directly.
Eoin: And we're kind of assuming, I guess, Luciano, that we're always dealing with kind of crowd applications and web based front ends and maybe mobile front end with an API behind it. You're talking about like a REST API, GraphQL, some database in the background. What if it's a different kind of ecosystem you're involved in? Like you're building at IoT devices and you need infrastructure to support that, or you have some sort of machine learning algorithm and you're building a service on top of that. Not everything is API driven and front end driven. How does the serverless equation fit into those classes of startup?
Luciano: Yeah, I think if we stick to that definition of serverless where you are basically using services that are most appropriate for your use case, I think AWS has a lot of services that can help you out. For instance, in the case of IoT, you have all sorts of different services, even to provision the different devices to update them, to keep them in sync or in a network where they can talk to each other.
So definitely you are going to have big advantages in picking that option because otherwise you probably are on your own to rebuild all this infrastructure yourself. And similarly for machine learning, maybe not my best area of expertise, but I know that there are plenty of tools and services in AWS to basically satisfy all the different needs that you can have in terms of AI and machine learning. So if you're doing something that is standard enough, I'm going to say probably you can just use something off the shelf like that rather than building from zero your own platform. Yeah, I could definitely testify to that.
Eoin: Having worked with a startup previously that had developed an idea around IoT devices and the machine learning algorithm, and it was actually astonishing for both me and for them how quick it was to be able to productionize, I suppose, a prototype that wasn't running in AWS, bring it into AWS with AWS IoT, Lambda functions, DynamoDB, and machine learning all together. I mean, a couple of years ago, this would have been a project that ran into months or years, but in the world of AWS IoT and things like SageMaker, it's dramatically reduced the amount of effort you have to put in. Okay.
Luciano: Maybe just to close this episode off, let's try to explore another final question, which maybe some of you might have, which is what if you don't have the experience yet to go with serverless, but you see a long-term advantage in going with it because we described a bunch of pros of this approach, and maybe you see that there is a lot of value in some of these things that we mentioned. So what can you do? On one side, we said it's good for you to stick with what you know and be productive. On the other side, you might be missing out the benefits of serverless. So do we have any advice there? Okay.
Eoin: Yeah, that's a really good one. I think the question itself should prompt people to think, okay, what am I optimizing for here? Am I trying to get to market quickly with the basic MVP, or am I trying to strategically select a technology that's going to sustain me for years and allow me to hire developers in 18 months time who have the right skills to maintain this? And I think that's a really good one.
It's a really good thing to think about. And I guess the answer I've kind of alluded to there, if you're willing to make that investment, you have the funding and you have the time. Say if you're really going to focus time on building a complete product and you wanted to have a sustainable, stable technology set of choices underneath it, then absolutely go for serverless and invest the time in acquiring the skills, especially if you have the funding. If you're budget constrained, you're bootstrapping and you're trying to get something out there to onboard users quickly, and you're happy to iterate and change the technology over time, then go with the technology you know.
Luciano: Absolutely.
Eoin: What would you say? Is there any other way you'd respond to that question? Because I think that's probably the most important question we're covering.
Luciano: Yeah, I think there might be another case where maybe you are a company that builds multiple products and you already have a bunch of different products in the market. If you're in that position, probably you can afford to experiment a little bit because it's always going to happen that in an existing product, you need to build a new feature. Why not trying to build that feature? If it's not the primary feature, of course, with something like serverless, maybe you're going to try to run that particular functionality in a Lambda, store some data in DynamoDB.
And that way you can have a very low risk way of starting to try out these technologies. And probably at that point, you can see a lot more clearly whether that technology is going to give you benefits or not. Also people in the team, they can start to recognize if they feel more productive in using these technologies, if they can ship faster. And at that point, it's so new to decide, okay, I want to invest more or maybe my next product I'm going to try to build this from scratch using what I learned from these experiments. So that can be another way, but I suppose that makes more sense for more established companies that are seeing a longer term return on this kind of approach. And they want to de-risk, I suppose, jumping straight into serverless. Yep, yep, good call.
Eoin: Okay.
Luciano: And with that, I think we have covered enough for this episode. So thank you so much for being with us today. Please give us your feedback. Feel free to leave us comments or to reach out to us on Twitter or LinkedIn. And if you have any question that you would like us to address for the next episode, send it our way and we'll try our best to reply that question. And with that, thanks again. We'll see you in the next episode. Bye. Bye. Bye.