在首次将工作负载迁移至云端时，他们往往会错误地认为公共云可以解决所有IT问题（如可扩展性、高可用性、降低成本等）。
在实现目标时，组织常常犯下架构上的错误。
在这篇文章里，我们会来看看公司们在做架构设计时经常踩的坑。
直接迁移方法将遗留的单体应用从本地环境迁移到公共云（除非你需要特定的许可证或硬件支持）可能有效，但这样效果会很差。
尽管虚拟机在云端可以运行得很好，但大多数时候，你需要随时间衡量虚拟机的性能，并根据实际运行的工作负载调整实例大小以适应实际负载，以符合客户需求。
直接迁移的方法适合作为临时解决方案，直到组织有时间和资源来重新设计工作负载架构，可能还会选择不同的架构（比如从虚拟机迁移到容器，甚至直接采用无服务器架构）。
从长远来看，直接迁移将是一个成本高昂的解决方案（与本地解决方案相比），并且无法充分利用云提供的功能（如水平扩展、扩展到零负载、托管服务的弹性恢复能力）。
使用 Kubernetes 处理小型/简单的负载在设计现代应用程序时，组织通常会跟随行业趋势。
最热门的趋势之一是选择容器来部署各种应用组件，在很多情况下，机构会选择 Kubernetes 作为容器编排工具。
虽然 Kubernetes 确实有很多好处，虽然所有大规模的云提供商都提供托管的 Kubernetes 控制平面，这同时也带来了许多挑战。
完全掌握如何配置和维护 Kubernetes 系统的学习过程会非常漫长。
对于小型或可预测的应用程序，由少量不同类型的容器构建而成，有更好的且易于部署和维护的替代方案，例如Amazon ECS，Azure Container Apps，或Google Cloud Run——它们都足以运行生产工作负载，相比Kubernetes，更容易学习和维护。
云存储备份与灾难恢复当组织开始寻找使用公共云的第一个用例时，他们首先想到了将其作为备份位置，或者直接用于灾备场景。
虽然这两种用例都有效，但往往会忽略整体情况。
即使我们使用对象存储（或管理的NFS/CIFS存储服务）为组织的备份站点，我们也必须始终考虑到恢复阶段这个过程。
从云端拉取大型二进制备份文件回本地环境需要很长的时间，更不用说还有出网数据费、调用API的费用等等相关费用。
与DR场景一样——如果我们把本地的虚拟机或甚至数据库备份到云端，如果云端没有类似的基础设施环境，那么在发生灾难性灾难时，冷DR站点又能帮上什么忙？
将应用程序与后端数据存储库层级解耦大多数应用是由前端应用层和后端持久存储层组成的。
在遗留或紧密耦合的架构中，应用层和数据存储层之间需要保持低延迟，尤其是在从后端数据库读取或写入数据时。
一个常见的错误是创建一个混合架构设计，其中前端在云端，从本地数据库获取数据，或者连接到云中的数据库服务，这种情况较为罕见。一个本地遗留系统会连接到这样的数据库服务。
除非目标应用程序对网络延迟不太敏感，通常建议将所有组件尽量靠近，以减少组件之间的网络延迟。
转向多云环境以期望解决供应商锁定的问题很多组织也在面临的一个常见问题是供应商绑定（即，客户被特定云供应商的生态系统绑定）。
当我们谈到这个风险时，供应商锁定就是指在不同云服务提供商之间切换的麻烦。
多云环境并不能解决这些风险，但它将带来更多挑战，例如技能不足（熟悉不同云提供商生态系统的团队）、集中式身份管理和访问控制、跨多个云环境的事件处理、出站流量费用等等。
与其设计复杂的架构来缓解理论上的或潜在的风险，不如设计满足业务需求的解决方案，先熟悉一个公有云提供商的生态系统。随着时间的推移，一旦你的团队对不止一个公有云提供商有足够的了解，再逐步扩展你的架构——不要一开始就急于采用多云。
选择云中性价比最高的位置一般来说，除非你有特定的数据驻留要求，否则选择离你客户近的区域，以减少网络延迟
成本确实是一个重要因素，但你应当设计一个架构，使得你的应用程序和数据更接近你的客户。
无论你的应用服务于世界各地的客户，还是在多个地点，可以考虑添加一个 CDN 层来将所有静态内容保持得更接近客户，结合多区域解决方案（例如跨区域复制、全球数据库、全球负载均衡器等）。
瑞典译为未能重新评估现有架构在过去，我们通常为应用设计架构，并在整个应用的生命周期中保持架构不变。
在设计现代应用程序时，在云端，我们应该保持灵活思维，即不断评估架构，回顾过去决策，看看新技术或新服务能否为运行应用程序提供更好的解决方案。
云的动态特性所带来，结合不断进步的技术，从而使我们能够更快、更稳定且更经济地改变和优化运行应用程序的方法。
架构决策中的偏见这是一些架构师常犯的错误——他们有特定云服务提供商的背景，并以其生态系统为中心设计架构，从而在架构设计中嵌入了带有偏见的决策和服务限制。
相反，建筑师应该充分理解业务需求、云解决方案的全貌、服务的成本及限制，然后才开始选择最合适的，并参与应用程序架构的设计。
在做架构设计时，没有考虑到成本因素成本是一个重要因素，在使用云服务时，其中一个主要原因是能够随需使用服务，并且停止为不用的服务付费。
你做出的每一个决定（从选择合适的计算资源、存储资源、数据库资源等等），都会影响成本。
一旦我们理解了每个服务的定价模式以及具体的工作负载增长潜力，我们就能估算出潜在的成本。
如我们之前提到的，由于云的动态特性，每个月的成本可能会有所不同，这取决于云的动态特性。因此，我们需要定期检查服务成本，根据需要更换服务，并调整以适应实际的工作需求。
摘要公共云服务在选择合适的服务和架构来满足特定的工作需求和应用场景时，面临着许多挑战。
尽管在设计架构时没有绝对的对与错，但在本次博客文章中，我们回顾了许多“不尽如人意”的架构决策，这些决策可以避免，因为它们仅仅关注短期解决方案，而忽略了长期规划和整体视角。
给帖子读者的建议是：不断扩展你在云和架构技术方面的知识，并不断质疑你当前的架构，看看是否随着时间的发展，是否有更适合你过去选择的替代方案。
作者简介Eyal Estrin 既是一位云安全架构师，也是一位信息安全专家，著有《云安全指南》（https://amzn.to/3xMI4Ak）和《云原生应用安全指南》（https://bit.ly/4cyxaA6），拥有超过 20 年的 IT 行业经验。您可以在社交媒体上找到他（https://linktr.ee/eyalestrin）。
这些都是他自己的看法，不代表他老板的观点。
简单点说 🚀感谢你加入简单英语社区！感谢你成为简单英语社区的一员！在你离开之前，希望你在这里度过愉快的时光，简单英语 社区期待你的再次参与。
- 记得为作者点赞并关注👏
- 关注我们：X|领英（LinkedIn）|YouTube|Discord|Newsletter
- 访问我们的其他平台：Stackademic|CoFeed|Venture|Cubed
- 更多精彩内容请访问 PlainEnglish.io
随时随地看视频
