Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I am of the same mind, microservices is more for scalability both in a multiple instances way and multiple developer teams and not in speed on a single instance.
You might get improvement due to less internal complexity in each service but the extra communication will add extra latency in most cases. -
I think the problem with Twitter and microservices is misunderstood in that the problem isn't microservices but the amount of microservices or how they were used by Twitter.
In Musk's opinion, many of them aren't needed and can just be turned off. If it is the right way to just rip cables in the server room is debatable, but Twitter is somewhat still running, which is a miracle if it is true that many microservices were turned off and thrown away.
I've heard complaints that specific functions didn't work, e.g. 2FA, which would be very critical, but these outages, IIRC, didn't last long.
The negativity for microservices exists because of the way Musk and his Musketeers ranted about the topic, even though the problem is very unlikely to be microservices but the way Twitter used microservices. -
@jonas-w I still think that it does require all this drama. We all know that we have some useless legacy services running, most of the time we forget about them, and turn them down when they trigger an alert.
Would still be interested in seeing what the architecture of Twitter look like, but working with a well designed architecture is very satisfying -
-
@SuspiciousBug yes, I think you have to start easy and not to micro, at least if you have no real experience building microservices.
That what we are trying right now, to break the monolith into maybe a dozen or slightly more services.
Later on those might be broken down further if we find that there are clear benefits for it but yes, the more services the more extra calls you need adding latency.
So unless you really need to make the services very small I like your example “reasonably “ sized :) -
I listened to a 1 hour conversation with Elon and George Hotz trying to dig into the twitter codebase https://youtu.be/x09bBEelbXA
What I gathered was basically that
* Twitter microservices aren't necessarily isolated. (Or perhaps they are but many changes require data models to change everywhere)
* Local dev is hard - to test one service within the context of the entire stack you have to wait for a 10 minute deployment of that service
(PS: not putting too much belief in this - as Elon and Hotz are new to the company and Hotz is said to be infamous for wanting to experiment on his own rather than being introduced to a codebase) -
We should define the term microservice.
I think of microservices as when a single team has a feature that normally would be a single service but they decide to divide it up into multiple services. Like if rendering the head and body for a html article would be separate services.
I do NOT consider it a microservice architecture when a large company with multiple teams have one service per team (like a separate CMS, authService, contentAPI, Web frontend and app frontend) that's not a microservice architecture to me - it's just the default when you have multiple teams. If you have 10 teams then having at least 10 services is normal. Having 1 monolith would be an exception. Having 200 services could be a microservice architecture.
So, I've been reading all this complaints about micro services which started to be loud thanks to the mad CEO of Twitter.
Keep reading but I am curious about your opinion as well
To me all the point of micro services has never been about improving the speed, in fact it might have a negative impact on the performances of an application. I think that given the calculation power we have nowdays, it's not a big deal
However on the other side, it makes all the rest so much easier.
When there's a problem on one service, I can just debug the given service without spending hours starting a huge slow turtle
If something goes down, it doesn't make unhealthy the whole app, and if I am lucky it's not gonna be a critical service (so very few people will be pissed).
I have documentation for each of them so it's easier to find what I am looking for.
If I have to work on that particular service, I don't have to go through thousands of tangled lines of code unrelated to each other but instead work on an isolated, one-purpose service.
Releasing takes minutes, not hours, and without risk of crashing everything.
So I understand the complaint about the fact that it's making the app run slower but all the rest is just making it easier.
Before biting my ass, I am not working at Twitter, I don't know the state of their application (which seems to be extremely complicated for an app deigned to post a bit of text and a few pictures), but in a company with skilled people, and a well designed architecture.
rant