2012年01月11日 星期三 21:50
开源软件让企业家和技术专家得以将创新型的解决方案带到市场。本文讨论了我们在创立这个后来卖价达 3.65 千万美元的公司之初为何以及如何采用了开源技术。
我们创建的 StudioNow 是最早的一个全球分布式的视频制作平台。它联系了视频制作者、编辑、平面艺术家、配音演员和其他的创意人员来为诸如 Yellow Pages、 Citysearch® 和音乐厂牌这样的客户制作内容。通过 StudioNow 的网站以及基于云的交付和转码平台,实现了成规模的视频制作,减少了单个视频的制作成本。
在 StudioNow 的创立之初,我和我的同事们必须决定采用哪种技术以及确定项目起步及掌握一套新技能的最佳方式。我们还必须应对缩放(scaling)挑战并做出明智的架构决策。经过这次体验,我们知道了使用这些技术如何能为创业带来巨大的优势。您的具体情况可能不同,但是如果您正在考虑为您的项目采用开源方案,那么我建议您:
在一个新的技术堆栈上构建一个解决方案绝非易事,但是在这些技术上构建一个全新的企业则完全将其带到了一个新层面。选择采用哪个平台是一个前期的战略决策。决策正确与否事关成败。如果技术太过深奥,那么这种决策不佳,往往会将收购的机会拒之门外 。 此外,如果社区很弱或是根本不存在,我们将不能很快地做到充分了解。开箱即用的功能是否足够多以至我们能关注于构建核心功能而不是忙于搭建支架。
我们之前有的背景知识多集中于企业软件,比如微软® .NET 和 C# 以及 Oracle 和 Java™ 技术,很明显这次我们需要做不同的选择。 没有人愿意在购买许可证上花钱,也不愿管理对许可证的遵从性,所以最后的决定需要在 Ruby with Ruby on Rails 和 Python with Django 中产生。最后之所以将范围缩小到这二者是因为它们是广受推崇的两种构建 Web 应用程序的开源选择。
在 2006 年初,我兼职为 StudioNow 工作,由我们的合伙人兼 CTO Adam Solesby 评估这两个平台并决定使用哪个平台。他最后选择了 Django,主要考虑了两个因素。对于初学者,Python 语言看起来更为吸引人。但更为重要的是,Python 和 Django 文档和社区都很强大。很容易找到示例及能清晰做出解释的文档。在决定采用何种技术时,这是一个很关键的因素。借助在线书籍Dive into Python、Freenode 上的 #django Internet Relay Chat (IRC) 频道以及 Python 和 Django 的文档(参见 参考资料),起步是很容易的。
每个开源项目(以及在某种程度上,围绕此项目的社区)都有特定的一套规则,或者表述直白,或者为大家心照不宣。为了在开源之路上一路成功,如下的几点考虑将非常重要:
在 StudioNow 的早期,我们对视频转码知道的不多。我们还在学习和试图将视频导出成 Sorenson FLV 格式以便在我们网站上回放。为了降低成本并说服编辑们在薪酬少于其自找的其他工作的情况下仍能加盟我们的项目,我们必须承担编辑们不想做的那些没有创造性的重复性工作。 这里的卖点是客户无须担心目标格式。
这种模式在早期阶段我们成交量不大时尚能忍受。我们有几个工作站和全职的员工来手动执行导出。此外,还有一些专设的脚本来帮助半自动化从编辑处将原始上传文档下载到办公室、进行转码,然后再将它们上传回项目网页供客户和顾客查阅的过程。
一开始就很明显,这个过程将不能缩放,我们需要在尽量多地节约成本的同时解决这个问题。进行下一轮的融资总是有很多不确定性, 我们不想乱花钱。
在 2006 年中,Amazon Web Services (AWS) 相对而言还很新。最初,我们被 Amazon Simple Storage Service (Amazon S3) 便宜的无限存储所吸引,这个成本是我们在公司成长的过程中能支付得起的。毕竟,我们是在两个同地协作的相对较老的服务器上托管了整个站点(网站和视频文件托管)。我们知道我们必须对转码进行伸缩,但是首要的一点是我们无须再担心我们服务器上的小硬盘会被填满。
我们决定将我们办公室内的转码解决方案中的转码存储转移到 Amazon S3 上并通过一个 API 调用将位置记录到我们的网站。这种解决方案给我们提供了一些时间来思考转码的缩放问题。
我于是开始通过编写自己的 Python 接口来与 Amazon S3 API 对接。不过,我很快发现了 Mitch Garnaat 的 boto 项目(参见 参考资料)。有了 Mitch 的直接帮助,我们在效率上有了显著的提高。这个库本身在为 StudioNow 节省时间和精力上功不可没, boto 的用户和开发人员社区更是极大地帮助我们弄清楚这种新形式的架构技术解决方案。在某种意义上,对 boto 项目的参与更多的是为了开放架构,而不仅仅是开源软件。
这种协作式体验让我得以成功地将我们原先那种受限的单一编码解码制作视频的方式转换成伸缩性极大的使用 Amazon Elastic Compute Cloud (Amazon EC2) 的编码平台。理论上讲,这个平台现在具备了以与编码单一视频相同的时间对成千上万大小不一的视频和面向不同目标设备和平台的编解码器进行转码的能力。
之前,我们曾考虑(在我们的 COO 建议下)使用一种基于 Java 的闭源解决方案。它是一种久经验证的技术,可向后期制作公司提供相同的转码服务。这虽不失是一种明智的保守建议,但那将需要我们投入一大笔资金来购买硬件、构建或租借数据中心空间、购买软件许可以及雇用额外的员工来管理硬件。不过,我们知道这种解决方案至少可以保证短期内的缩放。
在向这个黑盒解决方案投入资金之前,基于我们与 boto 社区的交往经验以及 “随用随付” 的承诺,我们决定探求基于云的解决方案。虽然当时还没有多少人这么做过,但具备的条件已经足够了。boto 库具有用来按需启动节点的接口。Amazon 则具有我们需要的定价公道的计算资源(按需以及水平计算资源而非大多数时间空闲却要永久运行的机器)。Mitch 甚至还写了一篇文章,展示了他如何使用 FFmpeg
转码一个视频以便在 Apple iPod 上播放。
这意味着我将需要构建一个原型来引导图像、接受要转码哪个视频文件的输入、用到我们已经构建的 API、将结果存储在 Amazon S3 上并自行关机。我花了几星期时间完成它之后,它给了我们基于 AWS 和开源软件构建解决方案的信心。它还允许我们对平台有更多的控制。我们能集中于学习对公司业务至关重要的技术,比如 FFmpeg
和视频转码。这还意味着我们不会受锢于一个软件产品提供商或受物理硬件或预算的限制。我们能很准确地知道某项目计算资源和存储资源的成本并能将其作为因素计入定价。
构建这个平台的一个关键部分是了解视频转码和我们实现目标所需的主要工具: FFmpeg
。我发现这个项目比一个纯 Python 库,比如 boto,更为技术化和复杂。视频编解码器当时对我来说十分陌生,我不确定我能否掌握这个工具、此工具使用的库或是一般的视频规范。
我开始成为 Freenode IRC 频道 #ffmpeg 的常客,阅读那里的文档,甚至开始尝试研习用 C
编写的源代码。我发现 IRC 频道很有用,但是对于那些提出的问题通过自己研究和阅读文档完全能自己解答的人却不那么宽容。起初这有些令人生厌,但一段时间后,我了解到有人这么做更多的是为了节省精力而非故意无理。这个社区的社交规则似乎是先在 FAQ 和文档内寻找答案,然后如果要在频道内提问,要提供相关的有用信息或上下文。在我了解了这些社交规则后,我就能成功地获得问题的答案了。
参与创业的所有人都愿意看到的一天来了,有人有兴趣收购我们。在最初的兴奋逐渐褪去后,随之而来的是一系列的资质检查 。其中的一项检查是验证我们构建 StudioNow 所用软件的许可情况。AOL 的律师对有无 GPL 相关代码的使用痕迹尤其关注。GPL 的条款中规定 GPL 代码的任何衍生作品都必须携带 GPL 并发布源代码。此外,对链接到受 GPL 许可的库(静态或动态链接)是否就是要执行的这个许可的 “病毒” 本质的起因也甚是模糊不清。
在多数方面,我们都还不错。但是,我们使用 FFmpeg
时带有链接库,这意味着适用的是 GPL 而非 Lesser General Public License (LGPL)。虽然我们不会重新发布或修改源代码(只使用编译了的二进制来进行视频的转码)我们仍然需要找出这个问题的出路。幸运的是,我们没有在转码服务中使用任何需要 GPL 的代码,所以我们只是用不同的编译标志重新编译了一个新的 FFmpeg
二进制。
使用开源软件将解决方案成功推向市场所需要的绝非仅仅是一些免费的源代码。开源软件是一个生态系统和社区。成为各个感兴趣社区的积极而活跃的会员也会受益良多。而且,出于使用软件的特质,您将能更多地回馈此项目。最后,对所使用的不同开源软件的许可情况要特别留意和慎重,因为这可能对日后的发展至关重要。
请享受用开源软件构建您的下一个企业的自由和快乐吧!
2012年01月12日 星期四 13:09
开源确实有这方面的优势呀
2012年01月12日 星期四 13:23
是啊,价值远超过我们的想象
Zeuux © 2024
京ICP备05028076号