Because we have all met this guy

Because we have all been burned by a framework

dev : prod parity

Because nobody knows what the future will hold

But we all want to play with new, shiny things

And of course, we want to be the one to herald a new age of "business agility"

NB: NOT GOOD FOR BACK OR PRODUCTIVITY

Best practices when adopting frameworks (and this time, the Serverless framework)

@ElliottSpira - @GorillaStack

ape.gs/SLS-AWS

Memebot

• list all available meme templates
• search through existing meme templates
• create a meme using an existing template
• create a meme from a custom image url

Functionality

Memebot

• slack!
• issue commands using a /memebot slash command

Interface

1. Decouple our business logic from the serverless framework as much as possible
2. Test our code rigorously to prove Mr. "I need a Test Harness" wrong
3. Get a decent development environment going to address factor 10!

GOALS

Goal: Test our code rigorously to prove Mr. "I need a Test Harness" wrong

Start with a fresh project

• Treat your first Serverless project as a tech spike
• Team needs to know:
  • Experimentation is the goal
  • Failure is OK
• Pick a project without specific latency requirements
• Ideally first build something new, rather than refactoring something that exists (don't associate problems with your existing tech debt with Serverless architectures)

USE DEPENDENCY INJECTION

• Finding the right framework is like dating.  Don't marry at first sight.
• DI Containers will help make your business logic more portable
• Also protected against big breaking changes in the underlying framework (classic framework move)

Same SDLC as any other project

• People love familiarity
• Developers want the SDLC to be the same as every other project
• Maintain same CI/CD workflows / tooling
• Maintain the same QA processes

Don't forget about security

• Remember that you still have to think about security (networking, IAM etc.)
• Leverage Lambda options to associate some Lambda functions to your VPCs with DBs and resources in private subnets