应用错误收集

您几乎可以将本地应用程序提升并迁移到云中，而无需更改应用程序代码。

但是，如果这样做，您将几乎失去了云的要点，因为您仍将负责修补服务器，配置负载均衡器，优化数据库等。

如果您的唯一目标是降低物理基础架构成本，并且您不担心运营成本（例如，将管理基于云的基础架构的人员），并且云肯定便宜，那么您可以这样做。

但是，如果您想利用云的真正好处-弹性和更完全托管的服务-那么您可能想要看看云的本机功能。

例如（以AWS为例）

可以考虑使用DynamoDB（完全托管的非SQL数据库）来代替自己管理MongoDB数据库
考虑使用RDS（一种完全托管的数据库即服务，支持PostgreSQL，MariaDB，MySQL等多个DB），而不是像PostgreSQL这样的传统SQL数据库。
考虑自己使用ELB（托管网络和应用程序负载平衡器）来代替自己配置负载平衡器
考虑运行SQS和SNS（基于HTTP的轻量级消息传递），而不是像RabbitMQ那样运行消息代理
请考虑是否可以将其实现为无状态Lambda（功能即服务，即除了您的代码之外，什么也没有，而不是运行操作系统，应用程序服务器和微服务代码的大量虚拟EC2服务器） / S或应用程序服务器或容器管理）。

其中许多服务都可以自动，无缝地扩展和缩小以满足需求，而您只需为使用的商品付费，而无需超额配置。

那只是关于如何重新考虑应用程序设计以利用云的一些想法。请注意，您在此路径上将自己锁定为供应商。

编辑：好的，因此，如果您打算在内部进行构建，然后再迁移，则上面的云原生选项显然不会起作用，尽管有些仍然适用。

因此，最简单的方法是正常构建应用程序，然后在OS，应用程序服务器和应用程序运行于今天的生命周期内，转向基础架构即服务（IaaS）。将数据库移至等效的托管服务。考虑简单地放弃内部负载平衡器，并在迁移时使用云原生负载平衡器。

另一种方法是使用容器（特别是Docker）在内部打包和部署。您需要在内部管理自己的Docker集群，但是当您将应用程序转移到云中时，可以将其托管在托管服务上，例如ECS（AWS弹性容器服务）或EKS（AWS弹性Kubernetes服务）。