When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020

This interview was recorded for the GOTO Book Club. #GOTOcon #GOTOBookClub
gotopia.tech/bookclub
Sam Newman - Author of "Monolith to Microservices"
Martin Fowler - Chief Scientist at ThoughtWorks
DESCRIPTION
Upgrade your microservices knowledge by listening to a spirited conversation between two living legends: Sam Newman and Martin Fowler. The two touch upon the main reasons for using or not using microservices, and, if you decide to do use microservices, what else you should change along the way to fully benefit from the switch, plus much more.
The interview is based on Sam Newman's new book "Monolith to Microservices": amzn.to/2Nml96E
TIMECODES
00:00 Series intro
00:50 Episode intro
01:25 Why a new book about microservices?
03:50 When to use microservices
06:14 Don't use microservices as a default option?
08:35 Top 3 reasons to introduce microservices
11:00 How to avoid a distributed monolith
14:49 Why strive for independent deployment?
20:09 Organizations & teams
22:51 Handling data
31:57 Handling people
37:05 Outro
Read the full transcription of the interview here:
gotopia.tech/bookclub/episode...
Check out our upcoming masterclasses with Sam Newman here:
bit.ly/3uIvd0O
RECOMMENDED BOOKS
Sam Newman • Monolith to Microservices • amzn.to/2Nml96E
Sam Newman • Building Microservices • amzn.to/3dMPbOs
Ronnie Mitra & Irakli Nadareishvili • Microservices: Up and Running• amzn.to/3c4HmmL Mitra, Nadareishvili, McLarty & Amundsen • Microservice Architecture • amzn.to/3fVNAb0
Chris Richardson • Microservices Patterns • amzn.to/2SOnQ7h
Adam Bellemare • Building Event-Driven Microservices • amzn.to/3yoa7TZ
Martin Fowler • Patterns of Enterprise Application Architecture • amzn.to/3lp4sIq
Martin Fowler • Domain-Specific Languages • amzn.to/3nzOIFk
/ gotocon
/ goto-
/ gotoconferences
#Microservices #MartinFowler #SamNewman #Programming #MicroservicesArchitecture #SoftwareArchitecture #MonolithToMicroservices #ThoughtWorks #OReilly #BuildingMicroservices
SUPPORTER
This episode of the GOTO Book Club was made possible thanks to the support of GOTOpia.tech. Created for developers, by developers, the GOTO event series goes beyond annual conferences held in Chicago, Amsterdam and Copenhagen: you can also join online conferences, online masterclasses and meetups with top creators and leaders in tech year-round.
And if joining one of these top-rated events isn't enough to satisfy your hunger for the latest in tech, you can watch over a thousand high-quality talks on the GOTO KZbin channel - subscribe now for new videos released (almost) daily and join GOTO in person or online at any upcoming conferences using the promo code ‘bookclub’.
gotopia.tech
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
kzbin.info...

[@dhellraisa]

Very sensible and nuanced exchange. Wish there was more of that format in our space.

[@GG-uz8us]

I totally agree with "Our industry tends to focus on tech instead of the outcome". Many design decisions are based on technology (follow the trend), not what your requirement, your business domain. When you decide to use some tech, you should really understand what it is designed for, what kind of problem it is trying to solve, then look at your problem, ask yourself, can it really resolve what I want to?

[@jonashansen2512]

I’m totally guilty in following the trends. But at least I realize it and use it as an opportunity to improve 😅

[@gatsbylee2773]

Maybe. Not really. For me, not at all.

[@ThomasTWilliams]

It was never meant to improve anything, just a way to bypass difficult decisions with high-level tech. By this, getting products to market quicker, but on the cost of performance.

[@ryanrobinson8682]

It's that herd mentality of jumping on the latest technology band-wagon that really hurts companies. Teams end up over engineering really simple problems, because they are mentally indoctrinated in one single way of thinking. It's so refreshing to find this video that supports the argument of common sense over 'just build microservices' for everything.

[@orstorzsok6708]

🎖🎖🎖

[@ketanparmar]

Interesting conversation. For me, there are main two takeaway from this talk 1. As Industry, We focus on activity, not outcome. We focus on the tech tool, not the thing that tech tool lets you do. 2. Only two things are complex in computer science: Data and People. I personally think that first understand the problem and domain then decide which architecture pattern fits for the problem and domain. Do not use the architecture pattern because everyone else is doing. Do not choose a programming language or framework because it's popular.

[@GG-uz8us]

Just like one of Venkat's talks, Do not walk away from Complexity, Run.

[@deadbeef16]

I thought it was when to evict caches and naming things ;)

[@randysvids4774]

But I like shiny new toys

[@abdurrehmanazeem5119]

I will disagree with the last point, I think using a programming language or framework because its popularity has its benefits. For example, it's easier to find developers. The counterargument could be you might end up with bad devs.

[@ketanparmar]

@@abdurrehmanazeem5119 My point was choose programming language which is appropate for your project and domain.. don't choose because framework is popular.

[@ozanuslan]

Loved the key talking points! Thank you for this productive talk, definitely checking out the books mentioned.

[@slikk66]

"information hiding" sounds like a term I heard of a long time ago called "embrace the encapsulation".. was used for objects but fits here as well for microservices. also another oldie is "code to the interface, not the implementation". seems both still hold up!

[@ryanrobinson8682]

Been a software dev for 12 years and can't tell you how many arguments I've had with colleagues over micro services and not to automatically not use them for everything. So many developers think microservices are a silver bullet, the answer to all our issues. It's just not. You have to unpick the (often hidden) logic out of the monolith and try and create some nice simple service abstractions first. Create some nice bounded contexts like 'Payment Service' 'Communication Service' 'Order Management Service'. These services might be a little bulky at first (because they aren't microservices) - But you get an immediate value from that. They can be re-used by other teams and domains that need access to that functionality. It gives you a chance to optimise that code, put a good good alerting and monitoring and documentation (swagger) in-front of those new API abstractions. The legacy code can then be modified to call these new services, rather than having that logic embedded in the old monolith. Then once it's working, delete the old code, making the monolith smaller. (strangler pattern) I think a lot of people get confused over what a 'micro service' is, VS what a 'service' is. Micro just means really small, but a lot of people think event consumers and event publishers are the answer and they try and go from a bad monolith into a distributed monolith (using microservices) - Rather than just creating those nice service abstractions first. Don't try and sprint before you can crawl. I'm so glad in this video that both Sam and Martin agree with that concept in the video. It makes having these conversations easier with colleagues, when we can point them to videos like this.

[@careya]

Monoliths have a very bad name, in part because there tends to be a lot of bad design and programming built into them. Even within a monolith, code and data needs to be grouped. But too often even in microservice architectures, everything is still tied too tightly together. One service goes down and a bunch of others go crashing like dominoes.

[@NilsElHimoud]

Agreed. I tend to say. If you can't manage to modularize your monolith you should definitely not try to modularize it with microservices.

[@forebearing1320]

the folks that failed at producing good monoliths will also fail at producing good microservices...same reasons...except that the cost of failing in microservices is much much higher, complexity and maintenance wise.

[@chauchau0825]

because it's an easy execute. Blame everything on monoliths and then they can do all the shitty works all over again

[@ryanrobinson8682]

There's good monoliths and bad monoliths from my experience. But 8-9 times out of ten a monolith ends up being bad, just because it's never been refactored or modularised properly within itself. (over the years of it's existance) So many teams start jumping straight from a (bad) monolith into microservice event consumers & publishers.. Then end up creating a distributed monolith. They do this because they heard on the grape-vine that microservices are the dogs bo***** It's far better to create nice service abstractions, move the legacy monolith to call the new API, then delete the old code and strangle it out over time. You get the benefit of re-use from your service abstractions and potentially if they are big enough you could give it away to a single team. if they then want to drive that into microservices, that's their decision, but the hard work of simplifying the monolith would already be done and proven at that point.

[@orstorzsok6708]

@@forebearing1320 👌👌👌

[@sergiob3698]

Really interesting conversation. You guys are amazing.

[@bariscan9267]

09:00 zero downtime is true of monolithic apps as well, in case of an architecture that does not contain batch process operating on or manipulating shared data which might lead to an inconsistent state for the system.

[@MysticAngel3224]

Loved this presentation!

[@ethanthebrave2895]

Amazing chat! When it comes to architecture transformation, my primary interest is around the people element. (yep scrummy and transformation specialist here). I think when you move an architecture like this, as Sam has rightly pointed out - it's imperative to know your staff as you take the journey. Everything is symbiotic, the organization is a reflection of the people, is a reflection of the technology, and all vice versa, so it's important to understand that as you transition to a different architecture you'll be forcing the team from potentially 'performing' stage back to 'forming' and worse 'storming'. People don't like change. Especially change that questions their identity and how they see themselves. I've seen many senior leaders under-estimate the 'people' transformation side of things, and projects have suffered as a result. There will be casualties in such an undertaking. But I think, if you look after your talent with proper people transformation strategies, you can limit the damage. Of course, if it all goes terribly wrong, there is always wine. ;)

[@ryanrobinson8682]

Exactly, many companies (and it's usually coming from tech principles and dev leads) - blindly start indoctrinating the microservice approach. Even if that company has no experience with microservices, and has no staff with significant experience, they do it anyway. It's the equivalent of jumping in a car with no training or experience and driving on the motorway because 'you saw your friends do it' It's also symptomatic of cargo cult programming (give cargo cult programming a google and see what I mean)

[@alvaromoe]

I love this new format! Keep it up, can't wait to see more discussions with follow-up questions rather than undisputed one-sided presentations 👏🏽

[@meaanitu]

always great to hear such conversation. There are no bullet points to use MS or not... Or vice versa. It's Architect's role to decide what suits best for given requirements/constraints.. etc.

[@kennykanp5320]

OMG. i love watching these kinds of videos

[@shanikawijerathna1958]

Good conversation, but there was a point I actually double-checked which year this has been posted

[@mohammadmoozeh]

Thank you for great content. In the last part "Handling people", Sam mentioned trust, So what is his solution to build trust with in a team that want to use microservices?

[@pascalmartin1891]

To test a big monolith is often complicated, if you want to cover the system: a lot of features mean a lot of tests to run, and a lot of interdependencies that multiply the numbers of use cases to test.

[@washedtoohot]

Love this format ♥️

[@mehmetozkaya]

legends !

[@koskarvounis]

Great chat! My dad ears hear a baby crying in the background at @31:46. I thought it was my daughter initially

[@bbeda]

Good one. Thank you

[@solarseraph]

"We shouldn't need to make things difficult to make us do the right thing, but that just seems to be what life is" Not what I came here for, but man isn't that the truth Great conversation, a lot of developers ignore the semantics behind when and why you use a particular technology

[@deemarx]

Great conversation! What runtime does support hot deploy of modules? Why don't we move to that and avoid all the problems/complexity related to unreliable network?

[@Feyko]

Bit late of an answer but Erlang!

[@patcoder1287]

couldnt agree more with that last point. Left my previous job just bcoz my director was unwilling to make incremental organizational changes to accommodate the much more responsible incoming gen-Z batches, who without a doubt would eventually leave the company very soon given the orthodox rigid state they would have to continue working in.

[@premnathkn1976]

I am glad finally they came out together and spoke. This is a must watch video for all still struggling to get their products/solutions/services out as “General Availability” with microservices.

[@ryanrobinson8682]

I'd say all software engineers should watch this. It helps win these ridiculous arguments over common sense. So many companies have that cargo cult mentality and even videos like this won't sway them away from blindly implementing microservices.

[@nekony3563]

So, one of the reasons to go with microservices is that it's hard to coordinate the database part of a release (changes to the schema, etc.), but after getting to microservices one of the hardest issues is again the database (data consistency, relations, etc). Which contradicts/reverts the original reason. The only one left is people. If you get many people, then you have to split them into independent groups (as it is easier to work inside a small group) and sacrifice simplicity of the system (more distributed is more complex).

[@CalifornianViking]

Any good database allows you to create ACID compliant upgrade scripts that can be tested and run automatically. When building a database, it is important to be aware of what part of the database that is available outside the database. Most of the externally visible content should be through views and functions. This will ensure that internal changes can be hidden from apps that are external to the database.

[@FlaviusAspra]

What do you mean at around 21:55 that modules in java become weak? The jigsaw modules have become quite useful. Am I missing something?

[@user-pu5ho5kj7u]

I really like the summarization of key points that have been edited into this video, but at 31:19, the summarization missed a major point from Sam. It's better to break you data out first and then break out the code.... watch and you'll see Sam makes that point pretty clear.

[@justlearn3049]

Thank you

[@ronaldmusula3851]

this is cool guys database decomposition i think is key can also help us identify candidate microservices during migration

[@hosseinmohammadi4574]

It is all about doing engineering to achieve a performing product or to go for fashion to be seen as a cool designer. Whichever you aim, you can achieve

[@guestguest8226]

I think the only thing that makes me go for micro services is scalability. Otherwise, SOLID principles is enough.

[@frankhaugen]

I am a .net developer, and if I was starting a big application project as a one-person team, I would want to start out with a monolith structured like microservices. With that I mean that I have one solution for a huge amount of projects that have as few cross-project dependencies as possible, and structure the individual projects as if they are solutions. This will make it very easy to extract the logic into actual microservices when and only where it's needed, as it's a pain to develop for multiple microservices i parallel as a single individual

[@Norman_Fleming]

One thing to be wary of is when you have one solution which builds multiple dlls it is easy to introduce circular dependencies over time. I have been 'given' systems where you have to have the old build to build the new build because it had become so intertwined. I think microservices as mentioned here is another attempt to avoid that coupling. Glad he is not promoting this as the cure to all problems, but another tool to make use of where it works.

[@frankhaugen]

@@Norman_Fleming Anyone selling a "cure to all that ails you" is selling "snake oil", so agreed that the message here is on-point about it being a tool. I believe in strict de-coupling, but only as far as it makes sense. Sometimes it's better to duplicate code, other times it's fine to share a nuget, or just throw things in a pile because it's a limited scope. What many developers have a tendency for is "pattern lock-in", and refuse to change regardless of the realities around them; so as long as developers use the sensible parts of established norms, (Hungarian notation not included), it'll be manageable and maintainable to some degree. On the flipside, I'm seeing a lot of Python-first developers making the jump to .net and Java, having 1000++ lines of code in a single method with variable names horribly truncated then incremented with an integer at the end because "if you can't re-use then rename"... #rantover 😛

[@user-rs7ty4kg2z]

when you prepare the monolith for dividing into microservices, to ensure their independence, you will understand that everything has already been done and you no longer need to transfer to microservices)

[@frankhaugen]

@@user-rs7ty4kg2z that's the big question, but usually you have to balance cost, (many cloud providers charge by the pod), that will set your threshold, but I have microservices that have a single endpoint and less than 200 lines of code, and then I have huge microservices that have tens of thousands of lines and hundreds of endpoints. Only experience and experiments will give you the answer in the context of your application :-)

[@samuelkoo3014]

Amazing insights and a breathe of fresh air when I hear religious believes of why Microservices is God and has no downsides - and there are no space for anything legacy. Appreciate the objective judgement and this video should also help audiences who are interested in understanding what’s going on either side of the fence (mono vs micro)

[@ryanrobinson8682]

I agree, the problem is though it's not just Monolith VS Microservice. There's a lot of stuff in between them that people should build first. There's a difference between a normal Service/API and a Micro Service. 9/10 Your going to want to build a simple service that has a nice abstraction. Sometimes a microservice could be useful, a single AWS lambda that takes a file and writes a record away to a table, for example. Sometimes it's suitable to have a larger service that does a lot more work, but is limited to a single bounded context. (good monolith / normal service)

[@user-np5uh8do2x]

I think there are other set of reasons to use microservices. This is my ones: 1. When you need to separate reactive and passive parts in order to get your system being able to scale and avoid duplication of schedulers. 2. When a monolith becomes over complicated due to combining different contexts. 3. If different parts of the application have its own paradigm. I mean the major pattern appearing in your application. So if you have an app with a lot of integrations and the application should go through all of them like Chain of responsibility and there is another part providing things to the chain, you might need an adapter service and a chain.

[@heathbruce9928]

Your recap was much more useful than the ones in the episode. Thank you for commenting

[@kahnfatman]

When an enterprise is bad with a monolith, imagine how much worse it is for them to build a bunch of micro-monoliths that TALK.

[@milanzivkovic5790]

I would prefer more emphasis on problems that we are trying to solve. A CTO who is focused on microservices is probably not a good CTO. I like the part where it was disucced on top reasons to go for microservices but the same time conclusions are not convincing enough. Even Martin did not sound very convinced and if we are looking the best way to solve these top 3 problems we would probably find some other better solutions. I think that splitting code in multiple processes without understanding the bounded context can lead to much worse coupling problems than what we can find in monolith.

[@TheAmeer3881]

Yeap because design is not something that pure mathematics can help you with. Hence we have lots of coders, and less programmers.

[@ThomasTWilliams]

Very mature response IMO. The microservice architecture is highly depending on state awareness, so determinism is vital. In designs involving complex coupling of states, monoliths may be more effective. But is it wrong to take the best from both worlds? Isn't it what we have always done already?

[@ryanrobinson8682]

I genuinely think the adoption and discovery of microservices has hurt so many businesses. It's created so much over complexity and cognitive overload in companies, where problems could of been solved way easier. Sure there's a time and a place for a micro/small service, but too many developers think it's the answer to everything, and it's really hurt so many companies. There's a thing called minimum viable architecture (MVA) and it violates this so badly. You end up swapping out the problem of a hard to understand and manage monolith with complex business logic, to an impossible to manage distributed monolith. The complexity and mess of your domain logic still exists with microservices, you've just moved it around and probably introduced information hiding. From my experience it becomes and unmanageable mess and those developers end up leaving, then the staff left behind have no way of maintaining or understanding what's been created.

[@kevinfleischer2049]

I don't understand why OpenShift is mentioned here as a "rule by tool"? Its a container orchestration tool. Like k8s. Whats bad about it?

[@leonardo5695627]

Great format and edition!

[@vitorassissantos4302]

This video is a treasure

[@Anbu_Sampath]

Interesting conversation. one suggestion move the takeaway sections to last. I feel it stops the conversation flow.

[@lytwyna2]

DISCLAIMER: I havent watched the rest of the video, past 5:46, so they may have touched on this later on. But, my two cents on the "When to use microservices" is: When you have a variety of domain business logic inside a single monolithic application, then you should split that monolith into separate domain-specific microservices.

[@SM-ok3sz]

What is the point of interrupting the video to repeat what we just heard?

[@stiofanmacthomais]

I enjoyed this video, and the "challenge response" format is super helpful!

[@dennymeta]

Yeah, the format of the main content works really well! It's a shame about the jarring interruptions with 'takeaway point' voiceovers.

[@juancpgo]

Isn't the main point of microservices scalability? If I want to make an app for 1 thousand people, monolith will do, as long as I know how to manage servers. But if I want to target 1 million users and still focus on the product, I need to outsource infrastructure. And infrastructure as a service means I'm renting functions, which means I'm dealing with a decoupled architecture (microservices) by default.

[@deadbeef16]

We already left that phase. Currently companies adopt microservices where the user base is already very settled. Why would they invest in microservices if they know from experience how much traffic they have and can provision enough resources at any given time? For such companies scaling in team sizes is more important than scaling by demand. In the end everything is a trade-off. invest in LEDs to save energie, or keep the lighting as is, because of the costs? And a good SQL Server cluster will scale good enough for most of them. You can add caching too. So many options, so many decisions but in the end it is not about tech but the service you provide to your customers. But oh, noone will work at a company that does not proclaim agile and microservices. I have the feeling that splitting up a monolith fits only one purpose: new staff does not want to touch the old stuff. The old staff has already left and the knowledge is gone. Now splitting the big unknown up is one way of escape. It will fail because of burried business logic, thought though design and constant improvements done in tne past that just gets lost when building anew.

[@bobbycrosby9765]

No. It isn't. Depending upon your exact problem, 1 million users may be trivial to support with a monolith. You can take your monolithic codebase and load balance requests across multiple servers. Every server is running the same code and talking to the same set of SQL databases and distributed caches such as Redis and Memcached. Back in the late 2000s, we used these methods on a couple projects that got around 2-4 million daily unique users, each project using anywhere from 7 to 15 bare metal servers. By my calculations at the time it would have worked for a few more million users. And the limitation wasn't the code. It was the database. The database is the hard part because that's where the state is. We could have just kept piling on more application servers running our monolithic codebase for a very long time and it would have been just fine. We had around 30 total bare metal servers across all our projects, serving around 10 million daily unique users. With full redundancy. It took two of us an average of about 1 day per month to service those 30 machines - that includes patches, broken hardware, etc. Keep in mind this was all back in late 2000. Modern machines are much beefier. Despite what cloud providers may have you believe, servers run on electricity - not the tears of sysadmins. I have a friend that is still a sysadmin. His team of 10 manages around 3,000 bare metal servers and the virtual machines running on them.

[@house9Tube]

> Isn't the main point of microservices scalability? Yes, scaling your organization. Scaling number of requests per second, no.

[@srikanthinfy]

you can thank me later - martinfowler.com/articles/extract-data-rich-service.html the article fowler is taking about in @27:34

[@daisyflow]

Good discussion. The section summaries/take-aways seems totally losing it though!

[@vyrwu]

Great material!

[@vikasbisht7872]

P

[@guestguest8226]

I totally disagree with the second point about using micro services to isolate data from processing. This can be done using the database gateway/repository pattern.

[@djgreyjoy1495]

After you extract the microservice you look at the data? I would say it should be the other way around…

[@SB.collection897]

Super..

[@peterpodgorski]

This is an amazing conversation and an insanely important one. One technical feedback I'd like to give, though - I personally find the "takeaway" interjections distracting and not of much value.

[@peterpodgorski]

@@TheBledson exactly :)

[@CripplingDuality]

I disagree, I quite like them.

[@CripplingDuality]

@@TheBledson yeah that's fair.

[@rauljosechaves3291]

I disagree, for me was insightfull and give me some time to reflect about what they are saying. Maybe for advanced professionals can be distracting, but for new ppl i think is good.

[@scosminv]

@@rauljosechaves3291 It's good for everyone, unless you're in a hurry :)

[@dempile]

Finally Thanks

[@vinodshalgar]

nice

[@thirupathir6394]

Thanks a lot bro 👍

[@mirekrusin]

Just drop this micro- prefix and it all makes sense.

[@j.j.9538]

The problem is not with the monolith architecture. The problem is bad developers or tight schedules, creating code smell. This is obvious. So much so that, the greatest benefit with microservices is the great refactoring that comes with it, but give enough time and we'll all see the same problems ocurring with microservices.

[@awmy3109]

99% of apps don't need microservices just good modularity.

[@gflorin7761]

Yeah, unfortunately I believe you're talking about the 99% of apps that fail because of low sales, a goal no one should set. What IF you are successful enough to draw tens of millions of users?

[@awmy3109]

@@gflorin7761 High number of users doesn't equate to microservices. Where did you get your BS 99% stats from? My experience has been, delusional devs, riding the hype train, going with microservices when they don't need it and failing spectacularly.

[@kingscrusher]

Throughout this video what really concerned me from a theoretical perspective is the creation of bottlenecks and dependencies if organisations did experiment with just one microservice and without a microservice architecture that doesn't have an event bus. An event bus will reverse all the dependencies and make it easy to add new microservices, etc. Surely given the importance of "Event bus microservices" they should really be qualified like this and the standard recommendation nowadays. Without an event bus, the issue of for example join queries is made even worse if services have to be interrogated for their data rather than a reverse dependency scenario where they enrich a central event bus. Cheers, K

[@mrrajyt7693]

😂

[@paulpasquel5905]

Monolith: a good term to make good business ... 😁 if you heard monolith, you will tend to relate your software with dinosaurs ...

[@szeredaiakos]

"It's easier to limit the impact of each release when using microservices" this is false. It is not easy at all. In fact it is just as hard if not harder. The fact that you HAVE TO do it doesn't make it any easier. In a modular monolith you can fully decouple certain parts of the application. The way to test that is to delete the folder containing a discrete module. If your app still works, you are golden. But that alone requires some finesse. Now imagine doing that while bouncing back and forth between applications playing wackamole with coupling. Tho it is easier to draw the boundaries of service based architectures, the context boundary violation still occurs in both approaches. The monolith offloads the context boundary protection to engineering discipline, the microservice approach offloads that responsibility to management and team interactions. Further, it is pointless to adopt any service based architecture if a company lacks the ability to build, automate and maintain delivery pipelines with some respectable haste. Needless to say, I have more trust in engineering discipline than technical management competence (tho' not much in any of them). IMHO the primary reason to break out a separate service is when a particular context has wildly divergent architectural characteristics from the rest of the service and becomes prohibitively expensive to satisfy all of them in the context of a monolith.

[@wariskn7096]

Athil vella albudamonumilla eng kazinjal varkapannni muthal porrota addikunathu sarva sadaramanu... ..

[@zainulabid3157]

Sir endhine patti ulla Discation aana just explain cheyyan patto

[@vikaspanwar2537]

here's my perspective on why micro services may not be the right choice for you - kzbin.info/www/bejne/gouzpKyOZa9seq8

[@rebuzzalex]

Mantap

[@michaeldeng1981]

One of the problem Microservice bring is orchestration of services

[@temporary112]

For me going for microservices gives me chance of: - remembering what the whole service/app is doing and is resposible of, in total, with all extensions: "context" - using any developer instead of a real senior, to split up the work: the monoliths almost always require an experienced personnel due to very harsh time debugging and undestanding where the bottleneck is. On the other hand, monitoring/profiling separate systems are more easy with common tools. - as told many times, having less and less misfortune when the scaling is needed (mostly) That's why I tend to lean more towards microservices with more bias. All in all, thanks for great talk.

[@gentooman]

"using any developer instead of a real senior, to split up the work: the monoliths almost always require an experienced personnel due to very harsh time debugging and undestanding where the bottleneck is. On the other hand, monitoring/profiling separate systems are more easy with common tools" Right, so debugging a single application is hard, but debugging a distributed application is easy? "as told many times, having less and less misfortune when the scaling is needed (mostly)" you don't know what you're talking about

[@temporary112]

@@gentooman Thank you.

[@JamesSmith-cm7sg]

If you can't create a quality monolith then creating a microservices architecture will be much worse.

[@kenigiri]

Very insightful.

[@maazrehman8723]

Sam knows his domain very well.

[@careya]

So many great points here. Thanks for the great content.

[@-Jason-L]

There's this weird argument that "proper" microservices (thin slice, context bound) are more difficult than a "proper" monolith (coded with proper techniques (loosely coupled, etc)). I believe the entire opposite - only go down the monolith path if there is a very good reason for it. I had about 15 -20 years of monolith experience. 5 or so years in micro services. I have not heard one argument pro monolith that I agree with anymore. It reminds me of the late 90's, when folks would still claim there was an argument for building your middle/back on a mainframe, with a thin tier between it and a modern (at the time) desktop UI (java swing, vb, etc). Or custom building messaging servers at the socket level instead of using something off the shelf. Folks just unwilling to let go of skills that have become irrelevant as technology marched forward. Move to serverless and microservices and be done with it.

[@phantom2068]

Saving money with micro-services architecture. Hire a costly developer, make them build one or two micro-services in next two to three months and then fire that developer. To do this successfully make sure to hire a very low cost developer who joins on the last working day of costly developer and maintains the new micro-services.

[@awmy3109]

Lol... Experienced devs have something up our sleeves for douche bags that think they can get away with behaving that way. When we play the card, the day we leave is the day your project comes crashing down. Your cheap developers can't save you. Only more experienced and "more expensive devs" will. You will spend more while trying to be smart.

[@pesetskyps]

I feel like Martin sometimes was sitting and thinking: "Too abstract, Sam, too abstract...". next time let Martin answer the questions :)

[@PunkVoter]

Martin got no chill

[@SamuelKarani]

Jesus and Moses discuss microservices

[@numankaraaslan]

The biggest downside of monolithic application is the fact that the developers of these applications come and go frequently. That results in bad code which is hard to interpret. This necessitates a big doctrine or set of principles to follow for developers. This guideline grows bigger as project grows bigger. And this reults in bad code from frusturated developer again :) I don't think there is a truly dedicated company to make this work and keep the developers happy and the system in check.

[@matejlaskomulej]

This. Though there are companies you talk about in your last sentence, even here in Slovenia. Companies find it more and more important to keep their employees happy.

[@davidhsv2]

Can't wait for this hide and seek microservices trend goes away. And this java one liner obfuscated functional code goes away too. When people decided to over complicate programming by default?

[@kellyrankin8844]

Complicated has some relativity to it. I find large vertical scroll to be more difficult to digest vs chained operations.

[@CaimAstraea]

99.999% of the time microservices are not needed imo. Much easier to scale and reason about with a monolith. The headaches and introduced complexity is just not worth it.

[@kellyleahy3950]

OMG.... this session is incredible, but I really wish the commentator was somewhere close to the level of knowledge of the two session presenters. Each summary comment I saw in the session made me cringe. I can't think of a single one that "summarized" the discussion in a way that I'd agree was the "valuable point" of the discussion.

[@about_midnight]

so microservices are not about performance scaling? sorry not an expert

[@vinayekka6915]

VIVO

[@thebholevlogs]

Hari Om

[@oeaoo]

Micro is the first untrue of all the other.

[@user-ul6fo4bh7i]

Roshni thakor

[@Sskull3031]

Idk, why I m watching this

[@orstorzsok6708]

some points are very good, but this new hype with the microshit and the whole over-philosophying of this simple shit that is sw development is ridiculous 😂

[@kalpanamukherjee6225]

Manna Dey hindi songs

[@chchandra8205]

Ku

[@tufanibaba777]

Language problem im from India language Hindi

[@mcpop2828]

Solving a political problem ? Why dont they discuss more sociotechnical aspects. We live in an organizational context, ie political one.

[@adityagarimella4723]

Sam is using too many words to explain simple things. Just use simple language and be direct. Please don't waste you time, you can watch some other video.

[@iamworstgamer]

another mumbo jumbo on microservices without a substance

[@sid06]

What is this "take away" stupidity? It makes the video nearly unwatchable. I just heard _your_ take away, it was 30 sec. ago.

[@tube4Thabor]

Especially egregious when Fowler says "monolithic is easier", and the takeaway becomes "monolithic is harder"