Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: ua-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
01:00 What is a monolithic application (Everything together in one process) 01:16 For Microservices take each capability and put it in separate processes 03:30 Article about *9 Characteristics of Microservices* Common Characteristics 03:43 *Componentization via services* 04:23 Components should be independently replaceable and independently upgradeable 04:55 2 forms of components - libraries (needs same plattform) - services (more independent) 06:28 *Organized around business capabilities* 07:57 *Smart endpoints and dump pipes* 09:19 *Decentralized Data Management* 10:17 Never talk to another services data store directly - only over the services API 11:01 Choice of data persistence, language and tools should totally be at the individual service 11:23 *Infrastructure Automation* is crucial 12:10 *Explicit design for failure* Usual Questions 13:22 *Are microservices the same as 'Service Oriented Architecture'?* 14:37 'Microservices' = subset of 'SOA' 15:46 *How big is a Microservice?* 17:49 *Microservices vs Monoliths* - Advantages Monoliths: Simplicity up to some size, Consistency, Inter-module interface refactoring - Advantages Microservice: Partial Deployment, Availability, Preserve Modularity, Multiple Platforms 24:03 *Basic things to make sure if you do microservices* Rapid Provisioning, Basic Monitoring, Rapid Application Deployment, Devops Culture
Thanks, I was taking the similar note, but you have timestamp too :) just adding these links: - martinfowler.com/bliki/TalkNotes.html - martinfowler.com/articles/microservices.html
Fantastic, concise overview of microservices. My favorite part: @23:30: Use any programming language(s) for microservices except JavaScript, you have to do something to fight back against that monster. 4 years later, rewrites refactoring book with all examples in JavaScript. :)
1) difficult to avoid js, what with it being the only client-side web-browser scripting language 2) a refactoring book makes sense to target js, since most people will need the help _for_ refactoring (shitty) js code.
Things I learned from this talk: - Helpful to think of microservices vs monolith as distributed vs centralised - Microservices allow greater deployment flexibility and release granularity - Microservices might not be a good choice if boundaries in a system are poorly defined/understood
I've worked in organizations where the shift from monolith to microservices was well thought out, planned and executed. I've also worked in organizations where the attempt to make that shift resulted in the most awful mess that created nothing but tech debt and resulted in massive technological silos that no one understood. It reminds me of the early days of the design pattern movement where developers were picking up the latest cookbook, learning a couple patterns and then shoe-horning every software challenge into them regardless of fit. I think that as with any other software development fad, microservices are great for specific cases. In most cases it's just not needed and creates complexity rather than enabling solutions.
Actually a quite good and ,now and then, quite humorous story. I now understand why no-one was laughing though: "This presentation was recorded at GOTO Berlin 2014"
For what it's worth, I've come across another key difference between SOA and microservices. as stated by Mark Richards in the book Software Architecture Patterns published by O'Reilly, the difference is that a microservices do not use any form of service orchestration (which i would rather call composition). when talking about SOA, there are structures where multiple services might work together to deliver one (partial) result.
Development in isolation. The key of modularity, and I think a better phrase when discussing the pros and cons of modularity. Development in isolation is impossible in a monolith, but a monolith has the benefit of discovering boundaries and simpler troubleshooting prior to those boundaries being found. Development in isolation is the only option in Microservices, but troubleshooting becomes difficult if your boundaries aren't clear. The key is that a microservice shouldn't be developed with unclear boundaries. And when you start with a monolith and extract services with clear boundaries, you can then develop and troubleshoot in isolation. SOME Developers (lol if he reads this) like to run every micro service and the root application(s) simultaneously and locally to troubleshoot. That either means the boundaries aren't clear (which they should be), or it means your mindset is stuck in the monolith and you don't know how to deal with development in isolation. Long-story-short: Start with monoliths, don't prematurely microptimize (lol?), but try to get to clear boundaries asap, and move to micro-services if you can support the requirements the Master Fowler speaks of toward the end of his talk.
Good point, agree later refactoring is better. You can refactor towards Microservices when you understand the boundaries, but its far harder to go the other way.
Thanks for such a wonderful explanation. Component:Independently Replaceable and Independently up gradable. Infact this monolithic approach's problem was with Microsoft .Net framework also. That's why they gave MVC as a nuget package instead of integrated with .Net otherwise they would have to wait until the next version
+anug14 Never again refer to Martin Fowler as "the speaker." Refer to him as God, Master Fowler, or His-Grace. To answer your question: He was alluding to the fact that Javascript is growing like mold and taking over many responsibilities. It's a good thing, but also scary. We all know it will never take over CPU-intensive development, that's why node uses C++ for the backend, and we can use C++ for those CPU intensive things, and plug it into the javascript.
energale i agree...from what i have known about node.js, it should lend quite well to this type of architecture...i wonder how node.js community responding to this buzz or concept or reinvention ..whatever... spring cloud foundry project seems to be promising and would greatly help java developers to adopt to micro services
+Suamere This CPU-intensive processing applies to Node.js architecture, not to the JavaScript itself. Anyway, in case you need to do this kind of task, probably a better idea is not to 'plug it into javascript', but have a separate (micro ;) ) service which does this task and is implemented in completely different language/app server...
Ideology versus the real world: That's gonna my future book. Things that look so nice on paper could appear thousands fold more so when an articulate speaker delivers a keynote on it. Things turn into hell during implementation because the real world deals with aspects not mentioned during the talk. LISTEN TO ALL but THINK FOR YOURSELVES and trust a few.
Quite impressive presentation. Clear thought expressed thru attractive powerful voice. This pres paired with the one of Eric Evans here should round up a good overview of microservices.
sure, because if you want to write code for the web, you have to use javascript. Ofc you can use transpilers to generate javascript from other languages like C++
Hello , I need to know if there is any industry standard to follow on how to split a monolithic application. Kind of guiding principle. This is from the perspective of a functional person who will be logically splitting the application to smaller one.
There is no 1 principle. I would say focus on logic and responsibility boundaries, too many services = too much 'talk', too few services = no benefits. Marin also highlighted several areas to focus on, services should revolve around a product rather than a technology (e.g Orders).. well written monoliths are often built with microservices so look for service classes e.g CustomerService, OrderService, these are good starting places. Also check for resource access, you don't want lots of services accessing the same resource. Be very careful splitting database access across several services, this is a classic versioning and compatibility trap.
Se liga nessa série de posts da galera do SoundCloud sobre quebrar um sistemas monolítico em micro-serviços developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith
Decentralized data - sometime it is an illusion if the micro-services data are strongly coupled in the problem space. The best solution is the one that model the problem not something else.
Hi there i want to build a microservices backend for android app. what is the best backend technologies for this i was thinking of using Node.js but i also though about using Python. ANY THOUGHTS THANKS
All good except that comment about javascript. There's no such a rule. It comes in handy in some situations and sometimes it isn't. always has two sides.
I think this is an old talk when ES5 was out perhaps? A lot of people in js community back then felt that js was a badly thought out language with inconsistent features etc. I am more of a Java person, but that comment would probably not hold true today. JS is heading in a great direction indeed with ES6 and some of its new features. I am still a beginner though. :)
Doesn't R.C Martin clean architecture give you the ability to leave the decision of monolithic vs WS to the time you will have enough knowledge to decide? Boundaries and size is not a WS problem, its a components/libraries challenge. .By the time you create components and test it, you have enough data to decide.
Modularity discipline - if i will multiplied 500 business rules in 20 microservices, each multiplied 10-20 times - this a fatal illness for your system. DRY options - use a library - encapsulate in services - cost of a rocket for bicycle
Multiple instances off each service in an illness? How? Use a library. So I'm stuck to a language/stack when though there are better solutions available in some other stack.
The independent "upgradability" of technology - yet it is enabled, but heterogeneous technologies will increase your system complexity, and also the cost of change from heterogeneous suppliers. We really want that ?
Ability to cater to change, without having to notify clients about downtime, at cost of some complexity is not a bad deal at all. BTW what kind of complexity are you referring to here ?
Messages - are flexible but ... The cost of a asynchronous solution for a synchronous problem will raise to the sky for only benefit of a solution provider. So. I will do not trust to any solution provider that will propose me a solution with a model that does not fit with the model of the problem. More - asynchronous software is a hell for testing - hard to test. I need good reasons to go there ...
He seems a typical JAVA and .NET lover, who loves Object oriented styles. Java Script is the future , better that you learn to work in that and get rid of writing restful apis in .Net and .JAVA because that does not make sense to me.
It's funny how the only time there was an applause during this, otherwise excellent, talk is when the mandatory JavaScript bashing manifested... It's 6 years later, and JavaScript microservices are one of the more common ones being done, thanks to Node.js... Who's laughing and applauding now, bunch of dudes in 2014?
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: ua-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
01:00 What is a monolithic application (Everything together in one process)
01:16 For Microservices take each capability and put it in separate processes
03:30 Article about *9 Characteristics of Microservices*
Common Characteristics
03:43 *Componentization via services*
04:23 Components should be independently replaceable and independently upgradeable
04:55 2 forms of components
- libraries (needs same plattform)
- services (more independent)
06:28 *Organized around business capabilities*
07:57 *Smart endpoints and dump pipes*
09:19 *Decentralized Data Management*
10:17 Never talk to another services data store directly - only over the services API
11:01 Choice of data persistence, language and tools should totally be at the individual service
11:23 *Infrastructure Automation* is crucial
12:10 *Explicit design for failure*
Usual Questions
13:22 *Are microservices the same as 'Service Oriented Architecture'?*
14:37 'Microservices' = subset of 'SOA'
15:46 *How big is a Microservice?*
17:49 *Microservices vs Monoliths*
- Advantages Monoliths: Simplicity up to some size, Consistency, Inter-module interface refactoring
- Advantages Microservice: Partial Deployment, Availability, Preserve Modularity, Multiple Platforms
24:03 *Basic things to make sure if you do microservices*
Rapid Provisioning, Basic Monitoring, Rapid Application Deployment, Devops Culture
Thanks, I was taking the similar note, but you have timestamp too :)
just adding these links:
- martinfowler.com/bliki/TalkNotes.html
- martinfowler.com/articles/microservices.html
Very crisp and helpful
You the real MVP
Very articulate, clear-cut, easy to follow diction. That is a great speaker.
lmao hes boring af....
That's cause he's British. Or at least his accent is.
Fantastic, concise overview of microservices. My favorite part: @23:30: Use any programming language(s) for microservices except JavaScript, you have to do something to fight back against that monster. 4 years later, rewrites refactoring book with all examples in JavaScript. :)
1) difficult to avoid js, what with it being the only client-side web-browser scripting language
2) a refactoring book makes sense to target js, since most people will need the help _for_ refactoring (shitty) js code.
I wonder what Martin thinks in 2022 regarding using TypeScript instead as it got quite mature.
Things I learned from this talk:
- Helpful to think of microservices vs monolith as distributed vs centralised
- Microservices allow greater deployment flexibility and release granularity
- Microservices might not be a good choice if boundaries in a system are poorly defined/understood
Startups should NEVER go micro service for the third given reason: Product is not defined, service is not well-bounded.
I've worked in organizations where the shift from monolith to microservices was well thought out, planned and executed. I've also worked in organizations where the attempt to make that shift resulted in the most awful mess that created nothing but tech debt and resulted in massive technological silos that no one understood.
It reminds me of the early days of the design pattern movement where developers were picking up the latest cookbook, learning a couple patterns and then shoe-horning every software challenge into them regardless of fit.
I think that as with any other software development fad, microservices are great for specific cases. In most cases it's just not needed and creates complexity rather than enabling solutions.
That Netflix guy talk about microservices doesn't ever get close to the quality of this talk. Thank you, Martin!
Actually a quite good and ,now and then, quite humorous story.
I now understand why no-one was laughing though: "This presentation was recorded at GOTO Berlin 2014"
Great high-level talk on microservices! Concise and highly informative.
Finally, I found one meaningful presentation about micro services. I still have so many questions..
Thank you for clarifying those concepts
Another great Martian Fowler talk
As always, some very valuable, astute and insightful commentary from Martin Fowler - thanks!
Summary of this video: American pizzas are very large, americans love shopping, fight back the javascript monster
This and the noSql speech have made me a big fan of Martin
Good solid overview of microservices by Martin Fowler
What a legend Martin Fowler is
Easy to understand, that's a plus!
Wow nice! He did a great job at explaining micro services
Very good intro to micro service architecture given by The Martin Fowler.
I had a bad bias against microservices. This presentation made it clear why I was right... And why I was wrong :)
For what it's worth, I've come across another key difference between SOA and microservices. as stated by Mark Richards in the book Software Architecture Patterns published by O'Reilly, the difference is that a microservices do not use any form of service orchestration (which i would rather call composition). when talking about SOA, there are structures where multiple services might work together to deliver one (partial) result.
Development in isolation. The key of modularity, and I think a better phrase when discussing the pros and cons of modularity. Development in isolation is impossible in a monolith, but a monolith has the benefit of discovering boundaries and simpler troubleshooting prior to those boundaries being found. Development in isolation is the only option in Microservices, but troubleshooting becomes difficult if your boundaries aren't clear.
The key is that a microservice shouldn't be developed with unclear boundaries. And when you start with a monolith and extract services with clear boundaries, you can then develop and troubleshoot in isolation.
SOME Developers (lol if he reads this) like to run every micro service and the root application(s) simultaneously and locally to troubleshoot. That either means the boundaries aren't clear (which they should be), or it means your mindset is stuck in the monolith and you don't know how to deal with development in isolation.
Long-story-short: Start with monoliths, don't prematurely microptimize (lol?), but try to get to clear boundaries asap, and move to micro-services if you can support the requirements the Master Fowler speaks of toward the end of his talk.
Good point, agree later refactoring is better. You can refactor towards Microservices when you understand the boundaries, but its far harder to go the other way.
Thank you for providing your thoughts on microservices, Martin.
Thanks for such a wonderful explanation.
Component:Independently Replaceable and Independently up gradable.
Infact this monolithic approach's problem was with Microsoft .Net framework also. That's why they gave MVC as a nuget package instead of integrated with .Net otherwise they would have to wait until the next version
Very clear and well explained.
Very good and neutral view on Microservice!
Smart Ends and Dump Pipes is a good band name
"For the first time on stage together, ladies and gentlemen, Smart Endpoints and Dumb Piiiiiiiiiiiiiipppppesssss!!!"
It's a Pr0n film.
Sounds like a Beck album.
Martin Fowler is one the great one in software development area. Thank you.
Explaining in great way.Easy to undertand
Mircroservices is just Erlang implemented with other languages and runtimes.
Any Erlang programmer can eat two of your American pizzas.
+Mikhail Franco my thougth watching this video: "if only there was microservices on a language level.." now i'm going to look into erlang :)
there is also elixir, phenomenal language that works on beam vm and can use all erlang code
And now Elixir. I was exactly thinking the same. It's Microservices on the language level.
23:30 why not javascript? In the context of services, is the speaker alluding to node.js?
+anug14 Never again refer to Martin Fowler as "the speaker." Refer to him as God, Master Fowler, or His-Grace. To answer your question: He was alluding to the fact that Javascript is growing like mold and taking over many responsibilities. It's a good thing, but also scary. We all know it will never take over CPU-intensive development, that's why node uses C++ for the backend, and we can use C++ for those CPU intensive things, and plug it into the javascript.
+anug14 node.js seems like the perfect match for microservices. I mean it comes with built in networking and an event loop.
energale i agree...from what i have known about node.js, it should lend quite well to this type of architecture...i wonder how node.js community responding to this buzz or concept or reinvention ..whatever... spring cloud foundry project seems to be promising and would greatly help java developers to adopt to micro services
+Suamere This CPU-intensive processing applies to Node.js architecture, not to the JavaScript itself. Anyway, in case you need to do this kind of task, probably a better idea is not to 'plug it into javascript', but have a separate (micro ;) ) service which does this task and is implemented in completely different language/app server...
bartolomeonew well said.
Egregious Spaghetti Box, pure gold.
I laughed out loud at work, heh.
Excellent talk!
Impressive presentation. And I just like your humor.
Ideology versus the real world: That's gonna my future book. Things that look so nice on paper could appear thousands fold more so when an articulate speaker delivers a keynote on it. Things turn into hell during implementation because the real world deals with aspects not mentioned during the talk.
LISTEN TO ALL but THINK FOR YOURSELVES and trust a few.
Quite impressive presentation. Clear thought expressed thru attractive powerful voice. This pres paired with the one of Eric Evans here should round up a good overview of microservices.
Martin Fowler is a Prophet in SOA world!
I like it - " You got to fight back that monster"
You are a great presentator Martin
Great Presentation.
Thanks
J.N
Good explanation
Very interesting and thought provoking
Great as always.
Thank you.. Great presentation..
Hope he changed his mind about javascript two years later. That monster is becoming stronger and stronger thanks to Node.
Not really changed his mind, but sort of gave up. Still hates it, but code examples in new edition of his Refactoring book are in javascript.
@@artgentumk how ironic is that, the language overpowered him at last
sure, because if you want to write code for the web, you have to use javascript. Ofc you can use transpilers to generate javascript from other languages like C++
Hello , I need to know if there is any industry standard to follow on how to split a monolithic application. Kind of guiding principle. This is from the perspective of a functional person who will be logically splitting the application to smaller one.
There is no 1 principle. I would say focus on logic and responsibility boundaries, too many services = too much 'talk', too few services = no benefits. Marin also highlighted several areas to focus on, services should revolve around a product rather than a technology (e.g Orders).. well written monoliths are often built with microservices so look for service classes e.g CustomerService, OrderService, these are good starting places. Also check for resource access, you don't want lots of services accessing the same resource. Be very careful splitting database access across several services, this is a classic versioning and compatibility trap.
Thanks for sharing knowledge
Great presentation!
Very Well Explained Martin,
Wonderful!
Se liga nessa série de posts da galera do SoundCloud sobre quebrar um sistemas monolítico em micro-serviços developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith
Very good speech!!
Hi there, I'd like to get clarification, is it 2 American pizzas to feed 2 American people?
Decentralized data - sometime it is an illusion if the micro-services data are strongly coupled in the problem space. The best solution is the one that model the problem not something else.
awesome talk..
Hi there
i want to build a microservices backend for android app.
what is the best backend technologies for this
i was thinking of using Node.js
but i also though about using Python.
ANY THOUGHTS
THANKS
It was the only moment I actually heard 3 people laugh!!! LOL
Nice, thanks!
Great presentation. Very understandable. He also sounds like John Oliver, which is a good thing.
loved it..
I think the characteristics of Micro Services and Domain Driven Design seem to overlap in my opinion.
when to have a new Microservice is easy. Every new feature is a new Microservice.
You Sir, are the reason why consultants get paid more.
Good overview
What can I cook on this snake oil?
Partial deployment can be also a disadvantage
exact moment I clicked like: "don't use javascript" - damn straight!
Funny thing, he write a book where he uses javascript for example code. :p
@@Daniel-dj7vc We've all done things we're ashamed of. lol
All good except that comment about javascript. There's no such a rule. It comes in handy in some situations and sometimes it isn't. always has two sides.
I'm not sure where he was leading with that. A shot at NodeJS? Why? I'm not sure what the issue with that is.
A typical old style .NET and JAVA developer.
I think this is an old talk when ES5 was out perhaps? A lot of people in js community back then felt that js was a badly thought out language with inconsistent features etc. I am more of a Java person, but that comment would probably not hold true today. JS is heading in a great direction indeed with ES6 and some of its new features. I am still a beginner though. :)
23:46 Javascript in 2017 did not notice the fighting back..
Doesn't R.C Martin clean architecture give you the ability to leave the decision of monolithic vs WS to the time you will have enough knowledge to decide?
Boundaries and size is not a WS problem, its a components/libraries challenge.
.By the time you create components and test it, you have enough data to decide.
Boundaries have to be explicit in SOA..
Modularity discipline - if i will multiplied 500 business rules in 20 microservices, each multiplied 10-20 times - this a fatal illness for your system.
DRY options
- use a library
- encapsulate in services - cost of a rocket for bicycle
Multiple instances off each service in an illness? How?
Use a library. So I'm stuck to a language/stack when though there are better solutions available in some other stack.
OMG, I'm surprised about the bad comment of JavaScript.😂
Another reason to love Elixir and the Erlang VM
Great talk about Microservices, but doesn't say anything about how to actually implement in code. :(
+Rahul R that's because it is not at the code level, but an architectural pattern.
Apache Thrift is a great tool that glues microservices together in a SOA.
amen to the java statement!
"What is the most important things to Americans?....shopping!" - Martin Fowler
Completed
It is a good concept, but there is nothing new here. Most of the top software designers have been using these ideas for years.
The independent "upgradability" of technology - yet it is enabled, but heterogeneous technologies will increase your system complexity, and also the cost of change from heterogeneous suppliers. We really want that ?
Ability to cater to change, without having to notify clients about downtime, at cost of some complexity is not a bad deal at all. BTW what kind of complexity are you referring to here ?
Messages - are flexible but ... The cost of a asynchronous solution for a synchronous problem will raise to the sky for only benefit of a solution provider. So. I will do not trust to any solution provider that will propose me a solution with a model that does not fit with the model of the problem.
More - asynchronous software is a hell for testing - hard to test. I need good reasons to go there ...
shopping must go on :)
Lot funnier and interesting when you put into into 1.5x speed!
Man like Martin F
Microservices: doing what Linux has been doing for decades in a more convoluted way.
Completely different scale. Elaborate.
How big is a microservice... he did not answer.. mocked others??
Sounds like someone jumped out of a Harry Potter movie and started studying Microservices
Sounds like you jumped into coding and didn't bother to check who Martin Fowler is.
remains actual
He seems a typical JAVA and .NET lover, who loves Object oriented styles. Java Script is the future , better that you learn to work in that and get rid of writing restful apis in .Net and .JAVA because that does not make sense to me.
Martin Fowler is Jesus for software developers.
Jesus is dead, though.
put microservices in DOCKER and that helps much better.
American-sized pizzas? But then again, those are American sized people. You can't feed "a hell of a lot" of americans with two american pizzas.
Una charla muy interesante, me.ayudo a complementar lo que sabía ua-cam.com/video/N95W6I_DoRs/v-deo.html
Saludos y seguiré viendo el bueno contenido.
This didn’t age well
Cool, but dude get to the point lol.
Boring fluff.
It's funny how the only time there was an applause during this, otherwise excellent, talk is when the mandatory JavaScript bashing manifested... It's 6 years later, and JavaScript microservices are one of the more common ones being done, thanks to Node.js... Who's laughing and applauding now, bunch of dudes in 2014?
Any "ROOTING" stuff.. lol.. english language speech is such a phonetic disability!
bla-bla-lba.