A company may have more than one monolith
A monolith means a big heavy app
Easier dependency management
Easier version management
Easier to track breakages across different projects
Easier to know what team is doing at a glance
Harder to split code ownership
Harder to define responsibilities
Monolithic codebases can easily become a mess
No strong conventions
Can be harder to deploy
Increased complexity on codebase
Harder to distinguish responsibility of the codebase
Only WWW is a monolithic app
It is impossible for your code to get out of sync with itself
Any change can be considered and reviewed as a single atomic unit
Refactoring to modularity becomes cheap
When should you break down a monolithic app?
When should you unbundle a monolith?
Lots of data duplication
FaaS / Serverless
Lighter weight deployments
Poor knowledge sharing
Services that can't exist in a FaaS environment
AWS Lambda Limitations
Execution time. AWS has a limit of 15 minutes
Uploads of 50mb zip
When to use microservices?
Reusable functionality across different services
Can exist as a library; or micro service
Isolate small piece of code for:
When you want to create a black box
If it can exist as it’s own product
Things which can’t exist in a FaaS
Questions to ask:
When should you bundle a microservice?
When should you unbundle a microservice?
When should you break down a monolothic app into a microservice?
When does a microservice become a monolithic app?
If your goal is to keep it as a Single Responsiblity Principle
Why not just use a FaaS architecture?
DevOps is not required
Reduce security footprint
Pay for what you use
Increased complexity on infrastructure
Teams with poor devops
When to use FaaS?
Competing faaa products (Ec2) can leveraged auto scaling
Small work loads that don’t require an always on machine
Low traffic url shortener https://github.com/aizatto/url-shortener/