『阿里云云栖社区TB』就是没有架构?,云原生基础架构的最佳状态( 二 )


这里强调一下自治 , 它和自动化不能划等号 。 自动化是人类输入的一个完整的业务流程 , 一个流程只能做一件事 。 而自治不需要人类做出决定 , 它仍然使用自动化 , 但只有当系统不能自动确定正确要做的事情时才应该通知人 。 自治比自动化多了智能化 。
总的来看 , 云原生基础架构一个较为通俗的描述 , 应用可以通过平台层自动完成资源调用、协调 , 无需人工干预 , 所有的资源都是可以随时拉起 , 随时释放 , 同时以API的方式提供弹性、按需的计算、存储能力 。
如果这种解释令人费解 , 那么 , 我们可以这么比喻 , 只要符合“杯子”的概念都是“杯子” , 但是制作流程和工艺、材质有本质的不同 。 而大体上 , 市面上有默认的几种模式 , 这也就形成了通用的标准 。
所以 , 云原生基础架构也没有业内“放之四海而皆准”的标准 , 它本身也在随着技术的演变而在演变中 , 只要符合“灵活、低成本、易维护”等特点 , 就是云原生 。 我们不必拘泥于概念 , 而是要不断往前看 , 为什么要采用“云原生” , 为用户带来的好处是什么?
这才是核心 。
能带来什么好处?
云原生基础架构带来最大的变革在于API机制 。 API机制允许用户从标准化基础架构即代码中获益 , 并增加了随着时间的推移版本化和更改表述的能力 。
具体而言 , 实现了云原生基础架构后 , 技术人员部署服务器、管理服务器模板、更新服务器和定义基础设施的模式都是通过代码来完成的 , 并且是自动化的 , 不需要通过手工安装或克隆的方式来管理服务器资源 , 运维人员和开发人员一起以资源配置的应用代码为中心 , 不再是一台台机器 。
值得一提的是 , 基础设施的包含范围也会很广泛 , 不仅包括机器 , 还包括不同的机柜或交换机、同城多机房、异地多机房等 。
换句话说 , 只需要调整相应的API就能实现资源使用方式的调整 , 整个过程无需关心底层基础架构的变化 。 云原生基础架构的理想状态是 , 它非常容易被忽略 , 它简单、自动化、可自服务 , 也就是没有基础架构 。
因此好处显而易见 , 对运维人员是一种解放 , 对企业而言 , 能将更多精力投入业务开发、运营中 , 公司整体运营效率将大幅提升 。 当前 , 这种模式已经被证明了可以扩展到巨大数据的基础架构和应用程序的 。
【『阿里云云栖社区TB』就是没有架构?,云原生基础架构的最佳状态】云原生基础架构实现
弄清楚了云原生基础架构的本质 , 这部分简单介绍下云原生基础架构的实现 , 主要分三部分:设计、开发和测试 。
至于具体的方法实践倒是其次 , 这部分最重要的是转变观念 。 原本传统的基础架构运维人员要成为基础架构软件工程师 , 只有适应了身份的转变 , 才能更好地到达云原生基础架构的彼岸 。
作为一名基础架构工程师 , 不仅要掌握设计、管理和运维基础架构的基本原则 , 还要把专业知识应用在构建强健的应用程序中 , 这些应用程序代表了将要管理和改变的基础架构 。
回归技术关键 , 最重要的一个环节就是API , 设计、开发 , 乃至最后的应用 , API关乎成败 。 因为基础架构将需要随着时间的推移而变化或者变异 , 这是云原生环境的本质 。 当运维承担改变基础架构的任务时 , API的真实价值就体现出来了 。
有关API的设计 , 及更多技术细节这里不做太多讨论 , 有兴趣的朋友可以找相关书籍查阅 , 每本书的思想、方法都可能不一致 , 要学会兼容并蓄 , 取长补短 。
总结全文 , 云原生基础架构是基础架构的自然而可能预期的演变 。 实现云原生基础架构是比较难的 , 如果你认为云原生基础架构是你可以购买的产品 , 或者可以运行服务的供应商 , 显然要失望了 , 就目前阶段而言 , 只有极少数产品实现了云原生 , 比如今年 , 各大云服务商都在推的云原生数据库算是其中的典型代表 。 实现云原生这条路还很长 , 要慢慢学 , 慢慢深入 。