作者 ｜ Brian Scanlan
翻译 ｜ 王者
策划 ｜ Tina
从过早优化产品到过度设计解决筹划，在做出技巧决定计划时，你很轻易陷入一些困境，这些决定计划可能会减慢而不是加快公司的成长。
是以，在制订技巧策略时，你须要评估与营业成功相干的每个构成部分。
本文的内容源自我比来在都柏林 AWS 社区日活动上的一次演讲，演讲内容是关于我所经历过的一些行不通的技巧策略，以及赞助我们在 Intercom 实现增长和扩大的策略。
这些只是我的小我不雅点，并不是规矩，当然也弗成能实用于所有情况。
它们是基于我在技巧范畴的工作经验、它们在不合场景中的实际应用以及与同业评论辩论的成果。尽管它们看起来像是某种不雅点，但个中的很多技能都反应了软件工程的重要原则：应用现有的资本、根据须要来设计解决筹划、不要反复本身（DRY）、保持简单和愚蠢（KISS）！
要避免的十大年夜技巧策略
1. 多云架构
假如你在以前几年里一向有存眷一些标语喊得很洪亮的技巧营销，那么你肯定据说过多云。多云是指将应用法度榜样安排到跨多个云供给商的异构云平台上。
固然这些营销看起来还不错，但根据云经济学家 Corey Quinn 的说法，多云违背了最佳实践，是“默认要避免的糟糕实践”。Corey 致力于为他的客户削减 AWS 账单成本，在实践中亲眼目睹了大年夜量的云架构，所以我认为他的经历是一个很好的参考来源。
多云架构对于几乎所有的企业（尤其是始创企业）来说都是一种过早优化，是一个你不想掉落入的陷阱。你的公司可能有很多问题须要解决，这些问题远比任何与多云安排有关的神话般的好处都更有价值。
人们对多云的一个常见误会是多云策略将赞助他们避免供给商锁定，这源于他们对将来营业需求的模糊错觉。并且，这可能很消费资本，因为抽离出任何特定云供给商的价值是很费时的，并且会影响你从云计算中获得好处的才能。
当然，在某些情况下，多云计谋对你有利。除非你是 Netflix 或苹果，并占据了大年夜部分互联网流量。对于大年夜多半企业来说，选择好一个云供给商，不要再想着在它们之间往返移动工作负载。将全部精力放在一个云供给商上，云平台才会展示出它的魔力：易用性、简单性和效力。
2. 应用“最好的对象”
不要应用最好的对象来完成工作，这听起来有悖常理，不是吗？在 AWS 平台上，DynamoDB 可能是最好的高可用键值数据拜访存储对象，Timestream 可能是最好的时光序列数据对象。然而，假如你已经有了一个正在运行的 MySQL Aurora，你就不克不及直接把数据放在那边吗？
“你应当进行全局优化，所以你应当应用已经在应用的对象”。
即使是在云端，增长新技巧也会分散你的留意力。你应当进行全局优化，应用你已经在应用的对象。除非你肯定现有的软件无法知足你的需求，不然不要往你的技巧栈中增长更多的技巧。
在 Intercom，我们称之为“运行更少的软件”，这是我们技巧策略的一部分。我们认为，这对我们来说很有赞助。它赞助我们避免了创建和保护大年夜量会拖慢我们开辟速度的器械。
3. 容器与无办事器主机情况
在刚开端创建始创公司时，可能不是你懂得 Kubernetes 的最佳机会。但假如你已经有一个积聚多年的重要的基本举措措施须要构建，或者假如你的产品是要出售给 Kubernetes 用户，那么可以去懂得。然则，除非你已经异常精晓 Kubernetes，不然的话，启动并运行一个办事的最快办法是应用最简单、最灵活、最常见的构建块，比如在负载均衡器后面安排一堆可主动伸缩的 EC2 主机。
在 Intercom，我们成功地将 Lambda 作为 AWS 办事之间的粘合代码。我认为 Lambda 是一项惊人的技巧，但它应当被用在对的处所。它善于履行由事宜触发的简单义务，比如调剂上传到 S3 存储桶中的图像的大年夜小。我爱好把它们算作是云的存储过程，但我不想用 Lambda 运行一个大年夜型的、复杂的应用法度榜样，因为限制很大年夜，并且在可不雅察性方面还不敷成熟。
由前 AWS 工程师 Daniel Vassallo 和 Josh Pschorr 合著的“The Good Parts of AWS”一书对应当应用 AWS 的哪些部分提出了很好的看法，并对 Lambda 进行了评价。“我们认为 Lambda 是异常棒的??绝对是 AWS 的一个异常好的构成部分??只要你把它算作简单的代码运行器。我们经常看到的一个问题是，人们有时刻会误认为 Lambda 是一个通用的应用法度榜样宿主”。
假如你认为将其参加到你的技巧栈是精确的，那么就把它用在对的处所，不要把它当成一个通用的计算平台，不过它确切可以很好与 AWS 生态体系的其他部分协同工作，何况 Lambda 团队一向在推出异常棒的特点。
4. 微办事不会造成额外的包袱
和 Kubernetes 一样，除非你的团队已经在微办事方面有很多经验，不然大年夜多半始创公司都不该该采取微办事。应用微办事增长了复杂性，增长了掉足的概率，并且与一两个单体办事比拟，构建很多微办事要做更多的工作。
“我们的团队想要开辟产品，而不是保护办事”。
大年夜约 6 年前，在 Intercom，我们认为重要的新功能应当作为自力的办事来开辟，这是弗成避免的。是以，我们构建了一些新功能，比如将 Webhook 和事宜处理作为微办事，与我们的 Ruby on Rails 单系一切通信。但跟着时光的推移，我们发明我们的团队不爱好保护这些办事。
保护这些办事须要大年夜量的开销和沉重的反复工作，与开辟单系一切比拟，在微办事中添加新功能似乎须要更长的时光。我们的团队想要开辟产品，而不是保护办事。在以前的几年里，我们一向在把办事归并回 Ruby on Rails 单系一切中。我想类似的经验也实用于其他面向办事架构的体系。
5. 设备 AWS 控制台
我几乎每次在 AWS 控制台中做设备时都邑懊悔。“单击”操作固然很高效，但具有版本控制、经由同业评审的基本架构定义也很重要。不管你应用的是 Cloudformation、Terraform，照样更高等其余对象 (如 AWS 云开辟对象包)，这些并不重要。任何办法都比在 AWS 控制台中单击鼠标要好。
大年夜多半时刻，经由过程代码或设备定义的基本举措措施更轻易保护。在代码中定义基本举措措施并不必定会很复杂。在控制台中应用模块可能异常强大年夜，但也可能导请安想不到的副感化，所以我更偏向于避免 DRY(不要反复本身)，爱好简单的声明性指令。
6. 范围化构建
云是实现范围化构建的好处所，但这并不料味着你必须这么做。在 1968 年出版的《计算机编程的艺术》一书中，Donald Knuth 指出：“过早优化是万恶之源”。
“在非须要时添加极端的可伸缩性，很轻易让你掉落入技巧债务和低效力的陷阱”。
当然，经由过程应用 S3、Amazon Simple Queue Service (SQS) 和 DynamoDB 等产品，你可以轻松获得不可思议的伸缩性，并且如今的计算机异常快。然则，正如极限编程结合作者 Ron Jeffries 所说的那样：“你很可能不须要它”。在非须要时添加极端的可伸缩性，很轻易让你掉落入技巧债务和低效力的陷阱。现如今，你完全可以用少量的计算机和一个数据库做很多工作。
7. 优化成本
没有人爱好浪花钱，但在云平台上肯定有很多浪花钱的处所。AWS 的计费和优化是一个大年夜难题，尽管原生对象的极大年夜改进和新的购买力情势 (如节约筹划) 让这变得越来越轻易。
我认为最好的办法是对成本做出反响。宣布你构建的器械，然后设置一个日历提示，以便日后跟踪成本。我们很难精确地猜测某些器械须要若干成本??比如，假如你正在构建一个全新的办事，你须要花若干精力来计算相干的带宽费用、Aurora Storage IO 和 Amazon 简单队列办事 (SQS) 的成本？这些并不好估算。
我还发明，人们很爱好在降低项目成本方面“小打小闹”。移除一些没用过的弹性 IP 或 EBS，每个月可以省下不少钱，并且清理器械会给人一种知足感。但它真的会改变营业将来的成果吗？有时刻，我试图为这些行动辩护，因为如许可以让基本举措措施变得更清楚，特别是对于一个有些岁首的 AWS 账户来说。然则，大年夜多半时刻，最好把留意力放在大年夜问题上，而不是小打小闹地降低成本。
话虽如斯，我在 Intercom 确切花了不少时光来优化成本。对于一个在 AWS 上花费巨大年夜、营业需求明白的成熟企业来说，这是绝对值得做的工作，因为这确切会影响实际的营业成果。我们当然不是独一一家经由过程成本优化来削减账单的公司。
8. 复制成功公司的经验
浏览那些曾经是始创公司但如今已大年夜获成功的公司的工程博客，比如 Netflix、Uber 或 Airbnb，这会让你分心，让你为不存在的问题供给过度工程的解决筹划。此外，你真正须要从这些成功的公司获得的信息平日不会在博客或会议演讲中泄漏。这些器械平日是一些工程师为完成 KPI 或 OKR 而做的工作。相反，你应当与范围类似的始创公司的工程师们建立关系。根据我的经验，如许做异常有效。
9. 模仿 Hyperscaler
从成功的始创公司那边获得灵感是件功德，但你绝对不该该去模仿像亚马逊、谷歌和微软如许的大年夜型云供给商。一些公司可能受益于单体代码库、5 个 9 的可用性、微办事或站点靠得住性工程 (SRE)，但这些主如果为懂得决大年夜型组织所面对的问题。与其让始创公司担心他们的混沌工程策略，不如去构建一小群易于懂得的、内置了大年夜量冗余的托管办事，让其他人去担心若何应用混沌工程来改进他们的托管办事。
10. 盲目服从我的看法
对于你的创业公司来说，一个绝对糟糕的技巧策略就是按照你在会议上听到的去做。只有你最懂得你的营业背景和技巧挑衅。核心竞争力和沉重的反复工作之间的差别并不老是泾渭分明的。在定义和实施技巧计谋时，须要推敲大年夜量的工资身分，所以不要盲目地做这些工作。
应当要遵守的 5 种技巧策略
1. 构建安然
安然是互联网行业现今优先级最高的义务。不仅用户的期望比以往任何时刻都要高，像 GDPR 如许的律例也请求在产品中内置合理的安然级别。
“在安然问题上让客户不省心肯定会让客户掉去信念”。
在安然问题上让客户不省心肯定会让客户掉去信念。从一开端就在每个产品和功能中添加安然性要比之后再添加轻易得多。跟着你的公司进入高端市场，与更大年夜客户之间的对话将变得加倍细节化，对你的产品请求也加倍严格。值得光荣的是，这比以往任何时刻都要轻易，因为云平台供给了优胜的安然选项，并且在赓续改进，比如 S3 桶设备，可以避免你在应用云办事时碰到的一些典范的问题。
2. 尽可能多地交付
在 Intercom，我们说“交付就是公司的心脏”。我认为专注于交付的公司可以或许取获成功绝非有时。
我认为由 Nicole forgren、Jez Humble 和 Gene Kim 合著的《加快：精益软件和 DevOps 的科学》一书是高绩效技巧企业的圣经。作者应用研究办法来发明在真实公司中获获成功的最佳实践。假如你关怀你的企业是否可以取获成功，不管是什么行业，你都将从书中获益。
3. 雇用有潜力的人
幻想情况下，你应当要雇用真正想要成长的通才。成长心态本身就能鼓励成长，在一个快速成长的情况中，你会须要它的。专家固然可以供给诱人的临盆力，但最终他们可能会变成拖慢速度的“孤岛”，阻碍协作优势的发挥。
“假如你雇用了拥有深挚专业常识的人，你应当要确保他们可以或许分享专业常识，赞助你成长团队”。
假如全部团队无法解决最大年夜的问题，你就不会获得最好的解决筹划。你要让团队成员成长为可以深刻懂得公司重要问题的人，而不是成为“孤岛”。假如你确切雇佣了拥有深挚专业常识的人，你应当要确保他们可以或许分享专业常识，赞助你成长团队。
4. 把留意力放在上层办事上
正如我所提到的，应用少量易于懂得的办事是明智的做法。Elasticache、SQS 和 Amazon 关系数据库办事 (RDS) 是更好的默认选择，而不是应用本身的 Memcached、RabbitMQ 或本身保护的 MySQL 集群。
同样地，我认为一些云安然治理和 AI/ML 办事看起来异常棒，在建立类似的器械之前，我会先研究一下它们。当你确切须要解决一些超出当前技巧栈的问题时，我建议先避免本身去构建任何器械，而是简单地应用现有云供给商供给的器械。
5. 以客户为中间
假如你真的把这一点付诸实践，这意味着世界级的可不雅察性、监督、最佳运维实践、优胜的正常运行时光、机能和靠得住的安然性。
我认为 Jeff Bezos 所说的“老是从客户角度出发”这个不雅点是对的。我在亚马逊工作时第一次听到了这个不雅点，在 Intercom 工作之后就加倍肯定了。假如你不知道你的客户在做什么，体验什么，思虑什么，你就不是在存眷他们。像 Intercom 和 Honeycomb 如许优良的对象可以赞助你更好地懂得你的客户。
原文链接：
https://www.intercom.com/blog/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace
纵不雅20年间法度榜样员薪酬变更：涨幅降低，初级编码岗大年夜幅消掉
腾讯技巧Leader人均写3万行代码；拼多多超出阿里成为第一；360搜刮、UC浏览器因虚假医药告白被点名下架 | Q资讯
缓存踩踏：Facebook 史上最严重的宕机事宜分析
InfoQ 写作平台迎接所有酷爱技巧、酷爱创作、酷爱分享的内容创作者入驻！
还有更多 超值活动等你来！
填写申请，成为作者
开启你的创作之路吧~
点个在看少个 bug??
- 上一篇： “软硬兼施”建设数字乡村
- 下一篇： 闯入百亿美金的无代码市场，「MoPower」想让企业更个性一些
