Building a serverless application means you usually trade in old issues for new ones. This is an attempt to create a decision framework and break down arguments for and against using serverless vs. other computing models. If you ever find yourself deciding for or against serverless, the following tries to make the decision easier for you. Maybe you should save this post for future reference if you find it useful. Or don't, it's up to you. No seriously, save it. This is also an open document that I will keep improving in the future. Strengths -- The real benefit of serverless is that developers only focus on the business logic and that drastically increases development speed and time to market. Faster time to market -- If you follow the right architectural patterns, serverless is very scalable. Scalability -- In most cases, serverless is cheaper than other computing models although exceptions apply for some forms of compute-heavy data processing/background jobs. Cost-effectiveness Weaknesses -- It's difficult to test locally and it's difficult to navigate debugging data. You can set up a local environment for testing but it will take a lot of effort. Troubleshooting and testing -- New patterns and tooling can take a while to learn and adopt. Learning curve -- Bigger learning curve for new developers mid-project. Developer onboarding Opportunities -- All serverless architectures are by default. Keep in mind that it does not mean you'll get any visibility, it just means that most of the data necessary to understand your service is actually available in AWS through: Observable by default observable (CloudFormation, Lambda, API Gateway) APIs (CloudWatch and CloudTrail) Logs (CloudWatch) Metrics Services structure and visualize that information to make it navigable and simplify troubleshooting. -- If done well, you can get large parts of your service just by using available Lambda functions and services for auth etc. SAML and other services -- Developers are excited to work with new technologies, meaning that they are less likely to quit and it's easier to hire. Hype Threats -- Poorly constructed architectures, cold starts and database connections running out. Performance issues and latency -- Hard to migrate to Docker containers later if for some reason that's necessary. Lock in -- Bigger surface area for loopholes and higher complexity for security audits. Security Conclusion As you can see there are significant upsides and downsides, but if you make sure to structure your software right, the benefits greatly outweigh the downsides! If you have any feedback, the comment section is all yours. I'd love to hear what you have to say. I will be updating this analysis regularly.

Too Long; Didn't Read

Making security fun one episode at a time

Choosing a Computing Method: a Serverless SWOT Analysis

Too Long; Didn't Read

Taavi Rehemägi

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Choosing a Computing Method: a Serverless SWOT Analysis

Too Long; Didn't Read

Taavi Rehemägi

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES