3 ms·
I'd be going back to asking why you want to split it off though. If there's legitimate reasons for that then my other concern would be what about areas of the e
by davzie 5y ago
I'd be going back to asking why you want to split it off though. If there's legitimate reasons for that then my other concern would be what about areas of the existing codebase that are intertwined with those messages' modelling. Let's say you use the messages as objects throughout the system and those objects have their own methods that give you some nice way to intepret / action those messages. Now what? Do you need to re-write all that, create a shared library of models etc? It does add complexity and I'd always be last-resorting it.
- mg 5y agoThe motivation to split it off would be to make development easier. One developer can work on the messages codebase and the other one on the tweets codebase. Without much friction between them. Looking around on the Twitter website, I would expect there to be rather little entanglement of the messages functionality with the rest of the site.
- davzie 5y agoI agree, but I'm framing this entire talk about why people use microservices / these technologies prematurely. If you're at Twitter's scale, not only do you have a technical requirement to scale such an endpoint more than others, but also a people problem in that you want teams to be a bit more autonomous in the work that they do. None of that really applies to most companies. I just feel like most companies blindly model their developent practices off of FAANG when it actually hinders their development velocity instead of helps it.
- tored 5y agoAs long as you don’t have any dependencies between the services. But as soon as you do, which is probably the case, you end up doing method calls over HTTP and you need to have a strategy for refactoring two services at the same time that can be online at the same time but with different versions.