To Microservices and Back Again
Vložit
- čas přidán 21. 07. 2024
- QCon London International Software Development Conference returns on April 8-10, 2024. Level-up on 15 major software and leadership topics including; The Tech of FinTech, What's Next in GenAI and Large Language Models (LLMs), Performance Engineering, Architecture for the Age of AI, Innovations in Data Engineering and more.
Learn the emerging trends. Explore the use cases. Implement the best practices.
Register now: bit.ly/3rRgsJV
--------------------------------------------------------------------------------------------------------------------------------------
Video with transcript included: bit.ly/3dgDsox
Alexandra Noonan talks about what microservice antipatterns to avoid, the tradeoffs between microservices and a monolith, how to identify when it's time to take a step back and make a big change, and how moving to a monolith was the solution that worked for Segment.
This presentation was recorded at QCon London 2020: bit.ly/2VfRldq
#Monolith #Antipatterns #Microservices - Věda a technologie
The title of the talk should be: "How disastrous architectural choices cannot be recovered with ''microservices"...
I think MS would work if she separates destination business logic from third party integration logic in the worker. I mean I would have only one service for destination logic and create adapter services for each third party destination. Third party destination logic applying SRP will change only for integration logic reasons leaving business logic changes to the Destination/Single Worker service. In that way you can scale each services independently. IMO shared library should not have business logic, I think the team should be careful what to put in there. Business logic is more likely to change than common utilities functionalities or shared business abstractions but even though the team should decide what is appropriate to share and how. Is better to have granular shared libraries than a single big shared library.
2022 back to microservices again
I wonder why workers (monolith) can not be configured on deploy stage to handle particular service only? It seems like best of both worlds. You got full service isolation, single repo and simple monolith to test. It is probably also easy to scale/repliacte workers.
@InfoQ thank you so much for this content. I love to watch the presentations. So insightful.
Great presentation.
Using shared code library was the main problem. API for the external resources are independent from each other and not likely to change that often, so having shared library serves no benefit, on the contrary goes against the whole idea of having microservises. If it is development time you are trying to save copy paste would work. I think It was this shared library that broke your tests when you had monorepo. Otherwise, having mono or multirepo should not effect how your code works.
What's going on at 30:51 with the tests? Not understanding why the tests can suddenly speed up so much.
Is it actually saving time by comparing with historical responses from the destination apis instead of requesting them at the moment of running tests (is this how it was previously done)?
Then this would mean a risk of the destination api updating but the saved responses and tests which depend on them not being aligned with the most updated current response.
What does "playback" mean? Why wasn't this 2 phase save to file, then playback done to speed up tests previously?
Also how is the invalid test credential at 29:50 dealt with? At 34:20, how does moving back to monolith help with this invalid credential issue? What exactly does "more resilient" mean?
CI/CD first and Microservice
Mono code base could also make multiple deployables.
Their "microservice architecture" don't look like something that hard to implement without any microservices... Also I don't get why except a 'cool'-factor they switch to microservices at all...
many workers != microservices
distributed != microservices
modularity != microservices
scalability != microservices
stability != microservices
microservices is just OOP on a growth hormones. It is good for meat...only
Somtimes that meat is what you need, but it not a common case.
I think the big mistake was to implement a shared library because you broke the rule of total independence between the microservices, thats why you needed to deploy all microservices when changing the shared library
Agree. Rule number one for microservices is to not share code with other services.
@@SamiAlKhatibTA just red in a book today: either extract code to its own microservice or just duplicate it
@@MogelBoom yeah, exactly, I agree.
And didn't initially build tools and institute strong rules for managing the diversity of implementation across services. As a result, the different services became too complex and diverse to be easily managed.
@Behrang Saeedzadeh you're describing stateless utilities that don't house business logic, which you can build and spread freely across microservices, however in the talk, she described libraries that contained business logic/business related transactions which should be isolated to the microservices using them. They're both libraries like you said, but I think op's speaking of one type and not both.
There aren't that much truthful stories about coming back to monolith. Pretty interesting.
seems like 12 people accidentally watched this video with their laptop upside down and mistook the like button . Thanks for the great talk!
I think actor model could be a better fit than microservices to solve your problems.
For not moving from microservices to monolith and from monolith to microservices , you must hire Architect.
Is there any tldr, the title is not convincing.
Started with monolith, ran into issues --> switched to microservices, worked for a bit then ran into operational issues --> switched back to monolith but now had more understanding of their needs and tradeoffs (and built better tooling) so now they're happy.
Pretty much: Started with Monolith, switched to MS, broke the major rule of independence in code base, f*cked up a lot, rerolled to Monolith
Had 4 devs. Built a monolith. Hired more devs. Ran into problems with production support and infrastructure. Replaced system with micro services. Company grew to 150 devs, and 150 micro services. Devs forced to do devops. Devs don’t like devops. Devs replace microservices with monolith. System starts having performance and stability issues again. Devs solve problem by adding more code to automatically restart crashing processes. Devs no longer getting calls at 2am. Problem solved. :)
With her sneezing I'm not sure If she have flu or corona :3
Seriously now a conference? I see this article on my google feed and got irritated and now comes a video. Yes monoliths have their own scenarios but seriously why is this monoliths are better than microservices and think before you step into microservices crap being thrown by many people. Enterprise level architectures are built on microservices and that's why we have Netflix, Ali baba running flawlessly.
The thing is most of the time microservices are used with no fundamental reason - mainly people following the microservices hype. By default microservices don't solve any problem as far as I know. If you are Netflix, you are dealing with problems completely out of scale compared to 99% of compagnies.
Up to 6:03 you described an already failing MS structure with the reliability of your event translator. You started out wrong in the very beginning. Without watching the rest of the video I could tell you that infrastructure would fail in less than a few years. The problem starts in your que. If you are sending one global piece of data to a que and then letting some worker pick up that data, translate it and then send it back out, you have not only doubled the work of the que itself but also made your entire world reliant on that sole translator to get everything correct. Micro services are not supposed to be aware of each other. So your translator already doesn't fit in. And not every MS needs to be event driven. You have multiple versions. You can have event driven listeners or even specific APIs to a MS
It is not that monolithic is better or even the right answer. It is absolutely not the right answer. You are essentially building a Post Office every time you want to mail a letter. You are simply using your micro services incorrectly. If you want to accept a payment, then send an API call to your payment MS. But if you want to work with images and every image in your system must be converted and formatted, then send an image event to your QUE and then let the image worker, whom is listening to that event, pick up that message and work with the image. Part of that QUE message can be a callback for the worker to report back to.
Your goals must be to increase the speed of building new products. You do this by building all of the common parts one single time, so that when you think of a new product, you only build the new parts.
In any Enterprise company that desires scaling, there is no instance when a monolith app is the answer. It comes down to resources and money. Instead of going back to what was "easier", learn a lesson from your deployment mistake and restructure a bit to make it better. I assure you that MS is the best way to go.
Where does this crap end.
Ten Minute Tokyo 2 What do you mean? Genuinely curious.
Thats pretty rude ...