构建简单的东西时避免复杂的基础设施
构建简单的东西时避免复杂的基础设施
原文：https://medium.com/hackernoon/after-i-just-do-all-this-itll-be-so-simple-de73c5f799e2
3 条关于如何保持简单和避免复杂的建议
“你不明白——一旦我安装了 consul，为我的微服务设置了服务发现，构建了我自己的容器化持续集成管道，使用我的定制语言特定的 Dockerfile 从源代码构建了我的代码，并设置了我的高度可用的生产数据库，我的用于将代码部署到生产的系统将变得如此简单
“我的团队有多少人？哦，只有我。但是有一天..”
叹息；-).
我们用来降低复杂性的东西有很多复杂性。这一点值得注意。三个例子:
何时使用微服务
当它使事情比仅仅部署一个简单的单片应用程序更容易维护时。如果你可以很容易地部署一个单一的应用程序(例如，你是一个小团队，它不是一个巨大的应用程序)，你可能应该这样做。与简单的整体应用相比，微服务的基础设施复杂性成本很高。服务发现、多个组件、编排——这些东西不是免费的，它们会爆炸，你必须修复它们，维护它们。只有当一个单一的应用程序无法扩展时，才需要支付这笔费用。
何时运行自己的数据库
为了地方发展，去疯吧。对于实际的生产应用..我认为你应该避免这样做，直到你的业务规模扩大到有人会为你这样做。如果这看起来有争议，做一下计算:包括备份它，修补它，保持它的高可用性，花费的时间而不是在你的差异化功能上，等等。有许多可用的数据存储服务可以为您完成所有这些工作，并让您将有限的时间集中在您的应用程序上，当您考虑到运行生产数据库的实际成本时，它们真的非常便宜。编写您的应用程序，以便在以后需要时迁移到您自己的数据库的成本不太可能很高。管理一个简单的 web 应用程序，而不是管理一个 web 应用程序、一个生产数据库、一个消息队列等等，这是一个巨大的成功。
旁白:但是我怎么能信任别人来运行我的数据库呢？
你怎么能信任他们来运行你的 IaaS / blob 存储/负载平衡器/容器注册表等等？现在是 2017 年，我们都依赖于其他人现在维护的云服务。
什么时候应该使用容器？
看，我实际的工作是写容器。我喜欢容器。集装箱太神奇了。90%的开发者应该不需要和他们打交道。
使用一个平台，让你推送代码，并负责打包、修补操作系统、绑定服务、路由日志、负载平衡等。如果你正在编写这个平台，容器是一个很好的工具。如果你只是想获取代码并在生产中运行，它们会分散你的注意力。有像云铸造 ( 免责声明)这样的平台:我在上面工作并且热爱！)完全隐藏容器，或者像 Kubernetes 之上的 Deis Workflow 这样的平台，看看是否有符合你需求的托管版本。看看像 AWS Lamda 这样的“无服务器”系统，也许它们就是你所需要的。AppEngine 值得一看，尽管你可能最终会有点耦合到平台上。容器是构建 PaaS 的伟大工具，如果您可以使用现有的 PaaS，您可能会节省大量时间和复杂性。
所有这些规则的重要例外
你做这个是为了好玩，只是为了学习，作为一种爱好，还是因为你在为一家确实存在这些问题的大公司工作？或者，您是否正在编写一个持久的分布式服务或一些真正需要定制编排的东西？疯狂吧，享受吧！
黑客中午是黑客如何开始他们的下午。我们是 T21 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面、喜欢/在脸书上给我们发消息，或者简单地发送 tweet/DM @HackerNoon。