28 1月

我们为什么四个月徒劳,使用OpenStack又为什么失败

文 / David Laube:充满热情的互联网基础设施构建者,工作涉及托管服务,基础设施自动化和可扩展平台的部署。目前担任packet.net主管平台系统的副总裁。

原文链接:https://www.packet.net/blog/how-we-failed-at-openstack

去年初夏,我的同事Zac,也是公司的CEO,向我求助如何构建一个现代化的,任何东西都不安装的云托管平台。我回想自己以往的主要从业经历,包括构建,支持和使用可扩展的基础设施的经历,不禁犯起了嘀咕。我问自己,真的需要这样做吗?不是有很多不错的IaaS(Infrastructure as a Service),基础设施即服务可以拿来用吗?

随着沟通的深入,我最终意识到现在很多云服务不是用户友好型的,使用起来存在很大的困难。另外,我是Docker的早期用户,Docker是应用容器引擎,这种容器支持的部署方案会使高质量的物理裸机在运维工作方面更加给力。但某些公有云的虚拟化情况,还有一些托管服务商存在的问题,都没能与复杂多变的物理硬件发展的需求相匹配。于是我觉得需要为此做一些工作。接下来咱们随着packet.net的部署旅程一起过把瘾吧!

开始安装之旅

我一头扎进了部署packet.net的工作。还同时忙着关注部署策略和云自动化的相关动态,从头到尾地检查特定安装程序,还有所有的开源云平台,以及我们已经安装的那些服务。

Voxel是被Internap收购的一款云主机托管平台,我们在使用的时候部署了很多自己的程序,在这过程中既看到了带来的好处,又体验了自己拥有软件平台的感觉。服务器的安装工作看起来似乎特别容易,好像一旦完成,一劳永逸,对吧?但这是绝对的错觉!因为安装完成后会出现数不清的网络问题,还有随时发生的硬件调整,以及各种操作系统存在的差异。在这样的情况下为用户提供不折不扣的自动化服务,安装并管理数千台服务器,并确保这些服务器正常工作,在五分钟之内还能响应Zac做出的决定。这对我来说可不是件轻松的事情。

为了使 packet.net到达预期的目标,数千台服务器7×24小时不断地安装和启动,并要在数月后上线。我开始关注OpenStack在互联网基础设施方面的独特之处,它可以被当作我们构建服务的手段。这包括联网业务的自动化,IP地址的管理,安装过程的监控,以及硬件的调换和安装。如果我能依靠OpenStack这些核心项目完成工作的话,那么我的团队就可以更加专注于能给用户带来更多价值的事情,像硬件分析,还有对容器机制的应用引擎提供技术支持。

别人提醒过我OpenStack存在的一些隐患,但我还是自己花了数周时间去阅读近期的版本记录,混迹于好几个维基的IRC官方聊天频道,并且玩了一下OpenStack的安装脚本DevStack。我开始对OpenStack的核心项目不再那么陌生。在过去的两年中,DevStack已经发展得非常成熟,而且所逢时机也刚刚好。全球领先的托管服务器及云计算提供商Rackspace最近发布了OnMetal物理裸机服务器部署方案,并公开撰写博客指出如何在其物理机上使用Ironic进行部署。而美国时间2014年10月16日,OpenStack的一个重要的版本,Juno版也正式发布了。

所以我觉得应该使用OpenStack来为公司的物理服务器进行部署。

部署的过程

我知道学习OpenStack的过程不会平坦,并且明白这需要拼命努力学习其中的每一个项目,而不只是安装。我细致深入地研究OpenStack每一个项目,尽力去了解Nova的动态,还有Ironic的驱动程序,特别是Neutron。我们不仅要在物理服务器上安装Ironic,还要支持packet.net托管服务的网络模型,特别是要用Layer3取代Layer2和VLAN层主机的功能。

这个时候你可能说:“喂,要阅读和学习的文档那么多啊”!在过去的一个月里,我明显能感觉到我们所接触到的文档不是过时的就是有错误的。这让我不得不去从以前优质的文档中去删选内容,比如从维基上的文章,IRC(一种聊天工具)的日志,还有版本提交记录,从这些地方去寻找最新的正确信息。这些基础工作完成后,我要用python去做大量的调试工作,去验证各种与文档描述不一致的功能。比如这个是否工作,那个是否正确,这是很漫长的过程。

值得一提的是,存在着那么一群人和公司,他们依靠OpenStack生存,组成一个很大的共生系统,特别是OpenStack的Nova和标准的Neutron项目相关的部分。尽管从规模上这群体可以与其他开源项目进行匹敌,但其实对于Ironic来说,他们很难有人能够达到产品级的使用水平。我就碰到过这样的情况,我向其核心开发人员咨询了一些实施的问题,他们居然答不上来。并且我从Google搜索这些问题,也仅能得屈指可数的几条与问题有关的信息。

经验一:OpenStack规模不小 ,新兴并发展迅速,但要了解一些过去的基本信息,会感到相关的文档良莠不齐。

我把Neutron部分交给了我的同事去处理,而自己又深入地了解了Ironic。但实际的情况是,我们需要OpenStack每个部分特定的开发人员,让他们帮助我们去理解代码库,才能跟上OpenStack每个项目更新的脚步。那我们又怎么去恰如其分地满足自己的需要呢?于是我就通过IRC和来自Rackspace的OnMetal团队成员接触,还通过邮件联系。去逛OpenStack开发者论坛。我敢打保票,自己阅读了每一个相关文档,还有论坛里的每个帖子,而且还通过Google搜索出的相关信息去调试Ironic,这些我都做到了!

尽管对于先前那种Ironic项目来说OpenStack Nova版的物理服务器部署方案取得了突破性进展,但是OpenStack还是以为虚拟化技术为核心进行设计的。仍然存在很多功能和文档的修改还介于Nova的物理机部署方案和带有驱动的Ironic部署方案之间。我把这种情况反馈给了力量有限的Ironic技术支持部门,却硬被要求使用与虚拟技术相关的openvswitch和linuxbridge。我们的网络模型与此存在严重的冲突。于是我发现,OpenStack的Neutron项目不仅缺乏针对特定网络产品厂商的技术支持,也缺乏对不同网络模型的扩展能力。

对OpenStack的核心代码有更深了解的大用户(最典型的就是Rackspace公司),依靠将OpenStack的那些项目高度定制化后,使之能够在实际的物理网络上部署物理机。其中有几个补丁是已经发布了的,但很多重要的补丁都没有公开,需要用户自己重新编写,同时还要对以后新发布的版本进行维护。

经验二:OpenStack是基于虚拟化技术的平台,如果你用的不是虚拟技术,那就要再考虑了!

到了这份儿上,我已经对使用OpenStack部署公司服务产生了严重的怀疑。这么多需要了解的东西,还有要做与每个项目保持同步的工作,这样的情况令人望而生畏。并且,我开始认识到要对Nova和Ironic所做的定制化工作并不是小事一桩,这会抵消掉OpenStack在开源方面所带给我们的好处。

但我还是觉得完全了解Neutron的细节非常重要,这是我目前唯一的念想儿。

对于物理交换机和服务器来说,安装部署服务器并不太困难,而且解决方案十分成熟可靠。而自动化工作却需要很多工具配合工作才能完成。从我的经历来看,大多数基础设置部署工作最容易出错的部分就是网络部分的自动化。你看,物理交换机的操作系统还存在很多不足之处。对当前的自动化工作和API的交互的支持显得捉襟见肘。其实,我用过的另外一款网络自动化工具的蹩脚表现是让我考虑使用OpenStack的主要原因。Neutron项目有非常令人振奋的使命:可以按照需求提供可扩展,不受制于任意一项技术的服务,包括相关的库。我也希望是这样呀!

但现实并不像所承诺的那样。根据软件定义网络(SDN,Software Defined Networking)的说法,大多数在基于虚拟机监视器(hypervisor)的虚拟网络下工作的项目并不是真实的交换机。不仅是因为对于交换机厂商来说严重过时的Neutron驱动,而且OpenStack最新的Juno版本的支持工作也力量有限。另外,Neutron使用了自身并不完善的IP地址管理器(IPAM),根本没有任何自己分配外部访问方式的概念,也没有提供关于IP地址管理方面的书面说法和权限。牺牲用户体验来适应Neutron这些不足,这是不能接受的。

经验三:OpenStack的Neutron项目支持工作并不那么完备、系统。使用之前要先看看自己的交换机能否适应。

这样一来,我们要如何应对?

长话短说。在圣诞节的前一周,我们丢掉了OpenStack,然后又花了三周的时间开发了一套定制化的自动化部署平台。在十二月初搭建好自己的IP管理系统后,团队就卯足了劲要将系统搭建自己定制工具上。而每个新项目都会有自身的使命。作为一家公司,我们的愿景是不断进取,并且我们觉得,在调查和部署OpenStack的过程中,解决了存在的大部分问题:构建了一个灵活且能提供服务功能的IPAM系统(我们管它叫Magnum IP)。在设施管理平台和物理基础设施之间,我们还建立了用户和权限模型。

有时现存的东西并不一定是最好的,也不一定能满足自己的需要。我们使用OpenStack部署packet.net的过程就完全说明了这个道理。同时,我们也会努力发布自己的Neutron插件,与OpenStack项目的发展相适应,我们现在正在做。

之后的一周时间,我们最终完成了CoreOS系统的安装(这也是在考察了Ubuntu,Debian和CentOS后做出的决定)。工作精益高效,对变化反应迅速,对系统记录详尽,这样我们可以做一些高级功能和高可用性工作,而又不会影响到用户体验,这让我感到激动不已。我能说自己工作学习两不误吗?

http://www.csdn.net/article/2015-01-26/2823694

18 1月

在2015年,我们会看到SaaS怎样的转变?

文 / Omri Erel,walkme.com广告与绩效营销的负责人,让SaasAddict致力于寻找新的,创新性的道路来充实软件服务,使初创企业获得了成功。

原文链接:http://saasaddict.walkme.com/saas-2015-new-shifts-will-see/

又到了回首过去,展望未来的时刻了。对大事小事来说,做这样那样的预测都让人觉得有点儿傻。科学技术瞬息万变,变化之中体现出了发展的趋势。某项新技术的应用过程会比最初预想来得要缓慢,所以有时站在全局的角度审视事物也是很重要的。新年就是这样的好时机。

在2015年,我们大致可以看到SaaS(软件即服务)的发展趋势会遵循这样的轨迹:企业和客户之间会存在更多的选择。尽管我们心里企盼平稳,但是在市场,销售和产品研发领域,特别是云计算相关领域仍然会发生持续的变化。

我们在新的一年里会看到SaaS五大发展趋势:

1. 企业会在个体消费研究方面加大投资规模
目前很多对消费者的研究还停留在静态的方式上,比如通过问卷调查和对原始数据进行分析。更多的企业会在个性化定制服务方面加大投入。这些企业往往会通过社交网络,大数据技术的应用以及直接的接触(电子邮件和社交媒体)来了解客户的需要。像购买动机,生活方式以及内心需求这样的细节都很重要。

营销策略的关键是要提高客户的满意度,激发客户的品牌价值意识,所以营销不仅仅是一种服务。

2. 云数据服务将会赶超传统意义上的存储
Forrester Research分析,相对传统的前置应用,微软公司将会从其云服务领域获得更大收益。传统的前置应用受限于自身的前置存储空间,而云数据服务则更加开放。尽管云数据服务成本相对低廉,但企业为了获得有效的发展,还会研究去缩减其开支。

云数据服务需要提防的一点是其合法性问题。希望企业花重金来做好数据的安全工作,避免数据外泄。

3. 更多的SaaS应用会行业化定制
像医疗卫生行业,制造业以及零售业将会开发出更多适用其领域的应用程序。这样做面临的挑战之一就是要承担起客户更深层次,更复杂的体验工作。但在开发新的功能时,企业在特定领域SaaS所具有的用户基础会使企业抢得先机。同时对用户也有好处。这种趋势不容小觑的原因是用户对特定领域相关应用的需要日益增长。在任何一个领域,通用的应用软件都会避免变得过于复杂。过于复杂会提供给用户不切实际的服务而与用户脱节。

4. 多重租用的可选方案将会出现
允许多个用户共享一个应用对于管理云服务数据是有行之有效的,而传统认识是让多个用户使用,具有各自的界面。多重租用则具有更个性化的用户体验。例如,salesforce.com为企业所提供的新服务“Superpod”。这使企业在自己的数据中心拥有自己专用的基础架构,而不是连接到一个单独的服务器。

这些新的混合服务给企业通向未来提供了更多可选项,为系统的开发工作提供了更多的创新空间,这样就解决了云服务市场存在的瓶颈,也为用户提供了更多的选择。

5. 大数据分析更显突出
IDC的报告指出,在2015年DaaS(数据及服务)的应用量会呈现上升的趋势,消费额将达到2150亿美元。DaaS将利用云来提供服务。他们还预测,会有更多的企业使用大数据分析技术作为其商业及开放数据集的一部分。

云存储为企业的接入和整体存储容量提供了更高的灵活性。由于每单位云存储的相对成本在下降,越来越多的企业对大数据分析技术变得兴致有加,该技术则是实施开放数据集的绝佳机会。

http://www.csdn.net/article/1970-01-01/2823495

08 1月

编程语言易用性最低,却是迄今为止最强大的人机接口

文 / Andrew J.Ko:美国西雅图华盛顿大学信息学院助理教授。

原文链接:http://blogs.uw.edu/ajko/2014/03/25/programming-languages-are-the-least-usable-but-most-powerful-human-computer-interfaces-ever-invented/

这样的说法是真的吗?当自己破译一些神秘的错误信息,调试一些悄无声息的故障,或者给一些没有很好存档的函数提供正确的参数时,我经常会思考。上周我在对一个难以理解的PHP错误信息绞尽脑汁时,把这样的说法发到了推特上。但是,编程语言是否真的易用性差呢?

是还是不是,在推特上仁智所见。但我认为,只有部分缺陷是根本。举例来说,Jakob Nielsen[1]经典的易用性推测法,是关于易用性的一个粗略表征。用户界面其中一个最为突出的问题是缺乏系统状态的可见性:可用的接口应该提供用户输入状态及时和清晰的反馈,以便用户知道系统的状态以及接下来要做什么。当你编写程序时,会发现某个人所编写的指令集与这些指令对应的输出和对周围的影响有很大差异。事实上,即使一个简单的程序也可以有很多分支,也存在一些编写指令集的程序员无法看到的执行路径,而只有后来执行程序的人才能看到。再来说说延迟的反馈!具有复现性的全部文字记录,测试以及调试弥合了程序的命令与执行动作之间的脱节,更好地展现了一个程序执行时的行为。这些工具顶多为程序员认识程序提供了信息,因为程序执行过程固有的复杂性,这种认识需要花费大量的努力。

另一条准则是Nielsen的“系统应该对真实世界进行映射”:系统应当使用用户熟悉的概念,短语和比喻。而使用计算机术语表达思想是编程语言的本份。这可以通过标识符良好的命名,语言范式和结构的选择得到改善。你可能认为编程语言的发展是一个缓慢的过程,因而需要刻意去定义更好的抽象模型语意。但用计算机术语表达事物并不像人类思想那样凌乱和含糊其词。

编程语言可以产出非常实用的工具。事实上,编程语言研究人员向语言添加新的抽象,语义,以及尽力形式化的内容,是为了尽可能减少错误,最大化地使错误信息易于理解,有些人可能会争辩说,编程语言研究人员实际上在做什么?比如静态类型检查就是从根本上提供具体的,可操作的及时反馈。同样,Nielsen的准则“有助于用户认识错误、判断错误并从错误中恢复”已经不是通过语言设计来体现,而是通过精心设计语法高亮显示,源文件结构视图,类层次结构视图等这样的特征来体现。

还有编程语言可能超越图形用户接口易用性的其他易用性原则。举例来说,有什么更好的用户接口比编程语言更能支持撤销,重做和取消操作?当今的文本编辑器和版本控制器中,至少在设计期间,什么样的修改是不能够被撤销,重做或取消的?最优秀的编程语言大概是现有的最一致,灵活,简约和美观的接口了。大多数图形用户接口很难平衡这些设计原则,因为实现这些需要做出牺牲,以更好地适应现实世界。

因此,编程语言在某些方面可能缺乏易用性,但在工具设计中付出一定努力,编程语言可以接近图形界面的易用性。易用性方面的这些改进,能够大大提高易达性(accessibility),易学性(learnability)以及用户的使用效率。

现在来说第二部分:编程语言真的是有史以来发明的最“强大”用户接口吗?这取决于我们对强大的定义。这些编程语言当然是我们拥有的最具表达力用户接口,可以比其他任何用户接口创造出更多东西。

但是如果我们把强大理解为可以直接促进人们的特定目标,那么就会有很多任务,使编程语言变成一种蹩脚的工具。像发送邮件,视频聊天,玩游戏,阅读新闻什么的。这些事情最好由围绕这些活动及其相关概念进行设计的应用程序来支持,而不是由编程语言更低层的抽象来完成。从这个角度讲,编程语言可能是最不强大的用户接口。

如果说这个帖子有什么实在的东西,那么就是其隐含的概念,编程语言只是另一种类型的人机接口,是丰富且多样的用户接口范式设计领域。这里有一些有趣的暗示。例如,程序员也是用户,像HCI(Human-Computer Interaction)研究人员那样,他们一样需要像非程序员使用非编程语言接口那样去思考。在这两个领域我们没有发现更多不同的方法和文化,但问题和相关现象却显著地一致。

对于了解我和我工作的人来说,这些说法应该是不足为奇的。我所有研究的前提是编程语言即用户接口。这就是为什么,尽管我事实上主要学习代码,编码和编码器,但在攻读HCI方向的博士学位,而不是PL(Programming Language),软件工程或者其他一些与这些现象有关的领域。编程语言现在并将永远是我最着迷去学习和改造的一种用户接口。

[1] Web易用性专家,在丹麦科技大学获得了人机交互方向的博士学位。