第一件，他们会尝试用和本地一样的架构在云端以租用的方式来运行，重新创建相同的功能。温馨提示： 一定不要采取这种方式，因为这样做的结果是，最终会导致项目失败。

第二件，他们将重新设计和再造应用程序，利用云计算的一些基本优势来操作。换个意思来表达，就是云原生方式。

虽然，不管哪种方式，都可以将传统的应用和数据直接迁移到云端，但笔者建议：对比直接把软件从本地迁移到云的方式，选择云原生的架构，会让企业在未来的上云体验更加顺畅。

原因一、云原生架构能带来更弹性的成本优势

假如，你想将您的物理基础设施用于与云，构建与云虚拟基础设施相匹配的资源体系，注定会造成失败的结果。即使像亚马逊、Azure和谷歌云这种大型云计算企业，能提供各种规模的虚拟机，并且所提供的服务能或多或少地与物理对应的规格相匹配，但也几乎永远不会在云支出上找得最佳平衡点。作为普通用户，我们的IT规划能力远不及这些大型云计算平台，不能提供灵活的定价选项，如 "保留实例"、企业协议和储蓄规划等等。

原因二、计算和存储的分离增强了本地和云之间的联系

在用户的数据中心中，我们购买的服务器通常有一些直接附加的存储(DAS)，你可以用它来存储临时文件、图像、文档或其他东西。但是，当你进入云端的SaaS领域时，依赖这种模式是很危险的，因为你的计算机/CPU需求的起伏可能与你的数据存储需求大不相同。而采用云原生的方式，我们能够使用AWS S3或ADLS等对象存储服务，这些服务可以根据计算需求分开购买、优化和管理。这种计算和存储分离的方式将帮助你避免 "规模化部署危机"，比如：在增加10000个新用户的时候，这种优势尤为明显。

原因三、读写分离的方式更容易扩展

同样，当你向潜在的高并发用户群部署应用，想获得更丰富的SaaS服务时，你可能要选择好的数据发现、数据操作和数据检索技术。在过去，关系型数据库可能是这些功能的合理选择，但在云规模的数据量和用户中，选择更专业的云服务可能是有意义的，比如列式存储、内存数据库或数据流。这样一来，如果你的大部分工作负载是读密集型的，而你的数据库写入是突发性或间歇性的，那么你的正常SaaS操作就会继续，即使写入量可能会激增(比如，在一个季度或一年的末尾)。读写分离的方式可以提供更好的用户体验和更有弹性的运营模式。

原因四、在云存储方面拥有得天独厚的优势

云优先的设计方案，还体现在云存储方面的优势，如S3或ADLS。在多云环境下，云提供商将面临更大的竞争压力，需要在其存储服务内进行改革和创新。密切跟踪并快速适应这些创新的应用架构师将比那些更加谨慎的竞争对手拥有各种优势。以亚马逊最近新增的读写一致性为例。将这一功能内置到存储中，可能意味着对于某些用例来说，支付某种SQL查询引擎可能没有必要。其他可以从这种竞争性创新中受益的领域是安全、加密、压缩或其他节约成本的措施。

原因五、让服务万无一失

对于那些采用云原生方法的公司来说，一个明显的优势是即时性、自动化和简化的思维方式。SaaS供应商通常可以通过是否能够提供即时配置、设置并忘记配置以及 "按钮式 "的用户体验来决定其生死，即使是复杂的IT或业务功能。万无一失的另一面是通过提高自动化程度、内置预测性智能或机器学习，使用户能够提高工作效率，从而确保你的环境以最佳状态运行。SaaS公司必须善于创建万无一失的工作流程，提高用户的生产力和效率。

原因六、让上云下云做到顺畅自如

虽然每个云提供商都有专有的云服务(数据仓库、ETL、消息传递、存储)，他们也提供了一套丰富的即开即用的开源技术，如Spark、Kafka、Flink、MySQL、Postgres等。虽然说使用这些开源产品就可以轻松地从一个云迁移到另一个云，并且这确实意味着，如果要更换云提供商，迁移可以不用完全重写。更为重要的是，许多IT架构师正在向多云模式发展，已经有更多公司在与两个或多个云提供商打交道。如果你的企业能够专业地利用来自不同厂商的云服务，能在各种混合云环境中游刃有余，这是你的云架构面向未来的第一步。

SaaS厂商要想在高手如林的市场竞争中取得成功，就需要先发制人，采用云原生的方案，可以达到令人满意的效果，把云服务打造成最完美云的标杆：弹性、创新，并更具成本效益。