“Serverless” is a hot buzzword right now – and that’s ok. Some people call it Jeff, some people say Function-as-a-Service. Name aside, let’s agree that services like AWS Lambda, API Gateway, and DynamoDB all provide some unique benefits (and trade-offs) when used the right way. For example, the folks (gurus?) at A Cloud Guru have built their whole platform on AWS Lambda, and run exactly zero servers themselves.
Even if you aren’t ready to start a serverless side hustle, learning a thing or two about serverless architectures is a good investment. When you start, you’ll find lots of articles about getting started on the Serverless Framework, but that’s not the way to learn. To best grasp such a new way of handling your application, I recommend starting much simpler. Eschew frameworks altogether. Make your first project with just basic services. Don’t be afraid to start small, since without a framework you’ll have to spend more time learning how the pieces fit together.
But then, learning how the pieces fit together is the whole point. You’re here to learn, and you don’t need to add a framework straight away. To help you get your first few projects under your belt, pick up a copy of the Lambda Video Course that I’ve been toiling on lately.
Where Frameworks Kick *aaS
Don’t bail on frameworks forever – there are smart developers that want to help you out. They’re making the Serverless Framework to help you towards best practices and patterns learned by experience. They excel at operationalizing technologies and making developers more productive.
I’m not even close to the first person to say this – ask anyone who wrote Ruby web applications before Rails. Having Rails has made it much easier to own a web app and made individual developers and teams more productive. The right abstraction layer can make a previously tedious, difficult job easy and maybe fun.
Use a framework when you set out to build a “real” project and your goal is not learning, but a product. That’s the time to use every advantage you can get your hands on. Go straight for the tutorials and boilerplate projects if they help you. Check GitHub to see what experienced devs are doing, wear out the search box on StackOverflow, and use the frameworks and tools at your disposal.
The biggest benefit of a framework is the community that exists around it; this goes double for the open source ones. The internet is full of friendly people that work on or with any given framework. Some of them write about their experiences, hang out in chatrooms, and share projects on Github. When you pick a framework (or operating system, or programming language) you’re also picking a community to be a part of.
When to Abandon Them
The number one reason not to use a framework is when you want to know what’s happening under the covers. Do you want to know how the DOM works, or what syscalls you need to synchronize a file to disk? Perhaps a framework isn’t what you need today. This is how you learn! You build something small that works, test it, break it, and try again.
Frameworks add another layer of abstraction between you and the system you’re learning about. They help those who already know the system, but you aren’t one of those yet. In Lambda, there are lots of helpful things built right into the service like aliases, versioning, and rollbacks that don’t need a framework at all. If you started out on a framework, you’d probably never learn these concepts directly because they’re wrapped in Serverless by an abstraction called stages.
Worse, if something goes wrong with the tool you’re using, you won’t know where to look at the underlying system to find the problem. You’ve gotten where you are with the framework, and it’ll be tough to debug the deployment if you don’t understand how it works.
An analogy I like here is the extensive discussion on autopilot for airplanes. The autopilot makes life grand when it’s working well, it saves the pilot fatigue and effort. But at flight school, no training program starts with autopilot. The fundamentals of flight, control surfaces, and navigation are taught first – then autopilot is introduced as another tool to help handle those things.
The last reason to abandon a framework when you’re learning is to reduce the intimidation factor of getting started. To start with the Serverless Framework, a solid understanding of CloudFormation is effectively a prerequisite. That makes your “learning list” longer for a small project than if you were framework-less.
Why have I been thinking so much about how to learn Lambda? Funny you should ask – I’ve just finished a video series on A Cloud Guru to teach all about Lambda, and how to use it with other services like S3 and Kinesis. For the reasons above, I didn’t teach it with a framework like Serverless, and instead used only the AWS command-line tool for the lab work.