###Chapter 20 Designing for Any Technology 第20章 为任何技术进行设计 > Success in warfare is gained by carefully accommodating ourselves to the enemy’s purpose.—Sun Tzu > 战争的成功是通过小心地让自己适应敌人的目的而获得的。——孙子 Have you ever heard someone describe a design or platform architecture by using thenames of the third-party or open source systems used to implement that platform orarchitecture? The discussion starts with a question, “How are you architected?” andends with a statement like, 您是否曾听过有人使用用于实现该平台或架构的第三方或开源系统的名称来描述设计或平台架构？讨论从一个问题开始：“你是如何构建的？”并以这样的语句结尾 We use ACME Web servers running on Platinum computers connected to our own internalapplication running on Ace application servers. We use Bestco databases running on FastcoSMP servers to maintain state and store information. The Fastco servers are connected to aBestsan storage area network. All of our network gear is Fastgear and Datasafe providesour firewalls. 我们使用在 Platinum 计算机上运行的 ACME Web 服务器，该服务器连接到在 Ace 应用程序服务器上运行的我们自己的内部应用程序。我们使用在 FastcoSMP 服务器上运行的 Bestco 数据库来维护状态和存储信息。 Fastco 服务器连接到 Bestsan 存储区域网络。我们所有的网络设备都是 Fastgear，Datasafe 为我们提供防火墙。 Nice product plugs. Each of the speaker’s vendors and partners no doubt love howhe described his implementation. And yes, we meant to say implementation becausethe preceding statement is neither a design nor an architecture. The implementationspeech sounds like one long product plug covering multiple vendors and might befine if the company is getting paid by the reference, but that is not likely the case.Describing architectures through implementation is akin to constructing a picture ofyour current or desired soulmate from pictures cut out of US Magazine; the resultmay paint a good picture of what you have or want, but it in no way describes how itis that the soulmate will meet your current or future needs. 不错的产品插头。毫无疑问，演讲者的每个供应商和合作伙伴都喜欢他描述其实现的方式。是的，我们的意思是说实现，因为前面的陈述既不是设计也不是架构。实现演讲听起来像是一个涵盖多个供应商的长产品插件，如果公司通过参考获得报酬，可能会好一些，但情况不太可能是这样。通过实现描述架构类似于从图片中构建您当前或所需的灵魂伴侣的图片出自美国杂志；结果可能很好地描绘了您拥有或想要的东西，但它绝不能描述灵魂伴侣将如何满足您当前或未来的需求。 This chapter describes the difference between architecture and implementation.We further make the argument that the best architectures are not accomplishedthrough vendor partnerships but rather through vendor and technology agnostic“boxes” and descriptions. 本章描述了架构和实现之间的区别。我们进一步提出这样的论点：最好的架构不是通过供应商合作伙伴关系来实现的，而是通过与供应商和技术无关的“盒子”和描述来实现的。 ####An Implementation Is Not an Architecture 实现不是架构 Sometimes it is easiest, albeit indirect, to describe what something is by defining thatsomething by what it is not. For instance, in attempting to teach a child what a dogis, you might be required from time to time to explain that a cat is not a dog and thata dog is not a cat. This approach is especially useful when two things are often con-fused in popular speech and literature. An example of such a popular confusionexists within the definition of an implementation and an architecture. 有时，通过定义某事物不是什么来描述某事物是什么是最简单的，尽管是间接的。例如，在尝试教孩子什么是狗时，您可能会不时地被要求解释猫不是狗，狗也不是猫。当流行演讲和文学中经常混淆两件事时，这种方法特别有用。这种普遍混淆的一个例子存在于实现和架构的定义中。 Put simply, and with the “bottom line up front,” an implementation is not anarchitecture nor is an architecture an implementation. The best architects of build-ings and houses do not describe trusses, beams, and supports using the vendor’sname, but describe them in terms of size, load capacity, and so on. This is because thearchitect realizes that in most cases the items in question are commodities and thatthe vendor solution will likely be selected based on price, reputation, and quality. Inessence, the house architect intuitively or as a result of education understands thatdescribing something with a vendor’s name is an implementation, whereas describingsomething through specifications and requirements is an architecture. Similarly, elec-trical design engineers do not typically reference vendor names when describing adesign; they are more likely to reference a resistor and its level of resistance ratherthan indicating a specific vendor and part number. 简而言之，“底线在前”，实现不是无架构，架构也不是实现。最好的建筑物和房屋建筑师不会使用供应商的名称来描述桁架、梁和支撑，而是用尺寸、负载能力等来描述它们。这是因为架构师意识到，在大多数情况下，所讨论的项目都是商品，并且可能会根据价格、声誉和质量来选择供应商解决方案。从本质上讲，房屋建筑师凭直觉或通过教育了解到，用供应商的名称描述某事物是一种实现，而通过规范和要求描述某事物是一种架构。同样，电气设计工程师在描述设计时通常不会引用供应商名称；他们更有可能引用电阻器及其电阻级别，而不是指示特定的供应商和部件号。 Implementations define what you are today and represent the choices you havemade due to cost considerations, build versus buy decisions, returns on investment,skill sets within your team, and so on. The use of C++ or Java or PHP as a codinglanguage is not indicative of your architecture; they are choices of tools and materialsto implement components of your architecture. The choice of a Microsoft databaseover Sybase or Oracle as a database is not an architecture, but rather an implementa-tion of a database component of your architecture. The decision to go open sourceversus a vendor provided solution is another example of an implementation decision, asis the decision to use a Microsoft operating system over using some variant of UNIX. 实施定义了您今天的情况，并代表您由于成本考虑、构建与购买决策、投资回报、团队内的技能组合等而做出的选择。使用 C++ 、Java 或 PHP 作为编码语言并不代表您的架构；它们是用于实现架构组件的工具和材料的选择。选择 Microsoft 数据库而不是 Sybase 或 Oracle 作为数据库并不是一种体系结构，而是体系结构的数据库组件的实现。决定采用开放源代码还是选择供应商提供的解决方案是实施决策的另一个例子，就像决定使用 Microsoft 操作系统而不是使用 UNIX 的某些变体的决定一样。 ####Technology Agnostic Design 技术不可知设计 Mature organizations looking to produce the most highly scalable and reliable sys-tems, platforms, and products understand that there is a very big difference betweenarchitecture and implementation. The architecture of a platform describes how some-thing works in generic terms with specific requirements, and the implementationdescribes the specific technologies or vendor components employed. Physical archi-tectures tend to describe the components performing the work, whereas logical archi-tectures tend to define the activities and functions necessary to do the work. We liketo discuss architectures from a system’s perspective, where the logical architecture ismapped to its physical components such that both can be evaluated in the same viewto the extent possible. 希望生产最具可扩展性和可靠性的系统、平台和产品的成熟组织明白，架构和实施之间存在巨大差异。平台的架构以通用术语描述了某些事物如何在特定需求下工作，而实现则描述了所使用的特定技术或供应商组件。物理架构倾向于描述执行工作的组件，而逻辑架构倾向于定义完成工作所需的活动和功能。我们喜欢从系统的角度讨论架构，其中逻辑架构被映射到其物理组件，以便可以尽可能在同一视图中评估两者。 The implementation is a snapshot of the architecture and may not even be consis-tent with the end or desired state of any given architecture. For instance, take anarchitecture that has a write database as a subcomponent of the system, to which allwrites and updates go, and several read databases, from which all reads occur, in aload balanced fashion. For a very small site, it may make sense for a single databaseto accomplish all of these things (with an additional database for high availability ofcourse). The implementation in this case would be a single database, whereas the siteis potentially architected for more than one. Further consider the case where thearchitecture calls for nearly any database to be used with the application connectingthrough an abstracted data access layer (DAL) or data access object (DAO). The spe-cific implementation at a point in time might be a database from Microsoft, but withsome modifications to the DAL/DAO could ultimately become an open source data-base or database from IBM, Oracle, or Sybase. 实现是架构的快照，甚至可能与任何给定架构的最终或期望状态不一致。例如，采用一个体系结构，该体系结构具有一个作为系统子组件的写入数据库（所有写入和更新都将进入该数据库），以及多个读取数据库（所有读取都从中发生），以负载平衡的方式进行。对于一个非常小的站点，使用单个数据库来完成所有这些事情可能是有意义的（当然还需要一个额外的数据库来实现高可用性）。在这种情况下，实施将是一个单一的数据库，而该站点可能是为多个数据库而设计的。进一步考虑以下情况：该架构要求几乎任何数据库与通过抽象数据访问层 (DAL) 或数据访问对象 (DAO) 连接的应用程序一起使用。某个时间点的具体实现可能是来自 Microsoft 的数据库，但通过对 DAL/DAO 进行一些修改，最终可能成为开源数据库或来自 IBM、Oracle 或 Sybase 的数据库。 The aim of technology agnostic design (TAD) and technology agnostic architec-ture (TAA) is to separate design and architecture from the technology employed andthe specific implementation. This separation decreases both cost and risk whileincreasing scalability and availability of your product, system, or platform. Some ofour clients even incorporate TAD or TAA into their architectural principles. 技术不可知设计（TAD）和技术不可知架构（TAA）的目的是将设计和架构与所采用的技术和具体实现分开。这种分离可以降低成本和风险，同时提高产品、系统或平台的可扩展性和可用性。我们的一些客户甚至将 TAD 或 TAA 纳入他们的架构原则中。 #####TAD and Cost TAD 和成本 As we mentioned earlier, architects of houses and buildings rarely describe their workthrough the names of the vendors providing materials. Certain components, such as2u4s may have similar characteristics, but many finishing components that differenti-ate houses do not, such as cabinetry, sinks, toilets, and kitchen appliances. For thesecomponents, architects often attempt to describe them in terms of “fit and finish,”giving dimensions and design characteristics. These architects understand that if theyarchitect something appropriately, they open up several opportunities for negotia-tions among competing providers of the aforementioned materials. These negotia-tions in turn help drive down the cost of building (or implementing) the house. Eachvendor is subject to a competitive bidding process, where price, quality, and reputa-tion all come into play. 正如我们之前提到的，房屋和建筑物的建筑师很少通过提供材料的供应商的名字来描述他们的工作。某些组件（例如2u4）可能具有相似的特征，但许多使房屋与众不同的装饰组件却没有，例如橱柜、水槽、厕所和厨房用具。对于这些组件，建筑师经常尝试用“装配和完成”来描述它们，给出尺寸和设计特征。这些建筑师明白，如果他们适当地设计一些东西，他们就会为上述材料的竞争供应商之间的谈判提供一些机会。这些谈判反过来又有助于降低建造（或实施）房屋的成本。每个供应商都要经过竞争性投标过程，其中价格、质量和声誉都会发挥作用。 Technology solutions, much like building materials, suffer the effects of commoditi-zation over time. A good idea or implementation that becomes successful in an industryis bound to attract competitors. The competitors within the solution space initiallycompete on differences in functionality and service, but over time, these differencesdecrease as useful feature sets get adopted by all competitors. In an attempt to fore-stall the effects of commoditization through increased switching costs, providers ofsystems and software try to produce proprietary solutions or tools that interact spe-cifically and exclusively with their systems. 技术解决方案就像建筑材料一样，随着时间的推移会受到商品化的影响。在一个行业中取得成功的好想法或实施必然会吸引竞争对手。解决方案领域内的竞争对手最初在功能和服务方面进行竞争，但随着时间的推移，随着有用的功能集被所有竞争对手采用，这些差异就会减少。为了通过增加转换成本来阻止商品化的影响，系统和软件提供商试图生产与其系统进行特定且排他性交互的专有解决方案或工具。 Avoiding getting trapped by extensive modification of any provider’s solution oradoption of tightly integrated provider tools allows you the flexibility of leveragingthe effects of commoditization. As competitors within a solution space begin to con-verge on functionality and compete on price, you remain free to choose the lowestcost of ownership for any given solution. This flexibility results in capital outlay,which minimizes the impact to cash flow and lowers amortized costs, which posi-tively impacts profits on a net income basis. The more your architecture allows youto bring in competing providers or partners, the lower your overall cost structure.Several times within your career, you are likely to find a provider of technologythat is far superior in terms of features and functionality to other providers. You maydetermine that the cost of implementing this technology is lower than the other pro-viders because you have to build less to implement the product. In making such adecision, you should feel comfortable that the “lock in” opportunity cost of choosingsuch a provider exceeds the option cost of switching to another provider in thefuture. In other words, recognize that other providers will move quickly to close thefunctionality gap and do your best to ensure that the integration of the service inquestion can be replaced with other providers down the road. 避免因对任何提供商的解决方案进行大量修改或采用紧密集成的提供商工具而陷入困境，使您能够灵活地利用商品化的影响。随着解决方案领域内的竞争对手开始在功能上趋同并在价格上竞争，您仍然可以自由地为任何给定解决方案选择最低拥有成本。这种灵活性导致资本支出，从而最大限度地减少对现金流的影响并降低摊销成本，从而对净利润产生积极影响。您的架构允许您引入的竞争提供商或合作伙伴越多，您的总体成本结构就越低。在您的职业生涯中，您可能会多次找到在特性和功能方面远远优于其他提供商的技术提供商。您可能会确定实施该技术的成本低于其他提供商，因为您需要构建更少的产品来实施该产品。在做出这样的决定时，您应该感到放心，选择这样一个提供商的“锁定”机会成本超过了未来切换到另一个提供商的选择成本。换句话说，认识到其他提供商将迅速采取行动来缩小功能差距，并尽最大努力确保相关服务的集成可以被其他提供商所取代。 #####TAD and Risk TAD 和风险 In 2009, several American institutions suddenly collapsed; only five years earlier,those institutions would have been considered indestructible. Most independentinvestment banks that long led the storied march of American capitalism collapsed ina matter of weeks or were devoured by larger banks. Many people started to questionthe futures of Citibank and Bank of America as the government moved to prop themup with federal funds. Fannie Mae and Freddie Mac both received government fundsand became the object of additional government legislation. Other industries, peren-nially teetering on the edge of disaster, such as the American automobile industry,struggled to find ways to remake themselves. 2009年，美国几家机构突然倒闭；仅在五年前，这些机构还被认为是坚不可摧的。大多数长期引领美国资本主义传奇进程的独立投资银行在几周内就倒闭了，或者被更大的银行吞并。随着政府开始用联邦资金支持花旗银行和美国银行，许多人开始质疑它们的未来。房利美和房地美都获得了政府资金，并成为额外政府立法的对象。其他常年在灾难边缘摇摇欲坠的行业，例如美国汽车工业，正在努力寻找重塑自我的方法。 Imagine that you have built a wonderful business producing specialty vans forhandicapped people from Ford vehicles. One hundred percent of your business isbuilt around the Ford Econoline Van, and you can’t easily retool your factory foranother van given the degree of specialization, your tools, the types of parts necessaryto perform your conversions, and your deep relationship with Ford. What do you doif Ford goes out of business? What happens if Ford stays in business but increases itsprices, significantly changes the Econoline Van family, or increases the interest rateon the loans you use to purchase and customize the vans? 想象一下，您已经建立了一家出色的企业，为残疾人士生产福特汽车专用货车。您的业务 100% 是围绕福特 Econoline 厢式货车构建的，考虑到专业化程度、您的工具、执行转换所需的零件类型以及您与福特的深厚关系，您无法轻松地为另一辆厢式货车重组您的工厂。如果福特倒闭了，你会怎么做？如果福特继续经营但提高价格、显着改变 Econoline Van 系列或提高您用于购买和定制货车的贷款利率，会发生什么？ Now, apply a similar set of questions to your implementation (again, not an archi-tecture) should you choose to become tightly integrated in design and implementa-tion with a database or application server provider. Maybe you have used aproprietary set of APIs for some specific asynchronous functionality unique to thedatabase in question or maybe you have leveraged a proprietary set of librariesunique to the application server you’ve chosen. What do you do when one or both ofthose providers go out of business? What if the provider of either technology findsitself being sued for some portion of its solution? What if the viability and mainte-nance of the product relies upon the genius of a handful of people within the com-pany of the provider and those people leave? What if the solution suddenly starts tosuffer from quality problems that aren’t easily fixed? 现在，如果您选择在设计和实现中与数据库或应用程序服务器提供商紧密集成，请将一组类似的问题应用于您的实现（同样，不是架构）。也许您已经使用了一组专有的 API 来实现相关数据库特有的某些特定异步功能，或者您可能已经利用了一组您所选择的应用程序服务器特有的专有库。当其中一个或两个提供商倒闭时，您该怎么办？如果任一技术的提供商发现自己因其解决方案的某些部分而被起诉怎么办？如果产品的生存能力和维护依赖于提供商公司内少数人的天才而这些人离开了怎么办？如果解决方案突然开始出现难以修复的质量问题怎么办？ Technology agnostic design reduces all of these risks by increasing your ability toquickly move to other providers. By reducing your switching costs, you not only havereduced your cost, but you have reduced the risk to your customers and shareholdersas well. 与技术无关的设计可以提高您快速转向其他提供商的能力，从而降低所有这些风险。通过降低转换成本，您不仅降低了成本，还降低了客户和股东的风险。 #####TAD and Scalability TAD 和可扩展性 TAD aids scalability in two ways. The first way is that it forces your company andorganization to create disciplines around scale that are not dependent upon any sin-gle provider or service. This discipline allows you to scale in multiple dimensionsthrough multiple potential partners, the result of which is a more predictable scalablesystem independent of any single solution provider. As stated earlier, your risks andcosts of scalability are decreased. TAD 通过两种方式帮助扩展。第一种方法是，它迫使您的公司和组织围绕规模创建不依赖于任何单一提供商或服务的纪律。这一规则允许您通过多个潜在合作伙伴在多个维度进行扩展，其结果是独立于任何单一解决方案提供商的更可预测的可扩展系统。如前所述，可扩展性的风险和成本会降低。 A common misperception is that by implementing a certain solution, you are reli-ant upon that solution. Just because you use Rapidware’s database replication tech-nology does not mean that you are dependent upon it alone for scale. True, on anygiven day, you rely upon the application to work for proper functioning of your site,but that is not the same as saying that the architecture relies upon it for scale. Again,we separate architecture from implementation. Architecture is a design and shouldnot rely upon any given vendor for implementation. Implementation is a point-in-time description of how the architecture works on that day and at that moment. Theproper architecture in this replication scenario would call for a replication mecha-nism with requirements that can be fulfilled by a number of vendors, of which Rapid-ware is one. If you have done a thorough analysis of the provider landscape andknow that you can either switch databases or replication technology providers easily(again, not without some work), you have a scalable solution that is independent ofthe provider. 一个常见的误解是，通过实施某个解决方案，您就依赖该解决方案。仅仅因为您使用 Rapidware 的数据库复制技术并不意味着您仅依赖它来实现扩展。确实，在任何一天，您都依赖应用程序来保证站点的正常运行，但这并不等同于说架构依赖于它来实现扩展。再次，我们将架构与实现分开。架构是一种设计，不应依赖任何给定的供应商来实现。实现是对架构在当天和那一刻如何工作的时间点描述。这种复制场景中的正确架构需要一种复制机制，其要求可以由许多供应商来满足，Rapid-ware 就是其中之一。如果您对提供商的情况进行了彻底的分析，并且知道您可以轻松地切换数据库或复制技术提供商（同样，并非没有一些工作），那么您就拥有了独立于提供商的可扩展解决方案。 You should not get caught in the trap of saying that you must personally build allcomponents to be truly independently scalable. Remember our discussion in Chapter15, Focus on Core Competencies: Build Versus Buy. Scalable design allows you todrop in commodity solutions to achieve an implementation. Furthermore, nearly alltechnologies ultimately move toward commoditization or attract open source alter-natives. The result is that you rarely need to build most things that you will need out-side of those things that truly differentiate your product or platform. 您不应该陷入必须亲自构建所有组件才能真正独立扩展的陷阱。请记住我们在第 15 章“关注核心能力：构建与购买”中的讨论。可扩展的设计允许您引入商品解决方案来实现实施。此外，几乎所有技术最终都会走向商品化或吸引开源替代品。结果是，除了那些真正使您的产品或平台脱颖而出的东西之外，您很少需要构建您需要的大多数东西。 #####Review of the Four Simple Questions from Chapter 15 回顾第 15 章的四个简单问题 These are the four questions from Chapter 15 that we recommend be used to guide any buildversus buy decision: 我们建议使用第 15 章中的四个问题来指导构建还是购买决策 * Does this component create strategic competitive differentiation? Are we going to have long-term sustainable differentiation as a result of this in switching costs, barriers to entry, and so on? * 该组件是否会创造战略竞争差异化？我们是否会因此在转换成本、进入壁垒等方面实现长期可持续的差异化？ * Are we the best owners of this component or asset? Are we the best equipped to build it and why? Should we sell it if we build it? * 我们是该组件或资产的最佳所有者吗？我们是最有能力建造它的人吗？为什么？如果我们建造它，我们应该卖掉它吗？ * What is the competition to this component? How soon until the competition catches up to us and offers similar functionality? * 该组件的竞争是什么？竞争对手要多久才能赶上我们并提供类似的功能？ * Can we build this component cost effectively? Are we reducing our cost and creating additional shareholder value and are we avoiding lost opportunity in revenue? * 我们可以有效地构建这个组件吗？我们是否降低了成本并创造了额外的股东价值？我们是否避免了收入机会的损失？ Remember that you are always likely to be biased toward building so do your best to protectagainst that bias. The odds are against you that you can build a better product than thosealready available and you should tune your bias toward continuing to do what you do welltoday—your primary business. 请记住，您总是可能对构建存在偏见，因此请尽力避免这种偏见。您很难构建出比现有产品更好的产品，因此您应该调整自己的倾向，继续做您今天擅长的事情——您的主要业务。 The second way that TAD supports scalability is actually embedded within thefour questions from Chapter 15.Can you see it? Let’s ask two questions to get to theanswer. Do you believe there will be a rapid convergence of the functionality in ques-tion? Do you need to deeply integrate the solution in question to leverage it? If youbelieve that competitors will rapidly converge on functionality and you do not needdeep integration to the selected provider’s solution, you should consider using thesolution. In doing so, you avoid the cost of building the solution over the long term.The key, as hinted at by the second question, is to keep away from deep integration. TAD 支持可扩展性的第二种方式实际上嵌入在第 15 章的四个问题中。你能看到吗？让我们问两个问题来得到答案。您相信相关功能会快速融合吗？您是否需要深度集成相关解决方案才能利用它？如果您认为竞争对手将迅速在功能上趋同，并且您不需要与所选提供商的解决方案进行深度集成，则您应该考虑使用该解决方案。这样做可以避免长期构建解决方案的成本。正如第二个问题所暗示的，关键是避免深度集成。 You should not be building logic deep within your system to benefit from a providerssolution. Building such logic ties you into the solution provider and makes it moredifficult for you to benefit from commoditization. 您不应该在系统深处构建逻辑来从提供商解决方案中受益。构建这样的逻辑会将您与解决方案提供商联系在一起，并使您更难以从商品化中受益。 We argue that deep integration of a third-party solution provider is almost nevercritical to scale if you’ve properly architected your system, platform, or product. Inour experience, we have never come across such a situation that absolutely demandsthat a company be deeply tied with a third-party provider in order to scale to thecompany’s needs. In most cases, this misconception is fueled by a poor decisionsomewhere else in the architecture. You may, however, find yourself in a situationwhere it is faster to resolve a pending or existing crisis by leveraging unique function-ality provided by a third party. Should you find yourself in that situation, we recom-mend the following course of action: 我们认为，如果您正确构建了系统、平台或产品，那么第三方解决方案提供商的深度集成对于扩展几乎从来都不是至关重要的。根据我们的经验，我们从未遇到过这种情况，绝对需要公司与第三方提供商紧密联系才能扩展以满足公司的需求。在大多数情况下，这种误解是由于架构中其他地方的错误决策而加剧的。但是，您可能会发现自己处于这样一种情况：利用第三方提供的独特功能可以更快地解决未决或现有的危机。如果您发现自己处于这种情况，我们建议您采取以下行动 1.Abstract the integration into a service so that future changes to eliminate theintegration are limited to the service and not deeply integrated with your sys-tems. Such an abstraction will limit the switching costs after your crisis is over. 1.将集成抽象为服务，以便将来消除集成的更改仅限于服务，而不是与您的系统深度集成。这种抽象将限制危机结束后的转换成本。 2.Make a commitment to resolve the dependency as soon as possible after the crisis. 2.承诺危机过后尽快解决依赖问题。 To illustrate our first point, the abstraction of a service, let’s consider AllScale’sselection of a database within its technology stack. AllScale desires to leverage a fea-ture from BaseData’s new database offering that allows the database to be immedi-ately replicated to multiple locations without replication delay and further allows anyreplicated database to be the primary database of record for all writes to the database.At the time of the decision, no other database provider or open source alternative hasthis capability, and in implementing the BaseData’s offering, the AllScale teambelieves it can save more than one hundred thousand dollars in internal developmentcosts for similar functionality. Time to market is key here, so Johnny, Christine, andthe technology team decide to purchase the database and quickly implement it. 为了说明我们的第一点，即服务的抽象，让我们考虑一下 AllScale 在其技术堆栈中选择的数据库。 AllScale 希望利用 BaseData 新数据库产品的一项功能，该功能允许数据库立即复制到多个位置，而不会出现复制延迟，并进一步允许任何复制的数据库成为所有写入数据库的记录的主数据库。在做出决定时，没有其他数据库提供商或开源替代方案具有此功能，并且在实施 BaseData 的产品时，AllScale 团队相信它可以为类似功能节省超过十万美元的内部开发成本。上市时间是关键，因此 Johnny、Christine 和技术团队决定购买数据库并快速实施。 Christine insists that the team protect the company from being locked into Base-Data’s offerings. She does not want BaseData to put a gun to AllScale’s head for long-term licensing and maintenance fees. Johnny and the team decide to abstract thedatabase access into a service or “layer” of the architecture. By structuring all data-base access within a single layer or object, they limit the amount of work necessary tochange the database at a future date. Although some functions are unique to Base-Data, the team believes it can simply modify or rewrite this single layer withoutextensive code modifications throughout the AllScale HRM system. Only a certainnumber of developers are allowed to write code that will ultimately access the data-base, and the rest of the development team is required to use a developer API torequest data objects from the database. Christine 坚持认为团队要保护公司不被 Base-Data 的产品所束缚。她不希望 BaseData 拿枪指着 AllScale 收取长期许可费和维护费。 Johnny 和团队决定将数据库访问抽象到架构的服务或“层”中。通过在单个层或对象内构建所有数据库访问，它们限制了将来更改数据库所需的工作量。尽管某些功能是 Base-Data 所独有的，但该团队相信它可以简单地修改或重写这一单层，而无需对整个 AllScale HRM 系统进行大量代码修改。只允许一定数量的开发人员编写最终访问数据库的代码，而开发团队的其余成员则需要使用开发人员 API 从数据库请求数据对象。 #####Resolving Build Versus Buy and TAD Conflicts 解决构建与购买以及 TAD 冲突 Don’t be confused with the apparent conflicts between a build versus buy decision and design-ing agnostically; the two are actually complementary when viewed properly. We’ve stated thatyou should own and have core competencies within your team around architecting your plat-form, service, or product to scale. This does not mean that you need to build each discretecomponent of your architecture. Architecture and design are completely separate disciplinesfrom development and implementation. Build versus buy is an implementation or developmentdecision and TAD/TAA are design and architecture decisions. 不要混淆构建与购买决策与不可知论设计之间的明显冲突；如果正确看待的话，两者实际上是互补的。我们已经说过，您应该在团队中拥有并拥有围绕构建可扩展的平台、服务或产品的核心能力。这并不意味着您需要构建架构的每个离散组件。架构和设计是与开发和实施完全不同的学科。构建还是购买是实施或开发决策，TAD/TAA 是设计和架构决策。 A proper architecture allows for many choices within the build versus buy decision, and thebuild versus buy decision should only result in buying if sustainable competitive advantage canbe created. 正确的架构允许在构建与购买决策中进行多种选择，并且只有在能够创造可持续的竞争优势的情况下，构建与购买决策才应该导致购买。 #####TAD and Availability TAD 和可用性 TAD and TAA affects availability in a number of ways, but the most obvious is theway in which it supports the ability to switch providers of technology when one pro-vider has significantly greater availability or quality than other providers. Often, thisleadership position changes over time between providers of services, and you are bestpositioned to take advantage of that leadership position by being agnostic as to theprovider. Again, agnosticism in design and architecture leads to benefits to customersand shareholders. TAD 和 TAA 通过多种方式影响可用性，但最明显的是，当一个提供商的可用性或质量明显高于其他提供商时，它支持切换技术提供商的能力。通常，这种领导地位会随着时间的推移在服务提供商之间发生变化，而您最有可能通过不了解提供商来利用这种领导地位。同样，设计和架构中的不可知论会给客户和股东带来好处。 ####The TAD Approach TAD 方法 Now that we’ve discussed the reasons for TAD and TAA, let’s discuss how toapproach TAD and TAA. Implementing TAD/TAA is fairly simple and straightfor-ward. At its core, it means designing and architecting platforms using concepts ratherthan solutions. Pieces of the architecture are labeled with their generic system type(database, router, firewall, payment gateway, and so on) and potentially furtherdescribed with characteristics or specific requirements (gigabit throughput, 5 terabytesof storage, ETL cloud, and so on). 现在我们已经讨论了 TAD 和 TAA 的原因，让我们讨论如何处理 TAD 和 TAA。实施 TAD/TAA 相当简单明了。从本质上讲，它意味着使用概念而不是解决方案来设计和构建平台。架构的各个部分都标有其通用系统类型（数据库、路由器、防火墙、支付网关等），并可能进一步描述特征或特定要求（千兆位吞吐量、5 TB 存储、ETL 云等）。 The approach for TAD is straightforward and consists of three easily rememberedrules. The first is to think and draw only “boxes,” as in what you might find in awire diagram. For a physical architecture, these boxes depict the type of systememployed but never the brand or model. Router, switch, server, storage, database,and so on are all appropriate boxes to be employed in a physical architecture. Logicalarchitectures define the activities, functions, and processes of the system and shouldalso avoid the inclusion of vendor names. For this step, it does not matter that yourcompany might have contracts with specific providers or have an approved providerlist. This step is just about ensuring that the design is agnostic, and contracts andapproved providers are all implementation related issues. TAD 的方法很简单，由三个容易记住的规则组成。第一种是只思考和绘制“方框”，就像您可能在接线图中看到的那样。对于物理架构，这些方框描述了所使用的系统类型，但从未描述过品牌或型号。路由器、交换机、服务器、存储、数据库等都是物理架构中使用的合适的盒子。逻辑体系结构定义系统的活动、功能和流程，并且还应避免包含供应商名称。对于此步骤，您的公司可能与特定提供商签订合同或拥有批准的提供商列表并不重要。这一步只是为了确保设计是不可知的，合同和批准的提供商都是与实施相关的问题。 We hinted at the second step in the first step. Scrub and remove all references toproviders, models, or requirements that demand either a provider or model. It’sappropriate to indicate requirements in a design, such as a switch that is capable of10 gigabit throughput; but it is not appropriate to indicate a switch capable of run-ning a Cisco proprietary protocol. Again, interface requirements have to do withimplementation. If you have something running in your production environment thatrequires the same brand of system in other places, you have already locked yourselfinto a vendor and violated the TAD approach. 我们在第一步中就暗示了第二步。清理并删除对提供程序、模型或需要提供程序或模型的需求的所有引用。适当地表明设计中的要求，例如能够实现 10 GB 吞吐量的交换机；但表示交换机能够运行 Cisco 专有协议是不合适的。同样，接口要求与实现有关。如果您的生产环境中运行的某些东西需要在其他地方使用相同品牌的系统，那么您已经将自己锁定在供应商中并违反了 TAD 方法。 The final step is to describe any requirements specific to your design in agnosticterms. Use SQL transactions per second instead of a proprietary vendor databaseterm. Use storage in terms of bytes, spindles, or speeds rather than anything specificto any given vendor like a proprietary storage replication system, and so on. When indoubt, ask yourself whether your design has forced you into a vendor for any givenreason, or whether the description of the design is biased by any given vendor oropen source solution. 最后一步是用不可知的术语描述特定于您的设计的任何要求。使用每秒 SQL 事务数而不是专有的供应商数据库术语。使用字节、轴或速度方面的存储，而不是特定于任何给定供应商的任何内容，例如专有存储复制系统等。如有疑问，请问问自己，您的设计是否出于任何特定原因迫使您选择某个供应商，或者任何特定供应商或开源解决方案的设计描述是否存在偏见。 #####The TAD Approach—Three Simple Steps TAD 方法 — 三个简单步骤 Here are three simple steps to help guide you in TAD designs: 以下三个简单步骤可帮助指导您进行 TAD 设计 * In the design itself, think in terms of boxes and wire diagrams rather than prose. Leave the detail of the boxes to the next step. * 在设计本身中，请根据方框和接线图而不是散文来思考。将框的详细信息留到下一步。 * In defining boxes and flows, use generic terms. Application server, Web server, RDBMS, and so on. Don’t use vendor names. * 在定义框和流时，使用通用术语。应用程序服务器、Web 服务器、RDBMS 等。不要使用供应商名称。 * Describe requirements in industry standards. Stay away from proprietary terms specific to a vendor. * 描述行业标准中的要求。远离特定于供应商的专有条款。 Allow your instinct to help guide you. Should you “feel” as though you are being pulledtoward a vendor in a description or design statement, attempt to “loosen” that statement tomake it agnostic. 让你的直觉来帮助指导你。如果您在描述或设计声明中“感觉”好像自己被拉向供应商，请尝试“放松”该声明以使其变得不可知。 A very simple test to determine if you are violating a technology agnostic design isto check whether any component of your architecture is identified with the name of avendor. Data flows, systems, transfers, and software that are specifically labeled ascoming from a specific provider should be questioned. Ideally, even if for some rea-son a single provider must be used (remember our arguments that this should neverbe the case), the provider’s name should be eliminated. You simply do not want togive any provider a belief that you have already chosen its solution or you handicapyourself in negotiations. 确定是否违反技术不可知设计的一个非常简单的测试是检查架构的任何组件是否以供应商的名称标识。应质疑来自特定提供商的专门标记的数据流、系统、传输和软件。理想情况下，即使出于某种原因必须使用单个提供者（请记住我们的论点，永远不应该出现这种情况），也应该删除提供者的名称。您只是不想让任何提供商相信您已经选择了其解决方案，或者您在谈判中妨碍了自己。 Technology agnosticism is as much about culture as it is a process or principle dur-ing design. Engineers and administrators tend to be very biased toward specific pro-gramming languages, operating systems, databases, and networking devices. Thisbias is very often a result of past experiences and familiarity. An engineer who knowsC+ + better than Java, for instance, is obviously going to be biased toward developingsomething within C++ . An engineer who understands and has worked with Cisconetworking equipment her entire career is obviously going to prefer Cisco over acompetitor. This bias is simply human nature, and it is difficult to overcome. As such,it is imperative that the engineers and architects understand the reasons for agnosti-cism. Bright, talented, and motivated individuals who understand the causalitybetween agnosticism and the maximization of flexibility within scalability and themaximization of shareholder wealth will ultimately begin parroting the need foragnosticism. 技术不可知论既涉及文化，也涉及设计过程中的过程或原则。工程师和管理员往往非常偏向于特定的编程语言、操作系统、数据库和网络设备。这种偏见通常是由于过去的经验和熟悉程度造成的。例如，一位对 C+ + 比 Java 更了解的工程师显然会偏向于使用 C+ + 开发某些东西。一位了解并在整个职业生涯中使用思科网络设备的工程师显然会更喜欢思科而不是竞争对手。这种偏见是人性的本质，很难克服。因此，工程师和建筑师必须了解不可知论的原因。聪明、有才华、积极进取的人，如果了解不可知论与可扩展性中灵活性最大化以及股东财富最大化之间的因果关系，最终将开始重复对不可知论的需求。 ####Conclusion 结论 This chapter made the case for technology agnostic design and architecture. Technol-ogy agnostic design (TAD) lowers cost, decreases risk, and increases both scalabilityand availability. If implemented properly, TAD complements a build versus buy deci-sion process. 本章阐述了技术无关的设计和架构。与技术无关的设计 (TAD) 可以降低成本、降低风险并提高可扩展性和可用性。如果实施得当，TAD 可以补充构建与购买决策过程。 TAD is as much of a cultural initiative as it is a process or principle. The biggestbarrier to implementing TAD will likely be the natural biases of the engineers andarchitects for or against certain providers. Ensuring that the organization under-stands the benefits and reasons for TAD will help overcome these biases. Review thesection in Chapter 4, Leadership 101, covering the causal roadmap to success. TAD 既是一项文化举措，也是一项流程或原则。实施 TAD 的最大障碍可能是工程师和架构师对某些提供商的天然偏见。确保组织了解 TAD 的好处和原因将有助于克服这些偏见。回顾第 4 章“领导力 101”中的部分，其中涵盖了成功的因果路线图。 #####Key Points 关键点 * The most scalable architectures are not implementations and should not bedescribed as implementations. Vendors, brand names, or open source identifica-tions should be avoided in describing architectures as these are descriptions ofimplementations. * 最可扩展的架构不是实现，也不应该被描述为实现。在描述架构时应避免使用供应商、品牌名称或开源标识，因为这些是对实现的描述。 * TAD and TAA reduce cost by increasing the number of options and competitorswithin a competitive selection process. * TAD 和 TAA 通过在竞争性选择过程中增加选项和竞争对手的数量来降低成本。 * TAD and TAA reduce risk by lowering switching costs and increasing the speedwith which providers or solutions can be replaced in the event of intellectualproperty issues or issues associated with business viability of your providers. * TAD 和 TAA 通过降低转换成本并提高在出现知识产权问题或与提供商的业务可行性相关的问题时更换提供商或解决方案的速度来降低风险。 * TAD and TAA increase scalability through the reduction of cost to scale and thereduction of risk associated with scale. Where technology solutions are likely toconverge, TAD and TAA can help you achieve rapid and cost-effective scale bybuying rather than building a solution yourself. * TAD 和 TAA 通过降低规模成本和与规模相关的风险来提高可扩展性。在技术解决方案可能融合的地方，TAD 和 TAA 可以帮助您通过购买而不是自行构建解决方案来实现快速且经济高效的扩展。 * TAD and TAA increase availability by allowing you to select the highest qualityprovider and the provider with the best availability at any point in time. * TAD 和 TAA 允许您随时选择最高质量的提供商和可用性最佳的提供商，从而提高可用性。 * TAD and TAA are as much cultural initiatives as they are processes or princi-ples. To effectively implement them, you need to overcome the natural humanbias for and against technologies with which we are more or less conversant,respectively. * TAD 和 TAA 既是流程或原则，也是文化举措。为了有效地实施它们，您需要克服人类对我们或多或少熟悉的技术的自然偏见。
没有评论