关闭

.NET应用程序迁移到云的成本和收益v2.0

基于云的。net应用程序现代化指南

1.执行概要

数千个使用开发框架(如ASP)编写的遗留应用程序。NET仍然被组织使用,通常运行在本地环境中。与此同时,许多组织已经将云计算作为其数字化转型战略的一部分。COVID-19大流行加速了这些数字转型举措,并增加了云的采用,因为各组织不得不发展业务模式以生存。他们扩大了现有的应用程序,并将其转化为现代的、基于云的平台,以提高客户参与度,简化运营,支持远程劳动力,并降低成本。

删除和替换应用程序已经不再可行,对于那些努力应对预算缩减的组织来说,这变得越来越困难。技术决策者需要决定如何处理这些遗留应用程序。有三个主要选择:维持现状,什么都不做;将应用程序迁移到现代的、基于云的环境中并使其现代化;或者重写并替换它们。虽然第一眼看上去,第三种选择可能是最优的解决方案,但重写可能需要数千个应用程序的工作、时间和成本方面的开销可能并不总是最好的方法。

为了帮助技术决策者了解应用程序现代化背后的一些动态,我们进行了一个实地测试,以评估应用程序迁移的好处和成本。这是我们去年运行的一个测试的重复,因为我们希望确保迁移遗留应用程序仍然是一个可行的选择。现场测试将遍历一个迁移场景,并评估其成本、性能和收益。结果与之前的测试相似,并强化了以下几点:

  • 通过将应用程序从本地基础设施迁移到云端,可以显著节省成本。
  • 传统的. net应用程序可以从这种迁移中受益,而无需重构底层代码。
  • 微软Azure解决方案提供的潜在总拥有成本(TCO)比在本地运行节省高达54%,比在AWS上运行节省35%。
  • 精简的操作、简化的管理和接近高级云服务是额外的好处。
  • Visual Studio和MSSQL Manager的内置工具为数据库和应用程序迁移提供了易用性。

对于这种性质的练习,使用遗留应用程序迁移到云是非常关键的,因为这是许多组织发现自己身处的场景,需要平衡应用程序的需求和云的潜在优势。

实地研究专门研究了. net应用程序,这些应用程序允许评估不同的迁移方法,研究了每种方法的优点和缺点。我们发现,与Amazon Web services相比,迁移到Microsoft Azure具有可衡量的TCO优势——在应用Azure Hybrid Benefit (AHB)许可时节省了35%的成本——而且Azure在迁移的容易性方面提供了额外的好处。(图1

图1。三年总预计运营成本

我们得出的结论是,任何云迁移都可以释放大量的时间和资源,用于更有战略意义的任务,从而为业务带来价值,而不是维护资源密集型应用程序。必威网页精装版因此,我们可以说,现代化可以被视为前瞻性应用策略的一个必要元素。最好的起点是评估现有的应用程序,并根据优先级确定每个应用程序的最佳迁移策略。

2.数字化转型:由现代化需求驱动?

过去几年,数字化转型计划一直在进行中,许多组织都在实施多年战略。2019冠状病毒病加速了其中许多战略的实施,但也带来了一个难题,因为许多组织的利润受到了疫情的影响,它们突然发现自己不得不在加快数字化转型的同时削减预算。这样做的结果是保留更多的遗留应用程序,使它们现代化,并将它们迁移到成本更低的云平台上。

还有数千个遗留的。net应用程序仍在使用中,重写它们是不可行的。虽然它们为组织提供了价值,但它们的维护成本往往很高,效率低下,并且常常造成瓶颈。此外,应用程序现代化比开发新应用程序有优势。员工熟悉应用程序,并且随着现代化提高可用性和生产力,他们更容易使用,更容易维护,并且不需要在应用程序被替换时所需要的培训。

将现代化的应用程序迁移到云上可以使组织从云平台内建的安全性中获益,而不是不断地审查和更新内部应用程序的安全措施。采用云计算的另一个好处是,在大流行之后,许多员工现在在家工作,并从防火墙之外访问企业应用程序,组织可以从云供应商提供的安全措施的成本效益中受益。相比之下,确保办公场所内系统供远程工作者使用需要采取额外措施,增加了办公场所环境的总体成本。

因此,云迁移对企业来说很重要,企业需要评估是否应该对应用程序进行现代化,而不是替换。除非转换应用程序能带来切实的好处,否则任何努力都是白费的。选项、好处和成本将在下面的部分中考虑。

3.应用程序现代化的选项和好处

在应用程序现代化的选项中,有从完全重写应用程序到简单地将应用程序提升并转移到新平台的范围。术语可能有所不同,但我们可以将重点放在下面的选项上图2

  • Rehost-运行在本地服务器上的虚拟机被“提升并转移”到基于云的服务器上。
  • Replatform-应用逻辑(例如,用ASP.NET编写)从本地平台迁移到基于云的平台即服务(PaaS)。
  • 重构-对现有代码进行审查和重组,以更好地利用基于云的模型和服务。
  • 重写-本地应用被云本地版本取代,提供类似(如果没有增强的话)的功能。

图2。应用程序现代化的方法

每种选择都有其好处。一方面,就所涉及的工作和成本而言,重新托管相对来说是快速和简单的。然而,组织不能利用云提供商提供的额外功能,而且它没有解决运行过时的、遗留应用程序的所有低效问题。在天平的另一端,一个完全的重写将提供一个现代的应用程序,更有效,优化组织的需求,并允许云主机提供的额外功能,如分析和人工智能嵌入到应用程序中。这种方法的主要缺点是重写应用程序所需的预算和时间。

表1。现代化方法的好处和挑战

表1说明重新平台可以提供一种愉快的媒介,因为它消除了维护基础设施的需要,而这仍然是lift-and-shift方法所需要的,但它不像重写那样耗时或复杂。在重新平台迁移中,应用程序组件被转移到平台即服务(platform-as-a-service),如Microsoft Azure App Service或AWS Elastic Beanstalk。企业受益于让云提供商管理平台的底层基础设施和软件,而只需要对其应用程序进行微小的更改。

除了潜在的成本降低,改造平台的好处还包括:

  • 提高了生产率
  • 增强功能
  • 进入创新

这些好处满足了支持数字化转型的更大灵活性的需求。下面将逐一介绍,并附有微软Azure组合中的插图。

提高了生产率
将应用程序从本地部署迁移到公有云中的完全托管服务,可以通过以下不同的方式提高生产力:

  • 减少管理开销:采用托管平台有助于优化成本并降低与应用程序相关的管理开销。操作团队不再需要为操作系统打补丁、手动扩展容量或管理底层数据库引擎。
  • 提高运营效率:减少开销意味着操作团队可以腾出时间来关注系统的其他方面,努力提高操作效率,减少停机时间。这将操作转移到前面的脚,使团队操作更有信心。
  • 快速应用和特性交付:运营的最终目标不仅仅是保持照明,而是成为创新的推动者,通过减少部署时间和支持前沿服务,授权开发团队更快地交付新应用程序和功能。

像Microsoft Azure这样的提供商提供了丰富的监控、报告和分析工具,可以帮助运营团队诊断潜在问题,找到根本原因,并验证解决方案是否有效。Azure App Service和Azure SQL Database都可以动态自动伸缩,满足客户需求和应用需求。使用这些功能,操作团队不再需要花费时间手动创建新实例或垂直扩展数据库服务器以跟上需求。他们也不需要规划数据中心的容量来适应高峰负载和增长。云可以扩展以满足活动的爆发,然后在需求下降时收缩。

云提供商还可以自动提供用于开发、质量保证、登台等的额外操作环境。操作团队不再需要花费数周时间来创建额外的环境,他们可以使用基础设施作为代码来确保各种操作环境保持一致。

增强功能
除了操作效率之外,云提供商还提供了许多增强操作和开发体验的特性。例如,Azure应用程序服务平台允许开发者在web应用程序上使用部署槽。每个部署槽使用独立的名称空间运行其应用程序版本。流量可以分布在多个槽中,用于金丝雀部署、蓝/绿测试,或者在登台和生产之间进行常规切换。因为Visual Studio和Azure App Service之间也有深度集成,所以开发者可以解锁其他功能,比如现场调试。

Azure App Service还集成了GitHub、Azure Repos和BitBucket,以支持持续部署。对代码库中特定分支的新提交将触发一个构建过程,并将新代码部署到Azure App Service。持续部署特性可以与Azure pipeline集成,以确保在部署新版本之前执行适当的代码覆盖和测试。

使用云可以简化应用数据的备份和恢复以及复制到独立区域。Azure SQL Database可以很容易地将数据复制到指定的合作伙伴区域。Azure App Service的一个缩小的实例可以运行在同一个合作区域,整个解决方案放在流量管理器后面,使得故障转移过程相对简单。由于容量可以按需分配,因此不再需要始终保持容量匹配的灾难恢复环境。

进入创新
迁移本地应用程序将使它们与今天发生在云计算中的快速创新直接毗邻。像Microsoft Azure这样的云中不断引入新的服务和特性。在某些情况下,应用程序的某些部分可以更新以使用不同的服务,比如从传统的Microsoft SQL Server转移到Azure SQL Database,以处理频繁的伸缩性和不可预测的使用。在其他情况下,可以通过消费另一个服务来增强应用程序,比如使用Azure Bot service向现有应用程序添加聊天机器人,或者使用Azure Cognitive Services添加语音命令。

通过将一个应用程序移动到云端,它将可以直接访问所有这些服务,甚至更多。此外,开发人员和运营经理可以自由地调查和试验这些服务,而不是简单地保持照明。

4.比较用于迁移的PaaS产品

虽然新的应用程序可能以云本地的方式开发,但传统的ASP。NET应用程序是在。NET Core和微服务架构等先进技术之前编写的。重写这些应用程序以支持新的编程范式并不简单,也不经济,但这并不意味着它们不能利用云所提供的优势。

传统的ASP。由Microsoft SQL Server支持的NET应用程序可以转移到主要公共云提供商的PaaS产品上。微软提供了Azure App Service和Azure SQL Database,提供了大多数应用需要的web前端和数据库后端。Microsoft管理底层系统,减少与管理和维护web和数据库服务器相关的操作开销。

Amazon Web服务在其Elastic Beanstalk服务中有一些类似的功能,它可以生成包含自动伸缩EC2实例组和部署关系数据库服务的环境。AWS和微软都提供了运行Windows Server和IIS的托管虚拟机,反映了传统ASP的当前部署环境。网络应用程序。微软的PaaS解决方案抽象了大部分底层基础设施和维护细节,而AWS的产品则向客户公开这些细节。

这些平台的相似性使得ASP的迁移。来自内部部署环境的NET应用程序简单且可预测,同时提供了与只使用基础设施即服务(IaaS)组件的升降式迁移相比的优势。

基本上,无需重构或重写代码,传统应用程序就可以无缝地移动到云中的PaaS部署。至少理论上是这样的。为了验证这一理论,GigaOm选择对ASP进行实地测试迁移。NET应用程序从传统的内部办公环境到微软Azure和AWS。现场测试对比了三种环境:

  1. VMware上运行的Windows虚拟机
  2. 微软Azure使用Azure App Service和Azure SQL Database
  3. 使用Elastic Beanstalk、EC2和Amazon RDS的AWS

部署的应用程序是配件无限网上商店,一个ASP。NET应用程序使用IIS作为web服务器,Microsoft SQL server作为后端,如图3.网络商店有一个商品目录,注册用户可以搜索和购买。应用程序安装在每个环境中,并对性能、迁移的便捷性和每个云提供商提供的附加特性进行了评估。

图3。部分无限的应用程序架构

我们将在下面查看现场测试的顶级结果及其影响。附录中提供了现场试验的进一步细节。

5.现场测试结果,迁移收益和TCO分析

测试的一部分包括比较市场上两种领先的云解决方案的性能,Amazon AWS和Microsoft Azure,还有一种选择是将应用程序留在本地场景中。对每个选项进行了迁移的便捷性、性能和TCO测试。

迁移
总的来说,从本地部署到Azure和AWS的迁移过程相对简单,Azure稍微容易一些。微软的开发套件内置了迁移到Azure的功能。这使得通过Visual Studio 2017实现了应用程序的无缝部署。SQL从本地迁移到Azure不需要额外的工具,因为它能够使用MSSQL Management Studio中的内置功能。

使用Azure,整个基础设施都是通过Visual Studio建立起来的。还有很多Terraform可供选择。在应用端,Azure应用部署和基础设施是通过Visual Studio同时完成的。改变网页的能力。配置,而不执行重新加载是一个巨大的时间节省,因为它允许数据库连接字符串进行调整。使用调试控制台进行故障排除是一种愉快得多的体验。

在AWS迁移方面,基础设施是通过webGUI部署的,这使得升级相对容易。迁移数据库有点麻烦,因为我们需要将.bak上传到S3桶并导入它。MSSQL Management Studio没有内置的工具或插件,这将是有帮助的。

在应用程序部署期间,在负载均衡器上的粘性设置和日志记录的不透明性方面存在一些问题。部署后,除了重新部署以外,没有其他方法重新配置应用程序,这可能需要10到15分钟。另外,只能通过webGUI请求前面的100行日志。

on-premises选项需要启动整个VCenter环境,创建windows虚拟机模板,并部署服务器以创建基础设施。这很耗时,但使用Terraform项目会稍微好一些。如果我们要部署到现有环境中,那么许多步骤都是不必要的。将应用程序从开发机器迁移到IIS节点,然后克隆其他节点相对容易,因为这是应用程序部署的一种成熟模式,Visual Studio有内置工具来解决这一问题。

在所有环境中,性能都是相似的,这并不奇怪,因为我们试图确保每个选项使用相似的资源。必威网页精装版云环境的性能略好一些,这很可能是因为网络更加健壮,因为单个机器资源的CPU或RAM利用率从未超过10%。必威网页精装版关于硬件细节的更多信息可以在附录中找到。

这个测试的目的是表明,迁移后的应用程序的性能至少可以与内部部署的实例一样好,如果不是更好的话。一旦应用程序被迁移,就可以添加许多更新来提高性能,包括内容分发网络(CDN)、资源的动态伸缩、升级到HTTP/2,以及向web服务器添加本地缓存。必威网页精装版

微软Azure解决方案与本地办公方案相比节省了高达54%的成本,与AWS相比节省了35%,这表明通过将应用程序迁移到微软Azure可以节省大量成本。尽管与之前的基准相比,Azure的价格略有变化,但在一定程度上仍然是最具成本效益的选择,特别是考虑到迁移的便利性。除了比Azure更贵之外,运行在AWS上还不允许重用现有的微软许可。通过对环境进行动态调整,在需求减少的时期减少消费,可能会有更多的节省。关于TCO计算和性能考虑的更多细节可以在下面找到。

TCO分析
计算用于应用程序现代化或迁移的真正的TCO是困难的,因为在定性方面存在变数,例如管理开销和操作人员总数。对于每个环境的分析,我们假设员工总数保持一致,并且我们没有考虑可能是组织一部分的更大的数据中心或云部署。相反,我们研究了运行每个环境三年的成本。

还需要考虑托管方面的考虑。从本地环境迁移整个应用程序可能会导致删除一个虚拟化主机。因此,对于本地环境,我们包括了两台物理主机的成本、四个用于cpu的vSphere许可证的成本,以及这些主机消耗的电力和冷却的估计。

就结果而言,带有Azure Hybrid Benefit (AHB)授权的微软Azure的总体成本最低,比本地部署节省了约54%的成本,比AWS节省了35%的成本。

AHB许可允许现有的Windows Server和SQL Server许可与active Software Assurance一起应用于Azure虚拟机和Azure SQL数据库实例。根据2021年12月公布的官方价格,一个SQL Standard许可证的估计成本为18,842美元。假设在一个迁移场景中,现有的SQL Standard License被收回用于Microsoft Azure, Azure SQL数据库的成本将从18,842美元降低到8,334美元,这将使Microsoft Azure的总成本降低到32,226美元。在Amazon RDS上不能使用现有的SQL许可。AHB的加入比AWS节省了35%的成本。

这些相对成本显示在表2.请注意,我们没有包含动态可伸缩性和绑定特性,这也是有影响的。此外,Azure的定价计算使用了App Service和Azure SQL的预留容量定价和美国东部地区的托管,而AWS使用了预留实例定价和美国东部-1地区的托管。关于配置和计算的更多信息可以在附录中找到。

表2。按环境划分的估计成本

我们相信,在计算真正的TCO数据时,微软Azure还有其他不那么量化的方面具有优势。一个重要方面是业务效率和行政负担。每种方法都提供了不同的收益和成本组合:

  • Azure应用程序服务和Azure SQL数据库被设计成真正的托管平台,抽象组成每个服务的底层组件。在一定程度上,这限制了客户对web服务或数据库的定制和控制。其代价是微软要处理升级、打补丁和维护。
  • Amazon Elastic Beanstalk更像是提供环境的自动化平台,而不是完全管理的产品。Elastic beanstalk使用的基本构造(ec2、RDS、alb)不是从客户那里抽象出来的,提供了很大范围的灵活性。对于AWS客户来说,这样做的代价是可能会带来更大的管理负载,这与使用IaaS几乎没有什么不同。事实上,更恰当的比较可能是Azure虚拟机规模集、应用程序网关和Azure SQL托管实例。
  • 本地部署不提供任何形式的托管服务。继续支持该应用程序取决于现有的运营团队。与使用托管服务的较低成本和操作效率相比,向云的任何迁移都应该考虑新环境带来的额外管理负载和复杂性。

最后,我们注意到一些应用程序可能需要IaaS类型解决方案提供的额外灵活性。在我们的基准测试中使用的Parts Unlimited应用程序不是其中之一,它基于微软对传统ASP的大力支持。NET,大多数应用程序应该在Azure应用程序服务上工作。

价格/性能考虑
在基准测试过程中,我们在每个环境中平均每小时运行15,000次会话,或每月大约1100万次会话。没有一个web服务器的利用率超过25%,这意味着有足够的空间。通过将web服务器的数量减少到两个,并使用自动缩放策略在CPU达到70%时添加实例,我们可以在不牺牲性能的情况下进一步降低环境成本。

表3举例说明了每个环境的每月成本和每10K会话的成本,包括web服务器从4个缩减到2个。图4比较4 VM和2 VM级别每10K会话的成本。

表3。每个环境的每月成本(越低越好)

图4。每个环境每10,000个会话的成本(越低越好)

不管应用程序是在本地运行还是在Microsoft Azure上运行,都需要相同的SQL Standard许可。如果将应用程序移动到AWS,则不能迁移许可证,相反,许可证成本会被纳入RDS。因此,微软Azure与AHB环境相比,使用4个vm的AWS节省了35%的成本,使用2个vm的AWS节省了39%的成本。

6.结论

希望进行转换的组织可以将应用程序迁移视为减少本地遗留工作负载并受益于基于云的模型的优势的一个明确机会。正如. net应用程序的现场测试所表明的那样,迁移到托管平台环境可以是直接的,并且比本地解决方案提供了显著的好处,无论是有形的(成本/性能)还是无形的(获取创新)方面。

我们建议那些希望实现应用程序现代化的组织,尤其是。net应用程序,考虑以下几点:

  • 使用基于云的平台,可以以极低的成本运行现有的遗留和传统应用程序,释放资源,释放新的应用程序交付的潜力。必威网页精装版
  • 重新平台化应用程序的破坏最小,测试简单,可以在完全部署前进行试点迁移、风险评估和成本评估。
  • 与内部基础设施和平台栈相比,完全管理的平台提供了最高的简单性和最低的管理负担。
  • 将应用程序迁移到云提供了对云提供商提供的附加功能的访问。
  • 对于。net应用程序来说,利用Microsoft的。net很容易就能开始应用程序服务而且数据库迁移辅助工具,帮助自动化迁移到Azure应用程序服务和Azure SQL数据库。

为了开始迁移,我们建议采取以下行动:

  • 评估:根据收入和维护成本对现有应用程序进行分类。虽然可能要处理成百上千的应用程序,但请考虑根据特定的组(如部门、应用程序或数据类型)处理应用程序。
  • 优先级:根据现有维护成本、迁移风险和创建的机会等标准,确定适合迁移的应用程序,以解锁新功能。
  • 评估:您可以映射跨数据源、服务和基础设施的应用程序依赖关系,以帮助确定组迁移候选者。
  • 验证:执行测试迁移以验证功能和性能,并围绕目标环境构建经验,例如,就可用的操作管理仪表板而言。

总的来说,将应用程序迁移到云的机会并不一定要被看作是一件要么全部迁移现有虚拟机,要么部分或全部重写应用程序的事情。通过考虑将重新平台作为一种方法,组织可以在没有成本和风险的情况下迅速获得收益,并为创新和转型解锁新的机会。

7.附录

环境概述

内部办公环境有4台运行Windows Server 2019的web服务器,以及一台运行Windows Server 2019和SQL Server 2019的数据库服务器。负载均衡器是一个运行Ubuntu LTS 20.04和Nginx的虚拟机。图5展示了体系结构。

图5。内部基准测试环境

中的Microsoft Azure环境图6使用Azure应用程序服务和高级V3应用程序服务计划,配置为运行至少四个实例。数据库服务由Azure SQL Database的Gen5实例提供,有四个vcore。负载平衡服务是Azure应用服务的一部分。

图6。微软Azure基准测试环境

中的AWS环境图7m5d使用。Elastic Beanstalk提供的大型EC2实例。这些实例属于一个至少有4个实例的自动伸缩组。数据库服务由Amazon RDS提供,由Elastic Beanstalk提供。RDS实例是一个db.m5。运行Microsoft SQL Server 2019。弹性Beanstalk提供的应用程序负载均衡器支持负载均衡服务。

图7。AWS基准测试环境

测试配置

通过对应用程序运行三个不同的负载测试来评估应用程序每个实例的性能。的主页加载Test只是在浏览器窗口中加载应用程序的主页。的搜索项Test在主页上输入了一个搜索词,并单击了第一个结果。的项目采购Test将用户登录到站点中,并从站点中浏览购买商品的过程。每个测试都运行60分钟,同时有持续的并发用户访问站点的负载。有关测试的更多细节可以在本附录后面找到。

下面给出的两个度量是每次测试中执行成功会话的总数和每次测试的平均持续时间。AWS在成功完成的会话中处于领先地位,特别是在项目搜索测试方面,如图8

图8。跨不同负载测试的成功会话总数(越高越好)

AWS环境的每次测试的平均持续时间最短,Azure也显示了类似的数据。图9显示了结果。

图9。跨负载测试的平均持续时间(越低越好)

总的来说,所有环境的性能都非常一致,在页面加载和条目搜索方面,两个云服务都比本地环境表现出更好的性能。这是有意义的,因为每个环境都使用类似的硬件和软件。然而,就平均持续时间而言,本地站点比购买道具的云选项有更好的表现。

场景配置

模拟的目标是迁移现有的ASP。NET MVC应用程序从传统的内部部署到Microsoft Azure和Amazon Web服务。我们搭建了三个环境来测试应用程序的迁移过程和性能:Microsoft Azure、Amazon Web Services和运行在Packet提供的裸金属服务器上的VMware vSphere。为了保持比较的有效性,我们试图使每个环境尽可能与其他环境相同。在某些情况下,在每个环境中不能使用相同的CPU或确切的硬件和软件规格。例如,Azure SQL Database与Microsoft SQL Server使用的软件不同。当有散度时,我们尽量用最接近的等价物。

应用程序

该应用程序是运行ASP的Parts Unlimited应用程序的一个版本。NET 4.7与MVC。前端使用IIS,后端使用Microsoft SQL Server。配件无限应用程序的版本可以在aspnet45分支下的GitHub

应用程序是使用Visual Studio 2017 Community Edition加载和配置的。对于Microsoft Azure环境,应用程序是使用内置的Azure部署选项直接从Visual Studio发布的。该应用程序被部署到现有的Azure Web App和Azure SQL Database,而不是通过向导创建。向导处理对数据库连接信息的更改。

安装了AWS Toolkit for Visual Studio 2017扩展,以简化应用程序到Elastic Beanstalk的部署。该应用程序被发布到一个预先存在的Elastic Beanstalk环境,而不是通过向导创建一个环境。数据库连接信息的更改是通过一个web转换文件处理的。

对于on-premises环境,应用程序被发布到桌面的本地文件夹,然后手动复制到web服务器。通过更改Web的IIS配置来处理数据库连接信息的更改。配置文件。

应该注意的是,在真正的生产工作流中,发布应用程序的新版本很可能由自动化部署流程处理,作为源代码存储库支持的CI/CD管道的一部分。对于这个测试,更重要的是简单地部署应用程序,而不是构建完整的部署管道。我们将在后面讨论各种部署场景。

本地

为了模拟一个内部部署的环境,我们创建了一个VMware安装,它运行在Packet提供的裸金属服务器上。该环境由两个运行在Packet的Dallas-Fort Worth地区的裸机服务器组成。注意,对于CPU配置,Skylake(2015)是四个架构之一,还有Cascade Lake (2019), Broadwell(2014)和Haswell(2013)。维基百科提供了一个概述英特尔CPU架构.服务器的规格如下:

  • 大小:m2.xlarge.x86
  • CPU: 2倍Intel Scalable Gold 5120 (Skylake) 28-Core @ 2.2GHz
  • 内存:384 gb
  • 硬盘:3.2 TB NVMe
  • 网络:2 × 10Gbps
  • 操作系统:ESXi 6.5

在ESXi主机之上,为web服务器、数据库服务器、vCenter服务器、路由虚拟机和负载均衡器创建了虚拟机。中列出了每个服务器的规格表4

表4。本地服务器规格

虚拟机在内部虚拟机网络的私有地址空间和Packet提供的公网地址空间之间进行路由。

数据库服务器安装Windows SQL server 2019 Standard操作系统。

有四个web服务器与IIS,并安装了。net Framework 4.7。物理主机最多可以支持30个web服务器,尽管这将是一个手动过程来扩展它们。

web服务器的负载均衡虚拟机使用Nginx 1.21.5作为负载均衡。配置Nginx使用ip-hash负载均衡算法。这样做可以确保每个客户端都指向同一个web服务器。

微软Azure

Microsoft Azure环境使用Azure App Service和Azure SQL Database托管运行在美国东部地区的应用程序。应用服务部署时使用的应用服务规划使用Premium 1 v3 SKU。支持App Service计划的虚拟机是运行Windows Server 2019的D2v4 Azure VM SKU。最小实例数设置为4,并使用自动伸缩规则在平均CPU超过70%时添加实例。App服务计划中最多配置30个实例。

D2v4 SKU有2vcpu、8GB RAM和250GB远程文件存储。Azure虚拟机Dv4系列使用的CPU为Intel Xeon Platinum 8272CL (Cascade Lake)。

Azure SQL Database服务器是使用带有4个vcore和20GB RAM的硬件生成Gen5创建的。Gen5硬件使用英特尔Broadwell或Skylake处理器,每个vCore配置5.1GB内存。

Azure应用服务没有为部署在平台上的应用提供直接的负载平衡机制。在常规设置中,可以控制应用程序请求路由(Application Request Routing, ARR)关联。对于部署,我们将ARR亲和性设置为“启用”。

亚马逊网络服务

Amazon Web服务环境使用弹性Beanstalk服务和关系数据库服务(RDS)来托管运行在us-east-1 (N. Virginia)地区的应用程序。弹性Beanstalk环境在Windows Server平台上使用。net,在Windows Server 2019上使用IIS。

平台后面的目标群体使用m5d。大型EC2实例,使用Skylake-SP或Cascade Lake一代2vcpu、8GB RAM和250GB EBS存储的Intel Xeon Platinum。该组被设置为至少有4个实例,并使用自动伸缩规则在平均CPU超过70%时添加实例。最大实例数由AWS区域和帐户的EC2实例配额决定。m族实例的默认限制是64 vcpu,相当于32 m5d。大的实例。为了与其他环境保持一致,为目标组设置了30个实例的限制。

RDS实例使用db.m5创建。超大实例的大小。db.m5。xlarge实例使用Skylake-SP或Cascade Lake处理器,带有4个vcpu和16GB RAM。该实例配置了250GB的EBS SSD存储。

弹性Beanstalk服务的负载均衡器是一个应用程序负载均衡器(ALB),它启用了会话持久性,并采用轮循负载均衡方法。

环境比较

表5所示。跨三种环境的Web服务器和数据库组件

不同环境之间最大的差异是存储和CPU。对于web服务器,Azure应用程序服务实例提供了一个不可配置的250gb远程存储,而AWS EC2 m5d。大型实例默认为30GB, VMware建议Windows Server 2019为40GB。m5d增加了额外的存储空间。奇偶校验的大型实例。在尝试跨平台匹配硬件时,m5系列在内存和处理器方面最接近。

在数据库端,RDS实例大小的最小值为db.m5。xlarge是200 GB。Azure SQL Database有一个可配置的存储量,就像VMware实现一样。

由于存储不是part Unlimited应用程序的约束因素,我们确保所有环境都有足够的存储空间用于web应用程序和数据库。对于存储来说,更重要的因素是具有一致的媒体类型。Azure和AWS使用SSD存储,本地环境使用NVMe。在现场环境中,介质类型的差异可能会导致略微更好的性能,但净影响应该可以忽略不计。

更重要的因素是CPU内核的数量和类型以及RAM的数量,它们在不同的环境中几乎相同(如表6).同样,CPU的生成也尽量保持相似。

表6所示。各环境使用的CPU内核类型

通过保持尽可能多的因素相同,应用程序在所有三种环境中的性能应该是相似的。

测试配置

在这三个环境中执行了三个不同的测试,以检查它们在常见使用场景中的性能。使用Dotcom-Monitor的LoadView进行负载测试。LoadView是一个托管的解决方案,能够从全球多个AWS区域生成网页加载。每个测试由多个负载注入器节点组成,每个节点运行一个或多个测试实例。LoadView评估每个测试,以确定单个节点支持的测试实例的数量。

需要注意的是,测试在AWS中运行,并且测试环境之一也在AWS中运行。具体来说,AWS环境运行在美国东部(北弗吉尼亚)地区。测试环境混合使用了四个不同的AWS区域:

  • 40% -亚马逊美国东部(俄亥俄州)
  • 40% -亚马逊美国西部(北加州)
  • 10% -亚马逊欧盟(伦敦)
  • 10% -亚马逊亚太地区(东京)

这一安排可能会使AWS环境的性能数据略有改善,尽管数据似乎并不支持这一点。

LoadView执行的测试可以是简单的HTTP请求、完整的页面加载或多步骤的网站交互。对于性能测试,我们选择使用三个场景:

  • 首页加载:访问应用程序的主页,并评估加载所需的时间。
  • 条目搜索:访问应用程序的主页面,并使用搜索框搜索条目。单击搜索的第一个结果。
  • 物品购买:访问应用程序的主页面,并以客户身份登录。选择一个项目类别,然后单击该类别中的第一个项目。将商品添加到购物车中,然后购买该商品。

这些测试没有利用API或REST调用。每个测试都模拟浏览器(本例中为chrome)中的操作,并测量完成每个操作所需的时间,以及测试的总时间。

测试结果

主页加载
主页加载是一个加载应用程序主页的简单测试(下图):

负载类型为在一小时内执行的步进曲线,在前10分钟内用户数量逐渐增加,然后在随后的50分钟内持续负载。测试开始是10个用户,10分钟内增加10个用户,然后在50分钟内保持110个用户的稳定。

测试分布在四个AWS区域,负载注入器的分配和数量如下所示表7

表7所示。首页负载测试规范

每种环境都进行了相同参数的相同测试。如上所述,AWS环境以配置负载的40%运行在同一区域。我们应该预料到,由于网络延迟较低,这些测试的响应时间会稍短一些。

表8的结果主页加载针对所有三种环境进行测试。

表8所示。首页负载测试结果

AWS能够在一小时内加载更多的会话,Azure紧随其后。OnPrem有一个更长的会话持续加载页面。

搜索项
搜索项测试的目的是模拟用户加载网站并搜索产品。测试加载主页,在搜索框中输入“电池”,执行搜索,然后点击第一个结果。

负载类型为在一小时内执行的步进曲线,在前10分钟内用户数量逐渐增加,然后在随后的50分钟内持续负载。测试一开始只有5个用户,在10分钟内增加5个用户,然后在50分钟内稳定在55个用户。

测试分布在四个AWS区域,负载注入器的分配和数量如下所示表9

表9所示。项目搜索测试规格

每种环境都进行了相同参数的相同测试。表10的结果搜索项针对所有三种环境进行测试。

表10。项目搜索测试结果

LoadView可以在AWS环境中完成更多的会话。这很可能是由于LoadView代理位于AWS本身。

项目采购
项目采购测试的目的是模拟用户从网站购买商品。在每个环境中创建了10个用户,用于登录和购买过程。在每次测试中,用户都会访问主页并登录到站点。然后他们点击灯光类别,然后点击结果中的第一个项目。然后他们将商品添加到购物车中,然后去结账。结账时,他们填写购买字段并完成购买。

负载类型为在一小时内执行的步进曲线,在前10分钟内用户数量逐渐增加,然后在随后的50分钟内持续负载。测试一开始只有5个用户,在10分钟内增加5个用户,然后在50分钟内稳定在55个用户。

测试分布在四个AWS区域,负载注入器的分配和数量如下所示表11

表11所示。测试规格

每种环境都进行了相同参数的相同测试。表12的结果项目采购针对所有三种环境进行测试。

表12。项目购买测试结果

对于并发用户的数量,这三个选项的性能都一样好。LoadView被设置为在任务之间有一个“普通用户”延迟。这可能导致了类似的时间点。在此场景中,服务器从未被征税。

测试总结
总的来说,每个环境在所有三个环境中的性能是一致的。AWS能够在每个测试中处理最多的会话,并且平均持续时间最低。AWS环境还产生了最一致的性能,每次测试的标准偏差最低。在每次测试中,内部环境都滞后。

尽管AWS和Azure环境被配置为自动伸缩web服务器,但自动伸缩事件从未发生过。这四个实例能够处理测试生成的负载,而不会超过70%的CPU利用率标记。事实上,每个环境中所有web服务器的CPU利用率从未超过40%。

如果测试表示Parts Unlimited应用程序上的正常负载,那么将web服务器实例的数量减少到三个或两个可能是安全的。有了Azure和AWS的动态伸缩特性,当负载增加时向外伸缩,当负载低于某个阈值时往回伸缩就变得很简单了。

TCO的细节

使用AWS TCO计算器、AWS定价计算器和Azure定价计算器计算每个环境的成本。尽可能使用保留的容量,最长可维持一至三年。总成本是应用程序运行三年的估计。

成本计算只关注于运行应用程序,而不是所有的支持服务,如监控、数据保护和安全性。将单个应用程序从内部设施迁移到云不会显著影响剩余支持服务的成本结构。此外,每个云中的支持服务通常是免费的,或打包为服务的一部分。

节省下来的钱是非常可观的。我们的建模结果表明,在Azure上使用Azure Hybrid Benefit许可构建的部署可以比AWS部署成本节省35%,比本地部署成本节省54%。

本地费用
基准测试是在运行四个web服务器的情况下进行的,产生的成本为表13

表13。本地估算成本

微软Azure成本
执行基准测试时,App Service运行PremiumV3 SKU (P1大小),有4个实例,Azure SQL Database运行Gen5服务器类型(有4个vcpu)。由此产生的成本突破显示在表14

表14。微软Azure估算成本

注意,这里显示的Azure SQL数据库成本并没有反映Azure Hybrid Benefit (AHB)许可选项,该许可选项允许在Microsoft Azure上使用现有的SQL许可。在迁移场景中,一个组织可以将他们现有的SQL许可证带到Azure上,从而节省SQL许可证的费用,在三年内将Azure SQL数据库的成本降低到8334美元。Azure SQL Database和App Service Plan都应用了保留实例定价选项,以进一步降低环境成本。

这种成本结构,反映在计算中使用表2而且表3,可节省大量开支。例如,在没有AHB的情况下迁移到Azure的估计成本为42735美元,而使用Azure AHB的成本为32226美元,如下所示表2

随着AHB的应用,Azure迁移的每月成本也发生了显著的变化。一个4 VM的部署,花费895美元的Azure与AHB在表3如果没有AHB,将花费1187美元。使用Azure AHB的2 VM Azure部署的成本从613美元上升到不使用AHB的905美元。

对会话成本的影响是相当的。在4 VM时,使用AHB的Azure每10K会话的成本为0.81美元,而不使用AHB的Azure每10K会话的成本为1.08美元。在2 VM时,这些数字分别为0.56美元和0.82美元。

AWS成本
基准测试是用EC2在m5d上运行4个实例进行的。一个使用db.m5的RDS实例。超大尺寸。应用程序负载均衡器没有与Elastic Beanstalk捆绑在一起,网络流量也没有捆绑在一起——它们都被分解为单独的行项。表15显示估计成本的纲要。

表15。AWS估算成本

8.关于迈克尔Delzer

迈克尔Delzer

Michael Delzer是全球领先的技术公司,拥有丰富多样的技术经验。他曾担任美国航空公司(American Airlines)首席基础设施架构工程师15年,通过利用市场洞察力和准确的趋势预测,为从初创企业到《财富》100强企业的公司提供竞争优势。他擅长识别技术趋势并提供整体解决方案,这导致了业务涉众和IT人员对愿景目标的热情支持。迈克尔获得了美国建筑师协会颁发的金质奖章。

Michael拥有丰富的行业经验和广泛的知识,能够构建在实现创新的同时优化价值和速度的IT解决方案。20多年来,他一直在建设和运营数据中心,并完成了北美和欧洲1000多个数据中心的审计工作。他目前在绿色数据中心技术方面为初创公司提供建议。

9.关于乐时

乐时

KK Verma是一位职业生涯的首席信息官(CIO),拥有超过30年的经验,专注于通过利用技术来推动收入、盈利能力和客户卓越性,建立和发展组织。在他的职业生涯中,他曾领导过一些知名公司的技术部门,如Conduent, Citigroup, IBM, American Airlines, Hewlett Packard。

KK是一名战略顾问和合作伙伴,曾领导过几次大型组织的数字化转型,并取得了良好的成果。他将领导技能、组织发展和关系建立技能融为一体,创造新的商业模式,在新经济中茁壮成长。

他持有University of Texas的工商管理硕士学位和Pune University的计算机工程学士学位。他目前和家人在德克萨斯州的达拉斯居住了25年多。

10.关于埃文•奇泽姆

埃文•奇泽姆

Evan Chisholm是一名经验丰富的IT工程师,专注于过程自动化和提高运营团队的技能,以采用DevOps实践。埃文曾在多个垂直领域与各种规模的组织(从初创公司到财富500强)合作,包括金融科技、制造业和服务交付。他的目标是消除“苦差事”,让工程师能够做比他们想象中更多的事情。

11.关于GigaOm

GigaOm为IT战略数字企业和业务计划提供技术、运营和业务建议。企业商业领袖、cio和技术组织与GigaOm合作,为他们的业务现代化和转型提供实用的、可操作的、战略的和有远见的建议。GigaOm的建议使企业能够在日益复杂的商业环境中成功竞争,这需要对不断变化的客户需求有深刻的理解。

GigaOm直接与IT组织内部和外部的企业合作,应用经过验证的研究和方法,旨在避免陷阱和障碍,同时平衡风险和创新。研究方法包括但不限于采用和基准调查、用例、访谈、ROI/TCO、市场前景、战略趋势和技术基准。我们的分析师拥有20多年的经验,为从早期采用者到主流企业的客户提供咨询。

GigaOm的观点是公正的企业从业者的观点。通过这个角度,GigaOm与投入和忠诚的用户建立了深刻而有意义的联系。

12.版权

©明知公司。2022“。net应用程序迁移到云计算的成本和收益”是一个商标明知公司。如欲复制此报告,请联络sales@www.l5pwigs.com