在我们有关云原生计算的系列文章中，TheServerSide与该领域的许多专家进行了交谈，包括云原生计算基金会的许多成员。 以下是Cameron McKenzie和Apprenda的Sinclair Schuller之间的采访记录。
Apprenda的Sinclair Schuller访谈
您如何定义云原生计算 ？
卡梅隆·麦肯齐（Cameron McKenzie）：在服务端寻求更多了解传统企业Java开发如何与使用微服务，Docker，容器和Kubernetes的云原生计算新世界相适应的过程中，我们跟踪了Sinclair Schuller。 Sinclair Schuller是Apprenda的首席执行官。 他还是Kubernetes的拥护者，并且还是Cloud Native Computing Foundation的董事会成员。
因此，我们想从Sinclair那里了解的第一件事是，您如何定义云原生计算？
辛克莱·舒勒（Sinclair Schuller）：好的问题。 我想我会给您一个根深蒂固的定义。 对我而言，云本机应用程序是具有隐式或显式功能来行使其赖以生存的弹性资源的应用程序，并且具有一定程度的可移植性，可以轻松地在各种情况下运行，无论是在云A还是在云A上。云B或云C。但是在每种情况下，它以弹性方式理解和/或使用基础资源的能力可能是我要使用的最基本的定义。 这与可能部署在服务器上的传统非云本机应用程序不同。 那些人不知道其下面的资源是可替换的还是弹性的，因此它们永远无法利用这些基础架构属性。 这就是使它们天生就不可扩展，天生就没有弹性等的原因。
卡梅隆·麦肯齐（Cameron McKenzie）：现在，关于应用程序服务器如何崩溃的讨论很多，但是每当我看到人们为管理容器和微服务而创建的这些环境时，他们都会将所有这些工具整合在一起来进行诸如监控之类的工作。以及日志记录和编排。 最终，所有这些将导致出现某种仪表板，使人们可以了解其云原生体系结构中正在发生的事情。 我的意思是，应用服务器真的死了，还是只是重新定义应用服务器是什么？
辛克莱·舒勒（Sinclair Schuller）：我认为您确实很满意 。 我认为，不幸的是，在整个应用服务器上，死气沉沉的后果是低俗的营销活动，新供应商试图重新定位旧供应商。 公平，对吗？ 这些事情就是这样，但即使是旧的应用程序服务器死了也没有。 在许多情况下，他们仍会将应用程序部署到容器中的Tomcat等应用程序中。 因此，即使您正在构建新的微服务，这种情况本身也不会消失。
传统的重量级应用服务器已经消失了吗？ 是。 所以我认为这已不受欢迎。 以像WebLogic之类的旧产品或类似的产品，您将不再看到它们在新的云原生开发中使用。 但是您是对的，接下来会发生什么，我们肯定会看到这种情况，有一系列相当松散耦合的工具开始围绕新模型，在这方面看起来很像是应用服务器。
这是我不同意您的地方：我不知道是否会进行合并。 但是可以肯定的是，如果有的话，那么最终您会得到一家供应商，该供应商拥有所有可以有效交付云原生应用服务器的工具。 如果没有整合，并且该工具保持相当松散的耦合和分散状态，那么与传统的应用服务器模型相比，我们的结果会稍微好一些。 我们有能力按我们需要的方式最好地制作零碎工具。
云原生计算和UI开发
Cameron McKenzie：许多开发人员和架构师都在问的一件事是：“ UI在云原生计算世界中的作用是什么？” 它是否仅由诸如Angular UI的前端JavaScript框架开发？ 它实际上是嵌入到部署到容器的应用程序内部的吗？ 就云原生开发而言，UI开发空间实际上发生了什么？
辛克莱·舒勒（Sinclair Schuller）：我认为在某种程度上，UI之战已经赢了，可以这么说吗？ 似乎市场已经决定使用JavaScript和Angular之类的库来为这些后端服务建立有效的前端。 我想那边不再有太多的动荡或争议，这就是为什么您对此了解不多的原因。 事情的后端有些滞后，现在有容器进来了，并且正在发生革命。 因此，我认为后端服务和容器所发生的事情与JavaScript所发生的事情非常相似，例如十年前，JavaScript才真正开始流行。 因此，我认为JavaScript和HTML5所扮演的角色已经很好地定义了，我们不会在那里看到很多变化。
Cameron McKenzie：我可以开发一个“ hello world”应用程序。 我可以将其写为微服务。 我可以将其打包在Docker容器中，也可以将其部署到某种托管环境中。 我无法做的是，我无法进入航空公司制造商的数据中心并分解其整体，将其转变为微服务，弄清楚哪些应该是粗粒度微服务，并找出哪些应该是细粒度微服务。 。 我不知道最终应该使用多少个微服务，一旦完成所有这些工作，我将不知道如何协调生产中的所有微服务。
Apprenda在推进云原生计算方面的作用
你是怎样做的？ 组织如何采用这种云原生架构以及这种云原生基础架构和规模？
辛克莱·舒勒（Sinclair Schuller）：是的，所以您实际上只是在描述我们的业务。 实际上，我们在市场上注意到的是，如果您采用围绕这些单一应用程序构建的全球最大公司，它们将面临“我们如何分解它们，如何将信息传递到现代时代”的挑战？ 而且，如果我们当然可以某些应用程序不需要它，那么我们至少应该如何在云环境中以更好的方式运行它们，以便获得更高的效率，对吗？”
因此，我们专注于为云原生平台提供一个平台，并确保在缺乏更好术语的情况下，它提供错误桥接功能。 现在，在Apprenda中，通过我们的构建方式，我们的IP将允许您在平台上运行一个整体，我们实际上将对应用程序中的更改进行检测并使其行为有所不同，以便它可以在基于云的基础架构环境中很好地运行，如果可以的话，为该整体提供一些云架构元素。
现在，为什么这很重要？ 如果您能够做到这一点，并且可以Swift将一堆这样的应用程序欢迎到这样的云原生平台上，并消除了突然的要求，那就是您必须更改整体并将其快速分解为谁知道多少微服务？稍稍有些懈怠，因此这些企业中的开发团队可以更周全地考虑该决定。 他们可以选择整体的一部分，进行拆分，将其用作实际的纯微服务，并且仍然可以在同一平台上运行并与整体剩余部分一起工作。
通过这样做，我们实际上鼓励企业加速采用云原生架构，因为它不是如此突然的必需决策，也不是对架构本身的如此突然的改变。 因此，对于我们来说，我们对这一步骤充满热情。 其次，这就是我如何一次管理大量这些？ 在我看来，像Apprenda这样的良好云抽象是基于Kubernetes的良好平台，其目标是使管理10、1,000或N个微服务的运行和运行1或2一样容易。
而且，如果您能够做到这一点，并且可以将运行1或2的MO转换为仅运行大量微服务的MO，则可以从等式中消除该成本，并使企业更容易消化整个问题。 因此，我们确实非常重视这两件事。 我们如何提供这种桥接功能，这样您就不必进行如此突然的转换，而您可以在一个更舒适，更适合您所需的时间轴上进行转换，并解决规模问题？
最终，解决规模问题的唯一方法是，云平台必须真正提取底层基础结构资源，并充当微服务层和那些基础结构资源之间的代理。 如果能够做到这一点，那么扩展的规模实际上就变得微不足道了，因为平台架构得当。
Cameron McKenzie：现在，您谈到了抽象。 您能否谈谈抽象出该层的技术方面？
辛克莱·舒勒（Sinclair Schuller）：是的，绝对如此。 所以有几件事。 一种是如果要抽象资源，通常需要找到一些层，以便您可以从堆栈中投影出新的标准或新类型的资源配置文件。 现在，我的意思是什么？ 让我们以容器为例。
通常，我会拥有基础架构的刚性结构，例如该VM或该计算机具有如此大的内存。 它具有一个OS实例。 它具有这种特定的网络布局，现在，如果我想对其进行抽象，我需要提出一个模型，该模型可以位于该模型之上，并为您提供具有某种有意义容量的该应用程序，并以一种不再专门与该基础架构绑定。 因此，容器会解决这个问题，我们大家现在都已经知道了。
但是，让我们看一下子系统。 假设我正在构建一个应用程序，我们将从一个非常琐碎的应用程序开始。 我有类似日志记录的内容，对吗？ 我的应用程序将数据记录到磁盘，通常将某些内容转储到某个位置的文件中。 如果我已经有一个已有的应用程序正在执行此操作，则可能是将大量日志信息写入单个文件中。 而且，如果我在50个基础结构实例中拥有50个应用程序副本，则现在在基础结构中有50个日志文件，它们知道哪里。 作为开发人员，如果我想调试我的应用程序，我必须去找到所有这些。
使用Apprenda，我们专注于做类似的事情，“嗯，我们如何抽象该特定子系统？ 我们如何才能以一种实际上允许我们捕获日志信息并将其路由到类似分散式存储之类的方式干预日志记录过程的方法，该方法可以聚合日志并让您稍后解析它们？ 因此，对于我们来说，每当我们考虑将其作为一个实际问题考虑时，它就是在确定应用程序体系结构中的子系统（例如日志记录）（例如计算消耗），这些容器由容器负责（例如身份管理），并实际上拦截和增强这些功能，以便可以以更细粒度和更实惠的方式处理它。
为云计算故障做准备
卡梅伦·麦肯齐（Cameron McKenzie）：今年早些时候，我们看到了切尔诺贝利式的Amazon S3云崩溃，而且它几乎可以带走互联网。 您向客户提供什么类型的建议，以确保客户的云提供商失败，以确保其应用程序不会完全失效？
辛克莱·舒勒（Sinclair Schuller）：我认为其中的第一部分是从文化上了解真正的云，并确保所有员工和架构师都知道云的含义。 在许多情况下，我们认为云是某种意义上的模糊和分散的事物。 云实际上是非常集中的东西，对吗？ 我们将资源集中在少数大型提供商（如Amazon）中。
这是什么意思？ 好吧，如果您依靠像Amazon这样的供应商来通过S3之类的产品进行存储，您可以想象该公司或该基础设施可能会发生某些事情，从而导致该功能不可用，对吗？ 相反，我认为发生的事情是文化上的人们开始相信，云是万无一失的，它具有5-9和9-9s，可以选择所需的任何SL，并且他们依靠它作为保证可用性的专有手段。 。
因此，我认为第一，这只是在鼓励一种文化，即了解在云上构建时，您正在建立某种集中式功能，某种集中式功能，并且这种功能仍然可能会失败。 一旦您将其发现并得到人们的理解，那么下一个问题便是：“我该如何解决？” 我们已经在计算中做过很多次了。 为了解决这个问题，您必须提出一种可以正确处理数据分离和失败之类的架构模式，对吗？
那么，我是否可以构建一个可能使用S3并潜在地跨Azure或S3中多个区域的数据罢工的应用程序体系结构？ 因此，如果您认为如果心态像S3那样可能会失败，那么您会突然将这种担忧推到应用程序架构本身中，这确实要求开发人员开始以这种方式思考，他们说：“是的，我“将开始跨多个提供商或多个区域对数据条带化。” 这就摆脱了这种情况。
我认为我们看到S3失败并影响许多不同属性的部分原因是人们没有那样想，他们看到了SLA中的9位数，并说：“哦，我会很好的， ”，但事实并非如此。 因此，您必须在应用程序体系结构本身中考虑这一点。
卡梅隆·麦肯齐（Cameron McKenzie）：阿普伦达（Apprenda）在Kubernetes领域既是领导者又是倡导者。 Kubernetes当前在协调Docker容器和云原生架构的世界中扮演什么角色？
辛克莱·舒勒（Sinclair Schuller）：因此，当我们观察集装箱周围的世界时，有几件事变得非常清楚。 容器的配置，调度，例如确保我们可以进行容器放置，这些都成为人们关心的重要事情，并且某些项目（例如Docker Swarm和Kubernetes）在发展，并且以一种通用的方式与之竞争。
因此，当我们将像Kubernetes这样的东西作为我们架构的一部分时，我们的目标是确保我们正在选择一个项目，并与一个我们认为对计划，编排等项目具有最佳基础原语的项目进行合作。 如果我们能够做到这一点，那么我们可以研究围绕该问题的关注点，并在应用程序堆栈中向上移动以提供附加价值。
现在，在我们的案例中，通过采用Kubernetes作为所有云本机工作负载的核心调度程序，我们接着进行了研究，并说：“那么，作为一家公司，我们的使命是什么？” 将云带入企业，对吗？ 还是去企业。 Kubernetes与该任务之间有什么差距？ 差距在于处理现有应用程序，处理Windows之类的东西，因为那不是Kubernetes固有的东西。 我们说：“我们是否可以在Kubernetes上构建IP或附加IP，以解决世界上最大的公司迁移到云计算时存在的关键问题？”
因此，对于我们来说，我们走了两条非常具体的道路。 首先，我们利用了我们在Windows方面的专业知识，并在Kubernetes中建立了Windows容器和Windows笔记支持，并将其回馈给社区，我希望不久以后就能投入生产。 第二，我们用一堆IP围绕Kubernetes，IP致力于处理整体问题，并将整体分解为微服务，并使它们在云原生平台上运行。 因此，对于我们来说，它正在将Kubernetes的愿景扩展到容器编排，容器调度和放置之外，并在平台支持以及与云原生并行运行和支持现有应用程序的能力方面应对那些非常具体的架构挑战。
卡梅隆·麦肯齐（Cameron McKenzie）：要进一步了解Sinclair对云原生计算的现状，可以在Twitter @sschuller上关注他。 您也可以关注Apprenda ，如果您想查找有关云原生计算的更多信息，可以随时访问Cloud Native Computing Foundation的网站cncf.io。
您可以在Twitter上关注Cameron McKenzie： @cameronmcnz
180
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
