微服务是否是终点站
该定义总结了微服务当下最流行的常见说法。再者，若是处理得当的话，微服务真的能够作到它们想要作到的 全部美好的事情 。从架构和程序的角度来讲，相比于更加单体化的方案而言，微服务在应用开发方面拥有许多有意义的优点。看看那些像Amazon和Netflix这样成功的企业，发现本身有这样的想法也就很合情合理了，"微服务！必定是它！"html
不过，我并非很喜欢这个松散的定义，由于它彻底忽略了构建微服务背后的一个关键动机： 让团队可以更快地交付功能到生产环境，而且摩擦变得更少。 微服务只有在正确的软件文化到位时才能发挥最大效果。一个关注微服务的组织也应该像重视开发和运维生产力那样接受并实现一些文化方面的重大转变。git
从总体层面考虑，这里有三个严峻的事实是那些正在调研或实现微服务的组织须要考虑的。并且，不出所料，每一个事实都更多关注在人和文化方面，赛过工具或者架构。编程
- 除非你是一家以持续增加的名义有动力去吸引和留住优秀人才的公司，不然你没法作好微服务。 你的目标不必定像 Facebook 大约在2009年那样地高速成长，可是你确实须要一个真正的决心，持续发展业务，而且可以欣赏优秀的软件人才，让他们有用武之地；
- 在一个走下坡路的背景下，员工还挣扎在生存线的话，你将没法作好微服务。 生存主义是一种可以扼杀微服务本应会带来的灵活性和风险性的环境，并且它会积极地劝退那些最有才华的员工。天才的软件构建者们是一群渴望尝试和探索新的最佳实践的人，而不是去学习什么该作，什么不应作；
- 若是你打算将全部最优秀的开发人员"晋升"到管理岗，那么你（也许）没法作好微服务 。微服务架构是由一些超级增加公司设计和推广流行的，这些企业优先考虑的是工程化，这就意味着微服务须要的是有才华的而且熟练这块技能的人才致力于这方面的工做。若是你为他们提供的职业发展机会是技术通道，而非管理通道，他们之中的一些人将能够和你的业务一块儿快速发展。
在尝试推广微服务时，接受并解决与文化衰退和增加缓慢相关的问题的公司将会好不少。这就是缘由所在。安全
在一些高速增加的企业里，人就是流程
微服务的神话里有一个源自于Amazon和Netflix的传奇故事。这是世界上最有价值而且在当时也是发展最快的两家公司，他们在采用新架构和基础架构模型方面的领导地位有助于向世界传授构建云原生应用程序的意义所在。可是，当咱们如今回过头来考虑Amazon和Netflix为何在微服务上下这么大赌注背后的动机时，咱们开始看到一副更详细的画面，讲述了他们为什么可以成功转变。一个很大而未被充分认识的因素即是熟练的开发人员在松耦合和我的自治的环境里可以更快成长。架构
集中式架构将不可避免地发出一些我称之为文化超速罚单的东西 - 在一个单体软件项目中试图按时交付功能时所产生的缺陷的结果。有才华的开发人员会试图经过创新和向管理层提出想法来避免这些问题，这有助于保护他们的自由，自主性和研发速度。Amazon和Netflix的微服务并非商业计划的一部分。它们是软件工程师和运维人员最终找到的一种减小浪费的方式，而且帮助他们以一种更快，更安全的开发速度构建和运维应用程序 - 没有超速罚单。运维
对于许多人而言，在一家高速发展的企业里一个很能引发共鸣的反例就是Initech，这是一部另类经典电影 Office Space 中的虚构雇主。主角就是软件开发人员，他们因缺少自由和自主而受到扼杀。他们受到焦虑和粗心的困扰，由于他们处在生存模式 - 试图在一家重视流程甚于人的企业里继续努力工做（或至少要玩的开心）。一些管理顾问不断涌入而且要求他们削减成本，这让公司的员工感到恐慌，他们以为有必要为本身的存在辩护。在现实世界中，就像在电影里那样，这种状况下员工和雇主一般都不会满意。ide
不少时候，今天的软件开发领域一样分红两路派系：高增加的科技公司和其余全部人。 微服务的普遍采用有可能帮助填补这一差距，可是前提是采用微服务的公司是出自合理的原因作出的改变。改善软件架构的最佳途径是首先解决公司的文化问题 - 特别是当这种文化会致使微服务发展停滞，而让员工陷入生存模式的一些历史遗留流程还会成为拦路虎。函数
每一个人都想要自由，效率，以及可控
不过，微服务每每停留在想的阶段，部分缘由是一些历史遗留的软件实践可能会致使止步不前的文化氛围。开发人员一直但愿的是无需和运维沟通，能够更自由地自动化基础架构，而运维人员则但愿的是更自由地自动化基础架构的管理 - 主要是为了防止开发人员不断变动致使业务中断。这些需求源自于管理单体应用程序的共享基础架构时固有存在的困难。微服务
对这种架构的每次变动都是对系统稳定性的一次考验。每道护栏都是变动的障碍。在这种软件文化中，得罪人是一种常态，一我的的粗枝大叶可能致使其余人在周末时间帮忙收拾残局。所以，他们对于像微服务这样的事物的渴望始终存在。得益于云原生和开源工具的出现，业内不断涌现出性价比更高，更自动化的基础设施，让微服务的部署变得更加容易（若是你想要一些关于如何工做在上云以前的革命故事，我有不少能够分享的），可是，改变文化的困难和费用仍然是主要障碍。工具
然而，只是能够开始在Kubernetes集群上启动微服务并不意味着你应该急于立马这样作。许多公司没有意识到的是，花在部署上的时间和精力(多是失败的)，更好是用于首先检查通往生产的路径，而且能够准备将部署流水线作成一个自动化的可重复实践。若是须要几周时间才能把第一行代码部署到生产环境中，那么你应该考虑升级工具，应用一些像持续交付这样的实践。
在将新的复杂度引入架构前，你的出发点应当是为团队提供更轻松、更高效的生活。
图片来源: www.slideshare.net/adr ... erl…
试想一下从一个百万行代码的单体应用到500个微服务的转变。这有点像洛杉矶国际机场（LAX）里每一个广场只有一个电源插座，成千上万的乘客在大厅里走动，但愿找到它并使用它。这样作的话，洛杉矶国际机场也许很快就须要弄清楚该如何从1个出口到其余另外的至少10,000个出口。要解决这个问题，一种方案是购买大量的延长线而后增长插座的数量。这样作的话最终是让电线四处缠绕在走廊里，就像蛇盘绕在飞机上同样，全部都是出自一个插口。没有机场能够作到这一点，可是咱们在软件领域每每就是这么作的。
或者它也能够选择作正确的事情：打碎一些墙壁而后把系统重作一下，支持更多的墙壁插座。作正确的事情须要勇气，并且须要自顶向下思考，“若是被绊倒或者争夺单一代码仓库的控制权的人数会所以减小的话，那么打碎一些墙壁是值得的。”
新架构须要新文化
不管是经过微服务，函数仍是其余任何形式，软件架构的变革均需做出某种类型的转变，而这种转变源自一个扎根于坚持一种健康文化的有机过程。在这样的环境下，微服务实际上能够作到事半功倍的效果。现在，开发和运维均可以找到本身的角色 - 这意味着更快乐，更高效的团队，最终实现更高效的数字业务。
那么要怎么实现呢？如下是一些能够上手推进软件文化改变的事项：
1.鼓励员工，激励他们采用新的解决方案而且最大限度地下降犯错风险来解决问题。
2.使用黑客马拉松或其余类型的自由思考练习来加强创造力。
3.经过试验结对编程等实践来改善协做。
4.经过在办公室里公开采购一些内部工具和开办会议来创建社区和参与感。
5.经过举办技术讲座向员工们表达你对他们创造力的重视，他们能够分享衍生项目或其余技术兴趣。
6.经过启动绿地项目试验新的技术和软件实践。
7.经过聘请更多元化的团队，寻找新的想法和观点。
若是你常常作上述这些事情，那么你就像是一家为微服务作好准备的企业 - 由于你正扮演一家想要吸引并留住所需的人才来保持增加的企业。
重要的是要记住微服务不是终点站。 对于寻求在软件主导的世界中生存的数字业务而言，微服务只是星辰大海的一部分。 升级您的文化与升级您的工具同样重要 。