内容简介：What you’re about to read is an excerpt fromGo Time #114. You should read theoriginal transcript or listen to the entire conversation for more context. To set the stage, this is the 2nd ofMonoliths are the future because the problem people are trying to so
What you’re about to read is an excerpt fromGo Time #114. You should read theoriginal transcript or listen to the entire conversation for more context. To set the stage, this is the 2nd of Kelsey Hightower’s unpopular opinions (our new segment which people seem to be enjoying.)
Monoliths are the future because the problem people are trying to solve with microservices doesn’t really line up with reality. Just to be honest - and I’ve done this before, gone from microservices to monoliths and back again. Both directions.
Most people say,
“Look, we lost all of our discipline in the monolith. We just started creating classes, this person went and bought the Gang of Four book , came back and started doing design patterns and then QUIT , so half our codebase is doing this thing over here…”
So now it’s a nightmare. Now the codebase is so bad, and you say,
“You know what we should do? We should break it up. We’re gonna break it up andsomehow find the engineering discipline we never had in the first place.”
And then what they end up doing is creating 50 deployables, but it’s really a distributed monolith. So it’s actually the same thing, but instead of function calls and class instantiation, they’re initiating things and throwing it over a network and hoping that it comes back. And since they can’t reliably make it come back, they introduce things like Prometheus , OpenTracing , all of this stuff. I’m like, “What are you doing?!”
Now you went from writing bad code to building bad infrastructurethat you deploy the bad code on top of. There are reasons that you do a microservice. So, to me a microservice makes sense in the context of…
You’re a bank, and you have this big monolith that does everything. Then mobile comes out. You wanna do mobile banking, but it requires a different set of APIs. You don’t have to add that to the monolith. You can go create a new application that handles most of the mobile concerns, and then connect back to the existing infrastructure to do its work. That makes sense to me. But this idea of “microservices are a best practice” - it seems to be unpopular with most people’s initiatives .
They’re like,
“Oh, we’re bringing inKubernetes, so we can do microservices. We are going to rearchitect everything.”
Because it drives a lot of new spend, it drives a lot of new hiring…
So a lot of people get addicted to all the flourishment of money, and marketing, and it’s just a lot of buzz that people are attaching their assignment to, when honestlyit’s not gonna necessarily solve their problem.
Hear Kelsey’s expert opinion on where Kubernetes is headed (and more) :point_down:
以上所述就是小编给大家介绍的《Monoliths are the future》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
反应式设计模式
Roland Kuhn、Brian Hanafee、Jamie Allen / 何品、邱嘉和、王石冲、林炜翔审校 / 清华大学出版社 / 2019-1-1 / 98.00 元
《反应式设计模式》介绍反应式应用程序设计的原则、模式和经典实践，讲述如何用断路器模式将运行缓慢的组件与其他组件隔开、如何用事务序列(Saga)模式实现多阶段事务以及如何通过分片模式来划分数据集，分析如何保持源代码的可读性以及系统的可测试性(即使在存在许多潜在交互和失败点的情况下)。 主要内容 ? “反应式宣言”指南 ? 流量控制、有界一致性、容错等模式 ? 得之不易的关于“什么行不通”的经验 ? ......一起来看看 《反应式设计模式》 这本书的介绍吧!
