新闻动态

完善的7*24小时服务,携手共赢,共同成长

首页 新闻动态云计算文摘 正文

约束、创业维艰、Instagram这五年

2015-12-17 17:58:28   
 
SpeedyCloud 云计算文摘第二期:约束、创业维艰、Instagram这五年

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

我们首先听到《创业维艰》的作者告诉我们:预算,不应该是创业公司最重要的约束条件。接下来,是 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 排队公式
  • 多个队列还是一个组合队列?
  • 服务成本和质量之间的权衡
  • 在现实生活中使用排队论


金句:

 

掌握了排队论,你就可以把你的系统和团队构建得更加高效、更加可扩展、表现更好、成本更低,而且最后可以为你自己和你的客户提供更好的服务。当你需要计算瓶颈出现在何处,以及对性能的影响时,你就会知道应该怎么做。

就像一首歌里唱的:


不知道太多
但我知道我喜欢队列
那也许就是
我需要知道的一切

标签:排队论、运维、团队构建
下载电子书
 
点击回顾SpeedyCloud 云计算文摘第一期:Docker@Uber
 
关注SpeedyCloud官方微博
掌握最新动态和优惠
扫描SpeedyCloud官方微信
获取价值50元免费云主机
欢迎发送邮件到social@speedycloud.cn,聊聊你对于“SpeedyCloud云计算技术文摘”的想法和建议,也欢迎你说出对于SpeedyCloud迅达云成公司的意见和看法。

*|IF:REWARDS|*