在DevOps的实践中，从设计上考虑，应该注意什么？
在过去的十年内，由云计算推动了数据中心的一个大规模的转型。在早期，很多组织在基础框架的横向扩展方面苦于没有好的架构苦苦挣扎，拿到机器硬件之后，安装和配置往往需要数月，而数据中心一旦创建之后，更新和维护变成了更大的一个痛点，运维团队不得不一台一台机器进行补丁的安装和更新。 Amazon和Ali云等诸多云服务提供商使得按需获得用于计算的虚拟机器的服务非常容易。几乎当前所有的私有云或者公有云都支持使用API方式进行快速和便捷地配置和管理，传统手工或者不能标准化大规模处理的操作瞬间变得无比轻松，效率和速度大幅提升。 除了原生的云服务的工具，诸如Ansible/Chef/Puppet等工具也使得Infrastructure as code（IaC）的落地成为了现实。而最终则是整个数据中心可以以代码的形式存在，进行版本的管理，并能够进行自动的部署和变更管理。 企业由于几方面的因素，短时间内私有云和公有云将会同时存在，成为一段时间内的趋势。
因素详细说明安全一部分安全数据由于企业自身对于安全考量或者法律合规性的要求等原因，不能放到公有云上，同时目前的云服务提供商的Vendor Lock的可能性较大，很多企业为了避免核心功能免于受制于提供商，对核心业务使用企业私有云进行处理成本为了能够使旧有的硬件设施继续发挥更大的作用，使用现有的硬件组成私有云，更是能够提高ROI，节省成本，直接丢弃现有硬件显得不太现实旧系统旧的系统运行在企业内部原本的硬件环境中，即使统一使用采购的外部云服务，也会存在一个旧系统Porting的过渡过程，根据实际情况，这个过渡的时期往往会持续一段时间这是一个软件主宰一切的时代，应用软件对每个企业都变得无比重要。诸如Amazon/Netflix/Uber这样的公司颠覆了传统的业务模型，在很大程度上是依靠其强大的软硬件功能。虽然说不是每家公司都能转型成为Amazon/Netflix，但是随着技术的进步，这些公司目前所能体现的特性很可能在不久的将来成为大部分公司应用架构的标配，比如
24x7x365的高可用性，无宕机支持大规模高并发的并行工作流能够按需进行横向扩展或者横向规模缩小以适应实际需求复杂的基础架构，包括负载均衡方式，防火墙和安全机制快速更新和持续反馈降低风险并同时促进和推动创新更好的特性支持开发和运维团队以避免发布问题能够更加快速和稳定地进行服务的开发以及交付微服务的方式跟传统的SOA非常的类似，抛开概念之争，让我们重新思考一下传统企业那种超重的单一应用会有那些问题：经年累月之后，这种本来就很庞大的系统最终会形成一个谁也不敢轻易去动的多米诺骨牌： 修改成本巨大，扩展困难。 而是用微服务，通过尽可能对功能进行简单化/小型化，划定明确的功能边界，降低和其他模块的耦合度，通过规范化的轻量的RestAPI进行交互，服务的部署独立可置换使得对整体的影响较小，即使出问题也能限定影响范围，这种方式其实在传统的SOA方式的架构设计中我们也会经常考虑，只是在DevOps运动推行之前，部署的独立化这些要素没有覆盖，另外与微服务的微相比，显得更大更重一些而已，比如很多微服务中使用的RestAPI，以前更多使用SOAP等。目前也有很多开源的框架可以使得微服务落地时更加快捷，比如使用Spring Cloud提供的很多开箱即用的功能，服务注册，API网关，负载均衡，配置中心等等拿来即用，而我们只需要专注于业务功能的实现即可，而这些大大提高了效率。 微服务带来的有清晰的边界和可控的影响范围，也有很多其他的原本没有的问题。一个项目中推行微服务的朋友说他们推行了微服务，最大的好处就是以前部署一个包一次结束的事情现在需要做二十次。虽然是句玩笑，但是也说明了一个事实。微服务在设计上将业务功能解耦拆解成了可独立部署小型单元，但是随着服务的增多，这些在管理上会带来很多影响。没有DevOps实践支撑的微服务实践简直是不可想象的，这种解耦型的方式也将会成为DevOps实践中的流行架构之一。
容器使得交付变得更加透明方便和快捷，同时可以利用容器来实现DevOps实践中倡导的各个层级的环境一致性：开发环境/测试环境/生产环境的一致性。
项目详细说明开发环境一致性使用容器可以保证一致性的开发环境，确保所有成员在一致性的环境中进行开发，避免因各种版本不合导致的Rework。测试环境一致性使用容器可以一致性的测试环境,避免因环境的问题出现的非缺陷性确认和对应所需时间以及缺陷的延后出现的可能性。生产环境一致性使用容器可以确保准生产环境能够得到尽可能类似生产环境的测试要素，同时避免因软硬件变动导致的各种问题。容器相关已经聚集了成熟的各个层级的生态链，有丰富多样的镜像，也有各个层级的容器管理工具，有偏IAAS层的，也有以编排为中心的PaaS层的诸如Kubernetes之类的工具。
DevOps不仅仅是CI/CD和工具链，要想很好的推动DevOps实践的落地，系统的架构也必须要考虑，这篇文章讨论了在当前形势之下基础框架以及良好系统需要具有的特性，以及微服务和容器化等几个在架构上需要考虑的趋势和方向。但是一切还没有定论，比如微服务，能够进行解耦，但是耦合不会消失，只会以另外一种形式存在，当出现上千个设计不是很合理的微服务构成的整体框架，又希望了解整体的构成时，这种架构会不会成为另外一种噩梦还很难断言，但是技术总是在不停的发展的，在绝望中寻找希望，永不放弃，总有一天我们会得到拯救。
淼叔 认证博客专家 神经网络 TensorFlow NLP 资深架构师，PMP、OCP、CSM、HPE University讲师，EXIN DevOps Professional与DevOps Master认证讲师，曾担任HPE GD China DevOps & Agile Leader，帮助企业级客户提供DevOps咨询培训以及实施指导。熟悉通信和金融领域，有超过十年金融外汇行业的架构设计、开发、维护经验，在十几年的IT从业生涯中拥有了软件开发设计领域接近全生命周期的经验和知识积累，著有企业级DevOps技术与工具实战。