关于此书
作者：Viktor Farcic 目前是CloudBees的资深顾问，CloudBees是专业提供Jenkins企业版产品和服务的公司。他是一名资深的程序员，目前最喜欢的语言是Scala和JavaScript。他之前还写过另外一本书《Test-Driven Java Development》
本书的封面如下，够黑暗，够简洁。
本书的实体书非常重，很大很厚，内容则是更加的黑暗和强大。在美国亚马逊上的搜索排名比较靠前，搜DevOps，它出现在第四位。它是今年2月份在亚马逊上架。本书的评论不多只有8条，可是大家不约而同的都给出了5星的评价；可见老外盖楼的水平也都很专业。
篇章结构
我们先看下本书每一章的标题，随后我会按章节写出我的读书笔记。
- DevOps概念
- 实践的突破：持续交付，微服务和容器
- 系统架构
- 用Vagrant和Docker配置开发环境
- 实施部署流水线：初始化阶段
- Dcoker世界里的配置管理
- 实施部署流水线：中间阶段
- 服务发现：分布式服务的关键
- 代理服务
- 实施部署流水线：后期阶段
- 自动化实施部署流水线
- 持续集成/持续和部署工具
- 蓝绿部署
- 群集和服务扩展
- 自愈系统
- 集中化的日志和监控
本书并不长，一共就396页，我曾经在火车上一下午看了50页；由于信息量大，逻辑严密，确实有脑裂的感觉。本系列文章会按照我的阅读进度，来持续为大家通过读书笔记的方式，分享本书的干货和营养。当然，您最后去购买中文版实体书肯定是最好的。我的阅读没法代替您自己的理解力和判断力。读书笔记的作用对我来说是回顾和记录为主，其中对书籍评论部分请自行决定是否吸收。
第一章 DevOps概念
作者通过对两类项目经历的对比来描述了微服务架构的潜在价值和优势。这两种项目类型分别是：1）新生的从无到有开发的项目；2）需要和已有系统对接的，与老旧系统有关的延伸的，用瀑布式开发模式和运维的项目。
前者的优势：可以使用最新的技术，在系统的不同服务选择最佳的语言和开发堆栈。一个错误的设计或者模块可以推倒重来的代价按周计算。
后者的痛点：必须考虑和已有系统的对接，无法尝试新生技术和事物，技术创新被完全压制；系统设计和发布的失误导致的代价是巨大的。
传统的软件开发方式下，系统集成测试被放在最后阶段。把不同团队经过数月开发的成果集成在一起的时候，才是开发人员的噩梦的开始。各种返工、需求重定义像灾难一样不可避免地频繁发生。从这些血淋漓的经验教训中作者提出了CI/CD的必要性和价值。CI/CD往往被认为是Ops团队的任务，而不关Dev人员什么事。但是对于Dev人员来说，如果还没有入手和使用CI工具和自动化测试框架，这些欠下的技术债早晚还是要还的。你有木有半夜被Ops从床上捉起来去生产系统里面排bug的经历？有木有留下心理阴影？
CI/CD的操作流程和实践其实是要把所有可能的坑都提前踩一遍，建立以天、小时、甚至分钟的快速反馈机制。它需要影响和关联到系统开发和交付的所有环节中，从架构设计到测试，研发和运维人员每天都需要关注的是管理和业务需求是否满足。
因此：整体思维，系统性思维重要。
谈谈架构，作者做了一个形象的比喻：由很大的团队多年开发出的单体应用，不加充分测试，紧耦合，技术选择陈旧而保守。去给这样的系统做瘦身和优化，就像是企图把一个八十岁的老太太再变成为小姑凉一样的困难。所有的优化改造和升级都是无力回天的。作者对微服务架构的定义是：把系统构造成很多小的独立的服务，它们能被多个小团队维护，任何程序猿对每个服务的代码都能秒懂。微服务可以被任意改变开发框架、语言、数据库；而不会影响到其它系统。可以被独立的部署。我想很多人都在探求微服务应该切分多大和多小；我想微服务的服务并不关乎大小，而在乎其功能切分的合理性，微服务的总数与维护团队人数的匹配。
作者提出了程序猿所使用的共享库是紧耦合的陷阱，会拖慢系统实施的速度。标准化服务接口也是创新的隐形杀手。这些单体应用经常会出的错，微服务也可能会有，而且其后果可能是所有错误相乘的影响度。
从这里我们可以看出微服务的特点、切分、构建原则和可能的问题。只有清晰认识和定位它，才能保障在实践过程中能够收获它的优势和好处。
谈谈部署：服务部署的对象是一堆Jar，WAR，DLL和其它任何程序代码的输出制品。定位那些要部署在旧服务器上，那些在新服务器上困难重重。所有服务器有差异性，生产环境和准生产环境和开发环境有天然的差异性。用虚拟机可以保证一定的一致性，可是对于每一个运行了一段时间的虚拟机，谁也无法回溯它完整的手工系统配置和变更过程。系统理想配置状态和现实状态的差异性是由于时间积累导致的。除非自动化的工具和流程来代替手工的配置操作，才能保证服务部署和更新的成功率。我们很难把每个子服务都部署在不同的VM上，那样做会导致虚拟机的泛滥，VM的管理同样是问题。最后总结到：immutable server is good idea. 可以理解为：不可变服务/服务器。而我们已有的工具是无法支持它的部署的。
谈谈编排：传统的服务配置/编排工具如Puppet和Chef，如果是手工开发、维护和运作这些脚本，而没有系统性思考的话，基本上也是一个悲剧的噩梦的结果。这些编排工具也定性为：比没啥都没有要好的东东。
部署流水线的正途究竟在哪？ 本书的标题是工具集，因此作者在本章最后隆重推出了梦幻工具集组合。
Ansible：替代Puppe和Chef之类的工具。
Docker：替代缓慢的虚拟机，它是推荐的创建不可变（immutable）部署的工具。
服务发现：使用Swarm，Kubernets和Mesos/DCOS都可以。
作者提出微服务正在已缓慢的速度被应用于构架大型的系统，还需要涉及的工具包括：CoreOS、etcd，Consul，Fleet，Mesos，Rocket和其它的。
这一章基本上以作者对传统应用系统开发运维缺陷和弱点的吐槽，作者槽点总结的字字珠玑，没有废话，我也是非常认同。其中对微服务、DevOps概念和CI/CD的定位也非常到位。并且对应到了软件开发、架构设计和系统交付的全生命周期场景中。此作者完全是实践型，结尾亮出了十八班兵器；指出好戏在后面，把所有理论都展示出来，让读者通过跑通本书的测试代码才是真本领。
结尾
本书第一章结尾作者引用了黑客帝国里Morpheus的一句话，让我们共勉之。
This is your last chance. After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes.
写完此笔记之后，我的感觉是本书写的都是干货，它帮我梳理了思路，再次回顾了旧社会的苦难；而我们站在现在的时间点上看，我只想说：亲该吃药了，记得吃下那颗红色的药丸。
