云原生开发者的6个做与不做

世界各地的开发者正在经历着迄今为止最大的软件变革：从单体、单节点的应用程序迁移到运行在分布式系统上的基于微服务的云原生应用程序。

Lightbend最近完成了一项对1000多名者和其他IT决策者的调查，揭示了企业在这一转变过程中面临的挑战以及如何应对这些挑战。作为一名开发人员或软件工程师，你可以从这项研究了解到一些有用的东西。

别忘了为什么要采用云原生技术

你很容易陷入这样一个困境：你想搞明白在使用什么技术，以至于你忘记了当初为什么要使用它们。但请记住，采用云基础设施——无论是自己数据中心的Kubernetes集群，还是公共云中的无服务器API——不是目标。目标是帮助组织构建更具可伸缩性和灵活性的应用程序，并更快地完成构建。如果你在构建应用程序时没有真正考虑云基础设施的优缺点，那么很有可能没有真正实现组织的目标。

设计云原生应用程序来处理无响应或损坏的组件

节点崩溃。网络故障。远程API会产生意外的结果。云原生开发需要你“优雅”地处理这些问题。应用程序需要给用户某种响应，即使一个或多个组件损坏或无响应。你还需要考虑一旦损坏或不可用的组件再次工作时如何恢复。

别忘了安全性和法规遵从性

云原生应用程序面临独特的合规性和安全挑战。接受调查的高管们一再表示，他们希望开发者能在这些问题上多加考虑。早期将安全和合规团队引入开发过程并愿意投入工作以了解其行业的安全性和合规性要求的开发人员不仅会在工作场所取得领先，也可以通过避免在开发周期中进一步重构特性或整个应用程序，提高团队的工作效率。

一定要尽快找到可以转移到微服务或无服务器的功能

云原生开发不是一个全有或全无的命题。你不必一次扔掉所有的单体。你可以构建面向微服务的试点应用程序，同时查看所有现有的单体应用程序，并考虑哪些功能可以中断。跨多个应用程序共享的功能，如支付处理，是一个不错的选择。CPU密集型特性也会降低整个应用程序的速度。镜像转换是一个典型的例子，它可能最好在功能即服务（FaaS）平台上单独运行。FaaS不会强迫用户等待应用程序调整上传的一些镜像的大小，而是可以在应用程序的其余部分继续运行时处理该任务。

不要以为更可配置或更便携的解决方案是“杀手锏”

依赖于那些给开发者提供了很多选择并且在云端之间完全可移植的框架是很诱人的。但更多的选择和控制也意味着更复杂和更大的维护责任。这样做的结果是，你需要做更多的工作，从而将精力集中在构建提供业务价值的功能上的时间更少。当然，依赖云提供商的特殊功能会降低应用程序的可移植性。但是，如果你没有利用这些提供商提供的资源，你真的从云计算中获得了全部价值吗？有时候，最好牺牲一点控制权来换取灵活性和更专注于重要事情的能力。

确定组织可以接受哪些权衡

构建云原生应用程序需要权衡。你需要了解这些权衡，并明确哪些是可以牺牲的，哪些是不能的。这通常意味着要与管理团队沟通，确保技术目标与管理目标一致。

结论

向云原生环境的巨大转变会要求你放弃许多您熟悉的东西，从架构到开发流程再到框架。这也意味着放弃对应用程序部分的控制。但是，这种改变也会让你解脱，当你专注于更高层次的功能时，你会从开发的苦差事中解脱出来。这种迁移意味着把更多的精力放在感兴趣的事情上。

原文链接：6 Cloud Native Do’s and Don’ts for Developers – The New Stack