英文:
What is the real world performance overhead that comes with containerization?
问题
支持者表示性能成本微不足道，而这种权衡带来的好处包括可扩展性和可用性等。我想要了解的是，在实际情况下，容器编排何时是合理的，并且如何最好地进行？这种高流量的最常见问题是什么？（最好附带一个示例技术堆栈）我最近读到，Prime Video通过将架构的一部分更改为单体式已将成本削减了90%。很难想象，因为我已经将一些应用程序的部分容器化，而这些应用程序之间的请求远没有这么多 - 所以这更多是一个实际操作的问题。谢谢。
不是一个问题，只是想向有实际经验的人请教建议。
英文:
Proponents say performance cost is negligible and that trade off comes with benefits such as scalability and uptime etc. What I'm trying to get at is when in a real world scenario would container orchestration be justifiable, and what would be the best way to go about it? What are the most common issues with such high traffic? (with an example tech stack preferably) I read recently that prime video had cut costs by 90% by changing the part of the architecture to a monolith style. It's hard to imagine, because I've containerized parts of apps that don't receive anywhere near the number of requests between services - so this is more of a in practice question. Thanks.
not really a problem, would like to ask people with practice experience for advice.
答案1
得分: 1
在应用程序世界中，一切都是一种权衡。话虽如此，关于系统设计的选择，无论是单体架构还是微服务方式，都是非常项目特定的决策。
你在Prime视频部分的观点是正确的，他们通过切换回传统的单体架构节省了大量资金。话虽如此，这是否容易？实际上并不是。想象一下设计一个能够满足团队所需的大多数规模和可用性要求的单体架构所需的努力水平。
回答你的问题，我认为容器编排的使用/应用在两种主要情况下是合理的。首先，你的应用程序与容器编排所提供的功能非常匹配。另一个，也是最重要的一个，是你或你的团队能够理解和管理复杂的构建和编排工具，比如Kubernetes，正如我在两种情况下明确提到的原因，我见过许多严重的错误发生，都是由于缺乏适当的理解。
最后，以下是一些与容器化相关的额外开销/挑战的列表：
- 主机和容器之间的抽象，这会给管理它们带来额外的开销。
- 正如Burak所指出的，容器有自己的网络接口，管理它比在主机上运行应用程序稍微复杂一些。
- Docker-应用程序的隔离，以一种我们在第1点中讨论的操作进程的抽象方式进行。
- 分布式日志记录，假设容器Pods/ Docker实例根据负载需求不断启动和关闭。记录/日志存档是一个具有挑战性的任务。
希望这有所帮助。
英文:
Everything is a trade-off in the Application world. Being said the choice of System design whether it's a Monolith or MicroService way is a very project-specific decision.
You are correct on the Prime video part where they saved tons of $ by switching back to good old monolith Architecture. Being said that is it that easy? no really. Imagine what level of effort was gone into designing a monolith that fulfills the majority of the requirements regarding scale, and availablity needed by the team.
Answering your question I think the use/application of container orchestration is justifiable in two major scenarios. first, your application fits well with what container orchestration has to offer. and other and most important one is your or your team is capable of understanding and managing complex builds and orchestration-based tools like let's say Kubernetes. I explicitly mentioned the reason in two cases I have seen major blunders happening due to lack of proper understanding.
Lastly here are a few lists of overhead/challenges due to containerization:
- Abstraction between host and container which brings additional overhead to managing them
- As pointed out by Burak containers have their own networking IF. managing that is a bit overhead rather than running the app on the host itself.
- Docker-App isolation that too in an abstracted way of operating processes which we discussed in point 1.
- Distributes logging, Assuming container pods/docker instances come on and off as per load requirements. logging/log archiving is a challenging task.
Hope this helps.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论