世界上有两种基础设施，一种是拿来主义，另一种是自主可控。
原谅我也蹭个已经被浇灭的、没怎么火起来的热点。不过我们喜欢的是拿来主义，够用就行，不想也不需要过多的控制，也不想惹过多的麻烦，也就是 fully managed。
之所以想到写这篇文章，源于前几天看到的这篇来自微软 Azure 的博客内容： The Future of Kubernetes Is Serverless ，然后又顺手温习了一遍 AWS CTO 所撰写的 Changing the calculus of containers in the cloud 这篇文章。这两篇文章你觉得有可能有广告的嫌疑，都是在推销自家的共有云服务，但是仔细品味每一句话，我却觉得几乎没有几句废话，都很说到点子上，你可以点击进去看下原文。
有个前提需要说明的是，这里的 Serverless 指的是 Serverless infrastructure，而不是我们常听到的 AWS Lambda，Microsoft Azure Functions 或 Google Cloud Functions 等函数（功能）即服务（FaaS）技术，为了便于区分，我们将这些 FaaS 称为无服务器计算，和我们本文要介绍的无服务器基础设施还是不一样的。
IaaS：变革的开始
说到基础设施，首先来介绍下最先出现的 IaaS，即基础设施即服务。IaaS 免除了大部分硬件的 provision 工作，没人再关心机架、电源和服务器问题，使得运维工作更快捷，更轻松，感觉解放了很多人，让大家走上了富裕之路。
当然这一代的云计算服务，可不只是可以几分钟启动一台虚拟机那么简单。
除了 VM 之外， IaaS 厂商还提供了很多其他基础设施和中间件服务，这些组件被称为 building block ，比如网络和防火墙、数据库、缓存等老三样，最近还出现了非常多非常多的业务场景服务，大数据、机器学习和算法，以及IoT等，看起来就像个百货商店，使用云计算就像购物，架构设计就是购物清单，架构里的组件都可以在商店里买到。
基础设施则使用 IaaS 服务商所提供的各种服务，编写应用程序可以更专注于业务。这能带来很多好处：
- 将精力集中投入到核心业务
- 加快上线速度
- 提高可用性
- 快速扩缩容
- 不必关心中间件的底层基础设施
- 免去繁杂的安装、配置、备份和安全管理等运维工作
在 AWS 成为业界标准之后，各大软件公司，不管是新兴的还是老牌的，都开始着手打造自己的云，国外有微软、谷歌、IBM等，国内的 BAT 也都有自己的云，以及京东和美团这样的电商类公司也有自己的云产品，独立的厂商类似 UCloud 和青云等公司也发展的不错，甚至有开饭馆的也要出来凑热闹。而开源软件 OpenStack 和基于 OS 的创业公司和产品也层出不穷。
全民皆云。
容器：云计算的深入人心
之后在 2013 年，容器技术开始面向大众普及了。在 LXC 之前，容器对普通开发人员甚至 IT 业者来说几乎不是同一个维度的术语，那是些专业人员才能掌控的晦涩的术语和繁杂的命令集，大部分人都没有用过容器技术；但是随着 Docker 的出现，容器技术的门槛降低，也在软件行业变得普及。随着几年的发展，基本可以说容器技术已经非常成熟，已成为了开发的标配。
随着容器技术的成熟和普及，应用程序架构也出现了新的变化，可以说软件和基础设施的进化相辅相成。人们越来越多的认识到对技术栈的分层和解耦更加重要，不同层之间的技术和责任、所有权等界限清晰明了，这也和软件设计中的模块松耦合原则很相像。
在有了责权明晰的分层结构之后，每个人可以更容易集中在自己所关注的重点上。开发人员更关注应用程序本身了，在 Docker 火了的同时，也出现了 app-centric 的概念。甚至 CoreOS 还将自己对抗 OCI/runc 的标准称为 appc 。当然现在的 Docker 也不是原来的 Docker ，也是一个组件化的东西，很多组件，尤其是 runtime ，都可以替换为其他运行时。
和以应用程序为重心相对应的是传统的以基础设施为中心，即先有基础设施，围绕基础设施做架构设计和开发、部署，受基础设施的限制较多。而随着 IaaS 等服务的兴起，基础设施越来越简单，越来越多容易入手，而且还提供了编程化的接口，开发人员也可以非常方便的对基础设施进行管理，可以说云计算的出现也使得开发人员抢了一部分运维人员的饭碗（遗憾的是这种趋势太 high 了停不下来。。。）。
当然，现在以应用为中心这一概念也已经深入人心。特别是进化到极致的 FaaS ，自己只需要写几行代码，其他平台全给搞定了。
编排：兵家必争之地
容器解决了代码的可移植性的问题，也使得在云计算中出现新的基础设施应用模式成为可能。使用一个一致的、不可变的部署制品，比如镜像，可以让我们从复杂的服务器部署中解脱出来，也可以非常方便的部署到不同的运行环境中（可移植性）。
但是容器的出现也增加了新的工作内容，要想使用容器运行我们的代码，就需要一套容器管理系统，在我们编写完代码，打包到容器之后，需要选择合适的运行环境，设置好正确的扩容配置，相关的网络连接，安全策略和访问控制，以及监控、日志和分布式追踪系统。
之所以出现编排系统，就是因为一台机器已经不够用了，我们要准备很多机器，在上面跑容器，而且我不关心容器跑在哪台机器上，这个交给调度系统就行了。可以说，从一定层面上，编排系统逐渐淡化了主机这一概念，我们面对的是一个资源池，是一组机器，有多少个 CPU 和多少的内存等计算资源可用。
rkt vs Docker 的战争从开始其实就可以预料到结局，但在编排系统/集群管理上，这场“战争”则有着更多的不确定性。
Mesos（DC/OS）出来的最早，还有 Twitter 等公司做案例，也是早期容器调度系统的标配；Swarm 借助其根正苗红以及简单性、和 Docker 的亲和性，也要争一分地盘；不过现在看来赢家应该是 K8s，K8s 有 Google 做靠山，有 Google 多年调度的经验，加上 RedHat/CoreOS 这些反 Docker 公司的站队，社区又做得红红火火，总之是赢了。
据说今年在哥本哈根举办的 Kubecon 有 4300 人参加。不过当初 Dockercon 也是这声势，而现在影响力已经没那么大了，有种昨日黄花、人老色衰的感觉，不知道几年之后的 Kubernetes 将来会如何，是否会出现新的产品或服务来撼动 Kubernetes 现在的地位？虽然不一定，但是我们期待啊。
Serverless infrastructure：进化的结果
但是呢，淡化主机的存在性也只是淡化而已，并没有完全消除主机的概念，只是我们直接面向主机的机会降低了，不再直接面向主机进行部署，也不会为某些部门分配独占的主机等。主机出了问题还得重启，资源不够了还得添加新的主机，管理工作并没有完全消失。
但是管理一套集群带来了很大的复杂性，这也和使用云计算的初衷相反，更称不上云原生。
从用户的角度再次审视一下，可以发现一个长时间被我们忽略的问题：为什么只是想运行容器，非得先买一台 VM 装好 Docker，或者自己搭建一套 Kubernetes 集群，或者使用类似 EKS 这样的服务，乐此不疲的进行各种配置和调试，不仅花费固定的资产费，还增加了很多并没有任何价值的运维管理工作。
既然我们嫌弃手动在多台主机中部署容器过于麻烦，将其交给集群管理和调度系统去做，那么维护调度系统同样繁杂的工作，是不是也可以交给别人来做，外包出去呢？
按照精益思想，这些和核心业务目标无关，不能带来任何用户价值的过程，都属于浪费行为，都需要提出。
这时候，出现了 Serverless infrastructure 服务，最早的比如国内的 hyper.sh （2016.8 GA），以及去年发布的 AWS 的 Fargate（2017.12），微软的 ACI（Azure Container Instance，2017.7） 等。
以 hyper.sh 为例，使用起来和 Docker 非常类似，可以将本地的 Docker 体验原封不动的搬到云端：
1 | $ brew install hyper |
大部分命令从 docker 换成 hyper 就可以了，体验如同使用 Docker 一模一样，第一次看到这样的应用给人的新奇感，并不亚于当初的 Docker 。
使用 Serverless infrastructure，我们可以再不必为如下事情烦恼：
- 不必再去费心选择 VM 实例的类型，需要多少 CPU 和内存
- 不必再担心使用什么版本的 Docker 和集群管理软件
- 不必担心 VM 内中间件的安全漏洞
- 不必担心集群资源利用率太低
- 从为资源池付费变为为运行中的容器付费
- 完全不可变基础设施
- 不用因为 ps 时看到各种无聊的 agent 而心理膈应
我们需要做的就是安心写自己的业务应用，构建自己的镜像，选择合适的容器大小，付钱给 cloud 厂商，让他们把系统做好，股票涨高高。
Fargate（此处也可以换做 ACI ）：大厂表态
尽管 AWS 不像 GCP 那样“热衷”于容器，但是 AWS 也还是早就提供了 ECS（Elastic Container Service）服务。
去年发布的 AWS Fargate 则是个无服务器的容器服务，Fargate 是为了实现 AWS 的容器服务，比如 ECS（Elastic Container Service） 和 EKS（Elastic Kubernetes Service） 等，将容器运行所需要的基础设施进行抽象化的技术，并且现在 ECS 已经可以直接使用 Fargate。
和提供虚拟机的 EC2 不同，Fargate 提供的是容器运行实例，用户以容器作为基本的运算单位，而不必担心底层主机实例的管理，用户只需建立容器镜像，指定所需要的 CPU 和内存大小，设置相应的网络和IAM（身分管理）策略即可。
对于前面我们的疑问，AWS 的答案是基础设施的坑我们来填，你们只需要专心写好自己的应用程序就行了，你不必担心启动多少资源，我们来帮你进行容量管理，你只需要为你的使用付费就行了。
可以说 Fargate 和 Lambda 等产品都诞生于此哲学之下。
终于可以专心编写自己最擅长的 CRUD 了，happy，happy。
Serverless infrastructure vs Serverless compute
再多说几句，主要是为了帮助大家辨别两种不同的无服务器架构：无服务器计算和无服务器基础设施。
说实话一下子从 EC2 迁移到 Lambda ，这步子确实有点大。
Lambda 等 FaaS 产品虽然更加简单，但是存在有如下很多缺点：
- 使用场景：Lambda 更适合用户操作或事件驱动，不适合做守护服务、批处理等业务
- 灵活性：固定的内核、AMI等，无法定制
- 资源限制：文件系统、内存、进程线程数、请求 body 大小以及执行时间等很多限制
- 编程语言限制
- 很难做服务治理
- 不方便调试和测试
Lambda 和容器相比最大的优势就是运维工作更少，基本没有，而且计费更精确，不需要为浪费的计算资源买单，而且 Lambda 响应更快，扩容效率会高一些。
可以认为 Fargate 等容器实例，就是结合了 EC2 实例和 Lambda 优点的产品，既像 Lambda 一样轻量，更关注核心的应用程序，还能像 EC2 一样带来很大的灵活性和可控性。
云原生会给用户更多的控制，但是需要用户更少的投入和负担。
Serverless infrastructure 可以让容器更加 cloud native。
fully managed：大势所趋
所谓的 fully managed，可以理解为用户花费很少的成本，就可以获得想要的产品、服务并可以进行相应的控制。
这两天，阿里云发布了 Serverless Kubernetes ，Serverless Kubernetes 与原生的 Kubernetes 完全兼容，可以采用标准的 API、CLI 来部署和管理应用，还可以继续使用各种传统资产，并且还能获得企业级的高可用和安全性保障。难道以后我们连 Kubernetes 也不用自己装了，大部分人只需要掌握 kubectl 命令就好了。
IaaS 的出现，让我们丢弃了各种 provision 工具，同时，各种 configuration management 工具如雨后春笋般的出现和普及；容器的出现，又让我们扔掉了刚买还没看几页的各种 Chef/Puppet 入门/圣经，匆忙学起 Kubernetes；有了 Serverless infrastructure，也差不多可以和各种编排工具说拜拜了。
不管你们是在单体转微服务，还是在传统上云、转容器，估计大家都会喜欢上 fully managed 的服务，人人都做 Ops，很多运维工作都可以共同分担。当然，也会有一部分运维工程师掩面而逃。
本文转载自：「 人间指南 」，原文：https://tinyurl.com/exvzu9tb ，版权归原作者所有。欢迎投稿，投稿邮箱: editor@hi-linux.com。
