小公司应该避免的十大技术策略和应该遵循的五大建议
共 5473字，需浏览 11分钟
·
2021-04-02 12:34
因此，在制定技术策略时，你需要评估与业务成功相关的每个组成部分。
本文的内容源自我最近在都柏林 AWS 社区日活动上的一次演讲，演讲内容是关于我所经历过的一些行不通的技术策略，以及帮助我们在 Intercom 实现增长和扩张的策略。
这些只是我的个人观点，并不是规则，当然也不可能适用于所有情况。
它们是基于我在技术领域的工作经验、它们在不同场景中的实际应用以及与同行讨论的结果。尽管它们看起来像是某种观点，但其中的很多技巧都反映了软件工程的主要原则：使用现有的资源、根据需要来设计解决方案、不要重复自己（DRY）、保持简单和愚蠢（KISS）！
如果你在过去几年里一直有关注一些口号喊得很响亮的技术营销，那么你肯定听说过多云。多云是指将应用程序部署到跨多个云提供商的异构云平台上。
虽然这些营销看起来还不错，但根据云经济学家 Corey Quinn 的说法，多云违背了最佳实践，是“默认要避免的糟糕实践”。Corey 致力于为他的客户减少 AWS 账单成本，在实践中亲眼目睹了大量的云架构，所以我认为他的经历是一个很好的参考来源。
多云架构对于几乎所有的企业（尤其是初创企业）来说都是一种过早优化，是一个你不想掉入的陷阱。你的公司可能有很多问题需要解决，这些问题远比任何与多云部署有关的神话般的好处都更有价值。
人们对多云的一个常见误解是多云策略将帮助他们避免供应商锁定，这源于他们对未来业务需求的模糊错觉。而且，这可能很耗费资源，因为抽离出任何特定云提供商的价值是很费时的，并且会影响你从云计算中获得好处的能力。
当然，在某些情况下，多云战略对你有利。除非你是 Netflix 或苹果，并占据了大部分互联网流量。对于大多数企业来说，选择好一个云提供商，不要再想着在它们之间来回移动工作负载。将全部精力放在一个云提供商上，云平台才会展现出它的魔力：易用性、简单性和效率。
不要使用最好的工具来完成工作，这听起来有悖常理，不是吗？在 AWS 平台上，DynamoDB 可能是最好的高可用键值数据访问存储工具，Timestream 可能是最好的时间序列数据工具。然而，如果你已经有了一个正在运行的 MySQL Aurora，你就不能直接把数据放在那里吗？
“你应该进行全局优化，所以你应该使用已经在使用的工具”。
即使是在云端，增加新技术也会分散你的注意力。你应该进行全局优化，使用你已经在使用的工具。除非你确定现有的软件无法满足你的需求，否则不要往你的技术栈中增加更多的技术。
在 Intercom，我们称之为“运行更少的软件”，这是我们技术策略的一部分。我们认为，这对我们来说很有帮助。它帮助我们避免了创建和维护大量会拖慢我们开发速度的东西。
在刚开始创立初创公司时，可能不是你了解 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 团队一直在推出非常棒的特性。
和 Kubernetes 一样，除非你的团队已经在微服务方面有很多经验，否则大多数初创公司都不应该采用微服务。使用微服务增加了复杂性，增加了出错的概率，而且与一两个单体服务相比，构建很多微服务要做更多的工作。
“我们的团队想要开发产品，而不是维护服务”。
大约 6 年前，在 Intercom，我们认为重要的新功能应该作为独立的服务来开发，这是不可避免的。因此，我们构建了一些新功能，比如将 Webhook 和事件处理作为微服务，与我们的 Ruby on Rails 单体系统通信。但随着时间的推移，我们发现我们的团队不喜欢维护这些服务。
维护这些服务需要大量的开销和繁重的重复工作，与开发单体系统相比，在微服务中添加新功能似乎需要更长的时间。我们的团队想要开发产品，而不是维护服务。在过去的几年里，我们一直在把服务合并回 Ruby on Rails 单体系统中。我想类似的经验也适用于其他面向服务架构的系统。
我几乎每次在 AWS 控制台中做配置时都会后悔。“单击”操作虽然很高效，但具有版本控制、经过同行评审的基础架构定义也很重要。不管你使用的是 Cloudformation、Terraform，还是更高级别的工具 (如 AWS 云开发工具包)，这些并不重要。任何方法都比在 AWS 控制台中单击鼠标要好。
大多数时候，通过代码或配置定义的基础设施更容易维护。在代码中定义基础设施并不一定会很复杂。在控制台中使用模块可能非常强大，但也可能导致意想不到的副作用，所以我更倾向于避免 DRY(不要重复自己)，喜欢简单的声明性指令。
云是实现规模化构建的好地方，但这并不意味着你必须这么做。在 1968 年出版的《计算机编程的艺术》一书中，Donald Knuth 指出：“过早优化是万恶之源”。
“在非必要时添加极端的可伸缩性，很容易让你掉入技术债务和低效率的陷阱”。
当然，通过使用 S3、Amazon Simple Queue Service (SQS) 和 DynamoDB 等产品，你可以轻松获得难以想象的伸缩性，而且现在的计算机非常快。但是，正如极限编程联合作者 Ron Jeffries 所说的那样：“你很可能不需要它”。在非必要时添加极端的可伸缩性，很容易让你掉入技术债务和低效率的陷阱。现如今，你完全可以用少量的计算机和一个数据库做很多事情。
没有人喜欢浪费钱，但在云平台上肯定有很多浪费钱的地方。AWS 的计费和优化是一个大难题，尽管原生工具的极大改进和新的购买力形式 (如 节约计划) 让这变得越来越容易。
我认为最好的办法是对成本做出反应。发布你构建的东西，然后设置一个日历提醒，以便日后跟踪成本。我们很难准确地预测某些东西需要多少成本——比如，如果你正在构建一个全新的服务，你需要花多少精力来计算相关的带宽费用、Aurora Storage IO 和 Amazon 简单队列服务 (SQS) 的成本？这些并不好估算。
我还发现，人们很喜欢在降低项目成本方面“小打小闹”。移除一些没用过的弹性 IP 或 EBS，每个月可以省下不少钱，而且清理东西会给人一种满足感。但它真的会改变业务未来的结果吗？有时候，我试图为这些行为辩护，因为这样可以让基础设施变得更清晰，特别是对于一个有些年头的 AWS 账户来说。但是，大多数时候，最好把注意力放在大问题上，而不是小打小闹地降低成本。
话虽如此，我在 Intercom 确实花了不少时间来优化成本。对于一个在 AWS 上花费巨大、业务需求明确的成熟企业来说，这是绝对值得做的工作，因为这确实会影响实际的业务结果。我们当然不是唯一一家通过成本优化来减少账单的公司。
阅读那些曾经是初创公司但现在已大获成功的公司的工程博客，比如 Netflix、Uber 或 Airbnb，这会让你分心，让你为不存在的问题提供过度工程的解决方案。此外，你真正需要从这些成功的公司获得的信息通常不会在博客或会议演讲中透露。这些东西通常是一些工程师为完成 KPI 或 OKR 而做的事情。相反，你应该与规模相似的初创公司的工程师们建立关系。根据我的经验，这样做非常有效。
从成功的初创公司那里获得灵感是件好事，但你绝对不应该去模仿像亚马逊、谷歌和微软这样的大型云供应商。一些公司可能受益于单体代码库、5 个 9 的可用性、微服务或站点可靠性工程 (SRE)，但这些主要是为了解决大型组织所面临的问题。与其让初创公司担心他们的混沌工程策略，不如去构建一小群易于理解的、内置了大量冗余的托管服务，让其他人去担心如何使用混沌工程来改进他们的托管服务。
对于你的创业公司来说，一个绝对糟糕的技术策略就是按照你在会议上听到的去做。只有你最了解你的业务背景和技术挑战。核心竞争力和繁重的重复工作之间的区别并不总是泾渭分明的。在定义和实施技术战略时，需要考虑大量的人为因素，所以不要盲目地做这些事情。
安全是互联网行业现今优先级最高的任务。不仅用户的期望比以往任何时候都要高，像 GDPR 这样的法规也要求在产品中内置合理的安全级别。
“在安全问题上让客户不省心肯定会让客户失去信心”。
在安全问题上让客户不省心肯定会让客户失去信心。从一开始就在每个产品和功能中添加安全性要比之后再添加容易得多。随着你的公司进入高端市场，与更大客户之间的对话将变得更加细节化，对你的产品要求也更加严格。值得庆幸的是，这比以往任何时候都要容易，因为云平台提供了良好的安全选项，而且在不断改进，比如 S3 桶配置，可以避免你在使用云服务时遇到的一些典型的问题。
在 Intercom，我们说“交付就是公司的心脏”。我认为专注于交付的公司能够取得成功绝非偶然。
我认为由 Nicole forgren、Jez Humble 和 Gene Kim 合著的《加速：精益软件和 DevOps 的科学》一书是高绩效技术企业的圣经。作者运用研究方法来发现在真实公司中获得成功的最佳实践。如果你关心你的企业是否可以取得成功，不管是什么行业，你都将从书中获益。
理想情况下，你应该要招聘真正想要成长的通才。成长心态本身就能鼓励成长，在一个快速成长的环境中，你会需要它的。专家虽然可以提供诱人的生产力，但最终他们可能会变成拖慢速度的“孤岛”，阻碍协作优势的发挥。
“如果你招聘了拥有深厚专业知识的人，你应该要确保他们能够分享专业知识，帮助你发展团队”。
如果整个团队无法解决最大的问题，你就不会得到最好的解决方案。你要让团队成员成长为可以深入理解公司主要问题的人，而不是成为“孤岛”。如果你确实雇佣了拥有深厚专业知识的人，你应该要确保他们能够分享专业知识，帮助你发展团队。
正如我所提到的，使用少量易于理解的服务是明智的做法。Elasticache、SQS 和 Amazon 关系数据库服务 (RDS) 是更好的默认选择，而不是使用自己的 Memcached、RabbitMQ 或自己维护的 MySQL 集群。
同样地，我认为一些云安全管理和 AI/ML 服务看起来非常棒，在建立类似的东西之前，我会先研究一下它们。当你确实需要解决一些超出当前技术栈的问题时，我建议先避免自己去构建任何东西，而是简单地使用现有云提供商提供的东西。
如果你真的把这一点付诸实践，这意味着世界级的可观察性、监视、最佳运维实践、良好的正常运行时间、性能和可靠的安全性。
我认为 Jeff Bezos 所说的“总是从客户角度出发”这个观点是对的。我在亚马逊工作时第一次听到了这个观点，在 Intercom 工作之后就更加肯定了。如果你不知道你的客户在做什么，体验什么，思考什么，你就不是在关注他们。像 Intercom 和 Honeycomb 这样优秀的工具可以帮助你更好地了解你的客户。
后台回复 学习资料 领取学习视频
如有收获，点个在看，诚挚感谢