软件开发生产线 CodeArts-朴素的DevOps价值观:业务、架构与技术
下载软件开发生产线 CodeArts用户手册完整版
业务、架构与技术
下面，让我们先来看看业务（Business）、架构（Architecture）与技术（Technology）这个维度：
- Business matters...Architecture doesn't.
架构是服务于业务的，关于初创公司，新型的业务，是否需要采纳微服务，回答是视情况而定的，但通常建议从单体应用开始。
微服务的价值与挑战一样明显。
初创公司，业务方向还在不断探索，服务的边界是模糊的，即使对微服务的技术储备足够，也不建议此时就搞微服务架构，用最简单直接的方法搞定快速变化的业务诉求。
用贷款买房来类比架构投入，自己出的首付款就像是前期在架构上的投入，贷款就好比是减少一定的架构投入，所需承担的技术债务：
- 贷款买房，预期的是未来的房产的增值，贷款的利息相较起来是可以接受的。
- 一味追求全款买房，就会错过买房的最好时间窗口。
- 不能贷款过多，否则无法承担月供。
架构可以一开始简单些，原始一些，但基本的质量和NFR还是需要满足的；而一旦找对业务方向，又需要快速展开，所以架构在初期具备一定的扩展能力还是需要的。
- 要定期清理债务，房贷车贷过多，即使是有力偿还，生活质量也会下降，脱离了原始购房改善生活质量的初衷。
这其实是一个经济杠杆，用短期或长期的负债，来换取时间成本和机会成本。所以做架构也好，做DevOps也好，需要有经济的头脑。SAFe第一条原则Take an economic view，也有这层含义。这是一个平衡，一场与时间的赛跑，但总而言之，业务诉求高于一切。
以上所说的都是因为业务战略需要，主动有意识的承担技术债务。如果是无意识的负债，那个叫做奢侈浪费，原本就应该消除。
- Architecture matters...Technology doesn't.
《圣经·旧约·创世记》第11章记载，当时人类语言相通，同心协力，联合起来兴建希望能通往天堂的高塔，即巴别塔。“来吧，我们要建造一座城，和一座塔，塔顶通天，为要传扬我们的名，免得我们分散在全地上”。此举惊动了上帝，为了阻止人类的计划，于是他悄悄地离开天国来到人间，改变并区别开了人类的语言，使他们因为语言不通而分散在各处，那座塔于是半途而废了。
架构如此重要，所以一旦业务相对清晰一些，就要根据业务需要，考虑逐渐切换到微服务架构，才不至于堆积太多技术债务，对于可扩展性、可规模化、可部署性等也都至关重要。
优雅的良好的架构更加重要，不要让微服务成为另一座巴别塔。理论上微服务可以最大化利用各种语言的优势，但如果没有好的服务切分与架构设计，微服务只会变成更大的灾难，只会是碎片化而不是去中心化。微服务的目的是更灵活的协同，如果服务之间缺少沟通，就背离了微服务设计的初衷。
Google内部有开发三大语言，分别是官方编译语言C/C++、官方脚本语言Python、和官方UI语言Java。坚持三大语言意味着内部沟通的顺畅，没有使用最新的技术和语言，并不影响，反而有助于Google快速成为世界领先的公司。
团队效率高于个人效率，统一技术栈带来的收益，往往大于使用最新技术栈带来额外的维护和沟通成本。Etsy在2010年，决定大量减少生产环境中的技术，统一标准化到LAMP栈。“与其说这是一个技术决策，不如说是一个哲学决策”。这让所有人，包括开发和运维，都能理解整个技术栈。另一个例子，Etsy在2010年引入MongoDB，结果是“无模式数据库的所有优势都被它们引发的运维问题抵消了”，最终Etsy还是选择放弃了MongoDB，迁移到MySQL。
DevOps也并非只有Web应用、SaaS或是开放平台才适用，我们听到太多传统银行的转型案例，主机开发的案例，技术并非DevOps的绝对先决条件，虽然开放平台可供选择的工具会多一些，后面我们还会就工具进行讨论。
技术圈总是喜欢追逐潮流，总是存在各种鄙视链，就像曾经出现的PHP与其他各种语言的互喷群。还有类似于容器编排技术，大家一窝蜂的从Swarm、Mesos向K8s迁移。但对于企业而言技术永远不是第一位的，最新的未必是最合适的，永远追逐最新的技术，往往丧失了自我的思考和技术的积累。
