微服务架构在Netflix的应用 系列博文

[wanghaisheng]

英文版： 第一部分：http://nginx.com/blog/time-to-move-to-a-four-tier-application-architecture/ 中文版：第一部分：是时候转移到四层架构上来了/

英文版： 第二部分：微服务架构在Netflix的应用：架构设计的经验教训 中文版：第二部分：微服务架构在Netflix的应用：架构设计的经验教训

英文版： 第三部分：Adopting Microservices at Netflix: Lessons for Team and Process Design 中文版： [第三部分：微服务架构在Netflix的应用：团队和流程设计相关的经验教训]()

[wanghaisheng]

英文原文：移动应用所需要的四层 The Four-Tier Engagement Platform

Michael Facemire, John McCarthy和作者最近向整个软件技术行业发起了倡议：老式的web不是为移动APP和网站而设计的，也不能处理互联式产品的实时需求。是时候提出一种新架构了。

大致总结如下:

移动互联网把传统的web架构推到了悬崖的边缘。为传统PC的浏览器而设计的三层架构不够灵活，不能很好地扩展，也不能提供良好的移动端的用户体验，满足互联式产品的新兴需求。移动互联网的volatility and velocity of change需要的是一种分布式的四层架构，我们称之为“engagement platform”。 这个平台能够将技术功能分成4部分：客户端、分发端、集成聚合端、和服务端。

移动互联网APP的新需求需要将CDN、应用服务器供应商、移动端中间件供应商、PAAS供应商、各种初创公司和其他公司围绕着这四层架构整合起来。 CIO需要立即规划从三层架构到四层架构的迁移工作。

是时候扔掉三层架构，即表现层、应用层和数据层，转向能够满足新需求的四层架构模型：

“engagement platform”支持分布式的四层架构，能够提供优质的用户体验、优异的性能，以及与任何设备之间的模块化集成。

Figure 1 The Four-Tier Engagement Platform Makes Delivery Its Own Tier

四层架构的处理流程如下:

• 客户端层负责不同设备的唯一性的确定。 这一展现层将每个app以及设备(桌面端、移动端，浏览器或原生APP)的特殊功能与后台应用程序的服务隔离起来。这个边界使得开发人员可以将后台服务的开发与消费它们的app独立开来，比如航班状态和入港通知等等。确定明确的边界提高了开发人员的效率，无需顾及繁重的维护工作，一个良好的网络环境也是很重要的。
• 分发层处理中间的和最后一英里的问题。通过客户端层的信息决定交付特定场景下具体内容的最佳方式。通过over-the-wire的内容转换—这里与聚合层不同，聚合层使用的基于协议的转换，利用 edge-of-network cache 功能来增加动态数据， 如Akamar等提供的CDN、如Instart Logic的分发优化方案、如Riverbed Stingray的应用分发控制和on-premises in-memory database caches一起完成这方面的任务
• 聚合层负责内部和外部服务的集成和数据的转换。这样的API层有两方面的角色，不同APP请求和服务 的发现和客户端请求与后台服务的双向转换。这样能够使得底层数据的组装和服务更加简洁，能够提供相对实时的数据格式的转换。服务组合外加上商务智能、分析、基于角色的访问等更加动态。
• 服务层包括了内部外部提供数据和功能。通过一系列连贯的可部署的服务来动态组装服务和业务流程。 该层负责为上述三层提供数据，不关心数据具体如何使用。其他几层可以部署在防火墙内也可以部署在防火墙外，或者二种方式相结合。这样不论是APP使用还是生态系统中其他系统使用，在服务的动态组合和访问上就提供了相当的灵活性

未来的展望

问: 如果未来是engagement platform的天下，如何实现呢？

答: 颠覆现在的软件行业的核心架构。IBM, Microsoft, Oracle, and Akamai一直在推三层架构，现在将被 Netflix, Kinvey, and Salesforce.com提出的四层架构所替代。

是时候供应商、投资人员、架构师和开发人员对如何来构建和使用engagement platform展开讨论了。

engagement platform”支持分布式的四层架构，能够提供优质的用户体验、优异的性能，以及与任何设备之间的模块化集成，并且能够推动这些颠覆的演化:

• 公司将依赖于供应商的生态系统来deliver engagement. 你无须购买这个engagement platform平台。而且这个engagement platform平台也不是全部受你直接控制。相反，你以松耦合的方式组装各种 engagement 功能，而且能够按需扩展，同时能够保持灵活性，也能够解决持续交付的问题。
• HTTP traffic on Nginx will surpass the traffic on Apache. If you don't know what those things are, don't worry about it. If you don't but think you should, then see the last chart here and learn about it here and here.
• IBM, Oracle, Microsoft, SAP, and Salesforce.com will rethink their middleware products and architectures. Adding mobile app lipstick on an application server won't solve the delivery challenge by itself. These companies will slowly overcome their reluctance and begin to operate in a four-tier, ecosystem-dependent platform. But it will take five years for that to happen. Microsoft Azure is the farthest along, but still tentative in its strategy and execution.
• The content delivery network industry will accumulate content and performance optimization services. Akamai, Limelight, and Amazon CloudFront have done good work for the Web. But new approaches from Instart Logic and rumblings from Akamai point to the delivery-tier future.
• Platform-as-a-service providers like Amazon, Google, IBM, Microsoft, and Salesforce will grow many new platform services. For example, services in the aggregation tier loosely coupled with an intelligent delivery tier will handle notification at scale, including personalized messages, open-message analytics, and device and network customization.

[wanghaisheng]

英文版： 第一部分：time-to-move-to-a-four-tier-application-architecture 中文版：第一部分：是时候转移到四层架构上来了

新年伊始，你也许计划提升你现有的数字化体验或者从头构建新的网站或系统。如果你要做这些都话，首要的你要牢记在心的是”web“不再只是指 ”web browser“。专家这些年一直在提”mobile first approach“来进行系统开发。但今年的移动流量已经增长至接近60%，这已经是不能再拖的了。互联式设备数量的激增，流量从桌面端向移动端的转变，万物互联的潮水意味着项目必须以不同设备上的用户体验为出发点。 过去的专注于单个集成式的包含大多数功能和特性的整体式模型-既往的应用架构开始不适合这个你需要根据特殊设备特殊用户来调整用户体验的年代。此外，你不能通过很多旧的架构模式和行为实现现如今的系统所要求的敏捷性、灵活性和可扩展性的要求。

为了开发和部署能够有效的吸引和留住不同设备上的移动端的APP，你需要有一种崭新的应用设计的思路。本文中将会阐述为何整体式的架构模型不再适用，同时介绍一种新的架构模型，能够帮助你迎接当今web，乃至于未来web的挑战。

为什么软件架构的标准在变化

Monolithic Architecture, Source: Martin Fowler 在传统的 monolithic 架构中，应用程序处于中间那层，也就是说前端是展现层，后端是数据层。应用程序将数据传输给web浏览器，也就是展现层，它能给用户提供向应用程序请求信息、展现信息、管理和更改信息的方式，应用程序读写信息到数据层，数据层也就是数据库或其他存储设备负责管理和维护数据。应用程序本身负责与前后两层之间进行交互的业务逻辑以及数据的转换。

并不是monolithic架构自身存在缺陷，只是它已经过时了，在智能手机和其他移动设备设计之前就已经存在了，那时候应用程序在展现层只需要跟一种实体进行交互，这种缺陷并不是由于层数亦或是层与层之间数据的处理方式，而是应用程序本身被写成一个单独的统一的代码块。monolithic的天性导致开发人员很难用敏捷性和灵活性对应用程序进行改造以适应移动终端用户的需求，满足运营团队自由伸缩应用程序规模以满足实际的需求。

monolithic 的设计理念阻碍了应用程序开发流程诸多阶段的敏捷性。即使应用程序的功能是以模块化方式组织的，人以模块的更改都需要对整个应用程序进行编译和测试。这本身是恨耗时的，对于那些一年内只更新很少次的公司来讲可能是可以接受的，但要跟上如今的大环境，一年只更新几次的APP恐怕难以在竞争中存活下来。你需要很快的响应渐进式的更新来为用户提供更好的性能和最新的功能。在这样的一个世界里，更新APP永远不会给大多数用户带来不便。

Source: Martin Fowler

Microservices Architecture, Source: Martin Fowler

将应用程序拆分成模块长久以来被视为最佳实践。最近，开源项目的成功使得多数开发人员能够借助外部的一些库来实现特殊的功能。这些开源库常常用于那些开发人员不熟悉的特殊功能，或仅仅是为了节省时间，或者是出于维护安全性的考虑。对于 monolithic设计而言 就不存在从诸多方案中任选其一的灵活性，应用程序往往是由一些高度耦合的组件开发而成。

最后一点，三层架构缺乏伸缩性。事实上，提出这种架构理念的年代并不存在 elasticity and rapid scaling 。由于应用程序的功能组件是打包成一个整体的，你要响应客户端需求变更的唯一方式就是对整体进行扩展。由于应用程序是紧耦合的，三层架构的应用程序通常是没有办法对某个特殊部分单独进行扩展的。不管是一个电子商务的平台、社交媒体的应用还是一个博客，现如今应用程序的基本要求是能够按需伸缩，成本越低越好。对应用程序进行伸缩控制的过程要简单、自动化和智能。比如说某个应用架构能够让你根据用户注册的突发量来部署额外的Node.js节点。

[wanghaisheng]

英文版： 第二部分：微服务架构在Netflix的应用：架构设计的经验教训 中文版：第二部分：微服务架构在Netflix的应用：架构设计的经验教训

在最近的一些博客里我们解释了采用四层的架构对于开发和部署微服务的应用程序是很重要的。 如果你仍然采用十年前的开发流程和应用架构，你不能很快地获取和满足移动端用户的需求，移动端用户可以从越来越多的APP中进行选择。

向微服务架构的转换给市场上的公司带来了很多的机会。对于系统架构和开发人员，它在为用户提供新的用户体验的同时又带来了一种前所未有的控制力和速度。但在现在这样紧张的节骨眼上，感觉上是不允许出一点差错的。现实世界中，你不可能革新期间就停止APP的开发和部署的。你深深明白未来的成功取决于能否成功迁移到微服务架构中来，但是你该怎么来做呢？

幸运的是，微服务的早期实践者本着开源的精神慷慨地分享他们的专业知识，不仅有开源代码，也会在会议上做一些演讲，写一些博客。Netflix就是其中之一。Adrian Cockcroft作为web工程和云计算架构师总监负责监督了公司内负责DVD租赁系统的100人的工程师团队从传统开发模式到只需要很少人员负责数百个后台服务的微服务架构来为数百万的Nrtflix客户提供数字娱乐服务。Battery Ventures公司的技术人员Cockcroft是微服务和云架构方面著名的布道者，目前供职于Nginx技术咨询委员会。 后续的两篇文章中，我们会给大家将一些从去年Cockcroft做的2场演讲，一场是10月的NGINX大会上，一场是几个月之后的硅谷微服务meetup中的一些启发。

• 这篇里面主要是给微服务架构一个定义，阐述了一些设计微服务架构的最佳实践
• 后面的一篇讨论了采用软件设计新思路以及绕着这种新思路来重组团队的原因和方式。

什么是微服务架构?

Cockcroft 把微服务架构定义为由松耦合的有相应语境的元素构成的一种面向服务的架构

松耦合意味着你可以独立更新这些服务。更新其中一个服务并不会改变其他的服务。 如果你的系统里有大量的特殊服务，但是又必须同时更新它们，它们又不是微服务，因为它们不是松耦合的。在向微服务迁移的时候人们常常会把数据库的耦合看的过重，也就是所有服务都连的是同一个数据库，更新其中一个服务就意味着要改变数据库的schema。这种情况你需要对数据库进行拆分

_bounded contexts_的概念来源于Eric Evans的书 Domain Driven Design 。就软件开发的目的而言，拥有恰当语境的微服务本身是自包含的。由于微服务和其他微服务之间交互是严格通过API来进行的，你不需要共享数据结构、数据库表结构和对象的内部表达形式，在不了解其他服务的内部结构的情况下你也可以理解和更新一个微服务的代码。

如果你开发的是互联网应用，你已经很熟悉这些概念了，实际上只不过用的不是同样的叫法。大多数移动APP都用到了一些后台服务，这样用户可以在APP里实现Facebook里共享、从Google Map里得到地理位置、在Foursquare找到一家餐馆。假如你的APP与这些服务是紧耦合的，这样你在更新之前必须与开发团队进行协调来确保你的更新不会破坏任何东西。

在使用微服务架构时，你要把其他的开发团队看作是这些后台服务：也就是那些你的微服务通过API交互的外部服务。微服务之间最通用的协议就是它们的API足够稳定，也是向前兼容的。

就跟Google Map 的API不可能事先提醒就进行更改是不能所接受的，这样的话，你是API可以演进，但是必须要与之前的版本兼容

微服务架构设计的最佳实践

Cockcroft解释他在Netflix的职位是云架构师，他的职责不是管理架构，而是发现和标准化公司工程师所形成的架构。Netflix开发团队提出了几条设计和实现微服务架构的最佳实践

每个微服务的数据单独存储

不同微服务不要使用同一个后台数据存储。让开发团队选择适合每个微服务的数据库。或许，不同团队使用同样的数据结构来存储会减少工作量，但当其中某个团队想要更改数据结构的时候，其他服务不得不跟着改变。

数据的拆分会使得数据管理异常复杂，是因为单独的存储系统不容易同步，易于出现不一致的情况，外键也会发生意外的改变。你需要一个后台运行的主数据管理的工具来发现和修复不一致的情况。比如，你需要检查每个存储订阅者ID的数据库来确保所有的ID都是同一个。这个工具可以自己写或者直接买。很多商用的关系型数据库都提供此类核对，它常常过于耦合，不能支持很好的伸缩性。

使用类似程度的成熟度来维护代码

微服务中所有代码都保持同样的类似程度的成熟度和稳定度。也就是说，你想要重写或给一个运行良好的已部署好的微服务添加一些代码的话，最好的方式常常 是对于新的或要改动的代码，新建一个微服务，现有的微服务丢着不管就行。 [编辑注：这种架构常常称之为immutable infrastructure principle.] 这样的话，你可以迭代式的部署和测试新代码，直至没有bug，性能足够好,现有的微服务不会出现故障或性能下降.一旦新的微服务和原始的服务一样稳定，如果确实需要进行功能合并的话，你可以将其合并在一起，或者处于性能的考虑合并它们。然而，就Cockcroft’s的经验来讲，常常是你发现你的服务太大而要进行拆分。

每个微服务都单独进行编译构建

每个微服务都单独进行编译构建，这样你就从代码库里某个版本中抽取单独的组件。这样，你可以拿到多个类似文件的微服务，但却是不同的版本的。这样如果要对codebase进行清理会比较麻烦，但对于在新建微服务时添加新文件时的便利性的话，是值得的。The asymmetry is intentional: 你想要引入新的微服务、文件或者功能，很容易又不会存在风险

部署到容器之中

将微服务部署到容器中很重要是因为这意味着你需要一款部署的工具。只要一个微服务是在容器之中，该工具就应该知道如何部署。无论是那种容器都没有关系。也就是说，Docker看起来很快会成为容器的行业标准。

将服务器看做是无状态的

将那些特别是部署了客户端代码的服务器视作是可替换的一组之中的一个。这些服务器的功能都是一样的，你无须关心某一个。只需要关心要实现你的目标是否数量足够，你可以使用自动伸缩来按需调整数目。如果其中一个服务器宕机了，可以由其他一个替换。避免了那些单个服务器完成特殊功能的系统中存在的雪崩现象，

Cockcroft打了个比方，你把服务器看做奶牛而不是宠物。如果生产系统中某个服务器负责某个特殊的功能，你通过名称认识这个服务器，这个服务器宕机后大家都回很难过，这也就是一个宠物。相反，如果你把服务器看作是一些奶牛。你关心的是你每天能挤多少奶，如果有一天你发现今天挤的奶少了，你知道是哪头牛有问题，你可以换掉它。

Netflix Delivery Architecture is Built on nginx

下面是一段软广吧。不过nginx还是很NB的。 Netflix is a longtime nginx user and became the first customer of NGINX, Inc. after it incorporated in 2011. Indeed, Netflix chose nginx as the heart of their delivery infrastructure, the Netflix Open Connect Content Delivery Network (CDN), one of the largest CDNs in the world. With the ability to serve thousands, and sometimes millions, of requests per second, nginx is an optimal solution for high-performance HTTP delivery and enables companies like Netflix to offer high-quality digital experiences to millions of customers every day.

Video Recordings

Fast Delivery

Fast Delivery nginx.conf2014, October 2014

Migrating to Microservices, Part 1

Migrating to Microservices, Part 1 Silicon Valley Microservices Meetup, August 2014

Migrating to Microservices, Part 2

Silicon Valley Microservices Meetup, August 2014

[wanghaisheng]

英文版： 第三部分：Adopting Microservices at Netflix: Lessons for Team and Process Design 中文版： [第三部分：微服务架构在Netflix的应用：团队和流程设计相关的经验教训]()

In a previous blog post, we shared best practices for designing a microservices architecture, based on Adrian Cockcroft’s presentation at nginx.conf2014 about his experience as Director of Web Engineering and then Cloud Architect at Netflix. In this follow-up post, we’ll review his recommendations for retooling your development team and processes for a smooth transition to microservices. Optimize for Speed, not Efficiency

Source: Xyzproject@Dreamstime.com

The top lesson that Cockcroft learned at Netflix is that speed wins in the marketplace. If you ask any developer whether a slower development process is better, no one ever says yes. Nor do management or customers ever complain that your development cycle is too fast for them. The need for speed doesn’t just apply to tech companies, either: as software becomes increasingly ubiquitous on the Internet of Things – in cars, appliances, and sensors as well as mobile devices – companies that didn’t used to do software development at all now find that their success depends on being good at it.

Netflix made an early decision to optimize for speed. This refers specifically to tooling your software development process so that you can react quickly to what your customers want, or even better, can create innovative web experiences that attract customers. Speed means learning about your customers and giving them what they want at a faster pace than your competitors. By the time competitors are ready to challenge you in a specific way, you’ve moved on to the next set of improvements.

This approach turns the usual paradigm of optimizing for efficiency on its head. Efficiency generally means trying to control the overall flow of the development process to eliminate duplication of effort and avoid mistakes, with an eye to keeping costs down. The common result is that you end up focusing on savings instead of looking for opportunities that increase revenue.

In Cockcroft’s experience, if you say “I’m doing this because it’s more efficient,” the unintended result is that you’re slowing someone else down. This is not an encouragement to be wasteful, but you should optimize for speed first. Efficiency becomes secondary as you satisfy the constraint that you’re not slowing things down. The way you grow the business to be more efficient is to go faster. Make Sure Your Assumptions are Still True

Many large companies that have enjoyed success in their market (we can call them incumbents) are finding themselves overtaken by nimbler, usually smaller, organizations (disruptors) that react much more quickly to changing consumer behavior. Their large size isn’t necessarily the root of the problem – Netflix is no longer a small company, for example. As Cockcroft sees it, the main cause of difficulty for industry incumbents is that they’re operating under business assumptions that are no longer true. Or, as Will Rogers put it,

It’s not what we don’t know that hurts. It’s what we know that ain’t so.”

Of course, you have to make assumptions as you formulate a business model, and then it makes sense to optimize your business practices around them. The danger comes from sticking with assumptions after they’re no longer true, which means you’re optimizing on the wrong thing. That’s when you become vulnerable to industry disruptors who are making the right assumptions and optimizations for the current business climate.

As examples, consider the following assumptions that hold sway at many incumbents. We’ll examine them further in the indicated sections and describe the approach Netflix adopted.

Computing power is expensive. This was true when increasing your computing capacity required capital expenditure on computer hardware. See Put Your Infrastructure in the Cloud.
Process prevents problems. At many companies, the standard response to something going wrong is to add a preventative step to the relevant procedure. See Create a High Freedom, High Responsibility Culture with Less Process.

Here are some ways to avoid holding onto assumptions that have passed their expiration date:

As obvious as it might seem, you need to make your assumptions explicit, then periodically review them to make sure they still hold true.
Keep aware of technological trends. As an example, the cost of solid state storage drive (SSDs) storage continues to go down. It’s still more expensive than regular disks, but the cost difference is becoming small enough that many companies are deciding the superior performance is worth paying a bit more for. [Ed: In this entertaining video, Fastly founder and CEO Artur Bergman explains why he believes SSDs are always the right choice.]
Talk to people who aren’t your customers. This is especially necessary for incumbents, who need to make sure that potential new customers are interested in their product. Otherwise, they don’t hear about the fact that they’re not being used. As an example, some vendors in the storage space are building hyper-converged systems even as more and more companies are storing their data in the cloud and using open source storage management software. Netflix, for example, stores data on Amazon Web Services (AWS) servers with SSDs and manages it with Apache Cassandra. A single specialist in Java distributed systems is managing the entire configuration without any commercial storage tools or help from engineers specializing in storage, SAN, or backup.
Don’t base your future strategy on current IT spending, but instead on level of adoption by developers. Suppose that your company accounts for nearly all spending in the market for proprietary virtualization software, but then a competitor starts offering an open source-based product at only 1% the cost of yours. If people start choosing it instead of your product, than at the point that your share of total spending is still 90%, your market share has declined to only 10%. If you’re only attending to your revenue, it seems like you’re still in good shape, but 10% of market share can collapse really quickly.

Put Your Infrastructure in the Cloud Source: Fbmadeira | Dreamstime.com

Source: Fbmadeira@Dreamstime.com

In Make Sure Your Assumptions are Still True, we mentioned that in the past it was valid to base your business plan on the assumption that computing power was expensive, because it was: the only way to increase your computing capacity was to buy computer hardware. You could then make money by using this expensive resource in the right way to solve customer problems.

The advent of cloud computing has pretty much completely invalidated this assumption. It is now possible to buy the amount of capacity you need when you need it, and to pay for only the time you actually use it. The new assumption you need to make is that (virtual) machines are ephemeral. You can create and destroy them at the touch of a button or a call to an API, without any need to negotiate with other departments in your company.

One way to think of this change is that the self-service cloud makes formerly impossible things instantaneous. All of Netflix’s engineers are in California, but they manage a worldwide infrastructure. The cloud enables them to experiment and determine whether (for example) adding servers in particular location improves performance. Suppose they notice problems with video delivery in Brazil. They can easily set up 100 cloud server instances in São Paulo within a couple hours. If after a week they determine that the difference in delivery speed and reliability isn’t large enought to justify the cost of the additional server instances, they can shut them down just as quickly and easily as they created them.

This kind of experiment would be so expensive with a traditional infrastructure that you would never attempt it. You would have to hire an agent in São Paulo to coordinate the project, find a data center, satisfy Brazilian government regulations, ship machines to Brazil, and so on. It would be six months before you could even run the test and find out that increased local capacity didn’t improve your delivery speed. Create a High Freedom, High Responsibility Culture with Less Process

In Make Sure Your Assumptions are Still True, we observed that many companies create rules and processes to prevent problems. When someone makes a mistake, they add a rule to the HR manual that says “well, don’t do that again.” If you read some HR manuals from this perspective, you can extract a historical record of everything that went wrong at the company. When something goes wrong in the development process, the corresponding reaction is to add a new step to the procedure. The major problem with creating process to prevent problems is that over time you build up complex “scar tissue” processes that slow you down.

Netflix doesn’t have an HR manual. There is a single guideline: “Act in NetFlix’s best interest.” The idea is that if an employee can’t figure out how to interpret the guideline in a given situation, he or she doesn’t have enough judgment to work there. If you don’t trust the judgment of the people on your team, you have to ask why you’re employing them. It’s true that you’ll have to fire people occasionally for violating the guideline. Overall, the high level of mutual trust among members of a team, and across the company as a whole, becomes a strong binding force.

The following books outline new ways of thinking about process if you’re looking to transform your organization:

The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt and Jeff Cox. This book has become a standard management text at business schools since its original publication in 1984. Written as a novel about a manager who has only 90 days to improve performance at his factory or have it closed down, it embodies Goldratt’s Theory of Constraints in the context of process control and automation.
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim and Kevin Behr. As the title indicates, it’s also a novel, about an IT manager who has 90 days to save a project that’s late and over budget, or his entire department will be outsourced. He discovers DevOps as the solution to his problem.

Replace Silos with Microservice Teams

Most software development groups are separated into silos, with no overlap of personnel between them. The standard process for a software development project starts with the product manager meeting with the user experience and development groups to discuss ideas for new features. After the idea is implemented in code, the code is passed to the quality assurance (QA) and database administration teams and discussed in more meetings. Communication with the system, network, and SAN administrators is often via tickets. The whole process tends to be slow and loaded with overhead. silos-base

Source: Adrian Cockcroft

Some companies try to speed up by creating small “start-up”-style teams that handle the development process from end to end, or sometimes such teams are the result of acquisitions where the acquired company continues to run independently as a separate division. But if the small teams are still doing monolithic delivery, there are usually still handoffs between individuals or groups with responsibility for different functions. The process suffers from the same problems as monolithic delivery in larger companies – it’s simply not very efficient or agile. Source: Adrian Cockcroft

Source: Adrian Cockcroft

Conway’s law says that the interface structure of a software system will reflect the social structure of the organization that produced it. So if you want to switch to a microservices architecture, you need to organize your staff into product teams and use DevOps methodology. There are no longer distinct product managers, UX managers, development managers, and so on, managing downward in their silos. There is a manager for each product feature (implemented as a microservice), who supervises a team that handles all aspects of software development for the microservice, from conception through deployment. The platform team provides infrastructure support that the product teams access via APIs. At Netflix, the platform team was mostly AWS in Seattle, with some Netflix-managed infrastructure layers built on top. But it doesn’t matter whether your cloud platform is in-house or public; the important thing is that it’s API-driven, self-service, and automatable. Source: Adrian Cockcroft

Source: Adrian Cockcroft

Adopt Continuous Delivery, Guided by the OODA Loop

A siloed team organization is usually paired with monolithic delivery model, in which an integrated, multi-function application is released as a unit (often version-numbered) on a regular schedule. Most software development teams use this model initially because it is relatively simple and works well enough with a small number of developers (say, 50 or fewer). However, as the team grows it becomes a real issue when you discover a bug in one developer’s code during QA or production testing and the work of 99 other developers is blocked from release until the bug is fixed.

In 2009 Netflix adopted a continuous delivery model, which meshes perfectly with a microservices architecture. Each microservice represents a single product feature that can be updated independently of the other microservices and on its own schedule. Discovering a bug in a microservice has no effect on the release schedule of any other microservice. Continuous delivery relies on packaging microservices in standard containers. Netflix initially used AWS machine images (AMIs) and it was possible to deploy an update into a test or production environment in about 10 minutes. With Docker, that time is reduced even further, to mere seconds in some cases.

At Netflix, the conceptual framework for continuous development and delivery is an Observe-Orient-Decide-Act (OODA) loop. Source: Adrian Cockcroft (http://www.slideshare.net/adrianco)

Source: Adrian Cockcroft (http://www.slideshare.net/adrianco)

Observe refers to examining your current status to look for places where you can innovate. You want your company culture to implicitly authorize anyone who notices an opportunity to start a project to exploit it. For example, you might notice what the diagram calls a “customer pain point”: a lot of people abandoning the registration process on your website when they reach a certain step. You can undertake a project to investigate why and fix the problem.

Orient refers to analyzing metrics to understand the reasons for the phenomena you’ve observed at the Observe point. Often this involves analyzing large amounts of unstructured data, such as log files; this is often referred to as big data analysis. The answers you’re looking for are not already in your business intelligence database. You’re examining data that no one has previously looked at and asking questions that haven’t been asked before.

Decide refers to developing and executing a project plan. Company culture is a big factor at this point. As previously discussed, in a high-freedom, high-responsibility culture you don’t need to get management approval before starting to make changes. You share your plan, but you don’t have to ask for permission.

Act refers to testing your solution and putting it into production. You deploy a microservice that includes your incremental feature to a cloud environment, where it’s automatically put into an AB test to compare it to the previous solution, side by side, for as long as it takes to collect the data that shows whether your approach is better. Cooperating microservices aren’t disrupted, and customers don’t see your changes unless they’re selected for the test. If your solution is better, you deploy it into production. It doesn’t have to be a big improvement, either. If the number of clients for your microservice is large enough, then even a fraction of a percent improvement (in response time, say) can be shown to be statistically valid, and the cumulative effect over time of many small changes can be significant.

Now you’re back at the Observe point. You don’t always have to perform all the steps or do them in strict order, either. The important characteristic of the process is that it enables you quickly to determine what your customers want and to create it for them. Cockcroft says “it’s hard not to win” if you’re basing your moves on enough data points and your competitors are making guesses that take months to be proven or disproven.

The state of art is to circle the loop every one to two weeks, but every microservice team can do it independently. With microservices you can go much faster because you’re not trying to get entire company going around the loop in lockstep. How NGINX Plus Can Help

At NGINX we believe it’s crucial to your future success that you adopt a 4-tier application architecture in which applications are developed and deployed as sets of microservices. We hope the information we’ve shared in this post and its predecessor, Adopting Microservices at Netflix: Lessons for Architectural Design, are helpful as you plan your transition to today’s state-of-the-art architecture for application development.

When it’s time to deliver your apps, NGINX Plus offers an application delivery platform that provides the superior performance, reliability, and scalability your users expect. Fully adopting a microservices-based architecture is easier and more likely to succeed when you move to a single software tool for web serving, load balancing, and content caching. NGINX Plus combines those functions and more in one easy to deploy and manage package. Our approach empowers developers to define and control the flawless delivery of their microservices, while respecting the standards and best practices put into place by a platform team. Click here to learn more about how NGINX Plus can help your applications succeed.

[wanghaisheng]

https://github.com/owainlewis/microservice-design

Microservices Design

Notes, resource and ideas from a recent BBC Microservices course.

A software developer reading list for learning more about micro service architecture

Postel's Law

Be liberal in what you accept, and conservative in what you send

Videos

• Microservices - Martin Fowler
• State of the Art in Microservices - Adrian Cockcroft
• Deploying And Testing Microservices - Sam Newman
• Microservices Anti-Patterns
• Practical Considerations For Microservice Architectures - Sam Newman
• Migrating to Microservices - Adrian Cockcroft
• Microservices at Netflix

Books

• Antifragile: Things That Gain from Disorder
• The Black Swan
• Implementing Domain-Driven Design
• Building Micro Services - Sam Newman
• Antifragile Software - Russ Miles

People

• James Lewis
• Sam Newman
• Russ Miles
• Martin Fowler

Architectural Patterns

• API Gateway
• Bounded Context
• Circuit Breaker

Design Principles

1. Do not worry about the size of services. Focus on which componnents "change together"

Event Transport

• Protocol Buffers