105 lines
6.4 KiB
Markdown
105 lines
6.4 KiB
Markdown
# I’m sorry, but the way you adopt serverless is wrong
|
||
|
||
- **期号**: SRE Weekly Issue #435（2024-07-28）
|
||
- **作者**: Yan Cui
|
||
- **链接**: https://theburningmonk.com/2024/07/im-sorry-but-the-way-you-adopt-serverless-is-wrong/
|
||
|
||
## 简介
|
||
|
||
If you want to convert to serverless, don’t switch to microservices or change your datastore at the same time, argues this article.
|
||
|
||
## 正文
|
||
|
||
|
||
|
||
|
||
Yan Cui
|
||
|
||
I help clients go faster for less using serverless technologies.
|
||
|
||
|
||
|
||
There is often the sense that going serverless means going microservices and event-driven architectures, too.
|
||
|
||
**That’s NOT TRUE!**
|
||
|
||
They are related but ultimately separate design choices.
|
||
|
||
So much of software engineering is about making smart choices. Often, when I see teams struggle to adopt serverless, it’s because they try to take on too many new ideas at once.
|
||
|
||
### A marathon, not a sprint
|
||
|
||
I have seen many ambitious teams that want to modernise their application and go from on-premise monoliths to:
|
||
|
||
- Cloud-native: leverage fully managed services as much as possible. This *serviceful* approach to building systems is what being “serverless” means to me.
|
||
- Microservices: break down a large system into subsystems, each specialising in a different business domain. Allowing them to grow, scale and fail independently.
|
||
- Event-driven: create loosely coupled systems by allowing them to communicate asynchronously through shared events instead of synchronous API calls.
|
||
|
||
On top of that, “migrating to DynamoDB” is often thrown into the mix.
|
||
|
||
That is A LOT of moving parts, and it requires many different experiences and expertise to navigate successfully. Expertise that most of these teams do not have.
|
||
|
||
Learning to do all this while you’re expected to deliver tangible results under a looming deadline is very risky.
|
||
|
||
It’s like trying to learn to juggle flaming swords and ride a unicycle at the same time… while you’re on a tightrope!
|
||
|
||
A more prudent approach is to take a slow and steady path towards your goal.
|
||
|
||
**Limit the scope of change**
|
||
|
||
Limit the number of big (and risky!) architectural changes in one go. One is best; two is plenty, and three is probably too much.
|
||
|
||
If you’re switching compute (e.g. EC2 -> Lambda) and database (e.g. MySQL -> DynamoDB) paradigms, then don’t add microservices or event-drivenness to the mix.
|
||
|
||
**De-risk along the way**
|
||
|
||
Look for opportunities to de-risk, such as running your existing web application as a Lambdalith. Tools like [Lambda Web Adapter](https://github.com/awslabs/aws-lambda-web-adapter), [Serverless Express](https://github.com/CodeGenieApp/serverless-express) and [Chalice](https://github.com/aws/chalice) all support this pattern.
|
||
|
||
That way, you can enjoy the benefits of Lambda (e.g. scalability) without refactoring your entire application and adopting a new set of software development practices.
|
||
|
||
**Start small**
|
||
|
||
If your team is new to AWS and the *serviceful* mindset (i.e. prefer using a managed service over custom code), then start by introducing a low-risk service to your stack.
|
||
|
||
Changing a database requires a lot of work. Moving to Lambda impacts CI/CD and development workflow. So maybe you can start by introducing S3 for blob storage. Or perhaps replace a custom-built scheduling service with EventBridge Scheduler.
|
||
|
||
### It’s not about being “serverless”
|
||
|
||
Instead of thinking about “adopting serverless”, it’s better to focus on reaping the benefits of serverless with the least effort:
|
||
|
||
- Scalability. For example, if your application struggles with traffic bursts, then Lambda can be a good fit because it scales very quickly.
|
||
|
||
|
||
|
||
- Cost-efficiency. Pay-per-use pricing is great for systems with relatively low throughput.
|
||
- Security and compliance. If you have dealt with compliance checklists, my condolences… but you’d appreciate why serverless is gonna be a win for you here!
|
||
- Agility and focus. Spend less time managing infrastructure and more energy building what your customers want. Oh, and don’t confuse “configuring AWS resources” with “managing infrastructure”; [they are totally different things](https://www.linkedin.com/posts/theburningmonk_so-many-people-confuse-configuring-aws-resources-activity-7214022501234847745-qKIM?utm_source=share&utm_medium=member_desktop) .
|
||
|
||
|
||
|
||
|
||
### Serverless-First, not Serverless-Only
|
||
|
||
We say “serverless-first” because we want people to leverage serverless technologies **where it makes sense**.
|
||
|
||
Your business changes over time, and as your context changes, you should adapt accordingly.
|
||
|
||
As I discussed in [my retrospective of the PrimeVideo article](https://theburningmonk.com/2023/05/is-serverless-overpriced-what-can-we-learn-from-the-primevideo-team/), your architecture should evolve with your business needs.
|
||
|
||
Being serverless is not the point. It’s not a religion.
|
||
|
||
For me, the best thing about serverless technologies is that they help me deliver customer value faster. Like that time when [I helped a client launch a new social network in weeks](https://theburningmonk.com/case-studies-nova-sport/).
|
||
|
||
When it comes to adopting serverless technologies in your organization, you too, should focus on finding value. If a move is risky, then find ways to de-risk and take smaller steps instead.
|
||
|
||
|
||
### Related Posts
|
||
|
||
|
||
|
||
**Whenever you’re ready, here are 3 ways I can help you:**
|
||
|
||
1. [**Production-Ready Serverless**](https://productionreadyserverless.com/?utm_campaign=3-ways-I-can-help&utm_source=blog&utm_content=text-link) : Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for**quickly levelling up your serverless skills** .
|
||
2. I help clients **launch product ideas** ,**improve their development processes** and**upskill their teams** . If you’d like to work together, then let’s[**get in touch**](https://theburningmonk.com/hire-me/) .
|
||
3. [**Join my community on Discord**](https://discord.gg/Ucc9nZBA8H) , ask questions, and join the discussion on all things AWS and Serverless.
|