Been in software engineering field over 19 years. I'm developer to Architect and really love when these two skilled persons talking about this topic. Microservices! The headache of everyone in this industry.
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.
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.
@@abdurrehmanazeem5119 My point was choose programming language which is appropate for your project and domain.. don't choose because framework is popular.
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?
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.
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.
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.
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.
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.
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.
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).
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.
"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!
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. ;)
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)
"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
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?
@@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.
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.
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
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.
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.
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?
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
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.
@@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 😛
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)
@@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 :-)
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.
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.
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)
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)
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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
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.
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.
"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
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.
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.
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.
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.
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.
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.
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?
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 😂
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.
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
Been in software engineering field over 19 years. I'm developer to Architect and really love when these two skilled persons talking about this topic. Microservices! The headache of everyone in this industry.
Very sensible and nuanced exchange. Wish there was more of that format in our space.
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.
Just like one of Venkat's talks, Do not walk away from Complexity, Run.
I thought it was when to evict caches and naming things ;)
But I like shiny new toys
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.
@@abdurrehmanazeem5119 My point was choose programming language which is appropate for your project and domain.. don't choose because framework is popular.
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?
I’m totally guilty in following the trends. But at least I realize it and use it as an opportunity to improve 😅
Maybe. Not really. For me, not at all.
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.
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.
🎖🎖🎖
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.
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.
Agreed. I tend to say. If you can't manage to modularize your monolith you should definitely not try to modularize it with microservices.
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.
because it's an easy execute. Blame everything on monoliths and then they can do all the shitty works all over again
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.
@@forebearing1320 👌👌👌
Loved the key talking points! Thank you for this productive talk, definitely checking out the books mentioned.
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).
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.
"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!
I LOVE TYHIS DISCUSSION AND HAVE LISTENED SEVERAL TIMES AND IS NEVER REPEATITION !!
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 👏🏽
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. ;)
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)
"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
I think the only thing that makes me go for micro services is scalability. Otherwise, SOLID principles is enough.
99% of apps don't need microservices just good modularity.
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?
@@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.
@@gflorin7761 Add another database and connect the same backend to it, then scale the backend horizontally.
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.
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
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.
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.
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.
Yeap because design is not something that pure mathematics can help you with. Hence we have lots of coders, and less programmers.
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?
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
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.
@@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 😛
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)
@@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 :-)
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.
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.
Your recap was much more useful than the ones in the episode. Thank you for commenting
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)
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)
Really interesting conversation.
You guys are amazing.
OMG. i love watching these kinds of videos
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.
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.
Great chat! My dad ears hear a baby crying in the background at @31:46. I thought it was my daughter initially
It's time for Microservices to Monolith now 😅
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.
Good conversation, but there was a point I actually double-checked which year this has been posted
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.
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.
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.
you can thank me later - martinfowler.com/articles/extract-data-rich-service.html the article fowler is taking about in @27:34
Loved this presentation!
What is the point of interrupting the video to repeat what we just heard?
Great format and edition!
Love this format ♥️
"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.
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.
@@TheBledson exactly :)
I disagree, I quite like them.
@@TheBledson yeah that's fair.
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.
@@rauljosechaves3291 It's good for everyone, unless you're in a hurry :)
This video is a treasure
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.
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.
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.
> Isn't the main point of microservices scalability?
Yes, scaling your organization.
Scaling number of requests per second, no.
legends !
Interesting conversation. one suggestion move the takeaway sections to last. I feel it stops the conversation flow.
If you can't create a quality monolith then creating a microservices architecture will be much worse.
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?
Bit late of an answer but Erlang!
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?
this is cool guys database decomposition i think is key can also help us identify candidate microservices during migration
Great material!
P
Good one.
Thank you
Thank you
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.
Good discussion. The section summaries/take-aways seems totally losing it though!
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.
Just drop this micro- prefix and it all makes sense.
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?
I enjoyed this video, and the "challenge response" format is super helpful!
Yeah, the format of the main content works really well! It's a shame about the jarring interruptions with 'takeaway point' voiceovers.
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
😂
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.
I feel like Martin sometimes was sitting and thinking: "Too abstract, Sam, too abstract...". next time let Martin answer the questions :)
After you extract the microservice you look at the data? I would say it should be the other way around…
Finally Thanks
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?
Monolith: a good term to make good business ... 😁 if you heard monolith, you will tend to relate your software with dinosaurs ...
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.
"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
@@gentooman Thank you.
Thanks a lot bro 👍
So many great points here. Thanks for the great content.
Very insightful.
Super..
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.
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.
Jesus and Moses discuss microservices
One of the problem Microservice bring is orchestration of services
nice
Sam knows his domain very well.
Martin got no chill
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.
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.
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.
True. The simplest reason is that you're not google, and you probably never will be google.
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.
Athil vella albudamonumilla eng kazinjal varkapannni muthal porrota addikunathu sarva sadaramanu... ..
Sir endhine patti ulla Discation aana just explain cheyyan patto
here's my perspective on why micro services may not be the right choice for you - ua-cam.com/video/LZPsyX0J9DM/v-deo.html
so microservices are not about performance scaling? sorry not an expert
Mantap
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?
Complicated has some relativity to it. I find large vertical scroll to be more difficult to digest vs chained operations.
VIVO
Idk, why I m watching this
Micro is the first untrue of all the other.
Roshni thakor
Hari Om
Manna Dey hindi songs
Ku
Language problem im from India language Hindi
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 😂
Solving a political problem ? Why dont they discuss more sociotechnical aspects. We live in an organizational context, ie political one.
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.
another mumbo jumbo on microservices without a substance
What is this "take away" stupidity? It makes the video nearly unwatchable. I just heard _your_ take away, it was 30 sec. ago.
Especially egregious when Fowler says "monolithic is easier", and the takeaway becomes "monolithic is harder"