Table of Contents
Before you switch to Serverless, make sure your engineers won’t quit
I’ve seen engineers resigning when migrating from monolithic EC2-hosted stand-alone applications to microservices. I’ve felt the same pain, too, and even considered quitting my job and going back to my comfort zone.
The same pattern is repeating today: engineers that went through the steep learning curve of setting up Docker in their machine, killing their CPUs with +10 microservices, are now trying to get a hold of the serverless architecture, with desperation mostly.
Where is Netflix?
The change is triggering the fight-or-flight response, and I don’t see Netflix (only 2 serverlesss-related posts in their blog?) heavily promoting the new way, as they did with microservices a few years back.
Most engineers have a hands-on attitude: “I know how to do this; let’s code, let’s get this done.” If they didn’t, they would probably get fired because they can’t ship.
In the serverless world, this attitude doesn’t work – at first, at least. The same was true with microservices: you need to plan for it. You need to sit down, draw boxes and connect them with arrows, and design the infrastructure before starting coding.
First design, then code
The challenge with a serverless architecture is that you need to plan where your code will run. Not a library, not a class, just a few lines of code; where does it run?
The team needs architecture design principles, AWS infrastructure diagrams, integration test plans, logging, and traceability strategy before you even begin thinking about opening the IDE.
Forget about deployment scripts and using the AWS console: you need CI/CD in place, and cloud release management tools, like SAM.
How do I start with Serverless?
Once you have an idea of which resources you need, you can choose an AWS Stack template that works better for you.
Here is a quick guide that you can use to introduce your engineering team to Serverless:
- Get them hyped: new is cool and fun for us, engineers. The AWS serverless tutorial is a good place to start.
- Let them design: buy a Lucidchart license and let the engineering team to play with different AWS infrastructure. There is no wasted time in exercising infra design.
- End to end example: take one simple use case, and ask the team to implement a full stack, end to end PoC: all the way from a React App, AppSync API, and Lambda/DynamoDB table.
- Contrasting Traditional vs. Remote Team Management Tactics - 11/20/24
- The Role of Color in Brand Identity - 10/23/24
- Human-in-the-Loop for Bias Mitigation - 10/16/24