Ask HN: 放弃 AWS Lambda/SQS/SNS/Aurora，值得吗？
1 分•作者: edweis•9 个月前
我们的客户希望在本地使用我们的SaaS解决方案，以降低服务中断的风险。
考虑到这个机会，我正在评估进行本地部署的成本，并可能部分或完全放弃AWS。
我们当前的架构是EC2/lambda/SQS/SNS/Aurora/S3以及一些基础的网络设置。AWS部署通过`serverless V3`完成，所有代码都使用Node.js编写，NGINX用于路由。
我看到放弃AWS的主要好处是：
1. 部署简单，只需在所有服务器上执行`rsync`，并在分片数据库上运行迁移。
2. 没有厂商锁定。
3. 节省成本，我们目前的费用不高，但账单一直在稳步增长。
而我主要担心的是：
1. 托管服务：SQS/SNS/lambda/Aurora都提供自动伸缩的托管服务。根据经验，这真的有必要吗，还是更大的服务器就能解决问题？
2. 实际迁移工作量：我们是一个精简的团队，但我们发现从其他服务（Cognito、DynamoDB）迁移比预期的要容易。
3. 服务质量下降：SQS/SNS/lambda可以轻松替代且不损失功能吗？我正在考虑RabbitMQ。
如果有人做过类似的迁移，你们的体验如何？另外，我这里讨论的是本地部署，但这真的是降低服务中断风险的最佳解决方案吗？
查看原文
Our clients are interested in using our SaaS solution on-premises to mitigate the risk of service interruption.<p>Considering the opportunity, I am assessing the cost of doing on-premise deployments and maybe partially or fully moving away from AWS.<p>Our current stack is EC2/lambda/SQS/SNS/Aurora/S3 & minor networking setups. AWS deployments made via `serverless V3`. All the code is in Node.js., NGINX is used for routing.<p>The main benefits I see in moving away from AWS are:
1. Ease of deployment, simply do an `rsync` on all servers and run migrations on the sharded database.
2. No vendor lock-in
3. Cost saving, we have minor costs for now but the bill is steadily increasing.
And my main fears are:
1. Managed services: SQS/SNS/lambda/Aurora are managed for autoscaling. From experience, is it really necessary or does a bigger server do the trick?
2. Actual migration effort: we are a lean team but we found that migrating away from other services (Cognito, DynamoDB) was easier than expected.
3. Worse service: can SQS/SNS/lambda easily be replaced without feature loss? I am looking at RabbitMQ.<p>If anyone did a similar migration, how did it go for you? Also I am talking about on-premise but is it the best solution to mitigate the risk of service interruption?