大数据实用DevOps/总结

本书的动机在于解决当今组织在开发大数据系统时面临的问题。如今，大多数组织面临着巨大的市场压力，其支持的 ICT 部门正在努力加速应用程序和服务的交付，同时保持生产和运营稳定。一方面，ICT 运营人员缺乏对应用程序内部结构的了解，包括系统架构和架构组件背后的设计决策。另一方面，开发团队并不了解运营细节，包括基础设施及其局限性和优势。对于大数据系统来说，这些问题甚至会被放大。对于这些系统，近年来，对使用数据密集型技术的兴趣迅速增长，例如 Hadoop/MapReduce、NoSQL 和流处理。这些技术在许多应用领域中都很重要，从预测分析到环境监测，再到电子政务和智慧城市。但是，此类应用程序的上市时间和拥有成本相当高。

本书解释了 DevOps 实践如何解决开发和运维之间常见的隔离问题。我们说明了 DICE 方法，这是一种用于大数据系统软件工程的实用方法，利用设计工件（如 UML 和 TOSCA 模型）可以发挥核心作用，在组织内组织架构和需求知识，并在 DevOps 工具链的设计时和运行时工具之间共享。与商业上提供的多数 DevOps 工具相反，这些工具将重点缩小到持续集成和持续交付，因此 DICE 实现了一种更雄心勃勃的 DevOps 形式，其中 Dev 和 Ops 的统一不限于交付阶段，而是应用程序开发的整个生命周期，开发人员和运营人员都依赖于模型来执行其活动。通过拥有涵盖整个应用程序生命周期的 DevOps 工具链，包括将生产监控数据反馈给设计师和开发人员，所提出的 DevOps 方法促进了由量化监控数据驱动的应用程序的迭代增强。

我们在定义 DICE 方法过程中学到的经验之一是，不同的参与者对模型应该发挥的作用有截然不同的期望。设计师将模型视为其工作中的核心要素，因此他们会发现使用模型驱动工程工具是自然的。对于大多数运营人员来说，情况并非如此，他们使用更接近操作系统和系统管理思维方式的抽象概念。单独来说，如果模型以文本形式呈现，例如在 TOSCA 编排和拓扑模型的情况下，运营人员往往会很轻松地使用它们。这种明显的矛盾表明，尽管 DICE 之类的 методология 可以完全基于模型，但在幕后，重要的是工具链中不同参与者需要不同程度的模型暴露，以便他们能够轻松地使用他们使用的工具。解决 Dev 和 Ops 之间的这种文化差异实际上是交付健全 DevOps 方法的主要挑战之一。我们相信，本书中提出的 DICE 方法是开发数据密集型应用程序的方法的第一个实例之一，它试图系统地解决这个问题。