That’s the problem with the Microservices hype. You still have to actually design your system to grow it evolutionary. It’s not 100% Holocracy. It is much more than naming services and delegating responsibilities. It is also about thinking business change ahead, designing and maintaining a valid Domain Model and system metaphor to make those projections of business driven change configurable or at least easy changeable and doing so continuously. Trying to solve this issue later through the technology stack increases complexity without bringing actual business value. I personally do not optimize for composability.
@semremal3 жыл бұрын
Uber, Amazon, Netflix and others have great presence on conferences. So it's not a surprise why everyone talks about microservices. But let's be honest, most of developers work in much-much smaller companies. And for those companies microservices may slow down development and increase time-to-market without any real benefits. So, the key thing about microservices is organisation scale and not that technical stuff everyone talks about. That technical stuff comes only in addition to organizational scale. Of course, there are exceptions, but most projects won't benefit from microservices. That's why some says "you're not Uber".
@DodaGarcia3 жыл бұрын
I agree, and I think the most positive change from people adopting micro services at small sizes is not even about scale or technology but one of design. Adopting the model forces you to rethink the application in a more service-oriented way, which a lot of us have the luxury of not doing when it’s built as a monolith.
@DodaGarcia3 жыл бұрын
Like I have no delusions that I’ll need to suddenly scale my business, but moving to microservices did force me to decouple the logic in a way that has made it easier to understand. That said it did come with a bunch of drawbacks that I’m now having to wrestle constantly, so I wish I could have done the decoupling without needing the microservice move.
@semremal3 жыл бұрын
@@DodaGarcia Some time ago I measured how much time we spent on tasks related to microservices architecture. It was around 25%. Yes, it was not a large project, more like MVP, but we weren't close to be production-ready (retries, timeouts, circuit-breakers, etc...)! And, still, we spent 1/4 of development time to achieve what we didn't need at all, as a monolith could solve all our needs perfectly. IMHO, it's better to learn how to build modular monoliths, than to start by doing microservices. And if the team doesn't know how to create modular monoliths, then you simply won't get good microservices.
@yahorsinkevich44515 жыл бұрын
Copy on Write - look at Miscrosoft SQL Server Snapshots, Composability -> Look at the Stream Processing, e.g. Apache Kafka, Apache Pulsar, Kinesis and etc
@danielschmider50694 жыл бұрын
there are surprisingly few answers in this talk "we need" "idk" "why isnt" "if anyone has" "i think" "maybe someone will" "we are not sure" "ideally, we would" yeah, I dont like this... Its basically a list of things that are hard, unsolved or where to start doing something to prevent complete disaster... the absolute state of an entire industry moving to microservices...
@yahorsinkevich44515 жыл бұрын
Few other ideas, try to make some sence in your microservices by building boundaries between some microservices groups. Like there is a group of microservices that represents a "product", and so, that group interacts with other "products" throught explicit and well defined channel and no explicit interactions between services in the different groups are allowed
@b1ueocean2 жыл бұрын
DOSA sounds interesting - I wrote a cron job back in 2005 to export and anonymise production data to create reusable dumps importable into test DBs and never looked back 😂 One of the issues we had with testing was things like email and notification flows that were triggering against REAL USERS and MOBILE PHONES. Would DOSA need to have a filtering layer to strip real emails and mobile numbers read from production or are tests (other downstream customers) ‘intelligent’ to where they pretend to email/SMS or use alternative infra while testing/evolving dev? 🤔
@prakyg4 жыл бұрын
1. He switches RPC to asynchronous events. But he doesn't talk about the latency implications of that? 2. He introduces a term Composable event processors. What is that? Just a fancy term? 3. How does this term solve the problem of adding business logic to check user preference for puppies raised in the previous diagram?
@BrunoCoelho3 жыл бұрын
2500 developers? 1700+ microservices? For matching people who want to move from point A to point B with drivers near them that can drive them from A to B? yeah.... something's weird about this...
@cristianpallares75653 жыл бұрын
Indeed
@aatkarelse82184 жыл бұрын
7:17 - 8:13 identifying the problem, identifying the solution, announcing it is not gonna happen, the rest of the talk . . . meh
@PuerinTheHunter6 жыл бұрын
What is this DOSA service? I understand the scope switching between mjr and prod, but is that all it does? Or is it like an ORM for Cassandra?
@nikhilramabhadra60526 жыл бұрын
A dosa is a breakfast food in India. So the DOSA service serves dosas. 🤣
@mattleahy39516 жыл бұрын
Nice presentation.
@mnthol2 жыл бұрын
Hey new software engineers, Underlying issues are not( it’s whatever I guess that’s fine I guess ) those are things that need to be handled carefully There is no I guess, You should know.
@solomonxie51572 жыл бұрын
Microservices make our lives miserable even when we only have 20+ services. I feel nothing about "convenience" or "agile" or "fast". Unlike Uber, 500ms is okay for us, so I think serverless would be a greater choice. In the context of serverless, I don't feel we need "service discovery" anymore?
@dovh497 жыл бұрын
Erlang? I don't know anything about scaling. But I thought that is what Erlang/Elixir is supposed to promise.
@sandman891766 жыл бұрын
They promise distribution and concurrency, it all depends on how you implement it, there is no magic language that solves all your problems.
@davidprivate57866 жыл бұрын
Great talk
@infoq6 жыл бұрын
If you want to browse through more content on Microservices you can check our dedicated page www.infoq.com/microservices
@kobac82076 жыл бұрын
Perfect example when someone thinks that they know what microservices are, but actually have absolutely no clue. I have such an urge to cry seeing where they ended up and how much accidental complexity they introduced by not understanding the initial idea and its purpose. If someone can please refer him to Sam Newman's book and all the DDD content on bounded contexts scattered around whole web.
@Greenthum65 жыл бұрын
It's a very successful company running their business on thousands of services. Telling them to read a book is embarrassing. It's us that need to learn from them and apply what we already know.
@Klayhamn3 жыл бұрын
@@Greenthum6 businesses can be successful even when they have made bad mistakes or bad designs... building a successful tech business does not DEPEND on having a correct software architecture, nor does building a correct software architecture guarantee business success so, ya...
@Greenthum63 жыл бұрын
@@Klayhamn I never said good architecture means good business. But try running thousands of services and making profit. There has to be something they did right. It is their view on the matter. There is no need to try to copy what they did. Just take ideas if you see them fit or learn from their mistakes.
@Oswee5 жыл бұрын
Great talk.
@tenminutetokyo26433 жыл бұрын
So the last 8 years was a total waste?
@csvegso3 жыл бұрын
So what comes after microservices? .... this is just another not well-structured presentation on the field of microservices. Hard to follow + the title is completely misleading
@JaihindhReddy6 жыл бұрын
39:27 *an example. Nice talk!
@roceb50096 жыл бұрын
"200 engineers -> 2500 engineers = 5x as many engineers." Well, at least I know how much to trust this guy
@mojmirnovakovic21705 жыл бұрын
He said correctly ... more than 5x growth over the year
@keshavmagge44636 жыл бұрын
I wonder why seemingly knowledgeable people throw in ehhhs, and errrrs and such 10 times per sentence and gloss over half the things they say! The content was good, but, the way it was said sounded like a teenager explaining to his parents why he was found sloshed on the street the previous nite!