在云上部署与本地部署相比,应用程序级别的变化是什么

时间:2019-02-13 09:58:31

标签: architecture cloud

如果我们使用云/内部部署,我想知道应用程序范围的变化。
基于云的:我们无需担心服务器,软件,可伸缩性,会话管理,负载平衡等问题。
内部部署:所有这些都可以在内部实现。

示例:我们可以考虑使用一个简单的Web应用程序来存储客户信息,而另一个页面列出了在该应用程序中注册的所有客户详细信息。它使用Web API,SQL数据库和Angular / React作为前端技术进行开发。

如果选择云还是内部部署,在应用程序中是否需要进行任何特定的更改?

1 个答案:

答案 0 :(得分:1)

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

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

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

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

例如(以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服务)。