提高开发速度
运维操作的最佳实践自动化
这两个要求推动了大多数软件平台的投资。真的，这两项可以作为自动化任何事情的检验标准。所以，没有一个平台对于任何用户来说是完美的，那么是否意味着我们要自己写呢？如果自己写，是否建立在一个现有的平台之上？您想要一个从上到下的紧密集成的平台，还是想要使用强大的扩展点松散连接的多层平台？这些都是一时间难以回答的问题，并没有一个真正适合每个人的单一答案。寻找合适平台的成就感是发现，比较和权衡之一。所以我们一起来吧！平台之美云平台的“彩虹”，总有您喜欢的色彩。每个厂商都会告诉你，他们的软件是特别的，甚至是独一无二的。他们都在努力区分产品，以提供不可替代的价值。但是，如果您仔细观察，并容忍一些粗糙的边缘，您可以根据它们提供的接口类型对这些产品进行分组。云平台例子软件平台术语“软件即服务”一词最早可追溯到年左右，指的是将打包的软件产品和支持服务捆绑在托管解决方案中，以避免经常未知的执行和操作成本。一个SaaS产品本身就是一个基础上的平台。术语描述的一些原始用途取代了传统企业资源计划（ERP）和客户关系管理（CRM）平台。像Salesforce和SAP这样的公司，对于那些没有大型工程师团队或IT部门来构建和管理这些复杂的系统客户，他们会在这些领域非常成功。即使是拥有这些资源的公司也可能认为这些事情不在其核心竞争力范围之内，不值得自己去建设或经营。如今几乎所有类别的软件都可以通过SaaS获得，从电子邮件到文字处理系统，再到内容管理系统比比皆是。Spectrum的另一端是基础设施即服务。将应用程序配置到基础架构平台上基础设施平台基础设施平台在SaaS之后不久就出现了。VMwareGSXServer（）和亚马逊弹性计算云（EC2，）提供了早期的虚拟化平台。然而，VMWare最初专注在企业内部部署，亚马逊web服务则将其托管的IaaS和SaaS产品结合，定位于更广阔的市场。后来，Rackspace和美国航天局开发了OpenStack（）作为VMwarevSphere（年发布，取代GSX）和亚马逊EC2的开源竞争对手。这些IaaS主要提供了一些具体的抽象：虚拟机计算节点，软件定义的网络和可挂载的存储。在有SaaS的情况下，托管的IaaS的主要卖点是外部资源容量配置操作的自动化，但与SaaS不同，托管的IaaS会给用户带来资源规模无限大的错觉。对于大多数对基础设施外包感兴趣的公司来说，AWS会提供比客户以往任何时候资源需求量大得多的资源，在您向AWS寻求更多节点之前，已经扩展了数据中心。对于无法或者不愿意外包的公司，像OpenStack和vSphere这样的基础设施平台可以在您选择的数据中心中托管自己的云。然而，管理不仅仅只是涉及硬件，还包括管理一个基础设施平台，并且这需要更多的工作，这是企业公司已经在自己的平台上做过的。无论是手动管理没有虚拟化层的硬件，还是渴望使配置更加自助化。因此，X即服务模式是圆满的：托管的平台成为了打包的产品，此次增加的多租户功能，允许客户自己的内部用户群体进行操作。随之而来的应用平台。基础设施平台上的应用平台应用平台Fotango的Zimki（）和Heroku（）率先使用平台即服务。后来的GoogleAppEngine（），CloudFoundry（）和其他几个加入了战斗。在当时，很明显，这些是真正的应用平台（aPaaS），专门用于加快开发人员的速度并降低运营开销。使得开发人员自己配置和管理他们开发的应用，进一步压缩了从开始到发布到反馈到迭代的周转时间，与日益普及的敏捷软件开发思想相契合，并为刚刚起步的DevOps运动播下种子。但进步永远不会停止。容器平台出现了。基础架构平台上的容器平台容器平台容器化已经比您想象得要深入（FreeBSDJails自年以来一直在使用），但是可以肯定的是直到Docker（）将Linux操作系统级虚拟化与文件系统镜像结合起来，容器化才真正广泛流行起来。这使得构建和部署容器化应用更加容易，这是一种可以理解为通过构建磁盘镜像来加快基础设施平台配置的IaaS用户模式。但与VM相比，同时运行的几台驱动器足以让您的工作站超负荷运行，容器则允许您在本地部署完整的微服务堆栈，大大加快了开发周期。另外，由于降低了开销，每个微服务器都可以拥有自己的容器映像，自己的发布周期和自己的滚动升级，允许更小的团队并行开发它们。从容器运行时到容器平台，这是一个明显的进步。像CloudFoundry这样的应用平台和像ApacheMesos这样的集群资源管理系统自成立以来就一直使用容器隔离。下一步是公开一个平台API，允许开发人员在一组机器上部署越来越受欢迎的Docker镜像。像基础设施平台一样，容器平台也是在内部开始的，后来提供托管服务。Mesosphere的Marathon（）是通用容器编排的首个开源平台之一，但它早期是由内部努力推动的，比如Google的Borg（?）和Twitter的Aurora（年写成，在年开放为ApacheAurora）。容器编排是容器平台的核心。与应用平台一样，容器平台需要提供基于约束的声明性调度。与应用平台不同的是，容器不限于十二要素应用程序。比如，有状态服务需要的持久卷，隔离保证机制，特定域的迁移过程及并行的备份作业等等。由于这种灵活性，容器平台可以轻松地变得比应用程序平台更复杂，以支持更多种类的工作负载。基于计算机集群的容器平台为了增加灵活性，并且在不迁移的情况下支持传统工作负载，许多人在基础设施平台之上运行容器平台，但这并不是绝对必要的。容器与单个机器已经十分接近，几乎所有的工作负载都是兼容的。所以并不是每个人都需要这种灵活性。许多开发人员将他们所有的时间都花在单层的堆栈中。他们寻找避免重复执行任务的办法，例如为他们构建的每个新应用程序手工制作容器镜像。对于这些人来说，功能平台（也称为无服务器）就出现了。基础架构平台上的容器平台，容器平台上的功能平台功能平台亚马逊推出了AWSLambda（），引领了无服务的“热潮”，在其虚拟基础设施平台之上提供轻量级的容器化事件处理。像其他AmazonWebServices一样，Lambda仅仅只是一种托管服务。因此，由Iron.io（），ApacheOpenWhisk（），Fission（），GalacticFog的Gestalt（），OpenLambda（）填补了私有化部署替代品的市场。除了他们各自基于特定语言的框架之外，功能平台的运行方式与应用平台相同。因此，开发人员只需要开发事件处理程序，并使用平台API将触发器映射到该处理程序即可，而不是使用多个端点编写应用程序。功能平台通常与API网关配合或集成，以处理代理，负载均衡和集中式服务发现。与应用平台不同，功能平台透明地集成了基于负载的自动缩放，因为它们控制所有入口点和复用。像容器平台一样，功能平台不一定需要基础架构平台，但与容器平台提供的灵活性不同，功能平台不是设计用于支持各种各样的工作负载。所以仅仅只运行一个功能平台可能是不明智的或不可能的。您可能还需要一个较低级别的容器或基础架构平台。一些功能平台甚至被设计成与容器平台集成，利用中间层自动化来降低较高层的复杂性。云平台，其接口以及抽象的规模平台抽象这些平台中的每一层都提供了自己独特的抽象和API，某些层比其他层更抽象。一些更高层级的平台要么全部采用，要么就全不用。它们具有顶部到底部的集成，但只能支持您要运行的一小部分工作负载。您可能会尝试选择最高层的抽象化来最大限度地提高开发人员的速度，但是您也必须考虑到这些平台上构建的软件将与平台最紧密耦合，当您需要重新选择平台的时候，这将增加您的风险。另一方面，较低级别的平台可以提供最大的灵活性，可以实现最广泛的工作负载，包括Web应用程序，微服务器，过时的整体架构应用，数据管道和数据存储服务。它们使得迁移更轻松和基础设施操作更容易，但是在上面实际开发或运维应用程序，服务或作业却更难。应用平台和基础设施平台之间的冲突是容器平台受欢迎的重要原因之一。容器平台在这两方面作出了妥协。它们允许您根据每个容器来决定您的工作负载是否需要自己的环境，或者可以作为二进制运行，支持更多种类的工作负载。但它们还像应用程序平台一样提供声明式配置，生命周期管理，复制和调度。如果您还需要更高层次的抽象，您可以轻松地在容器平台之上部署更轻量级的应用程序或功能平台，共享具有较低级别工作负载的资源和机器。如果您还需要较低级别的抽象，您可以轻松地在基础设施平台之上部署容器平台，而不是直接使用裸机。DC/OS架构层DC/OS——平台终极选择在Mesosphere，我们的使命就是让它非常容易建立和扩展规模到足以改变世界的技术。这意味着我们不仅仅服务于开发人员，也不仅仅是运营商，而是二者皆有。帮助您实现真正的敏捷性，既需要开发人员的速度和也需要运维人员的灵活性。开发人员希望减少重复工作，自动化的弹性，并建立在强大的平台服务之上。运维人员希望可见性，避免供应商锁定，以及控制成本的能力。因此，我们构建了DC/OS，以提供基于云的服务和开放的合作伙伴生态系统，与基础设施无关的容器平台。通过DC/OS，您可以获得一个坚实的容器平台，加上更高级别服务的目录：数据库，队列，自动化测试，持续交付流水线，日志记录和指标堆栈，弹性扩容及功能平台等。原文链接：