Monolith or Microservice?

在下一篇文章中了解有关微服务的更多信息 Streaming Media West.

阅读这段录音的完整文本:

Tanu Aggarwal: 我要说的是，什么时候应该采用整体服务，什么时候不应该采用微服务，以唤醒所有人，让他们从发布后的午餐昏迷中清醒过来. 如果你开始做一件新事情，或者开始做一件小事，这似乎是毋庸置疑的, 拥有完美的微服务架构, 让我们分开，重新开始吧. 然而，这里也有理由支持巨石. 如果你正在开发一个新产品, 如果你想给市场带来新东西, 如果你在做概念验证, for example, 实际上你可能需要多次转动. 你的产品将经历多次迭代. 你真的想陷入微服务的混乱吗?

正如Nermeen所指出的，它们很复杂. 在使用微服务时，您必须预先做出许多决定. 也许在你的产品生命周期的那个时候，从一个整体开始是正确的. 你的团队中可能有几个开发人员，你开始开发产品. Then what do you do? 你是从微服务开始还是从整体开始? Maybe you don't do both. You go the middle path. 你可以用平行发展的方式来划分它.

这和Nathan提到的并行化有点不同. 这实际上是关于能够并行开发，并且这些服务可以一起工作. 我之所以主张在你的游戏中尽可能推迟使用微服务，是因为你不希望预先进行投资. 你要专注于你的核心竞争力. Get your product out, 让一些实时流量通过它, evaluate it, monitor it, 你会惊讶地发现你认为需要缩放的部分实际上并不是最后需要缩放的部分. 这是需要注意的.

Olga Kornienko: I would not agree 100%. Granted, 我对这种观点有偏见, 但我也认为你需要弄清楚你的核心竞争力是什么. I fully agree with that. 找出你绝对需要控制的部分, need to be in charge of, 并且可以转移到微服务中. 然后决定它是否值得你花时间去开发, build, 然后把这些都算出来, 或者联系微服务提供商更方便. 你没有那么多的启动成本. 你没有那么多需要投资的基础设施, 为了启动一个可以作为微服务购买或需要的服务, 然后决定你需要的几个绝对会改变的组件, will be pivoting, 你需要的两种东西可以从现成的供应商那里买到，然后结合起来. 我认为这是最好的解决办法.