当组织开始他们的云应用之旅时，他们很快发现有很多事情可能出错。这些因素可能包括遗留的运营模式、过时的流程和组织对变革的抵制。
我们今天的嘉宾，德勤咨询公司总经理迈克·卡维斯，关注的是数字变革的人类方面，而不是技术。他和戴维·布朗关于确保顺利过渡到云所需的组织心态。
成绩单
凯文·蒙塔尔博今天，我们从澳大利亚来到这里托罗云首席执行官兼创始人兼鸡尾酒联席主持人大卫·布朗。
我们今天的嘉宾是“云架构：云计算服务模型的设计决策“和即将出版的书”加速云采纳：优化企业的速度和敏捷性“我们今天要谈的是这个问题。作为云计算的先驱，我们的客人也被列为世界上排名前100位的云专家和影响者之一。
他目前是德勤咨询公司(DeloitteConsulting LLP)云实践公司的首席云架构师，负责帮助客户实施云战略和架构，推动数字转换。除了他的技术经验之外，他还对如何应对与数字变革相关的组织变革、流程改进和人才管理挑战带来了深刻的理解。
和我们一起喝一杯鸡尾酒的是迈克·卡维斯。迈克欢迎来到节目。
迈克·卡维斯嘿，谢谢你邀请我！
公里在您的书中，您说过要成功地采用云，您需要考虑人员、流程和技术。在考虑与云相关的项目时，我们经常关注等式的技术方面。您能详细说明与人员和流程相关的考虑因素吗？
MK是的，这就是我写这本书的原因，因为我的第一本书是关于技术的，因为当我开始研究云的时候，它是2007年，2008年，没有书，我很难学到很多东西。
所以，我说下一个人不应该犯我所有的错误。这是我学到的。然后，由于我仍然是这个人在咨询，我开始看到所有这些公司的斗争。他们拥有世界上最聪明的人，但他们只是无法将足够的东西带入云端。他们永远不能关掉那些旧东西。
我一直看到的模式是遗留的过程、遗留的组织结构、遗留工具，它们阻止他们以他们想要的速度以最快的速度移动到云上。一个经常的例子是，很多公司都把注意力集中在CI/CD上。因此，我们的客户有一个很好的自动化管道，但有三个月的过程，他们才能按下按钮，创建它上舞台。还有三个月的时间才能把它投入生产，因为我们仍然有这些筒仓必须完成所有这些批准，尽管我们在CI/CD管道中实现了全部自动化。这就是一个例子。然后，当涉及到运行系统时，我们尝试以我们一直使用的方式运行它，这里的单独组对我们的云实现一无所知。
突然间，当出现事故时，我们的可靠性就会下降，因为我们试图使用那些在云中不能工作的工具，以及那些为在大型机上半年发布而构建的过程，而不是每天在云中发布的程序。所以，你知道，很多时候我们的关注点仅仅是技术，但是我们需要改变运营模式的支持组织结构和支持业务流程的速度，就像我们正在向技术转变一样。
戴维·布朗：你提到了这些CI/DC管道，我认为这是很多人开始的地方。成为一个敏捷的组织就是专注于构建过程。远不止这些。很多人已经解决了这个问题。它们有某种构建过程，但当我们谈到云的采用和数字转换时。我们说的远不止这些，对吧？
MK很多事情都是纯粹的心态。传统上，我们是在组织技术筒仓。当我想完成工作时，我需要与数据库团队、服务器团队、存储团队或网络团队进行交谈。当你移动到云端时，很多东西都被抽象到了它的代码中，所以我们把这些管道都放好了。问题是我们仍然需要得到服务器团队、存储团队、网络团队的批准。也有人担心这片云只是一个大而不安全的地方。现实是用正确的严谨，它实际上可以比你所拥有的更安全的前提。问题是有很多古老的想法。我使用的另一个例子是，很多人认为云是其他人的数据中心。每当你听到有人说‘云是别人的数据中心’，他们就会走向失败。这意味着你要像对待数据中心一样对待云，‘我这里有VM，那里有VM。’云远不止这些。
云中的值是当您开始在堆栈上移动时。您使用数据库作为服务器。现在，您突然拥有了一个完全管理的数据库，该数据库自动缩放处理区域和区域。我可以使用队列作为服务，而不是实现自己的Kafka队列。我不需要担心扩展，管理这些第三方解决方案。那条食物链的价值正在上升。云供应商现在甚至正在创建医疗API、金融API，甚至把堆栈提升到业务服务作为服务。当您被允许这样提升堆栈时，您交付软件的速度是难以置信的，您所关注的是您的特定需求，而不是所有的管道和商品化业务流程。
达布据我所知，您的基本前提是云技术提供了这种灵活性和速度。你可以利用这些服务。许多组织正在采用这种新的模式，即在一个大的组织内，他们的旧的官僚程序。
MK：：当然。比那更糟。无论您的进程在数据中心中有多好或多糟糕，它们都是已知的。当有问题时，无论好公司或坏公司解决问题，都有部落知识，他们会想出办法来解决这个问题。然后你移动到云中这个空白的画布上，人们所做的就是专注于构建软件，但是后来有些东西中断了。首先，那些旧流程不适用了，因为已经没有物理基础设施了。所以我经常看到的是可靠性下降了，因为它们从未考虑过你如何应对世界上的事件，因为在这个世界上，有一半的东西是从你那里抽象出来的。你经常看到，你看到这些公司回到数据中心。这并不是因为云没有任何好处，而是因为他们的云方法造成了很多失败。
达布：我想显而易见的问题是，他们应该如何接近云的采用？他们怎么能克服这一点？当你谈论一个大的组织时，分解过程是说起来容易做起来难，这些过程是有原因的，随着时间的推移。这是一个大型组织如何成为香肠机，因为他们有这些过程到位。在考虑采用云技术时，如何分解这些过程，使其成为一个更敏捷的组织？
MK：在纸上写东西很容易，但实际上很难做到。有很多方法和过程可以用来分析过程，找出废物在哪里，并将其移除。但是，如果你不能让每个人都在谈论这个问题，因为他们坚持自己的地盘，或者即使你说，这个过程中有60%的浪费，为什么你不把这个团队转移到这个团队，创建这个云运营团队，但这涉及到政治问题。很容易推荐识别和重新设计浪费的方法。但很难打破政治障碍，改变智者的心态。在这本书中，我给出了很多例子，说明两家公司都应用了不起作用的东西和应用了有用的东西的公司。我并没有真正的答案，那颗神奇的子弹在里面，但我所做的是创造意识。在我的经验中，这些东西比这些方法更有效。
其中很大一部分是运营模式。Adrian Cockroft如果你知道来自Netflix的Adrian总是说DevOps是一个组织变化。他说，几年前云是一个更大的组织变化。我们为什么这么说？因为我们构建的软件和以前完全不同。再把领域专家团队、服务器团队、存储团队、网络团队放在一起是没有意义的，因为所有这些东西现在都是以API的方式出现的。现在我们需要的是存储人员的大脑，网络用户和我们一起坐在一个房间里，帮助架构虚拟私有云，找出正确的存储单元是什么。我们不再需要他们转动螺丝刀和修补设备了。我们可能比以往任何时候都更需要这些人，但我们需要他们的工程头脑，而不是他们的管理头脑。当他们在筒仓里的时候，我每天都在送货上门，我不能发罚单，不能举行会议，也不能在软件部署的一天内这样做。
你真的必须改变事情，它必须更多的合作，更多的参与。我们真的建议团队更专注，更面向产品。您仍然可以拥有您的卓越中心，但您从那里撤出，您有安全工程师在您的产品。这样的话，你不需要58次会议，你有一个拥有这种专业知识的人，当他们需要得到答案时，他们可以回到安全墙，但你在那里有一个拥有共同目标的完整团队。这些共同的目标是产品的目标。这就是行得通的公式。说起来真的很容易，要想改变公司的意志和灵魂，让他们这样做是非常困难的。
达布：我们最近在单片应用程序设计和微服务之间的区别中谈到了这一点。如何使用单块应用程序设计，您往往有前端开发人员、服务层、数据库、安全工程师等等。就像你说的，它们都是不同的学科。在整体设计中，这是可行的。你说的是很长一段时间，在这些工程团队之间可以方便地进行沟通。但在微观服务领域，更好的方法是将这些团队围绕知识领域或产品知识领域整合到一个团队中。
如果您正在为购物车构建服务，那么您就有了购物车团队。每个人都在这个知识领域进行合作。问题是，该团队如何与其他团队协作？虽然他们可以在团队中拥有敏捷性，但他们仍然需要与其他涉众协作。其他涉众依赖于他们创建的服务。你是如何看待这种交流的？
MK如果你看看亚马逊做了什么，亚马逊提供了所有这些服务器。这些团队中的每一个都是一个具有自己文化的产品团队，因此唯一的要求是接口是相同的，API接口。他们可以随心所欲地解决这个问题，而且他们有一种合作的文化。在公司内部，这要困难得多，因为他们不习惯这样运作。
如果您采用这种方法并获得标准的API接口，您可能无法拥有一些独角兽公司的协作水平，但您可以在交付的服务中做到某种程度的自给自足。如果它是松散耦合的，您可以提供该服务。在一天结束时，它可能不会让客户满意，因为他们需要这些其他的东西，但至少您可以交付您的团队所期望的东西。这可以追溯到运营模式，如果每个人都在筒仓里，就很难让他们沟通。如果我正在构建一个产品，我想要的要么是配置，不是每个人的虚拟，但我想建立一个方式，人们可以满足虚拟或实时，他们的一天是专注于朝着相同的产品目标前进。
这是一个文化问题，但我想在你所画的一边倒的故事中再加上一件事。我是这件事的受害者和罪犯，很多次都是因为我们在那些地窖里，数据库团队，他们支持很多团队。很多时候他们不能满足我的需要。有时，我解决了他们应该在数据库、UI层或中间层解决的问题。我绕开瓶颈。单石虽然坚硬，但却变成了拖车式的公园建筑。你不会总是做正确的事情，你会做那些能帮你走出家门的事情。围绕瓶颈编写代码–您只需获得这个意大利面体系结构，每个版本都更具有技术性。
在微观服务方面，你可以很快地进入老鼠洞。MicroServices是很棒的，但是您如何管理100个微服务，特别是当3个团队在错误的粒度级别上编写时。可能会变得一团糟。我见过蜘蛛移植的微型服务，就像有人用蜡笔画画睡着了一样。你是怎么处理这一切的？MicroServices也会带来挑战，它们需要新的工具、流程和新的监控方式。你开始得到类似人工智能行动之类的东西。人类不能同时处理250个微服务。我们需要研究新的行动方式。没有容易的票。
达布：我想整体方法也有一些效率。当你有一个数据库团队时，它被许多不同的项目团队所需要，因此他们的资源由他们的IT经理根据优先级分配，或者谁的声音最大。至少这些资源正在得到有效的利用，您知道它们一直在以最大的容量运行。
我们所说的是将他们分解成独立的团队，致力于单一的产品或知识领域。听起来更多的人。现在，每个产品都有数据库工程师，那么，我们是否存在这样一种危险：在过去的高效模型中，我们仅仅是在增加成本支出，这几乎是一种资本主义的方法，用来处理投资回报率最高的项目，而不是在多个产品领域复制我们的团队吗？
MK：我不认为非常忙和非常有效率之间的区别，是的，数据库团队很忙，通常情况下没有效率。你不需要更多的人来做微型服务，你只是在提供小批量的服务。实际上，您正在更频繁地交付，并且希望，如果您有一个架构远景，您将继承您在前几个版本中所做的工作，所以您不会一直从头开始创建。
如果每个版本都具有良好的体系结构，则可以开始使用所有其他服务。回到单块模型，随着每次发布，您的体系结构通常会变得更糟，就像我说的，人们正在绕过瓶颈。当我在一家大公司工作时，另一个重要的问题是，不管我的业务问题是什么，Oracle是OLTP的答案，而Netezza是事务性数据的答案。
如果我需要一个文档存储数据库，我必须将其与这两个数据库中的一个连接起来。我没有这些选择，因为你必须做一个通常比我的项目更长的采购过程，做一个RFP和一个评估，然后我们必须雇用能够做到这一点的PDA。现在它是一个API调用，我不需要偏离到MOGIO数据库，因为它是一个API调用。现在，我可以构建架构，为工作选择合适的工具，而不是像以前那样把所有的东西都推到工作中去。那些甲骨文的人很忙，但这不是最有效率的工作，因为我们做了糟糕的技术选择。
达布：我想这导致了组织单位现在可以独立地采用软件或云平台的敏捷性。因此，过去管理采购、部署过程的集中式IT部门已经失去了对影子IT概念的控制。
MK：这有好的也有坏的。很多书都谈到了这些类型的运营模式。它讨论了联邦与中央集权和分权。我进去说它的优点和缺点是什么。分散模型的优点是，我的业务单位控制事情，我可以以我想要的速度前进。没有什么是指令性的。我可以选择我想要的技术。缺点是：如果我不太擅长安全，我会损害公司的声誉。
如果一家公司已经收购了大量的初创公司或潮湿的物业，那么这些公司通常都有如此多的云技能，因为他们出生在云端，所以他们是一个分散的模式，他们试图建立一个联邦模式，并说‘好吧，我们需要集中什么样的服务？’他们通常关注的是‘好吧，我们需要控制操作系统–至少是正确的–创建补丁最多的操作系统，让他们从中吸取教训。
通常，当它是自上而下的时候，它是完全集中的。我们控制一切，以至于你做不到任何事情，因为它只是天空中的另一个数据中心。从这里开始是可以的，因为你不想让每个人都做他们自己的事情，但是在某个时候，随着你的实践的成熟，你开始允许业务部门承担起一些加快行动的责任。我认为最终的，取决于每一家公司，承诺的土地是一种联邦模式，在那里有一些水平，有些东西我们需要集中控制，还有一些东西，你可以在业务部门节省开支。在金融机构，内部控制会少得多。
对于一家媒体公司来说，也许他们唯一想要控制的就是，‘这里是你可以实际使用的CI/CD工具，或者你可以使用这三种工具中的一种，但不是12种。“我们会给你红帽操作系统或Apache Tomcat的蓝图，我们会确保这是修补的，仅此而已。你想做什么就会有什么变化。在另一部分中，我谈到了中心团队的不同参与模式，那就是我可能有一个真正精通网络的团队，不需要我的帮助，他们只需要自助服务能力。但我这里有个新手小组，他们什么都不知道，他们需要白手套服务。我认为这是很多公司都会出错的地方。他们对待每个人都一样，这通常是最低分母的技能，所以有技能的团队，他们无法完成工作，所以影子IT只是诞生和繁荣。
达布：：有意思。让我们谈谈我们未来的处境。我们讨论的是DevOps和CloudOps，你甚至提到了AI操作。它似乎在不断发展，如果你采用的是DevOps，并且认为它们处于领先地位的话。你觉得我们实际在哪里，我们要去哪里？
MK：我想定义什么是DevOps。很多人认为DevOps是CI/CD。这是其中的一部分，但在我看来，如果你和DevOps的教父们交谈，这真的是关于结果，它是关于我们作为一个组织如何能够更好、更快、更可靠、更有效率地交付这些特性。自动化CI/CD管道是更好、更快的工作方式之一，但在构建和自动化CI/CD管道之前，您可能需要重新评估业务流程，否则您只是在自动处理浪费。
所以，你失败得更快，但你还是失败了。我所看到的是一个巨大的挑战，同时也有如此多的变化，这就是为什么你有这些X操作，还有DevOps，然后我们说Dev SEC操作，AI操作，昨天我在播客上–这是我的任务。
这是所有的操作，对，在我看来，技术是不同的，所以它的方法是不同的。这些情况仍然适用，您可能不需要举行过去和喜欢的会议，但您仍然需要服务请求管理，您仍然需要那些东西。只是你可以通过自动化解决很多这些问题。另外一个正在发生的事情是，云是一个分布式环境。我有幸在分布式环境中长大。我总是在零售，商店到处都是，所有的东西都是分发的。我的学习曲线要少得多。这是三层架构中的另一种野兽。我们还有一个担心。维护起来就难多了。
你所看到的是，现在运作的热潮，新的思维方式，你开始听到像可观察性和混沌工程这样的术语，在生产中进行测试。人们不会梦想在旧世界有意识地打破生产中的东西，但是如果我有500个微服务运行在数百个服务器上，有时你在那里，有时你不在那里。人类是如何通过看仪表盘来管理这些的呢？我们需要主动发现系统中的缺陷，并在用户遇到这些问题之前修复它们。我之前提到过，很多人搬到云端，因为系统没有移动，因为这是一种不同的游戏，所以可靠性更差。这对用户不好。我认为，在运营界和那些开始接受这一理念的公司中，有大量的好想法正在发生，即使这是缓慢的，而且不考虑他们今天是如何运作的，我认为我们在云领域会有更多的成功。
AI和ML就是其中之一。人工智能擅长于使人类所做的事情自动化。当你试图监控成千上万的应用程序或容器时，人类不能这样做，所以你让人工智能去做。Ml更适合于发现未知数。找到那些让你以后失败的事情，你不知道，你今天就能解决。虽然我是在应用程序开发中长大的，但我现在的大部分精力都集中在SRE和操作方面，因为我在这方面看到了很多挑战。
达布：在所有这些东西中，我们谈论的是自动化，比如微型服务和容器管理，其中有成百上千个微服务。采用云不是一种选择，而是一种必要的权利。这是你可以在内部现实地做的事情。越来越多的是，在公共云提供商上托管这些东西的云应用是必要的，这当然会导致AI Ops的增值服务来管理这些服务。它是携手并进的，这是微服务和DevOps的编排，以及管理它们的服务。你同意吗？
MK：：我同意在一个领域谈论集装箱。Kubernetes现在是首选的编排引擎，但是人们希望在Kubernetes周围转一转，而这些云服务提供商将Kubernetes作为一种服务。人们花费在云不可知论者身上的能量是相当惊人的。你一定要问这个问题。可移植性是什么意思？人们为了成为云不可知论者而努力工作，他们没有从云中获得任何价值，因为云计算只是一种计算，一种可以工作的存储。
每当我们开始谈论云的功能时，我认为它能够卸载管道，它不仅仅是基础设施–不仅仅是中间件层，甚至是业务层。这是价值所在，AI操作和ML。几年前，我在一家富有的营销公司工作，我们曾经提取大量的数据，然后把它扔到SaaS数据集中，而这些数据科学家，SaaS天才会做所有这些分析，他们会对他们所知道的事情提出假设，六个月后，我们会有一种新的方法来定位购物者，或者我们会有新的方法来分析购物后的旅行。
今天，它是一个API，你可以得到一个模型。我有一个团队提供了所有的分析。如果你要购物，这是下一件你要买的东西，所以我们会把这张优惠券拿出来，等你去买。去亚马逊或谷歌，就会有一个API。我有一个团队，8，9个人，大量的服务器，现在这是一个API调用。云的价值就在那里，你去拿吧。
达布：：使用ML和AI的服务，这在很大程度上是由于公共云提供商在这些空间中所做的投资而被迫使用的，以便在创建过程中利用API，并且您正在讨论使用API来节省六个月的工程工作。但它也以一种内在的方式起作用，对吧。当我构建应用程序、服务、构建我的数据库并将它们暴露给整个组织的团队时。我还想采用同样的方法，将所有内容都公开为API，这样人们就可以使用我的服务，从它中提取出的价值与您在公共云提供商中使用该ML服务的方式相同。
MK：当然，我开始看到工业界是这样想的。我刚和一家金融机构的首席技术官谈过。他们试图使数据科学的过程自动化。数据科学家有所有的工作要做，这是非数据科学家的工作，这是他们正在创建的模型，他们试图实现自动化，但同时，他们试图创造一个其他公司可以共享模型的环境。你的代码也是一样的。
如果您提供的服务有一个有价值的数据集，那么它不仅有价值将其作为一个API提供给您的公司，而且也可能是您将其货币化并在公司之外提供的机会，或者不是将其货币化，而是将其提供给一个同时向您提供API的社区。我们听说API经济已经很长时间了，我认为它已经开始出现了。我认为那些已经在云端工作了四年、五年、六年的公司在这方面已经相当出色，他们已经开始在这个层面上发展，他们不再考虑基础设施了。他们在考虑数据，他们在想，我们怎么能不写代码，我怎么能用尽可能少的代码来更快地进入市场呢？传统上，我们只喜欢写数百万行代码，但是你写的每一行代码都会让你觉得很好。
达布：我很想开始谈论低代码应用程序开发，但我认为这是一个完全不同的播客。迈克，这是一次很棒的谈话。非常感谢你的时间，人们如何才能更多地了解你和你即将出版的书？
MK：我在推特上，疯婆子65，我的女儿，我给你讲一个简单的故事。我女儿是市场营销专业的。她在一天内建立了我的网站，她不知道服务器是什么。谈论抽象。她在使用平台，在内容上很有天赋。如果你去mikekavis.com，有一个关于我的书的网站，一堆博客，还有我的播客。她在一天内创造了它。有一次我们在谈论服务器，服务器是什么？她不需要知道什么是服务器，我们在构建这些东西时应该考虑这个问题。我可以在不太了解物联网的情况下进行物联网，只需使用API，不管怎样，这是一个漫长的告别。
公里非常感谢迈克和我们在一起。对于我们的听众来说，你觉得这个播客怎么样？你是否经历过迁移到云的经历？你有什么云成功或云恐怖故事想要分享吗？让我们知道，在评论，从任何播客平台，你正在听。此外，请访问我们的网站www.toroCloud.com，了解我们的博客和产品。我们还在社交媒体，Facebook，LinkedIn，YouTube，Twitter和Instagram上。在那里跟我们谈谈，我们会听的，去找托罗·克劳德。
福州小程序开发有多少家？
再次感谢您今天的收听。这是迈克·卡维斯, 戴维·布朗，凯文·蒙塔尔博为你效劳鸡尾酒编码.
