这一期云计算文摘有一个关键词：约束。

我们首先听到《创业维艰》的作者告诉我们：预算，不应该是创业公司最重要的约束条件。接下来，是 Instagram 的创始人分享了五个 Instagram 5年来的发展里程碑，并指出他们在一开始面对众多约束时，如何做出选择。第三篇文章，来自一家不需要服务器的创业公司，列举了他们如何使用云服务+CDN 完成无服务器创业，甚至连他们的网站都没有放在服务器上。第四篇，是我们的技术总监李孟，列出了创业公司在 CDN 和 DNS 技术选型时应该考虑的一些约束条件，当然还有最佳实践。最后的电子书，排队论是它的主题。

希望能对大家有帮助，并欢迎大家发邮件给Social@speedycloud.cn，谈谈你们对于 SpeedyCloud 云计算的看法。

“创业维艰”之后，如何用一个糟糕的流程搞死你的公司

第一篇并非纯技术文章，但却对技术人员有根本性的影响，推荐创业公司阅读，来自创业畅销书《创业维艰》的作者本·霍洛维茨。

闯过“七、八个人，十几条枪”的“创业维艰”阶段之后，很多公司会从预算的角度来制定公司未来的发展规划，然而他们却不知道，这样很有可能从财务和文化方面危及公司未来的前景。这就是本·霍洛维茨的结论。

他还列举了一个“必死的目标制定法”。

基本流程：

1. 设定我们的成长目标
2. 分解目标，然后落实到对应团队上
3. 细化、量化目标
4. 确定完成目标需要招聘多少人
5. 估算人力成本
6. 对比行业指数
7. 总体优化
8. 执行

上述完全从上到下的流程，如果你希望将公司膨胀到破产边缘、催生混乱的文化，那就这么做。

应该怎么做呢？

要以打造凝聚力文化为原则，并从此开始，将其作为约束条件，找到更好的制定预算的方法。

在凝聚力文化原则的基础上，他提出可以选择投入增长、盈利/亏损率、技术人员增长率、技术与其他职能部门比率来设定预算。

金句：

必须强调指出：局部激励条件，如果不能正确处理，将会极大激励局部的人员行为，从而破坏整体目标。

标签：技术管理、预算、人员招聘

打造 Instagram 这五年

Mike Krieger 是 Instagram 的联合创始人，他最近在一篇文中回顾了 Instagram 这5年来的发展过程，特别是技术和基础设施的演变，列出如下里程碑：

里程碑1：最大的挑战——3个月内用户达到100万。一开始选择使用物理服务器，后来马上做出决策，切换到云上，并从零开始，从技术社区分享的内容中学习如何运维和管理服务器。

里程碑2：最广为期待的上线——安卓版本上线。上线后，12个小时内就有超过100万新用户加入。Mike Krieger 也分享了自己在这个过程中学习到的基础设施经验。

里程碑3：最糟糕的故障——2012年弗吉尼亚暴风雨导致服务中断。亚马逊机房因暴风雨导致的故障，让 Instagram 决定转向更可以重复使用的服务器部署过程。一开始使用脆弱的 shell 脚本，后来转向完全的 Chef 方式，而且逐步降低使用难度，新加入的技术人员也可以很快上手。

里程碑4：最有野心的工程项目——与 Facebook 的系统整合。2013年，Instagram 已经有两亿用户，本段记录了他们与 Facebook 工程部门和架构的整合过程。重点在于：不要重新发明轮子。

里程碑5：下一个大赌注——趋势标签上线，并构建全新技术基础设施。为了帮助用户识别、排序、展现 Instagram 上的优质内容，他们构建了全新的基础设施。

金句：

我们的准则：先做最简单的事。但这并不意味着你的解决方案一定可用。我们学会了要开放接受产品的演化，有建立有针对性的团队，以适应我们快速增长的社区。

标签：云计算、运维、Facebook、Instagram

无服务器技术创业指南

本文来自 Teletext.io 的创始人。Teletext.io 是一个“内容即服务（Content as a Service）”的平台，为开发人员提供网站和APP 的内容管理服务。

他们仅仅使用Amazon API Gateway、Lambda函数式编程、DynamoDb, S3 和 Cloudfront就完成了整个产品的搭建和上线运行。

文章开宗明义指出：约束产生创造力。

他们的技术团队面临的约束是：不许使用服务器！一台也不行！

为什么？他们列出三个原因：

1. 即使保证最小用量的服务器，也要花钱。
2. 确保服务器的软硬件系统及时更新，占用运维成本。
3. 无法以细粒度向上或向下扩展，只能以单台服务器的粒度进行。

Teletext.io使用微服务架构，基于 API 运行，所以使用服务器会给很多小型任务带来很多不必要的成本。所以，他们使用Amazon API Gateway、Lambda函数式编程、DynamoDb, S3 和 Cloudfront构建出如下产品和服务架构：

• 内容管理

• 内容分发

• 网站

具体的搭建方法和相关数据，可以去原文查看。 

金句：

我们热爱创造性约束条件，并藉此成功上线了不使用服务器的创业项目，它可以自动扩展，有负载均衡和操作系统。这不仅是一种可扩展的解决方案，它还可以应对近乎无限的峰值容量，而且成本低廉。

标签：lamba、CDN、云服务器、对象存储、云 API

李孟：CDN 与 DNS 的设计和研发

在QCon 大会上，我们的研发总监李孟做了一个演讲：《选型指南：CDN与DNS的设计与开发》，主要介绍CDN与DNS业务的特征以及关于其区别的一些误区，评估各种业务场景所需要的CDN与DNS的指标水平；对网络I/O模型和数据存储等关键选型点进行形象的对比分析，以作为预定指标的技术选型参考；分析CDN与DNS如何表达流量调度，并针对关键细节点进行延展探讨。

此外，他还接受了 InfoQ 的视频采访，谈到了我们自己在研发 CDN 和 DNS 时遇到的问题和我们想出来的解决方法。

金句：

对于最初的功能规划和效果，工程师应该结合数据分析，拿到一线的真实数据，完整的数据，然后做相应的调研，再决定是不是采用这种方式。

研发人员应该去做一段时间运维。

标签：CDN、DNS、技术选型

电子书：关于排队论，你应该知道的一切

这本《Everything You Need To Know About Queueing Theory》仍然来自O'Reilly 畅销书《MySQL 高性能实践》的作者Baron Schwartz。他指出：掌握了排队论，你就可以回答如下问题：

关于基础设施：如果网络流量增加30%，服务器会过载吗？ 
关于硬件采购：我是否应该购买更快的磁盘，还是继续采购现有型号即可？
关于团队管理：如果我将团队的工作细分，并在不同角色之间创建交接过程，应该如何进行？

看看本书目录：

• 每个人都应该懂排队论
• 什么是排队论？
• 为什么说排队论有点棘手？
• 现实生活中的排队系统
• 为什么会发生排队现象？
• 排队论框架
• 描述排队系统
• 计算排队长度和等待时间
• Erlang 排队公式
• 近似的Erlang 排队公式
• 多个队列还是一个组合队列？
• 服务成本和质量之间的权衡
• 在现实生活中使用排队论

金句：