IT的发展自始至终都是以给业务创造价值为目标，在数字化大行其道的今天，IT逐渐从幕后走向了幕前，如何为企业增加新的业务应用，或为已有应用增添新功能以快速拉开与同类产品的差异是在这个时代下的业务重点，也是当下每个IT技术发展的关注点。
首先从部署流程来讲，传统的瀑布式开发已经很难应对市场快速多变的需求，相对于花五个月时间完成前期调研的需求的100%，不如每个月交付20%的已知需求，在递交下一个20%新功能的时候，同时也对之前的需求进行检视并根据市场反应更新已有功能。我们同样意识到开发和运维不是独立的，尤其在交付频率大增的情况下，开发需要兼顾运维的工作，或者明确地将错误代码的修正方式移交给运维；
接下来是应用架构，传统的单体架构应用耦合度极高，给版本迭代，各功能的独立修正带来了极大不便；之后比较通用的解决办法是分层架构，一般是Web, App和DB，当然这从根本上讲并没有区分应用的功能只是逻辑上体现了合理性，事实上所有功能的业务逻辑还是在App这一层；现在广为推崇的微服务架构从本质上消除了功能耦合，通过API调用使新应用搭建可以如同拼装乐高积木般仅需开发缺少的功能模块。
在基础架构方面，传统的线下数据中心由于容量有限和建设成本的问题，在一段时间内被租赁机房加外包运维服务所取代，但从本质上讲这依然是换汤不换药的转变，毕竟线下机房的容量是有限的。随着云服务商的崛起，全球化的数据中心网络很好地解决了资源延展性的问题，阿里双11和亚马逊黑五也不会在同一天发生，资源在任何一个时刻都能去往应用最需要的地方。
最后是应用的部署方式，刚才说了资源可以跑去应用最需要的地方，同样应用也需要方便迁移或快速扩展。早期的一台物理机一个应用是显然满足不了的，除非有非常便捷的物流公司:-)虚拟化技术解决了对硬件环境的依赖，但在软件工程领域没有解决对操作系统kernel的依赖，直到容器的横空出世，系统软件才不再约束应用的发展，开发团队不再需要单独开发Linux版本和Windows版本，只需关注应用本身的运行时。
下面咱们分别展开说说。
IT界对于Devops的定义有很多，本座比较认同的是，“用简单、快速可控的方式维护好应用的‘从生到死’”。任何一个应用的生命周期都应由标准化的流程所控制，这个流程应尽量减少人工干预的操作，最后每一次更新都应是对原有应用的能力提升。从实践角度，Devops主要有以下八个特点：
一切皆代码：应用是代码，基础架构同样是代码（Infrastructure as Code，IaC），这样才能连同环境一起无差别地交付运维；
持续集成/交付：CI/CD是Devops中最常被提及的流程，这个可以在本作之前的关于CI/CD的文章了解详情
流程自动化：除了在任何一个环境（临时环境、开发环境、UAT环境等等）内的自动集成与自动部署外，跨环境的提交也应减少人工干预；
交付管道：自动化的、安全的跨环境交付管道
持续监控：我们在谈论CI/CD的时候往往会忽略持续运维，而运维过程对于Backlog的监控恰是下阶段服务改进的方向，不可不察；
快速响应：快速获取市场响应；
重构与修复抉择：在全面收集市场反馈和Backlog之后，我们需对应用的已有功能做出重构和修复的抉择。
版本标记：应用需要标注版本编号以记录每一次的更新日志；
说到微服务，为了让大家有一个直观的认识，我们拿一个订座系统来说吧，一般分为用户注册、支付和订单查询这几个模块，如果作为一个单体应用，他会有以下几个特点：在一个流程中串联所有功能；系统变更将非常麻烦；实例拓展耗资巨大；测试周期长以及延展性差。当然好处就是技术栈单一，人员容易招募。当然相对于人力成本，市场反应一定是业务更关心的事情。
而微服务的架构实现了服务间的独立自治，每个服务可以用最适合的技术栈或产品。由于功能间解耦，整套架构中引入新功能或者对现有功能模块做变更就非常便捷，每个模块也可以根据业务量需求独立扩展，测试周期加快并且具有很好的可用性和延展性。
本座曾看过一副有意思的漫画，说CIO把“数据中心”的牌子换成“私有云中心”就跟领导汇报说企业已经完成了云建设。其实我们在讲云建设、云迁移以及云原生架构的时候，更多谈的是容器云的建设，因为一般数据中心内的物理机或虚拟机是没有办法跨平台跨云迁移的，甚至在一个服务体系下没法从测试环境搬到生产环境。因此我们说“可搬运”的应用才更符合云的特质，因此我们需要容器（Container，英文意思上是集装箱，说明自诞生之初就具备“可搬运”属性）。
如果说微服务是对应用的横向功能切片，那容器就是对每个功能的纵向依赖性切片，不同于虚拟机应用，不论是KVM，HyperV还是VMWare，底层只是将硬件资源虚拟化，构建应用的步骤还是从搭建操作系统开始；而容器是将应用代码和操作系统的内核完全剥离，通过容器守护进程直接运行应用及应用的必要依赖组件。这样的容器化应用就可以无缝地在不同的容器宿主上迁移了。
容器具备很强的横向扩展能力，可以快速地根据实际压力拓展出成百上千个应用实例。并且这些实例可以无视底层环境跨数据中心跨公有云地扩展，因此在理论上可以应对极端的访问压力，真正做到一次开发，无限部署的云转移。
说到容器平台，不得不提Kubernetes，其实在四年前容器平台还是Mesos，K8S，Swarm三方割据的场面，而如今几乎是K8S独大了。其实主要还是得益于K8S的生态建设，有源源不断的云厂商、虚拟化厂商、系统厂商为其丰富容器应用和平台功能，使其在之后的几年内一骑绝尘。
这些厂商中不得不提的就是Redhat，他是最早押宝Kubernetes的，在Kubernetes开源社区贡献排名第二（第一是谷歌），其中包括了成百上千个缺陷及性能问题的修复、超过200多个集成软件，并打造了今天基于Kubernetes的容器云生态Openshift，由此企业用户不用再担心使用开源产品的稳定性、安全性及支持问题了。
显然Openshift给企业带来了开发效率的提升，那运维呢？Openshift上有很多自动化运维工具，如Terraform，Ansible，同时基于Openshift搭建的企业私有云可以管理多租户并按租户计费，同时可支持云端升级及即插即用的架构模式。
在上图中大家也看到了Openshift的底座支持裸金属、私有云以及各种公有云环境，对于国际主流云厂商（如Google，Azure，AWS，IBM）Openshift有一整套的产品体系使用户在这些公有云上完成企业容器云的搭建，运维模式可以选择云服务商或者自己运维。同时Openshift也有数据中心版适合企业用自己的资源搭建容器云。目前全球已有超过2100家企业成为Openshift的直接用户。
Redhat开创了Openstack和Openshift，目前来讲国内的很多云厂商也是基于这套体系搭建的公有云，如华为云，天翼云，金山云等，华为还是亚洲唯一的OpenStack社区白金会员。
长按，识别二维码，加关注
