Netflix，亚马逊，谷歌，PayPal和Facebook具有更多共同点，而不是它们成为利基市场的绝对庞然大物。 它们都遵循微服务架构以及DevOps。
事实证明，这些数字世界的巨头是建立在微服务的基础之上的。 并且他们使用DevOps指南来确保事情成为应该（或可能需要）的方式。
DevOps原则提出了一个好主意，即软件开发周期中涉及的所有团队都应协调一致并更好地同步。 而且，微服务最终成为实现该想法的更好策略之一。
让我们进一步探讨该主题，并了解微服务架构如何帮助您坚持使用DevOps手册。
1. DevOps中的微服务–较小的团队，更好的沟通
开发，生产和测试团队之间曾经存在巨大的沟通空白。 直到一个团队完成了代码之后，其他团队才开始动手，似乎没人知道故事的另一面。 DevOps的议程是通过适当的沟通来弥合这种差距，并鼓励每个人朝着共同的目标努力。
微服务不需要每个部门都有大量成员的大型团队。 微服务的相对较小的规模导致了较小的组，因此，通信更好。 每个人都认识其他人，也认识团队其他成员所面临的挑战。
当杰夫·贝索斯（Jeff Bezos）提出了“ 两个比萨饼”团队的想法时，这个想法就是取消冗长而乏味的沟通机制。 较小的跨职能团队无需多加留意交流日志，但他们所有人都了解团队其他成员的需求和挑战，情况要好得多。 如果让团队感到高兴的是两个比萨饼，这不是很大的方便吗？ :)
2.使用最适合自己的工作
Netflix是最早实施微服务架构的公司之一。 他们就如何采用它提出了一个很好的模板。 对于微服务的好处，Netflix本身就是一个令人振奋的例子，说明使用微服务可以实现的目标。
DevOps文化强调着眼于最终目的来创建产品。 以瀑布方式，每个过程只是长链中的一个环节，通常与前，后过程有很大关系。 它增加了该过程的看管者的责任，并增加了熵。
Netflix当时的Web工程总监和云架构师Adrian Cockroft在许多会议中详细解释了Netflix实施微服务的整个过程 。 当他描述他们无需过多担心用于构建微服务的编程语言时，您几乎可以感到他的宽容。 他解释说，只要与部署机制配合良好，他们就可以接受。 他们专注于最终产品。
有了微服务架构，团队将能够使用工作所需的最佳资源。 他们可以在考虑最终产品的情况下做出大多数决定，这只会提高软件或服务的质量。
但是，您也不应迷失这种自由。 如果您未采取适当的谨慎措施，使用多种语言会使事情变得越来越复杂。
3.更好的问责制
假设您公司中有数百名开发人员，并且他们全都为单个代码做出了贡献-通常在整体式体系结构中会看到这种情况。 您使代码正式上线，让我们假设它出了点问题。 你现在在做什么？ 头疼的第一集是找出问题所在，然后是责备游戏。
您知道我们正在谈论的那种折磨，您可能已经过了一段时间。 DevOps原则建议消除这种持续的责任感。 您不想花费时间确定这是开发团队还是运营团队的错。 您宁愿将所有精力用于消除问题。
微服务架构在使团队负责方面做得很好。 您不会发现开发人员和测试人员会反复研究该问题，而是会共同努力使产品正常工作。 最后，无论软件是否正常运行，将由他们共同负责。 您将不会费劲，因为您需要使服务正常工作并同时找到问题的中心。
4.自治权还不错
强大的力量带来更大的责任。 而且，微服务架构不会错失事物的“力量”。 毕竟，如果您不让团队像他们期望的那样工作，就责备团队缺陷是不公平的。
微服务为团队提供了大量权限。 他们不必每次都要做出重要决定时都向当局查询。 当他们遇到障碍并使事情正常进行时，团队可以轻松地决定下一步。
当我们谈论DevOps下的跨职能自主团队时，其动机是带入项目所需的所有灵活性。 还有什么比创建垂直行业更好的引入自治的方法。 微服务架构使团队可以在规定的时间和预算内到达目的地的任何方向。 也许您还可以制定一条规则，禁止它们在国外航行。 ：P
5.帮助创建以用户为中心的产品
对康威定律的现代解释是，最终产品最终反映了组织的内部结构。 如果您想提出在各个方面都表现出色的产品，那么它应该反映在创建软件的团队结构中。
微服务体系结构使您可以逆向工程Conway的法律，并从建立可以证明最终用户愿望的团队开始。 招聘DevOps工程师并不一定意味着您遵循其原则。 这比什么都重要。 而且这种文化表明，您需要在考虑最终用户的情况下不断改进流程和产品。
通过允许您组建看似必要的团队和资源，微服务为您提供了一个良好的开端。 然后，您可以根据需要修改它们。 您可以继续进行更改而不影响整个系统的事实也有帮助。 由于微服务相对独立于服务的其他功能，因此引入更改不会有太多困难。 持续改进的周期会一直持续下去，直到您为用户提供满意的产品为止。
6.接受自动化和测试
在DevOps的原则下，大量强调持续改进和使您能做到的一切自动化。 在微服务问世之前，测试通常是在艰苦的软件开发周期之后进行的。 就像单片架构中该过程的其他步骤一样，它过去要花费大量时间。
微服务将应用程序堆栈分解为较小且相对独立的服务。 通常，这种较小的服务只能处理一项功能。 因此，单元测试最终变得更快，更容易自动化。
由于这些微服务，我们现在一天之内可以看到多个微版本。 过去要花几个月的时间现在要花几周，而过去要花几个小时的时间只需要几秒钟。 微服务的更轻松测试和自动化与它有很大关系。 这种增加的测试和发布频率的甜味副产品是更低的成本。
DevOps是一个好主意，几乎对每个人来说都是正确的。 但是当涉及到实现时，人们经常发现自己处在棘手的情况下。 微服务架构使坚持DevOps原理变得容易得多。
DevOps和微服务的一些重叠领域包括更好的通信，更多的自动化和更好的问责制。 对于DevOps的其他优点（例如专注于最终产品和不断改进），您可以放心，微服务是推动您朝着这个方向发展的理想催化剂。
翻译自: https://www.javacodegeeks.com/6-reasons-you-should-imply-microservices-in-devops.html