标签 AWS 下的文章

这篇文章针对开发和部署基于 JavaScript 的应用(服务器端的 Node.js 或者客户端)的各种经验水平的开发者,通过本文,你将看到如何把 AWS SDK, Amazon Cognito Identity SDK 嵌入到 JavaScript 中,以及如何使用流行的 webpack 模块打包器。

2016 年 7 月, AWS 推出了 Amazon Cognito 用户库 user pool ,这个新特性极大的方便了开发者在移动和 Web 应用程序上添加注册和登录功能。为了让开发者更容易在自己的应用程序中实现用户库功能,我们也发布了用于 JavaScript 的 Amazon Cognito Identity SDK

Amazon Cognito 用户库可以让你在移动和 Web 应用程序上添加用户注册和登录功能更加容易。全托管用户库可以扩展到数以百万计的用户,你可以在每个 AWS 账户下有多重目录。创建一个用户库只需要几分钟的时间,并且你可以决定当一个新用户在你的应用程序或服务上注册时哪些属性(包括地址、邮箱、电话号码以及自定义属性)是强制的,哪些是可选择的。你的应用程序也可以指定所需的密码强度,指定用户需要进行多因素认证(MFA),以及通过电话号码或者邮件地址来验证新用户,从而进一步加强应用程序的安全性。

如果你是首次接触用于 JavaScript 的 Amazon Cognito Identity SDK,那么请先阅读这篇 AWS 文章作为开始。

为什么在 JavaScript 上使用 Asset 及模块捆绑的 Amazon Cogtito Identity SDK

今天,针对移动和桌面的现代 Web 应用程序都能为用户提供安全、快捷、灵敏以及类本地应用的体验。毫无疑问,现代的浏览器功能足够强大,能够肩负起大量可能的功能实现。许多流行的实现很大程度上依赖于 JavaScript 应用程序通过某种形式的 asset 封装和/或模块捆绑进行部署。这使得许多开发人员能够很好的维护自己的 JavaScript 应用程序,并且可以通过使用 script 标签创建一个或多个可以加载到客户端浏览器上的文件。

关于如何实现打包有许多争鸣,包括 GruntGulp 这样的 task runner,以及 Browserity 这样的打包器。然而,一个普遍的共识是, asset 打包不仅可以改善加载时间 - 它可以在确保可测试性和健壮性的前提下使你的应用程序模块化。

使用带有 Amazon Cognito Identity SDK 的 webpack 打包 JavaScript

我们接到了许多请求,要求我们提供如何在 webpack 环境下整合用于 JavaScript 的 Amazon Cognito Identity SDK 的更多细节。我们特地要求确保 webpack 正确管理一下第三方的依赖包:

通过这些例子,可以看到,下面这些 bower 库都被 bower.json 使用

"aws-cognito-sdk": "https://raw.githubusercontent.com/aws/amazon-cognito-identity-js/master/dist/aws-cognito-sdk.js",
"amazon-cognito-identity": "https://raw.githubusercontent.com/aws/amazon-cognito-identity-js/master/dist/amazon-cognito-identity.min.js",
"sjcl": "https://raw.githubusercontent.com/bitwiseshiftleft/sjcl/master/sjcl.js",
"jsbn": "https://raw.githubusercontent.com/andyperlitch/jsbn/master/index.js",

出于我们前面给出的关于 asset 打包对于开发过程的重要性的原因,除非你的应用程序非常小,否则使用像 webpack 这样的 asset 打包工具几乎总是必须的。当然,还有一个方法是可以通过使用标签简单的处理所有依赖关系。然而,这会污染全局命名空间,而且不能够提供最优的资源管理和加载方式。许多开发者首次使用的是具有标准 babel 加载器的标准 webpack.config.js 文件,像下面展示的这样。

{
  /** test for file ending in js or jsx 
   * exclude node_module and bower_components - we dont want to babel these 
   * use the babel loader 
   * apply the react and es2015 (es6) transformations **/

  test: /\.jsx?$/,
  exclude: /(node_modules|bower_components)/,
  loader: 'babel',
  query: {
    presets: ['react', 'es2015']
  }
}

需要重点记住的是,这个配置没有考虑一些第三方依赖关系,这些被用于 JavaScript 的 Amazon Cognito Identity SDK 所使用的第三方依赖目前没有使用 JavaScript 通用模块定义(UMD)

UMD 模式试图提供与 RequireJSCommonJS 这些当前最流行的脚本加载器的异步模块定义 [AMD] 的基本兼容。

这是 webpack 所依赖的模式,为了让 webpack 能够工作,我们必须进行一些改变。不做这些改变,你可能会遇到下面这些错误。

amazon-cognito-identity.min.js:19 Uncaught ReferenceError: BigInteger is not defined

这样一个错误可能会在调用 AWSCognito.CognitoIdentityServiceProvider.CognitoUser property authenticateUser 的时候出现。在这个错误例子中,我们可以利用 webpack 的 import 和 export 加载器的能力来解决这个错误。

使用 webpack 加载器

根据 [webpack 文档],“加载器允许你通过 require() 或 load 来预处理文件。加载器是一种类似其它构建工具中 “tasks” 的工具,它可以提供一个处理前端构建步骤的强大方法。加载器可以把一个文件从一种语言转化成另一种语言,比如把 CoffeeScript 转化成 JavaScript ,或者把图像转换为 data URL。“

为了解决 UMD 的兼容性缺乏的问题,你必须依赖两个具体的加载器, import 和 export 加载器。

使用 export 加载器

在使用用于 JavaScript 的 Amazon Cognito Identity SDK 的情况下,我们需要确保把 theAWSCognito 变量导出到 require /import 它们的模块的变量范围内(针对 ES6)。

{
  test: /aws-cognito-sdk\/index\.js/,
  loader: 'exports?AWSCognito'
}

在由 webpack 创建的捆绑中,使用 export 加载器会有导出模块方法的效果。因此, 在 require 和 import 后,AWSCognito 和 AWS 是可访问的(针对 ES6)。

var AWSCognito = require('aws-cognito-sdk')

/*** EXPORTS from export-loader ***/ 
module.exports = AWSCongito

这儿可以找到更多关于 export 加载器的信息。

使用 import 加载器

import 加载器主要用于把变量注入(import)到另一个模块的变量范围内。当第三方模块需要依赖全局变量的时候, import 加载器非常有用,比如针对 JavaScript 的 Amazon Cognito Identity SDK 需要依赖 BigInteger 或者 sjcl 的时候。

如果你不使用 webpack 加载器,下面这些内容会在一个捆绑中生成。

__webpack_require__(431);       // refers to jsbin
__webpack_require__(432);       // refers to sjcl

因为 jsbin 和 sjcl 都不能 export 任何东西,因此任何依赖于这些模块的调用都会导致一个错误。

为了解决这个问题,我们需要使用下面的 webpack 加载器配置:

{
  test: /amazon-cognito-identity\/index\.js/,
  loader: 'imports?jsbn,BigInteger=>jsbn.BigInteger,sjcl'
},
{
  test: /sjcl\/index\.js/,
  loader: 'imports?sjcl'
}

这个配置把下面的这些内容嵌入到了由 webpack 创建的捆绑中(此时是 bundle.js)。

/*** IMPORTS FROM imports-loader ***/
var jsbn = __webpack_require__(431);
var BigInteger = jsbn.BigInteger;
var sjcl = __webpack_require__(432);

结果,jsbn、BigInteger 和 sjcl 都被从它们各自的模块中导入到了用于 JavaScript 的 Amazon Cognito Identity SDK 中。

有关 import 加载器的更多信息可以在这儿找到。

下一步

我们鼓励你下载用于 JavaScript 的 Amazon Cognito Identity SDK 并开始构建你的应用,并在这篇文章的指导下通过 webpack 能够迅速掌握。

如果你有任何意见或问题,请在下面自由评论,也可以发邮件到 [email protected] 或者在这儿提出问题。

引用

这篇文章引用了下面这些第三方资源:


via: https://mobile.awsblog.com/post/Tx1A84CLMDJ744T/Using-webpack-with-the-Amazon-Cognito-Identity-SDK-for-JavaScript

作者:Marc Teichtahl 译者:ucasFL 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

通过几个点击即可在 “AWS 快速起步”和“Azure 市场”上高效搭建产品级 Docker 数据中心。

通过 AWS 快速起步的 CloudFormation 模板和在 Azure 市场上的预编译模板来部署 Docker 数据中心使得比以往在公有云基础设施下的部署企业级的 CaaS Docker 环境更加容易。

Docker 数据中心 CaaS 平台为各种规模的企业的敏捷应用部署提供了容器和集群的编排和管理,使之更简单、安全和可伸缩。使用新为 Docker 数据中心预编译的云模板,开发者和 IT 运维人员可以无缝的把容器化的应用迁移到亚马逊 EC2 或者微软的 Azure 环境而无需修改任何代码。现在,企业可以快速实现更高的计算和运营效率,可以通过短短几步操作实现支持 Docker 的容器管理和编排。

什么是 Docker 数据中心?

Docker 数据中心包括了 Docker 通用控制面板 Docker Universal Control Plane (UCP), Docker 可信注册库 Docker Trusted Registry (UTR)和 商用版 Docker 引擎 CS Docker Engine ,并带有与客户的应用服务等级协议相匹配的商业支持服务。

  • Docker 通用控制面板(UCP),一种企业级的集群管理方案,帮助客户通过单个管理面板管理整个集群
  • Docker 可信注册库(DTR), 一种镜像存储管理方案,帮助客户安全存储和管理 Docker 镜像
  • 商用版的 Docker 引擎

在 AWS 上快速布置 Docker 数据中心

秉承 Docker 与 AWS 最佳实践,参照 AWS 快速起步教程来,你可以在 AWS 云上快速部署 Docker 容器。Docker 数据中心快速起步基于模块化和可定制的 CloudFormation 模板,客户可以在其之上增加额外功能或者为自己的 Docker 部署修改模板。

架构

AWS Cloudformation 的安装过程始于创建 AWS 资源,这些 AWS 需要的资源包括:VPC、安全组、公有与私有子网、因特网网关、NAT 网关与 S3 bucket。

然后,AWS Cloudformation 启动第一个 UCP 控制器实例,紧接着,安装 Docker 引擎和 UCP 容器。它把第一个 UCP 控制器创建的根证书备份到 S3。一旦第一个 UCP 控制器成功运行,其他 UCP 控制器、UCP 集群节点和第一个 DTR 复制的进程就会被触发。和第一个 UCP 控制器节点类似,其他所有节点创建进程也都由商用版 Docker 引擎开始,然后安装并运行 UCP 和 DTR 容器以加入集群。两个弹性负载均衡器(ELB),一个分配给 UCP,另外一个为 DTR 服务,它们启动并自动完成配置来在两个可用区(AZ)之间提供弹性负载均衡。

除这些之外,如有需要,UCP 控制器和节点在 ASG 中启动并提供扩展功能。这种架构确保 UCP 和 DTR 两者都部署在两个 AZ 上以增强弹性与高可靠性。在公有或者私有 HostedZone 上,Route53 用来动态注册或者配置 UCP 和 DTR。

快速起步模板的核心功能如下:

  • 创建 VPC、不同 AZ 上的私有和公有子网、ELB、NAT 网关、因特网网关、自动伸缩组,它们全部基于 AWS 最佳实践
  • 为 DDC 创建一个 S3 bucket,其用于证书备份和 DTR 映像存储(DTR 需要额外配置)
  • 在客户的 VPC 范畴,跨多 AZ 部署 3 个 UCP 控制器
  • 创建预配置正常检测的 UCP ELB
  • 创建一个 DNS 记录并关联到 UCP ELB
  • 创建可伸缩的 UCP 节点集群
  • 在 VPC 范畴内,跨多 AZ 创建 3 个 DTR 副本
  • 创建一个预配置正常检测的 DTR
  • 创建一个 DNS 记录,并关联到 DTR ELB

在 AWS 使用 Docker 数据中心

  1. 登录 Docker Store 获取 30 天免费试用或者联系销售
  2. 确认之后,看到提示“Launch Stack”后,客户会被重定向到 AWS Cloudformation 入口
  3. 确认启动 Docker 的 AWS 区域
  4. 提供启动参数
  5. 确认并启动
  6. 启动完成之后,点击输出标签可以看到 UCP/DTR 的 URL、缺省用户名、密码和 S3 bucket 的名称

在 Azure 使用 Azure 市场的预编译模板部署

在 Azure 市场上,Docker 数据中心是一个预先编译的模板,客户可以在 Azure 横跨全球的数据中心即起即用。客户可以根据自己需求从 Azure 提供的各种 VM 中选择适合自己的 VM 部署 Docker 数据中心。

架构

Azure 部署过程始于输入一些基本用户信息,如 ssh 登录的管理员用户名(系统级管理员)和资源组名称。你可以把资源组理解为一组有生命周期和部署边界的资源集合。你可以在这个链接了解更多关于资源组的信息:<http://azure.microsoft.com/en-us/documentation/articles/resource-group-overview/> 。

下一步,输入集群详细信息,包括:UCP 控制器 VM 大小、控制器个数(缺省为 3 个)、UCP 节点 VM 大小、UCP 节点个数(缺省 1,最大值为 10)、DTR 节点 VM 大小、DTR 节点个数、虚拟网络名和地址(例如:10.0.0.1/19)。关于网络,客户可以配置 2 个子网:第一个子网分配给 UCP 控制器 ,第二个分配给 DTC 和 UCP 节点。

最后,点击 OK 完成部署。对于小集群,服务开通需要大约 15-19 分钟,大集群更久些。

如何在 Azure 部署

  1. 注册 Docker 数据中心 30 天试用许可或者联系销售
  2. 跳转到微软 Azure 市场的 Docker 数据中心
  3. 查看部署文档

通过注册获取 Docker 数据中心许可证开始,然后你就能够通过 AWS 或者 Azure 模板搭建自己的数据中心。

了解有关 Docker 的更多信息:


via: https://blog.docker.com/2016/06/docker-datacenter-aws-azure-cloud/

作者:Trisha McCanna 译者:firstadream 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Tianhui Michael Li 和 Ariel M’ndange-Pfupfu 将在今年 10 月 10、12 和 14 号组织一个在线经验分享课程:Spark 分布式计算入门。该课程的内容包括创建端到端的运行应用程序和精通 Spark 关键工具。

毋庸置疑,云计算将会在未来数据科学领域扮演至关重要的角色。弹性,可扩展性和按需分配的计算能力作为云计算的重要资源,直接导致云服务提供商集体火拼。其中最大的两股势力正是亚马逊网络服务(AWS)谷歌云平台(GCP)

本文依据构建时间和运营成本对 AWS 和 GCP 的 Spark 工作负载作一个简短比较。实验由我们的学生在 数据孵化器 The Data Incubator 进行, 数据孵化器 The Data Incubator 是一个大数据培训组织,专门为公司招聘顶尖数据科学家并为公司职员培训最新的大数据科学技能。尽管 Spark 效率惊人,分布式工作负载的时间和成本亦然可以大到不能忽略不计。因此我们一直努力寻求更高效的技术,以便我们的学生能够学习到最好和最快的工具。

提交 Spark 任务到云

Spark 是一个类 MapReduce 但是比 MapReduce 更灵活、更抽象的并行计算框架。Spark 提供 Python 和 Java 编程接口,但它更愿意用户使用原生的 Scala 语言进行应用程序开发。Scala 可以把应用程序和依赖文件打包在一个 JAR 文件从而使 Spark 任务提交变得简单。

通常情况下,Sprark 结合 HDFS 应用于分布式数据存储,而与 YARN 协同工作则应用于集群管理;这种堪称完美的配合使得 Spark 非常适用于 AWS 的弹性 MapReduce (EMR)集群和 GCP 的 Dataproc 集群。这两种集群都已有 HDFS 和 YARN 预配置,不需要额外进行配置。

配置云服务

通过命令行比通过网页界面管理数据、集群和任务具有更高的可扩展性。对 AWS 而言,这意味着客户需要安装 CLI。客户必须获得证书并为每个 EC2 实例创建独立的密钥对。除此之外,客户还需要为 EMR 用户和 EMR 本身创建角色(基本权限),主要是准入许可规则,从而使 EMR 用户获得足够多的权限(通常在 CLI 运行 aws emr create-default-roles 就可以)。

相比而言,GCP 的处理流程更加直接。如果客户选择安装 Google Cloud SDK 并且使用其 Google 账号登录,那么客户即刻可以使用 GCP 的几乎所有功能而无需其他任何配置。唯一需要提醒的是不要忘记通过 API 管理器启用计算引擎、Dataproc 和云存储 JSON 的 API。

当你安装你的喜好设置好之后,有趣的事情就发生了!比如可以通过aws s3 cp或者gsutil cp命令拷贝客户的数据到云端。再比如客户可以创建自己的输入、输出或者任何其他需要的 bucket,如此,运行一个应用就像创建一个集群或者提交 JAR 文件一样简单。请确定日志存放的地方,毕竟在云环境下跟踪问题或者调试 bug 有点诡异。

一分钱一分货

谈及成本,Google 的服务在以下几个方面更有优势。首先,购买计算能力的原始成本更低。4 个 vCPU 和 15G RAM 的 Google 计算引擎服务(GCE)每小时只需 0.20 美元,如果运行 Dataproc,每小时也只需区区 0.24 美元。相比之下,同等的云配置,AWS EMR 则需要每小时 0.336 美元。

其次,计费方式。AWS 按小时计费,即使客户只使用 15 分钟也要付足 1 小时的费用。GCP 按分钟计费,最低计费 10 分钟。在诸多用户案例中,资费方式的不同直接导致成本的巨大差异。

两种云服务都有其他多种定价机制。客户可以使用 AWS 的 Sport Instance 或 GCP 的 Preemptible Instance 来竞价它们的空闲云计算能力。这些服务比专有的、按需服务便宜,缺点是不能保证随时有可用的云资源提供服务。在 GCP 上,如果客户长时间(每月的 25% 至 100%)使用服务,可以获取更多折扣。在 AWS 上预付费或者一次购买大批量服务可以节省不少费用。底线是,如果你是一个超级用户,并且使用云计算已经成为一种常态,那么最好深入研究云计算,自己算计好成本。

最后,新手在 GCP 上体验云服务的费用较低。新手只需 300 美元信用担保,就可以免费试用 60 天 GCP 提供的全部云服务。AWS 只免费提供特定服务的特定试用层级,如果运行 Spark 任务,需要付费。这意味着初次体验 Spark,GCP 具有更多选择,也少了精打细算和讨价还价的烦恼。

性能比拼

我们通过实验检测一个典型 Spark 工作负载的性能与开销。实验分别选择 AWS 的 m3.xlarg 和 GCP 的 n1-standard-4,它们都是由一个 Master 和 5 个核心实例组成的集群。除了规格略有差别,虚拟核心和费用都相同。实际上它们在 Spark 任务的执行时间上也表现的惊人相似。

测试 Spark 任务包括对数据的解析、过滤、合并和聚合,这些数据来自公开的 堆栈交换数据转储 Stack Exchange Data Dump 。通过运行相同的 JAR,我们首先对大约 50M 的数据子集进行交叉验证,然后将验证扩大到大约 9.5G 的数据集。

Figure 1. Credit: Michael Li and Ariel M'ndange-Pfupfu.

Figure 2. Credit: Michael Li and Ariel M'ndange-Pfupfu.

结果表明,短任务在 GCP 上具有明显的成本优势,这是因为 GCP 以分钟计费,并最终扣除了 10 分钟的费用,而 AWS 则收取了 1 小时的费用。但是即使长任务,因为计费方式占优,GPS 仍然具有相当优势。同样值得注意的是存储成本并不包括在此次比较当中。

结论

AWS 是云计算的先驱,这甚至体现在 API 中。AWS 拥有巨大的生态系统,但其许可模型已略显陈旧,配置管理也有些晦涩难解。相比之下,Google 是云计算领域的新星并且将云计算服务打造得更加圆润自如。但是 GCP 缺少一些便捷的功能,比如通过简单方法自动结束集群和详细的任务计费信息分解。另外,其 Python 编程接口也不像 AWS 的 Boto 那么全面。

如果你初次使用云计算,GCP 因其简单易用,别具魅力。即使你已在使用 AWS,你也许会发现迁移到 GCP 可能更划算,尽管真正从 AWS 迁移到 GCP 的代价可能得不偿失。

当然,现在对两种云服务作一个全面的总结还非常困难,因为它们都不是单一的实体,而是由多个实体整合而成的完整生态系统,并且各有利弊。真正的赢家是用户。一个例证就是在 数据孵化器 The Data Incubator ,我们的博士数据科学研究员在学习分布式负载的过程中真正体会到成本的下降。虽然我们的大数据企业培训客户可能对价格不那么敏感,他们更在意能够更快速地处理企业数据,同时保持价格不增加。数据科学家现在可以享受大量的可选服务,这些都是从竞争激烈的云计算市场得到的实惠。


via: https://www.oreilly.com/ideas/spark-comparison-aws-vs-gcp

作者:Michael Li Ariel M'Ndange-Pfupfu 译者:firstadream 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

问题:我在配置一个需要访问我的亚马逊AWS帐号的应用时被要求提供AWS访问密钥ID秘密访问密钥,我怎样创建一个新的AWS访问密钥呢?

亚马逊AWS安全凭证用于验证你以及授权任何第三方应用访问你的AWS帐号,有各种不同的AWS安全凭证可用,如密码、访问密钥、多因素身份验证、X.509证书等。

如果你想要创建新的访问密钥(访问密钥ID和秘密访问密钥),请按一下步骤进行。

首先,登录到AWS控制台

从顶部栏选择“安全凭证”菜单(图中红色方框所示)。

在下一页中,选择“访问密钥(访问密钥ID和秘密访问密钥)”选项(图中红色方框所示)。

在下一页中,你将看到一个现存访问密钥ID列表(如果有的话)。注意,你不能恢复现存访问密钥ID的“秘密访问密钥”。出于安全的原因,秘密访问密钥只能在你创建新访问密钥时才可见。

点击“创建新访问密钥”(见图示),将会立即创建一个新的访问密钥ID和密码访问密钥对。

要么下载一个包含有新访问密钥的密钥文件,要么复制并粘贴新访问密钥信息。再次提请牢记,一旦你关闭该窗口,秘密访问密钥将不再可用,除非你下载一个密钥文件。

多用户AWS帐号

如果你是作为公司身份创建的帐号,多个雇员共享这一公司帐号,你可能想要使用身份和访问管理(IAM)来创建并管理他们的访问密钥。

IAM是一个web服务,它允许一个公司管理多个用户及其与一个AWS帐号关联的安全凭证。使用IAM,多个用户可以作为不同身份登入单一的AWS帐号,并管理他们的安全凭证而不会相互干预对方的密钥。

要管理IAM用户,点击“安全凭证”页面上的“用户”菜单(见图示)。

然后,你就可以创建一个新的IAM用户并管理他们的安全凭证,比如访问密钥之类的东西。


via: http://ask.xmodulo.com/create-amazon-aws-access-key.html

译者:GOLinux 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Mesosphere,一家试图围绕鲜为人知的 Apache Mesos 项目开展商业活动的公司,刚刚从 Andreessen Horowitz 那里获得了 1000 万美元投资。以下是为什么这个项目能够吸引如此巨款的原因。

事实上 Mesos 这款自动扩放软件已经出现了五年了。据 Mesosphere 的CEO及联合创始人 Florian Leibert 所述,Mesos 已经在 Twitter 内已经管理了超过 50,000 个以上的CPU。此外, EBay, AirBnB, Netflix 还有 HubSpot 也是这款软件的使用者。

当那些互联网巨头发现 Mesos 的时候,这项技术却并不为大多数企业所知。但它确实可以满足一些公司在他们内部的数据中心上应用公共云的一些技术的需求。

Mesos 管理集群机器,根据需要自动扩放应用。它在每台机器上只依赖很少的软件,它由一个主调度程序协调。据 Leibert 所说,其CPU 占用为 0 并且几乎不消耗任何内存。在其工作的每台机器上的该软件会向调度程序报告关于虚拟机或者服务器的容量信息,接着调度程序向目标机器分派任务。

“如果一项任务终断并且没有返回任何结果,主调度程序知道如何重新调度它和它所用的资源在哪里。” Mesosphere 的资深副总裁 Matt Trifiro 说。

Mesos 能自动扩放一系列的任务,包括 Hadoop 数据库,Ruby on Rails 节点,以及 Cassandra 。

使用 Mesos 使得 Hubspot 削减了一半的 AWS(Amazon Web Services) 的费用支出,Liebert 说道。这是因为 Mesos 能够在目标机器之间有效地分配作业量的原因。

然而,Mesos 更有可能应用到那些试图真正地在内部创建一个类 AWS 环境的企业,一位来自 451 Research 的分析员 Jay Lyman 说。AWS 提供一些自动扩放工具,但大多数公司对于在公共云基础设施上运行所有东西还是感到不安。与此同时,他们并不想着反对他们的开发者采用 AWS 那样的公共云中可用的优异性能。他们希望他们的私有云能集成这些可用的优点。

“如你所见,类似 AWS 风格的界面风格,与监控、命令、操控以及稳定性相融合,” Liebert 继续说道。

Mesos 既可以在一个私有云上也可以在 AWS 上运行,向企业提供最有效率地使用其内部云的方法,并在需要扩放时自动切换到 AWS 去。

但是,从另外的方面说 Mesos 也是有一些缺点的。它并不能运行任何 Windows 操作系统或者比较古老的应用比如说 SAP 软件。

不过,Lyman 说,“假如一个团队拥有长时期使用云的经历,他们大概早就对 Linux 操作系统情有独钟了。”

在将来,Mesosphere 能够支持 Windows 操作系统是很有可能的。最初,像 Puppet 和 Chef 这样的技术也只支持 Linux 操作系统,Lyman 表示。“这只是早期 Mesosphere 的特性。现在它还是不太成熟,” 他又说道。

Mesosphere 正瞄向大部分使用现代编程技术构建了越来越多的运行于 Linux 的应用的企业,以及 Twitter 和 Netflix 这种在初创时还没有 Mesos 类似技术的第一代 Web 2.0 公司。“这是早期两类最常见的客户概况,” Trifiro 说。

年终之前,Mesosphere 希望发布包含文档的商业产品,通过技术支持与颁发许可证来获得营收。Mesosphere 已开发一款名为 Marathon 的大规模扩放编制工具,并且支持 Docker 集成。它现在免费提供打包好的 Mesos 发行版,希望以此占有未来的市场。

Mesosphere 同时也正在为少数早期的顾客工作。它帮助 HubSpot 实施有关 Mesos 的搭建。

Mesosphere 在这个领域并不唯一。Rightscale,Scalr 以及现在归 Dell 所有的 Enstratius,全都提供了一些各种版本的扩放或云管理技术。Mesosphere 强调说,Mesos 及其公司自己开发的技术在单独机器中创建服务器集群方面的表现远胜于市场上的其他同类软件。来自 Andreessen 的新投资一定会帮助 Meos 获得更大的动力。


via: http://thenewstack.io/little-known-apache-mesos-project-helps-mesosphere-raise-10m-from-andreessen/

译者:SteveArcher 校对: wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出