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.
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".
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.
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.
@@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.
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...
Copy on Write - look at Miscrosoft SQL Server Snapshots, Composability -> Look at the Stream Processing, e.g. Apache Kafka, Apache Pulsar, Kinesis and etc
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? 🤔
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
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...
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?
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.
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?
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
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.
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.
@@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...
@@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.
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!
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.
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".
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.
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.
@@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.
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...
7:17 - 8:13 identifying the problem, identifying the solution, announcing it is not gonna happen, the rest of the talk . . . meh
Copy on Write - look at Miscrosoft SQL Server Snapshots, Composability -> Look at the Stream Processing, e.g. Apache Kafka, Apache Pulsar, Kinesis and etc
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? 🤔
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
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?
A dosa is a breakfast food in India. So the DOSA service serves dosas. 🤣
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...
Indeed
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?
Nice presentation.
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.
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?
Erlang? I don't know anything about scaling. But I thought that is what Erlang/Elixir is supposed to promise.
They promise distribution and concurrency, it all depends on how you implement it, there is no magic language that solves all your problems.
Great talk
If you want to browse through more content on Microservices you can check our dedicated page www.infoq.com/microservices
So the last 8 years was a total waste?
Great talk.
39:27 *an example.
Nice talk!
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
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.
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.
@@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...
@@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.
"200 engineers -> 2500 engineers = 5x as many engineers."
Well, at least I know how much to trust this guy
He said correctly ... more than 5x growth over the year
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!