I started reading Building Microservices a couple of weeks ago. I didn't know Sam Newman at the time. I'm glad I saw this conference, because now I'll be able to read the rest of the book in his british accent.
I wonder why this is not topping the charts when i search for micro-services. Not to mention the reason for those 5 incredible souls to thumbs down this illustration and walkthrough.
I have seen this at least 20-30 times and each time I get something new. Every single word shares lot of experience and knowledge. One the best in recent days that I have seen it.
Please don't hate me, but microservice actually meant to do asynchronous task, not making API response. Also database horizontal sharding is much effective than split database manually. Thus, it's okay to use monolith service as backend's face and shared database instead of split everything and make it more harder to maintain.
Seems like great info. I would remember that sometimes just making it simple is ok to with a front and backend. Depends on a lot of things. Maybe AWS will have microservice as a service one day so going through all the hard stuff may not be necessary.
One way to support multiple versions is to have a layer which converts older versions to your current version. You have a small risk you will introduce an issue, but if this works you can now change your service once without supporting multiple branches.
So my problem with all of the microservice videos out there is present here as well. People always talk about versioning, and how cool it is and it solves problem, but they fail to even mention is how hard of a task is it actually. Why do they never talk about the persistence layer? Why do they never talk about handling different API version problems, and practices? I get it that this is an overview, but can't anyone talk for once about real issues, and not already solved problems? Oh and what about ACID? What about transactions? What about relational DB-s? The problem is next to never at the REST layer.
noherczeg As far as I know most companies using microservices aren't using transactional databases but things like eventual consistency. Also, transaction over multiple services don't work well.
tomlxyz Thanks for the information! BTW the last thing you said was the thing I imagined as well. Yet I'm still curious how come we don't see any traditional architecture videos any more? I'm not trying to be offensive here, but is high throughput and world wide distribution the only problem people face? Back a few years ago everyone said "use microservices where they are fit", but now everyone talks about them. It's like there are no other challenges at all. In the meantime ignoring all the problematic topics like versioning, API consistency, synchronisation, interoperability, transactions, etc.
tomlxyz "Monoliths" For example I recently found the term "monorepo" which seems very promising since you can have your full app in a single source code repo yet you can manage and release it's parts separately. I fail to see why would everyone want to go with a microservice architechture when most of the web applications never reach such load requirements, yet it brings quite a few cons when applied unnecessarily.
Great video. Definitely the best in Microservices that I have come across. One question - you did mention about some patterns , do we have a pattern on how Microservices and a headless bpm interact ?
brilliant. Question on the co-existing endpoints section: you talk about endpoints and api's but in a way where the api is the service as well. Do you mean you would also have different version of the service deployed as well to go with the new api version?
It seems to me, and excuse me if this annoys people, but it seems, that this architecture is there to minimize problems that stems from bad coding? If you have written your Monolith with SOLID patterns in mind, would that not completely remove the problems that most of these 8 "main principles" want to fix? Lets say that I want to deploy something on a service with a persistence layer, any service that accesses this service, would have to be updated to now access the API with this function. If I update my Service layer, is it not the same issue? I have to update all components that implement that layer? But in the microservice, I have to now deploy the API, and the testing around that deployment is a bit of a wonky thing, as it depends on what you changed, how your message-client will require to test against the message system, between the deployed API and the consumer? To me, it seems like microservices are an architecture, that is applied to attempt to allow coders that have little skill or knowledge to crank out code quickly, in a more "protected" way. Because the complexity is moved out of the code an into the operations part of the system. It seems like an architecture devised by an OPS engineer/manager, rather than a coder. Because all you get here, is permission to write shit code, and let the OPS people deal with an architecture that isn't needed, and is super costly to develop, and makes their position safe, because you now can't deploy your software without the architecture infrastructure integrated into your code. Or at least, it will be very hard to get away from the microservices architecture, once it is built. Why not just train your coders to be better at following SOLID principles, make your components independent at the low-level components, and allowing the high-level components to control their own functionality?
@@teek1976 Thanks a lot, it's a long time i had started learning it, now i am in a better position, please let me know if you have any software work, i do freelancing now.
Smart man, and I love the talk and the book, but... Why were all the thread pool threads in the Strangler App blocked waiting for responses? Everything could have been async and of course you have a thread pool that has a limit. And it's not a thread per request, but a thread per job. The thread pool will go through the jobs quickly, firing out the requests to the underling services and there will be no harm done. Of course, you'd have to think about the threads on which the responses are coming back in and there for sure will be some (thread pool) queue filling up somewhere, but that's the best you can do and will avoid failure. When the queue reaches a watermark you start dropping requests... or responses, rather, in this case.
Curious what you think about the Vert.x framework? It looks a lot like your magical mystery bus but AFAIK doesn't have the land of hell you mentioned ;-)
I got a headache when he said "Services exist to be called." APIs exist to be called by components within the same service, but if you have services calling each other, don't you just end up with another monolith? Services are no longer autonomous if they are calling each other, isn't it? Perhaps I missed some context around his statement.
Yes, it's more like segmented monolith. Instead of separate them into different instance and call it "service", just put them into different directory (like django apps) and use "coroutine" feature. Then let another service instance handle asynchronous task.
Modeling around the business? Business cannot be sliced in completly independent parts. There are business dependencies. If we create other dependencies. we are introducing undesired, artificial complexity. There is business timing (sync/asyc). If we do not respect business timing, idem ~ undesired complexity. Any architecture that dos not match well to the problem to solve is a Big Up Front & Rigid design, no matter the labels and the advertising.
Sam probably wanted to succinctly say: "No energy system can produce sum useful energy in excess of the total energy put into constructing it. This universal truth applies to all energy systems [including digital systems]. Energy, like time, only flows in one direction, from past to future." Wail.
Lot of talk but nothing about how to actually implement it. If I want to isolate everything than I assume every "hexagon" has it's own database, own server, own host etc (I have never programmed microservices, I make websites in the classical M-V-C way, classical apache web server, phpmyadmin, the works). So..how to make isolation actually to work
The talk was good but Sam is really arrogant and the reason for that is his own insecurity, you can see that when he says "if you have another definition of microservices it's great you can write it on your own book", it seems like he is a bit defensive because people disagreed with him.
Sam Newman is such a brilliant speaker, so articulate and well-presented.
I started reading Building Microservices a couple of weeks ago. I didn't know Sam Newman at the time.
I'm glad I saw this conference, because now I'll be able to read the rest of the book in his british accent.
lol
🤣🤣🤣👌
Does it feel like reading Harry Potter now?
I was given this video as part of my training on my very first job in tech after changing my career. Great video!
I wonder why this is not topping the charts when i search for micro-services. Not to mention the reason for those 5 incredible souls to thumbs down this illustration and walkthrough.
maybe because the "buy my book" thing
I have seen this at least 20-30 times and each time I get something new. Every single word shares lot of experience and knowledge. One the best in recent days that I have seen it.
This is a great video. It gives information in a very simple form with great examples. Thanks Sam.
Definitely getting his book..One of the best talks on microservices .
Please don't hate me, but microservice actually meant to do asynchronous task, not making API response. Also database horizontal sharding is much effective than split database manually.
Thus, it's okay to use monolith service as backend's face and shared database instead of split everything and make it more harder to maintain.
This is one of the best talk on MicroServices, Sam you are subject matter expert, thanks for such a great session
One of the best Talks about microservices I have seen so far. Thank you.
Clarity of thought process reflected in the style of delivery. Very informative video
Seems like great info. I would remember that sometimes just making it simple is ok to with a front and backend. Depends on a lot of things. Maybe AWS will have microservice as a service one day so going through all the hard stuff may not be necessary.
One way to support multiple versions is to have a layer which converts older versions to your current version. You have a small risk you will introduce an issue, but if this works you can now change your service once without supporting multiple branches.
One of the best videos on Microservices
So my problem with all of the microservice videos out there is present here as well. People always talk about versioning, and how cool it is and it solves problem, but they fail to even mention is how hard of a task is it actually. Why do they never talk about the persistence layer? Why do they never talk about handling different API version problems, and practices? I get it that this is an overview, but can't anyone talk for once about real issues, and not already solved problems?
Oh and what about ACID? What about transactions? What about relational DB-s? The problem is next to never at the REST layer.
noherczeg As far as I know most companies using microservices aren't using transactional databases but things like eventual consistency. Also, transaction over multiple services don't work well.
tomlxyz Thanks for the information! BTW the last thing you said was the thing I imagined as well. Yet I'm still curious how come we don't see any traditional architecture videos any more? I'm not trying to be offensive here, but is high throughput and world wide distribution the only problem people face? Back a few years ago everyone said "use microservices where they are fit", but now everyone talks about them. It's like there are no other challenges at all. In the meantime ignoring all the problematic topics like versioning, API consistency, synchronisation, interoperability, transactions, etc.
noherczeg What do you mean by traditional archetecture?
tomlxyz "Monoliths" For example I recently found the term "monorepo" which seems very promising since you can have your full app in a single source code repo yet you can manage and release it's parts separately. I fail to see why would everyone want to go with a microservice architechture when most of the web applications never reach such load requirements, yet it brings quite a few cons when applied unnecessarily.
Microservices doesnt work without automation. Automation is key to microservices.
Great thank. this is the answer to my current legacy enterprise system
most of this talk is very useful! even when you are not in a microservice infrastructure...
This is indeed great! Great ideas and advise. Thanks Mr. Newman.
Very simple and clear video. Great work.
Amazing Presentation with good Articulation of concepts. Great Job !!
Great explanation!
This was a great briefing on micro-services. How could I get my hands on the slides?
Monolithic view of systems is perspective.... even a micro-service can be a monolith.
Really wonderful talk, simple and to the point
It's a nice shape and they are my slides, so I get to pick the shape... Irrefutable logic. I like it.
i am sorry, but i thought Jon Snow was on the stage for one second.
mslugx as soon as video started, i scrolled down for John Snow comment
You know everything about microservices, Jon Snoo
Amazing presentation.
This talk is seminal. Should be canonized.
What's Mike's book that Sam mentions when he's talking about circuit breakers? Does anyone know the title?
Michael T Nygard - Release it!
Sam Newman IS the Geico Caveman
Hey Sam, this is good !
Can we relate Canary release to BBA (Branch By Abstraction) pattern, what are your thoughts on the same.
Best way explained microservice 👍
Great video. Definitely the best in Microservices that I have come across. One question - you did mention about some patterns , do we have a pattern on how Microservices and a headless bpm interact ?
awesome talk about microservices...
brilliant. Question on the co-existing endpoints section: you talk about endpoints and api's but in a way where the api is the service as well. Do you mean you would also have different version of the service deployed as well to go with the new api version?
Really, Really great talk!!! Thx for sharing!!!
Excellent video
I have stumbled upon the Russell Brand of IT.
It seems to me, and excuse me if this annoys people, but it seems, that this architecture is there to minimize problems that stems from bad coding?
If you have written your Monolith with SOLID patterns in mind, would that not completely remove the problems that most of these 8 "main principles" want to fix?
Lets say that I want to deploy something on a service with a persistence layer, any service that accesses this service, would have to be updated to now access the API with this function.
If I update my Service layer, is it not the same issue? I have to update all components that implement that layer? But in the microservice, I have to now deploy the API, and the testing around that deployment is a bit of a wonky thing, as it depends on what you changed, how your message-client will require to test against the message system, between the deployed API and the consumer?
To me, it seems like microservices are an architecture, that is applied to attempt to allow coders that have little skill or knowledge to crank out code quickly, in a more "protected" way. Because the complexity is moved out of the code an into the operations part of the system.
It seems like an architecture devised by an OPS engineer/manager, rather than a coder. Because all you get here, is permission to write shit code, and let the OPS people deal with an architecture that isn't needed, and is super costly to develop, and makes their position safe, because you now can't deploy your software without the architecture infrastructure integrated into your code. Or at least, it will be very hard to get away from the microservices architecture, once it is built.
Why not just train your coders to be better at following SOLID principles, make your components independent at the low-level components, and allowing the high-level components to control their own functionality?
good video
Great talk .
Awesome
This is good.
Very good talk ...
Great talk!
great work...
Ecxellent !!
Am I the only one who is thinking this witty fellow is the guy with the British accent that married (briefly) Katie Perry? Let's see, Russell Brand.
Exactly My thought
what is the name of the book whose author is mike at 43:22
Michael T Nygard - Release it!
@@teek1976 Thanks a lot, it's a long time i had started learning it, now i am in a better position, please let me know if you have any software work, i do freelancing now.
Smart man, and I love the talk and the book, but... Why were all the thread pool threads in the Strangler App blocked waiting for responses? Everything could have been async and of course you have a thread pool that has a limit. And it's not a thread per request, but a thread per job. The thread pool will go through the jobs quickly, firing out the requests to the underling services and there will be no harm done. Of course, you'd have to think about the threads on which the responses are coming back in and there for sure will be some (thread pool) queue filling up somewhere, but that's the best you can do and will avoid failure. When the queue reaches a watermark you start dropping requests... or responses, rather, in this case.
Curious what you think about the Vert.x framework? It looks a lot like your magical mystery bus but AFAIK doesn't have the land of hell you mentioned ;-)
Can i get the slides for this session? Thanks.
what were the other book that he mentioned? name anyone, please
I think it was Release It! by Michael Nygard
I got a headache when he said "Services exist to be called." APIs exist to be called by components within the same service, but if you have services calling each other, don't you just end up with another monolith? Services are no longer autonomous if they are calling each other, isn't it?
Perhaps I missed some context around his statement.
Yes, it's more like segmented monolith.
Instead of separate them into different instance and call it "service", just put them into different directory (like django apps) and use "coroutine" feature. Then let another service instance handle asynchronous task.
this guy has good theory, where can i see a running app and perhaps codes?
Unpopular opinion: a database is just another service, hiding it is just a matter of taste.
Didn't realise Russell Brand was a dev
Services are meant to be called by clients. So when contract changes , all clients have to know. There is
No independence.
Modeling around the business? Business cannot be sliced in completly independent parts. There are business dependencies. If we create other dependencies. we are introducing undesired, artificial complexity. There is business timing (sync/asyc). If we do not respect business timing, idem ~ undesired complexity.
Any architecture that dos not match well to the problem to solve is a Big Up Front & Rigid design, no matter the labels and the advertising.
hahaha - distributed point of failure
waiting jon snow to drink water until the presentation ended :(
Sam probably wanted to succinctly say:
"No energy system can produce sum useful energy in excess of the total energy put into constructing it.
This universal truth applies to all energy systems [including digital systems].
Energy, like time, only flows in one direction, from past to future."
Wail.
Lot of talk but nothing about how to actually implement it. If I want to isolate everything than I assume every "hexagon" has it's own database, own server, own host etc (I have never programmed microservices, I make websites in the classical M-V-C way, classical apache web server, phpmyadmin, the works). So..how to make isolation actually to work
Y6
Martin fowler 2.0
The uncovered blood ethnopharmacologically bat because close surprisingly enter barring a imminent snow. disturbed, steady profit
the more one knows, the more one knows how little he/she knows. this guy does NOT seem to have learn this axiom. kinda grotesque
What does that even mean ?
The talk was good but Sam is really arrogant and the reason for that is his own insecurity, you can see that when he says "if you have another definition of microservices it's great you can write it on your own book", it seems like he is a bit defensive because people disagreed with him.
way to generic and arrogant for my taste
So much of non-constructive blah-blah. The whole idea of the video can be explained in 5 minutes
Can you share a link to your 5 minute video?
1 minute in and I already know i'm going to hate this. Listening to this guy is like chewing a lemon.
good video