云原生微服务应用平台
我们都听说过“云原生”数据库，安全性，治理，存储，人工智能以及云提供商可以提供的几乎所有其他功能。 这是我对云本机应用程序的定义：利用托管它们的公共云的本机系统的应用程序。
一般建议是：“云原生：好。 非本机升降：很糟糕。”
这是有道理的。 通过使用本机服务，我们可以利用核心系统，其中包括使用本机目录服务的本机安全性，本机置备系统以及本机管理和监视。 在公共云上使用非本机应用程序类似于在碎石路上驾驶超级跑车。
现在，我们将本机服务的概念带入新平台，包括容器编排（即Kubernetes）。 Kubernetes有一个由“本机”专用系统组成的大型生态系统，其中包括数据库，存储，安全性，治理，devops工具等。 这里有两种思想流派：
首先，原生是好的。 这些工具可能会提供更好的性能。 Kubernetes本地存储系统每分钟可以扩展到数千个节点和数千个并行操作。 这是因为它是内部人员，使用本地接口与本地Kubernetes应用程序一起工作。
当您需要使用非本机系统与外界联系来满足数据库，存储或安全性等需求时，仅通信转换会带来大量的延迟。 对于这种思维方式，Kubernetes本机总是更好，并且通常是首选。
第二种思想是，我们可能会全盘以赴，从而增加过多的复杂性。 尽管有优势，但迁移到Kubernetes原生系统意味着至少拥有所有两种功能。 迁移到Kubernetes驱动的基于容器的应用程序的企业正在寻找一种通用的数据库系统，该系统跨越Kubernetes内部和外部的应用程序。 与安全性，原始存储和其他云原生的系统相同，但不是Kubernetes。
正确的路径是什么？ 多年来，我吸取的教训之一是，最好的，适合用途的技术通常是正确的选择。 这意味着一切都是原生的，而一切都是原生的，但是您仍然需要明智地选择可以长期运行的解决方案，无论是否使用本机。
会有更多的复杂性吗？ 当然，但是考虑到向多云和基于IoT的应用程序的迁移，这实际上是您的后顾之忧。 无论您是否使用本地Kubernetes解决方案，事情都会变得复杂。 我们也可能擅长于复杂性，并在第一时间就将事情做好。
翻译自: https://www.infoworld.com/article/3449226/going-cloud-native-all-in-or-not.html
云原生微服务应用平台
