问题描述
想了解在什么情况下不适合使用AWS Lambda等无服务器技术。他认为使用无服务器计算，Amazon（AWS）将负责架构、管理和部署AWS服务（VPC/EC2/ELB/AScaling/Rtables/SGroups等），以使应用程序运行。然而，这种方法会使用户失去对设计与应用程序相匹配的最佳VPC架构的控制权。用户想知道在什么情况下不应考虑无服务器计算。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
通常情况下，没有一个通用的答案来回答这个问题，但以下是一些不考虑Lambda（或其他无服务器平台）的原因：
– 应用程序需要使用不可用的语言（如C++、Haskell、Erlang等）。
– 组织已经在容器化（或其他）应用程序开发模型上投入了大量资源，包括开发人员的知识、构建和部署流程。
– 可移植性是一个问题；即组织希望/需要保持应用程序在各个平台（AWS、Azure、各种k8s实现等）之间可移植的状态。
– 成本。运行Lambda函数以及相关资源（API Gateway、VPC组件）的成本是否超出预算？如果组织已经在AWS上运行，这是不太可能的，但与现有（已支付）的本地资源相比可能是一个因素。
方案2
使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。
示例：
以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：
#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b
在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。