Previous company I worked for had an architecture you could kindly call "a big ball of mud". So everybody decided that the thing to do was bust up the monolith and build everything out as microservices. They now have a big ball of mud - but microservice based. I don't love or hate microservices, but they're not magic and don't remove the need for a good underlying design. I certainly wouldn't be sorry to see the industry stop thinking that microservices are a panacea.
At the place where I work we have a nice microservice architecture. Everyone is happy with it. I guess "a big ball of mud" problem is not related to a type of architecture.
@@toooldtobejunior It absolutely is related to the type of architecture. Use the wrong tool for the job and you have problems. Saying micro services worked for you in one scenario therefore there are no issue with it is noob level dev thinking, and just terrible basic reasoning skills.
@@JohnSmith-op7ls okay. I get that I'm a noob from your point of view. Could you please teach me? Just tell me what is the business problem that you found microservice architecture is not suitable for? I will really appreciate it.
The company I worked for was burned badly by moving a cloud based service to microservices .... the decision was not made by the technical leads of the company .... it was the CTO's and CEO's who bought into the hype. They commanded loudly "Let there be microservices !!". A few brave souls among us peasants voiced concerns about falling for FOMO factor and no real reasoning behind this decision. Soon after, they were no longer seen. I suspect they are now at the bottom of some river tied to a concrete block. Some 100+ microservices later, we created a behemoth that even Egyptian pharaohs would be jealous of. We proudly slapped a price tag of a million bucks on it ... ... but that pesky little rival across the street was selling a teensy-weensy monolith for half the price and a fraction of the computing real-estate; while claiming all the same functionality. We stood tall and proud and bragged about our microservice based architecture. The customers all stood around that little hot-dog stand. Our CEO roared ..."Y'all blaady cheapskate plebians!! No appreciation for fine dining". Pretty much all of them figured their workloads are not so dynamic and they don't need K8s style scalability for at least another decade or so. A year later, half the company was laid-off (your truly included). Saving grace ... the CEO/CTO's were also thrown out the window (but they had their golden chutes on).
I always use to think that teams that are not able to modularize a monolith should definitely not try to modularize a distributed application. FIRST mudularize the monolith THEN spin out microservices IF there is a valid reason to do that.
I think you need to know why you're doing this. What's the gain at the end that you are desperate to have and evidence to know it'll be achieves. For example are you moving slowly as a development house, and what evidence have you got you'll move quicker afterwards.
The reason why this is good advice is that for having achieved the modularization, it means it was refactored enough to have sorted the right relations between dependencies, hence, the well modularized monolith works as a prototype on how to implement it more horizontally scalable with microservices.
@@SebastianSastre There is no diffirence if the goal is to modularize only. Monolith you call public function. Microservice you call api. Calling public function is faster vs calling api.
um... it seems hard to challenge back.. Ha.. Sometimes, people might thought this is a negative thinking. However, I do think in the same way. Distributed application is another level deserving more thoughtful actions. But most of time, we(or those around us) had too much expectation on "new toy" or under-estimate what it costs.
Only five users in the same building but solution developed using Microservices because the Team Lead, Devs and Architect opted for it. Reason it's always good in resume.
We introduced micro services at my company some years ago. Today the backend is a total fragmented mess that is extremely expensive to host. From my perspective micro services solved absolutely zero problems but added a shit tonnes of complexity
My experience is that developers get over excited and turn the simplest thing into an academic exercise of technical masturbation. This happens with both microservices and monoliths... so it's not a problem with the technical architecture. Example: at work we're building AI services. As the org wants to meter and charge for usage there's a gateway in front that handles that and the auth / routing to each service. Each service started as a HTTP api integrating straight with AI model providers. This meant developers could test and develop directly against the individual service and it should work when changing configuration to use the gateway. Happy days! developers can iterate quickly on what will likely be throw away AI services, they can choose which models and providers suit them. Simple. Then someone said "our services should know nothing about the AI providers" and built the "model facade", and an SDK, and a framework. Oh and it has a single set of API keys... cough... rate-limits... So now developers can't run their service and integrate directly with services (learning about the models / service) - they now have to run the great model facade. Now... the model facade is now getting changed by every developer, tests are bleeding across boundaries making tests slower to run.... there's no API versioning or strategy, no consumer driven contract tests... all because nobody asked why and pushed back (except me) but devs gonna dev... A year on, no AI service has been worried by a user, I suppose it's all got to be perfect first 🙈
The main problem I see with the costs are cloud related, instead of just using IaaS or on-premise. Nowadays a consumer PC hardware is more than enough to handle shit ton of software resources but what the heck lets develop shit ton of MSs with Node that do 1 simple thing with a docker container of 600MB and use almos 1 GB of ram each one of them and of course use the cloud to manage those containers... Lets over engineer MSs! because why not? need another function in the app? do another service! just throw some budget in it...Efficiency at its best
Totally agree. Zero problem solved, additional complexity (protocol sync between micro services, code dups, even different langage or framework), headache to maintain, time consuming. This is useless for small/medium structures. Modularize & go monolith. KISS.
The tech industry often chases trends, but we should prioritize what works best for our specific projects and teams. Meta's continued use of PHP, despite repeated declarations of its obsolescence, is a great example of this pragmatism. They've stuck with and improved a technology that suits their needs, rather than constantly switching to the latest 'shiny' thing. In software development, success comes from making informed decisions based on project requirements and team capabilities, not from blindly following trends. It's about finding the right tool for the job, whether it's cutting-edge or time-tested.
You left out that part where Meta isn't actually still using PHP. They found PHP to be so lacking w/r to scale that they more or less recreated a new programming language that uses PHP syntax that essentially compiled to C++ object files and then assembles these object files to native executables. So your example here doesn't really support the whole "you should switch to a new technology that does the job better than your old technology that does the job terribly"
@@thecollector6746 so based in your logic if a project was created using Java code and is later compiled using an Azul compiler then is no longer Java? I said and stand by: "They've stuck with and improved a technology that suits their needs, rather than constantly switching to the latest 'shiny' thing."
I have been doing solution architecture in large corporations for 25 years. I watch all the fads come and go and evangelism when some new architecture pattern comes along is amazing. My good friend builds houses for a living, when a new tool becomes available he just knows how to incorporate it into his building process, what he doesn't do is try and replace ALL his other tools with the new one.
The reason is that neither his new tool is going IPO or his building business is listed 😂 I remember a few decades ago some companies suddenly had valuations that shot up overnight merely because they started using XML to do whatever they had been doing before without XML 😂😂😂 today we have AI. I am sure there are business models that would be much better if they did NOT incorporate AI into them but they wouldn’t get the short-term attention that is often needed for continued funding/revenue. Would you like to learn more about this topic? (😂😂😂)
Agree with the sentiment here. One consideration you didn’t cover was microservices as a tool to solve the problems of organisational complexity. I have spent my career in technology in banks with thousands of technology employees and hundreds of interconnected applications, many of which were legacy. Coordinating a team of dozens of people on one, aging codebase becomes very hard. Also, if you have a dependency on one of those teams, getting a change made can be a coordination nightmare. Breaking into smaller services helped to solve that organisational problem. If you have a smaller simpler service, then it’s easier for others to contribute and it was also an opportunity to modernise, adding in automated testing, clearer interfaces etc, which led to more agile teams and technology. I do agree, it became over used and the downsides misunderstood or glossed over.
Micro-services allow you to scale - this was never about the tech or scaling horizontally to handle more traffic - it was about people, ownership and rate of change in different parts of a complicated system. It is all about organizational scale.
Shows you how much we have become a victim of the marketing from the large providers. I looked at microservices for our products and the biggest advantage was non-use no cost, but when used, cost a lot more then monolithic. Microservices are also a lot slower when you crunching a lot of data. You cannot cache it well enough and cloud costing make it super expensive. This was always obvious but still we saw a lot of terrible choices. Only now when money is stretched, are they seeing the reality.
You’re absolutely right, I’m seeing as Cloud cost continue to rise. Everybody’s running away from any inefficient architectures. Well micro services do have their used cases, they were indeed overapplied.
I think the pain point is, teams now want to make everything a service when there may actually not be a need for it. We currently have identity verification done in most of our services, and each service keeps duplicating codes, so we just decided to make an independent service to handle this verification which other service can make use of. The thing is in a much as its good, it can get out of hand just cause teams feels like its the shinny thing without understanding the complexities these might cause, including using queues for decoupling which adds its own complexity for something that no other service would even use.
Devs with less than 10-12 years of experience almost always have shiny object syndrome. They just haven’t been around long enough to see how these trends come, get overhyped, create lots of problems when misused, then get replaced by the next trend. And the trends usually come full circle and repeat. Like going from mainframes to fat clients back to thin clients which is a rehash of mainframes. Or server side rendering then bloated browser frameworks, now server side rendering is getting popular again. The grass is only greener when you really know what you’re doing and what the pros/cons are with each solution.
If monolith works just fine then there is no need to microservice it. Microservice is a solution to a problem. If there is no actual problem to solve by microservice then there is no need to do it.
I worked for a company with a cloud team that spun up containers with terraform and broken out to so many microservices that when I asked if we could look at a front end to confirm that these services are updated properly (just looking to confirm the footer notes went from version 15.3 to 15.4 as an example) and it started a fight within the team and a 2 hour meeting on why anyone cares about that vs how do we even know what we are changing is being changed....needless to say I left that company and they lost the contract they were on
Microservices are just one of the architectures you should be looking at when developing an application. To many times microservices has been to go to architecture based on hype rather than requirements and most importantly the team or teams structure type to develop and support the architecture.
I love micro services. Seriously. I think most folks just don't really understand how to work with them correctly or how to scale them correctly with costs in mind. They will quickly deploy an entirely new server cluster for a new service instead of shard sharing with the original lot. Auto scaling is a big deal when using micro services, and ensuring the correct setup from the beginning and the ability to rapidly deploy the correct patterns within the environment.
I think there’s some truth to that, I think most people don’t design them correctly that I’ve seen, also they’re used when they’re contraindicated, which is kind of the focus here. Whatever that doesn’t diminish from the fact that you brought up a good point.
Totally agree. Micro services are not magic, it's are just a good practice. And impotent architects and developers will not become good, whatever technology they using 😅
Microservice are like communism, nobody has really tried them or implemented as Lénine envisioned. I mean, 15 years is too short to figure out how it should really be
Thank you for making the video. I agree with your pragmatism. I would, however like to expand on and challenge the following: There are at least two types of modarity; development modularity and runtime modularity. The microservices camp talk about them as if they are the same. We have had development modularity since the introduction of the header file in C in 1973. There is value in runtime modularity in some select applications. The term "Monolith" is a misnomer. We have not built monolithic applications since the introduction of client-server architecture in the 1980s. Ironically, the only monolithic applications we build today are Single Page Applications (SPAs). Ironically, we refer to these as "modern", just like microservices. SPAs will be the next thing to die.
While I'm not here to specifically advocate for microservice-oriented architecture, my experience of over 20 years in the industry has shown that the most common challenges often stem from human error, rather than the technology itself. Microservices, when implemented correctly, offer a robust architectural approach. However, without the necessary skills to design and code within the framework's constraints, or by cutting corners and misapplying the technology, one cannot fairly place blame on the architecture itself. The key to success lies in understanding which parts of a system should remain monolithic-because overcomplicating certain components can introduce more problems than it solves-and which elements can be effectively broken down into independent services. Knowing the right tech stack for different modules, and when to leverage external services to seamlessly integrate the system, is what truly distinguishes capable architects and system designers from developers who have yet to refine these skills.
Very well said. Unfortunately, the industry is more about what we call things (agile, microservices, test driven) instead of what we actually build/deliver.
I'm so so glad that people started finally talking about the inherent problems of micro-service. I had so much problems explaining the dis-advantages of the micro-services, at least now I have some arguments.
Building microservices to read data is OK. Looking up SSN is a good example. However, once they start writing data then the problems begin. Communication between microservices, maintaining distributed transactions -- are not easy tasks at all.
IMO, the modernization discussion begins with "Why," not a target technology. Microservices definitely has its place, but not all apps require it, nor do all teams have both the resources and skills to architect it.
I think ultimately that’s the point I’m making, the problem is it’s been overused and causing grossly under optimized architectures that’s the other point I’m making.
One of the hidden cost is also eventual consistency. Remember that "Eventual consistency == Permanent inconsistency". A lot of mecanisms, tools, ... (aka moving parts) needs to be put in place to mitigate this problem that is near absent in a Monolith design.
In most cases, the deciding factor is Conway's law. If adopting microservices allows your different dev teams to work more independently and each at their best pace, it will most likely outweigh the cost of the increased overall complexity. As always, YMMV.
This. Service architectures aren't antything new. SoA over Soap this, Soa over CORBA that, Com+ distributed object computing etc.. Service based system is natural emergant property of large and complex organization. The principal value of SoA is having a standardized boundry which is usefull in comunication and job division. You write contracts at those boundries (like business contracts, I-ll-hire somebody to implement this spec contract). It is also the hardest thing to "capture". Conway's law is good practice here. It seems to me that large number of modern microservices are mostly driven by desire to be lightweight. To play *nice* with cloud. In short they are used because of associated technology stack. And not because of real need of service architecture. Which is perfectly fine as long as you know your dues.. If you find yourself using microservices without really needing boundry layers, you could probably simply your life by removing those.
My last job was a Microservices Architectural Hell! Basically, they simply had WAY too many services! And along with that, plenty of bugs which were difficult to track down, because of the highly distributed system. So I've now come to the opinion that, some kind of balance need to reach... Not Monolithic... Not Microservices... But something in-between... Macroservices!!! I.e. reducing the number of services to ease maintainability and costs... But still keeping these fewer larger Macroservices distributed. I.e. trying to aim for the BEST of Both Worlds!
Especially Microservices are not for Small Business and Small Applications. Even for mid scale there is a way to use a hybrid architecture or Mono + Microservice model.
All (non-need-to-synchronize) distributed systems are only as good as the underlying network they use, as well as their ability to recover, in a case of nonstandard events. In addition, any endpoint being used in such distributed architecture needs to be able to scale up/down its bandwidth accordingly, otherwise the sporadic-slowness transient events would be an absolute nightmare to deal with in real time.
The software industry has always been plagued by dogma, and it's much worse now than when I started 25 years ago. Microservices is no different. No quite as bad as TDD, but there are many microservices horror stories out there.
The problem is microservices develop interdependencies and rarely can you deploy one without having to regression test everything negating the entire benefit. All they do is avoid code conflicts, but the problem gets pushed down since code conflicts represent people not coordinating changes.
This is the key. I'd go so far as to say the only reason to use microservices is if you have scaling limitations that can't be addressed any other way. I'd wager that in virtually every case microservices actually slow development velocity in the mid to long-term. They basically push interface versioning and dependency management into an area between code-bases and introduce extra complicating factors (like network connectivity, latency, and caching).
It sounds a LOT like the conversation around Object Oriented design and componentization, because it's the same thing... The same applies to micro solutions in apps too, vs monolithic apps. I love the modular-monolith approach, but each choice needs to be considered on merit
Common sense is back (I hope). People just started to follow the trend blindly and got burned because they didn't have experience to break things down into microservices the right way (AWS was happy with all the cloud money they made..). It is not black and white between monolith and microservices
I've been building apps this whole time since microservices appeared either alone or in small teams of 2 to 5 people. And I always thought "yeah that sounds like it can be cool but I dont need that, it would overcomplicate things for nothing" so I never really used microservices. This video tells me that the experience confirms my initial intuition.
I agree with the premise - yes Microservices are HARD! However, the problem often comes at a lack of understanding the complexities it involves, and so many of these architectures today, basically suffer from the Marketing/Value proposition perspective. This is problematic. They were enabled and green-lit based on marketing, not on understanding the complexities of the architecture itself, and what it deems. It's also highly misunderstood that Microservices, also ties into an organisational pattern, and this requires your organisation to also embrace process' that are NOT aligned with more traditional constructs. So, I fully support NOT over-shooting here, when you could choose a small monolith - that in any case can always be virtualized. But I'm sorry, it is NOT the Microservice Architecture that is the root of the problem, it's Architects! Do it right, and you're in for a ride, do it wrongly and you end up in technical-debt scenarios, distributed-monoliths (because, someone didn't get it) and so forth.
Hi there, Nice video. I particularly like how you are leaning towards companies not just following the latest trend without taking an honest look at the deeper trade-offs possibly involved. Try to read through the sales pitches of new trending technologies and try to really understand the performance or scalability differences and if they are really worth the cost. Although the larger enterprises' would have the extra capital to put into these ventures more easily, small to mid-sized companies would not, and should everyone really just be chasing the next trend even if potentially not right for them.
I think that’s the ultimate message here, at the end of the day these micro architecture deployments are bespoke for the problem domain. My problem with these trendy architectures, like micro Services, is that they were overapplied, when actually they are pretty good when applied correctly.
Its the same as multi threading, first you try to make everything multhithreaded, atomic and so on but then you cant mantain this piece of code, so the rile of thumb is to find the sinplest solution you can find for this specific task
Microservices using mono repos is the right approach. Using three pillars around: Build and deploy them independently, build and deploy only once, shift test left (test on branch and not on the main line). I think something that nobody talks about is that in the end you have one application and you want to test that combination of different micro services before you release to production. Well you cannot do that if they are build and deployed independently. That is why you need something to bind all together at the end of the pipeline. And that is what you gain by having a mono repo where you can control the flow and test that particular combination of microservices before you merge and deploy to production.
I feel confident in saying the best approach to designing systems is to leverage a hybrid monolithic/microservice architecture. The backend, where the data resides, should probably be a monolithic entity. The issue is on the front-end. The WEB is stil the wild wild west of frameworks, languages, libraries and who knows what else. The front-end needs an intervention. It's crazy that we have all this complication to deal with.
I’ve been saying macroservices, not microservices since it came out. A general rule of thumb is systems should be between 25 and 100 database tables, perhaps 200 tables. But the 800 table systems are too big and should be broken up into 4 to 8 modules/macroservices with 100 to 200 tables. Likewise If a system has 3 tables in it, it is most likely too small unless it uses/needs a different stack like redis. There is a sweet spot on size and now with SSDs being very fast the hardware limits are removed now allowing for much larger database size. Databases used to be the bottleneck but are not as much anymore with the hardware improvements over the past decade
The first idea that comes to mind during the listening is to use (if exists) or develop a framework that allows developing apps as monolithic and, when needed/appropriate, "natively, (almost) instantly" convert parts of the apps into "ready to scale" microservices. And reverse, when needed.
Heyy , Will these monolithic or microservices replace by GenAI or Machine Learning. Or GenAI or ML will be inducted in Applications for other requirements of business. I am lil bit confused with This GenAI and ML thing. How it will implemented in Business. Please explain this point in your video. Thankuuu
On a provocative note: If an interface isn't defined well enough to be used everywhere, it shouldn't be used anywhere. "Well defined" is to say: Expecting input a(range), b(range), opt c(range); Will output x(range), opt y(range); Processing rules A, B, and C, ref source. Test development automation is trivially and universally available for microservices. From a DEV/QC perspective it might be worthwhile sticking to microservices, even if they end up being turned into libraries. BTW: I never believed for a microsecond that microservices were a good idea for medium scale (couple of ten thousand requests/s) deployment, and I have no idea how the large ones scale.
One way microservices might end up being beneficial as "end user accessible services" is ad hoc recombination of processing steps. For quick and pretty straightforward evaluations, CLI pipe style.
EJBs used to be a way to create specialized services but it was not a micro service. It was more of a monolithic java bean. The trend was to move away from this and move to micro services. I think it would be worthwhile to revisit the way services used to be made but work to improve them not replace them with completely different technology to promote a new trend.
Going back to 500k+ lines of code in one service I say would be a step backwards. Smart domain separation and interface definition so that you get a clear separation of concerns and right amount of cooks per soup I would say is something to keep. The question in my opinion is finding the right size of services. Within a clear domain a monolithic kind of setup is probably a good idea because it's faster to build up, easier to maintain, less network overhead etc. etc.
If you can't design your microservice architecture in a way that the services are loosely coupled with one another, that is, making a change in service A doesn't require making a change in service B, C, and D, then I think you're better off in a monolithic architecture. The need for heterogeneous scalability between different services is also a reason for switching to microservices, as in service A, B, C, and D need to scale up or down differently at different times. Also, network latency should not be a bottleneck; otherwise you're in a world of pain if you're trying to optimize for performance. Many people run into this issue and try to work backwards to merge various services together and you're left with some kind of ad-hoc design that is somewhere between a monolith and a true microservice architecture.
Mindlessly following trends will always lead to disaster. Being greedy will always lead to disaster. Architecture should depend on what we are trying to achieve
This is the first episode I watched and I don’t wanna be too critical, but this seem like the conversation was generated from ChatGPT and just read as a script. I expected to hear statistics and reasoning from both sides of the argument with real worldexamples. This video seems like a high level introduction to to ponder what you should do. The title should be I need to wonder about how I’ve built my architecture.
You need microservices. You also need a more robust documentation the more complex it gets. Nobody wants to spend the weekend trying to figure out the 5W1H of the value x
Microservices are great if they are the right solution for the problem AND you actually build a microserivce and not just a Spring Boot/Quarkus REST endpoint labeled as such. We all know that Microservices was a misused buzzword (like agile, event-based, and so on). REST is not microservices. Too many people incorrectly lable something 'microservice', then complain the microservices are not the answer when that is not what they built. Microserivces, like everything else, are not silver bullets. They aren't magical and won't fix every problem. If the solution calls for a microservice and you build it correctly, they are outstanding. Simply declaring 'microservices are dead' and moving onto the next thing will just result in that next thing being declared dead in a few years.
Easier to automate AI code maintenance with microservices versus monolith. If rate of iteration is important than microservices will be hard to beat. Monolith are great for optimization. But microservices is more than just popularity, it's the tradeoffs for composability and rate of change (at cost of complexity and price)
Microservices are a replacement technology for OOP/Static Typing (to be technical both are Message Passing technologies). You want to ditch OOP/Static Typing because it takes on average developers 3x as long to code a software feature in OOP/Static Typing as with dynamic languages like Python or Ruby. For example, 16 hour compile times in large Monolithic systems isn't uncommon... So the real question is should you go with Monolithics and 3x your developer costs or should you go with Microservices and the scripting languages and 10x your server costs. For 80% of cases, the Microservices approach is better since the #1 cost for businesses is salary costs rather than server costs. There is a pretty straight forward trade-off here, you just don't see it as developers are really bad at estimating how long software features take to develop, let alone how they vary when using different programming languages.
Ultimately, an algorithm will decide whether services are deployed separately or as part of a monolithic app. Or both. A particular service may need autoscale to many instances that are unnecessary for a monolithic app. Or vice versa. So if you can package them dynamically and scale the resulting apps independently, you can save resources. But machines will have to make those decisions. It’s too complicated for humans to optimize.
Monolith when you have the ability to execute it. Microservices when you lack dependencies in your monolith or need a different execution environment. If you need to get to market fast, do that and return stuff to the monolith later if and when you have time to do so.
Theres also the marketing aspect of it. The cloud providers pushed microservices because of course they like to sell cloud resources. Especially cloud resources that scale up. Another queue here, one more service bus there, why not integrate some key vault or the newest ai service while we're at it. And you have to go bigger from the start just to compensate for the overhead. And of course developers and architects have this fetish of overengineering stuff anyway. All those little coggs turning, with me being the creator and master of it all. Who doesn't like that? It's a useful approach for certain scenarios, if you have the team to implement it, that just got massively overhyped because of financial and narcistic reasons.
you have to solve the problem. Monolith, microservices, lambda, whatever. problem solved? mission accomplished. But today the problem is employment. microservices in your resume are more valuable than the ability to solve problems with the right tool.
Maybe I'm wrong here sone how but I think people rely on micro service to replace multi threading. An example is a Google cloud run python function that crunches a bunch of numbers at my work. My boss is relying on Google to spin up additional instances to handle concurrent requests. The same result can be had with a monolith in Go that's properly multi threaded and compiled. With go channels and such it's literally 20x or more faster and can handle more concurrent requests than we even have possible users. Even this could be put on the cloud and new instances could be spun up but it would RARELY need to happen. Not to mention the size of the Go binary is extremely small compared to the python files. Just like OOP I think micro services should be the backup for the times when you MIGHT get hit with a ton of traffic but instead people rely on them from the beginning.
I believe companies that are in markets with very tight margins and don’t do IT as a core shall think twice going to micro services. At the end they do it half way, many hands come and go and never achieve the original vision while a monolithic one can actually help them better. But some CIOs like the popularity of trends and posting that they are in it.
I think that caim like you either build monolith or microservices is too limited choice. I strongly believe we should build modular applications regardless of whether those are microservices or not. If this is done correctly multiple teams are able to work on the project realively independently. Some kind of coupliling will exist but it has to be well defined. If you need, for instance to achieve independent scaling, you may extract them into separate services. Consider pros and cons. Whatever you do, do it for a reason. It is unlikely you need hundreds or thousands of services. What is more you would rather prefer solutions which allow ypu to delay such decisions or even revert them if needed.
I'm in favor of one large monolith that becomes anything based on what parameters you pass to the binary. Now either everything works or nothing works, which is a huge enhancement 😂
Using microservices for specific tasks is beneficial, but the tasks should be substantial enough. If they’re too trivial, you’ll end up with an overwhelming number of minions (huh I mean microservices 😅 ) that are too difficult to manage.
You’ll be surprised to know that I actually agree with you, I have to keep this at a high enough level to make it interesting to those that are not interested in a deep technical discussion. I will be making more videos that dive down a bit deeper into this, even working through a case study or a used case. I don’t take criticism like this to hard, I take them as a message to improve.
most idiots don't even stop to think about the costs of serialization. But they're your tech leaders, so they know stuff and you don't. I'm just an ant in the nest.
I wouldn’t same most, but I get your point. The purpose of the video is to point out the fact that it’s situational, and largely micro services were not being applied for specific situations, but instead broadly. That’s where things went wrong.
If I have AWS fargate service composed with many containers can I call it microservice architecture? I think yes. What is the problem with microservice architecture then? It looks just fine to me.
I don’t think I’m asserting that there’s a problem with all use of micro services, or any fine grain service application. The assertion I’m making is that they’re typically overused, or leveraged when it’s not appropriate and causes an under optimization of the resources the application is able to use. I build dozens of micro service based systems over the years, there’s a time when you use it, a time when you don’t. That’s the point I’m trying to make.
@@CloudComputingInsider Okay. I probably misunderstood your point. Sorry. Could you please give an example of a business problem that cannot be solved with microservice architecture? Or maybe it's not practical to solve it that way?
@@CloudComputingInsider If you have a problem answering my question that totally fine as there's only one business case for this. IF business absolutely sure that a service will never need scaling out THEN using monolith architecture is practical. No need to say that this is extremely rare.
my apologies for the late response, for some reason your comment doesn’t come up in studio, it just is accessible via the traditional TH-cam interface. Not sure where that’s happening, but I put a link below to the Amazon Prime Video monolithic versus micro Services case study, which is pretty well known.
I agree, not just throwing monolithic at everything solves all of the problems. There has to be a it depends architectural approach to deal with each problems specifically.
It depends. Also what happens on entrrpricr is the whole sht show of weird programmers that add extra comolexity or just dont know the goal of the service. Thst happens even more on monolitic projects
Nice clickbait title. BTW Micorservices aren't necessarily (that) much more expensive vs monoliths. Cloud computing is getting pretty expensive though. Migrating from one cloud provider to a different one is awkward and difficult, once the whole solution grows and starts using proprietary cloud vendor tools extensively, e.g. for webseevices monitoring, you are pretty much locked and forced to accept any obscene cloud fees.
Great points. And I think one of the issues is that when you run micro Services on Cloud bases Systems, the patterns around the use of resources increases, so does your Cloud bill. It’s a bit more obvious when you’re paying for usage.
I don't get it. Why is cloud computing more expensive than an on premise server? Maybe you are talking about server less cloud vs on premise with a condition that you have a stable workload?
@@toooldtobejunior it's expensive because cloud providers charge hefty fees and not only for serverless processing. They do so becasue they can. Some examples: we use ubuntu vms in Azure and they are not cheap!, some other cloud services are more expensive than others, but once your project grows and you want utilise the benefits that cloud could give you, then it's gonna cost you, some examples. out of the box monitoring (e.g. Application Insights in Azure, they charge a lot for storage), or Redis cache (really expensive in Azure) etc I know medium sized comanies that decided to go back to on premises infra.
The Death of Microservices? - The content you presented in 24 minutes video is - Cost factor , Operational Complexity (architecture and Services wide spread etc ). Do you really need 24 minutes to say this ?. Disappointed with title spiked expectations. Even to present such poor sessions, In order to give space, we need Microservices archetecture.
I think that the downside of Micro-services occurs when unneeded complexity is introduced. This causes added expense as well. The same protocol in developing software needs to apply; "loosely couple components that can stand alone, and be tested individually". So say, reduce the number and of types of request and responses. Also, attempting to have common libraries that are used across different services does not work. Reusing the work is fine, but the libraries evolve as new services are built. So not tying libraries to legacy services kind of takes the chains off. This goes with deployment as well. It doesn't make sense to have a pile of micro-services connected to a monolith Continuous Integration/ Deployment (CI/CD) System. Smaller individual CI/CD Systems that are again, stand alone and loosely connected, is much easier to maintain. Another thing I find helpful is to not be so obsessed with the micro end of things, So don't make 10 services to handle something that can be done with one service. So If I have an SPA an API Service and Database, I don't need to make them all interconnect with other SPAs, APIs and Databases. Just have one SPA, API, Database stack for each purpose, where multiple stacks build a large site. The thing that makes it seamless is a single common look, feel, and menu link system.
Well, I think the only way to go forward is Microservices Architecture due to the cutting-edge technology support of OpenShift and K8, however, once the Microservices system is badly designed, it doesn't mean that we go back to Monolith Architecture but you review if you have too much broken down your Microservices or too less, you should have minimum interdependencies and if needed you to resolve by tools like GraphQL Federation. I agree Microservices Architecture is not cheap and it is not for small to medium-sized companies.
Hybrid is the way to go. To go 100% monolith would be going backwards; massively, and as that direction may lower some costs and dependencies, it will reintroduce many of the problems (complexities) that remote microservices solved at a cost. But to push everything to desperate servers is not always ideal, but far less bad than monolithic. There is a happy medium to my mind, it would be to repatriate vetted remote services locally, and even locally, keep them stateless, decoupled, and independent. There is a happy medium, a sweetspot that will lower costs, remove complexity, speed up execution times, minimize dependencies, all while keeping the architecture as simple as possible. And keep in mind, monolith can add massive costs to maintenance of the code base, the database, the adding of features., and the addition of complexity. Go hybrid!
It is clear that you saw poor implementations of microservices, didn’t understand the underlying problems, recalled the good old days when there were no options and everything was kinda good. You made this video to throw dirt on something that brilliant minds on netflix like because they understood what is it for.
![Docker Crash Course for Absolute Beginners [NEW]](http://i.ytimg.com/vi/pg19Z8LL06w/mqdefault.jpg)
Previous company I worked for had an architecture you could kindly call "a big ball of mud". So everybody decided that the thing to do was bust up the monolith and build everything out as microservices. They now have a big ball of mud - but microservice based. I don't love or hate microservices, but they're not magic and don't remove the need for a good underlying design. I certainly wouldn't be sorry to see the industry stop thinking that microservices are a panacea.
A bad monolith is always better than a bad array of micro services.
at a place I worked we joked that we had a distributed monolith architecture, as the "microservices" all depended on one another
At the place where I work we have a nice microservice architecture. Everyone is happy with it.
I guess "a big ball of mud" problem is not related to a type of architecture.
@@toooldtobejunior It absolutely is related to the type of architecture. Use the wrong tool for the job and you have problems. Saying micro services worked for you in one scenario therefore there are no issue with it is noob level dev thinking, and just terrible basic reasoning skills.
@@JohnSmith-op7ls okay. I get that I'm a noob from your point of view. Could you please teach me? Just tell me what is the business problem that you found microservice architecture is not suitable for? I will really appreciate it.
The company I worked for was burned badly by moving a cloud based service to microservices .... the decision was not made by the technical leads of the company .... it was the CTO's and CEO's who bought into the hype. They commanded loudly "Let there be microservices !!". A few brave souls among us peasants voiced concerns about falling for FOMO factor and no real reasoning behind this decision. Soon after, they were no longer seen. I suspect they are now at the bottom of some river tied to a concrete block. Some 100+ microservices later, we created a behemoth that even Egyptian pharaohs would be jealous of. We proudly slapped a price tag of a million bucks on it ... ... but that pesky little rival across the street was selling a teensy-weensy monolith for half the price and a fraction of the computing real-estate; while claiming all the same functionality. We stood tall and proud and bragged about our microservice based architecture. The customers all stood around that little hot-dog stand. Our CEO roared ..."Y'all blaady cheapskate plebians!! No appreciation for fine dining". Pretty much all of them figured their workloads are not so dynamic and they don't need K8s style scalability for at least another decade or so. A year later, half the company was laid-off (your truly included). Saving grace ... the CEO/CTO's were also thrown out the window (but they had their golden chutes on).
I always use to think that teams that are not able to modularize a monolith should definitely not try to modularize a distributed application. FIRST mudularize the monolith THEN spin out microservices IF there is a valid reason to do that.
That’s actually good advice.
I think you need to know why you're doing this. What's the gain at the end that you are desperate to have and evidence to know it'll be achieves.
For example are you moving slowly as a development house, and what evidence have you got you'll move quicker afterwards.
The reason why this is good advice is that for having achieved the modularization, it means it was refactored enough to have sorted the right relations between dependencies, hence, the well modularized monolith works as a prototype on how to implement it more horizontally scalable with microservices.
@@SebastianSastre There is no diffirence if the goal is to modularize only.
Monolith you call public function.
Microservice you call api.
Calling public function is faster vs calling api.
um... it seems hard to challenge back.. Ha.. Sometimes, people might thought this is a negative thinking. However, I do think in the same way. Distributed application is another level deserving more thoughtful actions. But most of time, we(or those around us) had too much expectation on "new toy" or under-estimate what it costs.
As a mostly front end guy, we go to an even whole new level of ridiculousness with micro-frontends.
Only five users in the same building but solution developed using Microservices because the Team Lead, Devs and Architect opted for it. Reason it's always good in resume.
Unfortunately, lots of people put bad architectural decisions on their resume, as something to be praised.
Aha, CVDD
You conflate the number of users to the use of microservices. One has little to do with the other.
resume-driven design
@@david50665 😂😂 👌
We introduced micro services at my company some years ago. Today the backend is a total fragmented mess that is extremely expensive to host. From my perspective micro services solved absolutely zero problems but added a shit tonnes of complexity
My experience is that developers get over excited and turn the simplest thing into an academic exercise of technical masturbation. This happens with both microservices and monoliths... so it's not a problem with the technical architecture.
Example: at work we're building AI services. As the org wants to meter and charge for usage there's a gateway in front that handles that and the auth / routing to each service. Each service started as a HTTP api integrating straight with AI model providers. This meant developers could test and develop directly against the individual service and it should work when changing configuration to use the gateway. Happy days! developers can iterate quickly on what will likely be throw away AI services, they can choose which models and providers suit them. Simple.
Then someone said "our services should know nothing about the AI providers" and built the "model facade", and an SDK, and a framework. Oh and it has a single set of API keys... cough... rate-limits... So now developers can't run their service and integrate directly with services (learning about the models / service) - they now have to run the great model facade. Now... the model facade is now getting changed by every developer, tests are bleeding across boundaries making tests slower to run.... there's no API versioning or strategy, no consumer driven contract tests... all because nobody asked why and pushed back (except me) but devs gonna dev...
A year on, no AI service has been worried by a user, I suppose it's all got to be perfect first 🙈
You’re not alone, pretty much most of my clients have that issue to some degree.
It's like the woke mind virus. Once the host is infected, it is difficult to persuade people of anything rational.
The main problem I see with the costs are cloud related, instead of just using IaaS or on-premise. Nowadays a consumer PC hardware is more than enough to handle shit ton of software resources but what the heck lets develop shit ton of MSs with Node that do 1 simple thing with a docker container of 600MB and use almos 1 GB of ram each one of them and of course use the cloud to manage those containers... Lets over engineer MSs! because why not? need another function in the app? do another service! just throw some budget in it...Efficiency at its best
Totally agree. Zero problem solved, additional complexity (protocol sync between micro services, code dups, even different langage or framework), headache to maintain, time consuming. This is useless for small/medium structures. Modularize & go monolith. KISS.
The tech industry often chases trends, but we should prioritize what works best for our specific projects and teams. Meta's continued use of PHP, despite repeated declarations of its obsolescence, is a great example of this pragmatism. They've stuck with and improved a technology that suits their needs, rather than constantly switching to the latest 'shiny' thing. In software development, success comes from making informed decisions based on project requirements and team capabilities, not from blindly following trends. It's about finding the right tool for the job, whether it's cutting-edge or time-tested.
yeah, they use PHP because it is not worth to switch to Python since Facebook is dead
You left out that part where Meta isn't actually still using PHP. They found PHP to be so lacking w/r to scale that they more or less recreated a new programming language that uses PHP syntax that essentially compiled to C++ object files and then assembles these object files to native executables. So your example here doesn't really support the whole "you should switch to a new technology that does the job better than your old technology that does the job terribly"
@@thecollector6746 so based in your logic if a project was created using Java code and is later compiled using an Azul compiler then is no longer Java?
I said and stand by:
"They've stuck with and improved a technology that suits their needs, rather than constantly switching to the latest 'shiny' thing."
I have been doing solution architecture in large corporations for 25 years. I watch all the fads come and go and evangelism when some new architecture pattern comes along is amazing. My good friend builds houses for a living, when a new tool becomes available he just knows how to incorporate it into his building process, what he doesn't do is try and replace ALL his other tools with the new one.
The reason is that neither his new tool is going IPO or his building business is listed 😂 I remember a few decades ago some companies suddenly had valuations that shot up overnight merely because they started using XML to do whatever they had been doing before without XML 😂😂😂 today we have AI. I am sure there are business models that would be much better if they did NOT incorporate AI into them but they wouldn’t get the short-term attention that is often needed for continued funding/revenue. Would you like to learn more about this topic? (😂😂😂)
Agree with the sentiment here. One consideration you didn’t cover was microservices as a tool to solve the problems of organisational complexity. I have spent my career in technology in banks with thousands of technology employees and hundreds of interconnected applications, many of which were legacy. Coordinating a team of dozens of people on one, aging codebase becomes very hard. Also, if you have a dependency on one of those teams, getting a change made can be a coordination nightmare. Breaking into smaller services helped to solve that organisational problem. If you have a smaller simpler service, then it’s easier for others to contribute and it was also an opportunity to modernise, adding in automated testing, clearer interfaces etc, which led to more agile teams and technology. I do agree, it became over used and the downsides misunderstood or glossed over.
Micro-services allow you to scale - this was never about the tech or scaling horizontally to handle more traffic - it was about people, ownership and rate of change in different parts of a complicated system. It is all about organizational scale.
I personally thought that Conway's law was a tongue-in-cheek observation/critique of bad software design, not a blueprint for success.
monolith scale better than microservices
Shows you how much we have become a victim of the marketing from the large providers.
I looked at microservices for our products and the biggest advantage was non-use no cost, but when used, cost a lot more then monolithic.
Microservices are also a lot slower when you crunching a lot of data. You cannot cache it well enough and cloud costing make it super expensive.
This was always obvious but still we saw a lot of terrible choices. Only now when money is stretched, are they seeing the reality.
You’re absolutely right, I’m seeing as Cloud cost continue to rise. Everybody’s running away from any inefficient architectures. Well micro services do have their used cases, they were indeed overapplied.
Oooof course you can do caching ... you just have to buy an additional caching service.
Increasing complexity and your bill even further.
Thanks for sharing! I used to just thinking about this possibility and thought people might under-estimate this situation like cost issues.
I think the pain point is, teams now want to make everything a service when there may actually not be a need for it. We currently have identity verification done in most of our services, and each service keeps duplicating codes, so we just decided to make an independent service to handle this verification which other service can make use of. The thing is in a much as its good, it can get out of hand just cause teams feels like its the shinny thing without understanding the complexities these might cause, including using queues for decoupling which adds its own complexity for something that no other service would even use.
Devs with less than 10-12 years of experience almost always have shiny object syndrome.
They just haven’t been around long enough to see how these trends come, get overhyped, create lots of problems when misused, then get replaced by the next trend.
And the trends usually come full circle and repeat.
Like going from mainframes to fat clients back to thin clients which is a rehash of mainframes.
Or server side rendering then bloated browser frameworks, now server side rendering is getting popular again.
The grass is only greener when you really know what you’re doing and what the pros/cons are with each solution.
@@JohnSmith-op7ls They follow market trends set by the recruiters, it's not their fault.
If monolith works just fine then there is no need to microservice it. Microservice is a solution to a problem. If there is no actual problem to solve by microservice then there is no need to do it.
I worked for a company with a cloud team that spun up containers with terraform and broken out to so many microservices that when I asked if we could look at a front end to confirm that these services are updated properly (just looking to confirm the footer notes went from version 15.3 to 15.4 as an example) and it started a fight within the team and a 2 hour meeting on why anyone cares about that vs how do we even know what we are changing is being changed....needless to say I left that company and they lost the contract they were on
Microservices are just one of the architectures you should be looking at when developing an application.
To many times microservices has been to go to architecture based on hype rather than requirements and most importantly the team or teams structure type to develop and support the architecture.
You got it.
Agreed but for inexperienced devs it is a highly recommended approach to take for obvious reasons.
I love micro services. Seriously. I think most folks just don't really understand how to work with them correctly or how to scale them correctly with costs in mind. They will quickly deploy an entirely new server cluster for a new service instead of shard sharing with the original lot. Auto scaling is a big deal when using micro services, and ensuring the correct setup from the beginning and the ability to rapidly deploy the correct patterns within the environment.
I think there’s some truth to that, I think most people don’t design them correctly that I’ve seen, also they’re used when they’re contraindicated, which is kind of the focus here. Whatever that doesn’t diminish from the fact that you brought up a good point.
Totally agree. Micro services are not magic, it's are just a good practice. And impotent architects and developers will not become good, whatever technology they using 😅
Microservice are like communism, nobody has really tried them or implemented as Lénine envisioned. I mean, 15 years is too short to figure out how it should really be
Thank you for making the video. I agree with your pragmatism.
I would, however like to expand on and challenge the following:
There are at least two types of modarity; development modularity and runtime modularity. The microservices camp talk about them as if they are the same. We have had development modularity since the introduction of the header file in C in 1973. There is value in runtime modularity in some select applications.
The term "Monolith" is a misnomer. We have not built monolithic applications since the introduction of client-server architecture in the 1980s.
Ironically, the only monolithic applications we build today are Single Page Applications (SPAs). Ironically, we refer to these as "modern", just like microservices. SPAs will be the next thing to die.
While I'm not here to specifically advocate for microservice-oriented architecture, my experience of over 20 years in the industry has shown that the most common challenges often stem from human error, rather than the technology itself. Microservices, when implemented correctly, offer a robust architectural approach. However, without the necessary skills to design and code within the framework's constraints, or by cutting corners and misapplying the technology, one cannot fairly place blame on the architecture itself.
The key to success lies in understanding which parts of a system should remain monolithic-because overcomplicating certain components can introduce more problems than it solves-and which elements can be effectively broken down into independent services. Knowing the right tech stack for different modules, and when to leverage external services to seamlessly integrate the system, is what truly distinguishes capable architects and system designers from developers who have yet to refine these skills.
Very well said. Unfortunately, the industry is more about what we call things (agile, microservices, test driven) instead of what we actually build/deliver.
I'm so so glad that people started finally talking about the inherent problems of micro-service. I had so much problems explaining the dis-advantages of the micro-services, at least now I have some arguments.
I have before, and many of the micro Service promoters tried to get me fired.
Building microservices to read data is OK. Looking up SSN is a good example. However, once they start writing data then the problems begin. Communication between microservices, maintaining distributed transactions -- are not easy tasks at all.
Most apps have more microservices than users and couldn't scale if they had to, which they thankfully have never tried.
IMO, the modernization discussion begins with "Why," not a target technology. Microservices definitely has its place, but not all apps require it, nor do all teams have both the resources and skills to architect it.
I think ultimately that’s the point I’m making, the problem is it’s been overused and causing grossly under optimized architectures that’s the other point I’m making.
One of the hidden cost is also eventual consistency. Remember that "Eventual consistency == Permanent inconsistency". A lot of mecanisms, tools, ... (aka moving parts) needs to be put in place to mitigate this problem that is near absent in a Monolith design.
In most cases, the deciding factor is Conway's law.
If adopting microservices allows your different dev teams to work more independently and each at their best pace, it will most likely outweigh the cost of the increased overall complexity. As always, YMMV.
This. Service architectures aren't antything new. SoA over Soap this, Soa over CORBA that, Com+ distributed object computing etc.. Service based system is natural emergant property of large and complex organization. The principal value of SoA is having a standardized boundry which is usefull in comunication and job division. You write contracts at those boundries (like business contracts, I-ll-hire somebody to implement this spec contract). It is also the hardest thing to "capture". Conway's law is good practice here.
It seems to me that large number of modern microservices are mostly driven by desire to be lightweight. To play *nice* with cloud. In short they are used because of associated technology stack. And not because of real need of service architecture. Which is perfectly fine as long as you know your dues..
If you find yourself using microservices without really needing boundry layers, you could probably simply your life by removing those.
I'm using AWS lambda and it's turning out to be much more cost effective at the scale I'm functioning at
My last job was a Microservices Architectural Hell! Basically, they simply had WAY too many services! And along with that, plenty of bugs which were difficult to track down, because of the highly distributed system.
So I've now come to the opinion that, some kind of balance need to reach... Not Monolithic... Not Microservices... But something in-between...
Macroservices!!! I.e. reducing the number of services to ease maintainability and costs... But still keeping these fewer larger Macroservices distributed.
I.e. trying to aim for the BEST of Both Worlds!
Especially Microservices are not for Small Business and Small Applications. Even for mid scale there is a way to use a hybrid architecture or Mono + Microservice model.
All (non-need-to-synchronize) distributed systems are only as good as the underlying network they use, as well as their ability to recover, in a case of nonstandard events. In addition, any endpoint being used in such distributed architecture needs to be able to scale up/down its bandwidth accordingly, otherwise the sporadic-slowness transient events would be an absolute nightmare to deal with in real time.
The software industry has always been plagued by dogma, and it's much worse now than when I started 25 years ago. Microservices is no different. No quite as bad as TDD, but there are many microservices horror stories out there.
I think we should switch from microservices to macroservices. The overhead of managing and orchestrating a microservice application is enormous.
The problem is microservices develop interdependencies and rarely can you deploy one without having to regression test everything negating the entire benefit. All they do is avoid code conflicts, but the problem gets pushed down since code conflicts represent people not coordinating changes.
This is the key. I'd go so far as to say the only reason to use microservices is if you have scaling limitations that can't be addressed any other way. I'd wager that in virtually every case microservices actually slow development velocity in the mid to long-term. They basically push interface versioning and dependency management into an area between code-bases and introduce extra complicating factors (like network connectivity, latency, and caching).
It sounds a LOT like the conversation around Object Oriented design and componentization, because it's the same thing... The same applies to micro solutions in apps too, vs monolithic apps. I love the modular-monolith approach, but each choice needs to be considered on merit
Common sense is back (I hope). People just started to follow the trend blindly and got burned because they didn't have experience to break things down into microservices the right way (AWS was happy with all the cloud money they made..). It is not black and white between monolith and microservices
I've been building apps this whole time since microservices appeared either alone or in small teams of 2 to 5 people. And I always thought "yeah that sounds like it can be cool but I dont need that, it would overcomplicate things for nothing" so I never really used microservices. This video tells me that the experience confirms my initial intuition.
I agree with the premise - yes Microservices are HARD!
However, the problem often comes at a lack of understanding the complexities it involves, and so many of these architectures today, basically suffer from the Marketing/Value proposition perspective. This is problematic. They were enabled and green-lit based on marketing, not on understanding the complexities of the architecture itself, and what it deems.
It's also highly misunderstood that Microservices, also ties into an organisational pattern, and this requires your organisation to also embrace process' that are NOT aligned with more traditional constructs.
So, I fully support NOT over-shooting here, when you could choose a small monolith - that in any case can always be virtualized. But I'm sorry, it is NOT the Microservice Architecture that is the root of the problem, it's Architects! Do it right, and you're in for a ride, do it wrongly and you end up in technical-debt scenarios, distributed-monoliths (because, someone didn't get it) and so forth.
Hi there, Nice video. I particularly like how you are leaning towards companies not just following the latest trend without taking an honest look at the deeper trade-offs possibly involved. Try to read through the sales pitches of new trending technologies and try to really understand the performance or scalability differences and if they are really worth the cost. Although the larger enterprises' would have the extra capital to put into these ventures more easily, small to mid-sized companies would not, and should everyone really just be chasing the next trend even if potentially not right for them.
I think that’s the ultimate message here, at the end of the day these micro architecture deployments are bespoke for the problem domain. My problem with these trendy architectures, like micro Services, is that they were overapplied, when actually they are pretty good when applied correctly.
AWS and Azure make a lot more money from Microservices than a nice efficient monolith.
Its the same as multi threading, first you try to make everything multhithreaded, atomic and so on but then you cant mantain this piece of code, so the rile of thumb is to find the sinplest solution you can find for this specific task
Microservices using mono repos is the right approach. Using three pillars around: Build and deploy them independently, build and deploy only once, shift test left (test on branch and not on the main line).
I think something that nobody talks about is that in the end you have one application and you want to test that combination of different micro services before you release to production. Well you cannot do that if they are build and deployed independently. That is why you need something to bind all together at the end of the pipeline. And that is what you gain by having a mono repo where you can control the flow and test that particular combination of microservices before you merge and deploy to production.
I feel confident in saying the best approach to designing systems is to leverage a hybrid monolithic/microservice architecture. The backend, where the data resides, should probably be a monolithic entity. The issue is on the front-end. The WEB is stil the wild wild west of frameworks, languages, libraries and who knows what else. The front-end needs an intervention. It's crazy that we have all this complication to deal with.
Most of application loads can easily be managed by DB. So it's a application server needs efficient handling.
Modular is way forward
Microservice = distributed monolithic
I’ve been saying macroservices, not microservices since it came out. A general rule of thumb is systems should be between 25 and 100 database tables, perhaps 200 tables. But the 800 table systems are too big and should be broken up into 4 to 8 modules/macroservices with 100 to 200 tables. Likewise If a system has 3 tables in it, it is most likely too small unless it uses/needs a different stack like redis. There is a sweet spot on size and now with SSDs being very fast the hardware limits are removed now allowing for much larger database size. Databases used to be the bottleneck but are not as much anymore with the hardware improvements over the past decade
The first idea that comes to mind during the listening is to use (if exists) or develop a framework that allows developing apps as monolithic and, when needed/appropriate, "natively, (almost) instantly" convert parts of the apps into "ready to scale" microservices. And reverse, when needed.
It's not new, I worked on large projects using object request broker (ORB) in the 90s.
Heyy , Will these monolithic or microservices replace by GenAI or Machine Learning. Or GenAI or ML will be inducted in Applications for other requirements of business. I am lil bit confused with This GenAI and ML thing. How it will implemented in Business. Please explain this point in your video. Thankuuu
On a provocative note: If an interface isn't defined well enough to be used everywhere, it shouldn't be used anywhere. "Well defined" is to say: Expecting input a(range), b(range), opt c(range); Will output x(range), opt y(range); Processing rules A, B, and C, ref source.
Test development automation is trivially and universally available for microservices.
From a DEV/QC perspective it might be worthwhile sticking to microservices, even if they end up being turned into libraries.
BTW: I never believed for a microsecond that microservices were a good idea for medium scale (couple of ten thousand requests/s) deployment, and I have no idea how the large ones scale.
One way microservices might end up being beneficial as "end user accessible services" is ad hoc recombination of processing steps. For quick and pretty straightforward evaluations, CLI pipe style.
11:03 he gets to the 'why' part here. Insightful video.
EJBs used to be a way to create specialized services but it was not a micro service. It was more of a monolithic java bean. The trend was to move away from this and move to micro services. I think it would be worthwhile to revisit the way services used to be made but work to improve them not replace them with completely different technology to promote a new trend.
Yes, there were reasons to use that technology approach, and a reason not to. I think that’s all we’re arguing here.
Great Analysis. I love it ❤❤❤
Glad you enjoyed it!
Going back to 500k+ lines of code in one service I say would be a step backwards. Smart domain separation and interface definition so that you get a clear separation of concerns and right amount of cooks per soup I would say is something to keep. The question in my opinion is finding the right size of services. Within a clear domain a monolithic kind of setup is probably a good idea because it's faster to build up, easier to maintain, less network overhead etc. etc.
If you can't design your microservice architecture in a way that the services are loosely coupled with one another, that is, making a change in service A doesn't require making a change in service B, C, and D, then I think you're better off in a monolithic architecture. The need for heterogeneous scalability between different services is also a reason for switching to microservices, as in service A, B, C, and D need to scale up or down differently at different times. Also, network latency should not be a bottleneck; otherwise you're in a world of pain if you're trying to optimize for performance. Many people run into this issue and try to work backwards to merge various services together and you're left with some kind of ad-hoc design that is somewhere between a monolith and a true microservice architecture.
Mindlessly following trends will always lead to disaster. Being greedy will always lead to disaster. Architecture should depend on what we are trying to achieve
This is the first episode I watched and I don’t wanna be too critical, but this seem like the conversation was generated from ChatGPT and just read as a script. I expected to hear statistics and reasoning from both sides of the argument with real worldexamples. This video seems like a high level introduction to to ponder what you should do. The title should be I need to wonder about how I’ve built my architecture.
You need microservices. You also need a more robust documentation the more complex it gets. Nobody wants to spend the weekend trying to figure out the 5W1H of the value x
We have to build a security layer to protect each microservice. That makes microservices harder to maintain.
Microservies is a resumay driven development most of the time
Great info, and I would encourage to have a visual aid for better presentation
Point taken.
Microservices are great if they are the right solution for the problem AND you actually build a microserivce and not just a Spring Boot/Quarkus REST endpoint labeled as such.
We all know that Microservices was a misused buzzword (like agile, event-based, and so on). REST is not microservices. Too many people incorrectly lable something 'microservice', then complain the microservices are not the answer when that is not what they built.
Microserivces, like everything else, are not silver bullets. They aren't magical and won't fix every problem. If the solution calls for a microservice and you build it correctly, they are outstanding.
Simply declaring 'microservices are dead' and moving onto the next thing will just result in that next thing being declared dead in a few years.
Easier to automate AI code maintenance with microservices versus monolith.
If rate of iteration is important than microservices will be hard to beat.
Monolith are great for optimization.
But microservices is more than just popularity, it's the tradeoffs for composability and rate of change (at cost of complexity and price)
Microservices are a replacement technology for OOP/Static Typing (to be technical both are Message Passing technologies). You want to ditch OOP/Static Typing because it takes on average developers 3x as long to code a software feature in OOP/Static Typing as with dynamic languages like Python or Ruby. For example, 16 hour compile times in large Monolithic systems isn't uncommon...
So the real question is should you go with Monolithics and 3x your developer costs or should you go with Microservices and the scripting languages and 10x your server costs. For 80% of cases, the Microservices approach is better since the #1 cost for businesses is salary costs rather than server costs.
There is a pretty straight forward trade-off here, you just don't see it as developers are really bad at estimating how long software features take to develop, let alone how they vary when using different programming languages.
“Keep things as simple as possible, but no simpler.” - Albert Einstein
Ultimately, an algorithm will decide whether services are deployed separately or as part of a monolithic app. Or both.
A particular service may need autoscale to many instances that are unnecessary for a monolithic app. Or vice versa. So if you can package them dynamically and scale the resulting apps independently, you can save resources.
But machines will have to make those decisions. It’s too complicated for humans to optimize.
Monolith when you have the ability to execute it. Microservices when you lack dependencies in your monolith or need a different execution environment. If you need to get to market fast, do that and return stuff to the monolith later if and when you have time to do so.
Theres also the marketing aspect of it. The cloud providers pushed microservices because of course they like to sell cloud resources. Especially cloud resources that scale up.
Another queue here, one more service bus there, why not integrate some key vault or the newest ai service while we're at it.
And you have to go bigger from the start just to compensate for the overhead.
And of course developers and architects have this fetish of overengineering stuff anyway. All those little coggs turning, with me being the creator and master of it all. Who doesn't like that?
It's a useful approach for certain scenarios, if you have the team to implement it, that just got massively overhyped because of financial and narcistic reasons.
Macro-services is the way to go
And that's what my current company is doing
you have to solve the problem.
Monolith, microservices, lambda, whatever.
problem solved? mission accomplished.
But today the problem is employment. microservices in your resume are more valuable than the ability to solve problems with the right tool.
Maybe I'm wrong here sone how but I think people rely on micro service to replace multi threading. An example is a Google cloud run python function that crunches a bunch of numbers at my work. My boss is relying on Google to spin up additional instances to handle concurrent requests. The same result can be had with a monolith in Go that's properly multi threaded and compiled. With go channels and such it's literally 20x or more faster and can handle more concurrent requests than we even have possible users. Even this could be put on the cloud and new instances could be spun up but it would RARELY need to happen. Not to mention the size of the Go binary is extremely small compared to the python files. Just like OOP I think micro services should be the backup for the times when you MIGHT get hit with a ton of traffic but instead people rely on them from the beginning.
Every solution has problems.
Smart solution provider hides them.
Others don't know them.
I believe companies that are in markets with very tight margins and don’t do IT as a core shall think twice going to micro services. At the end they do it half way, many hands come and go and never achieve the original vision while a monolithic one can actually help them better. But some CIOs like the popularity of trends and posting that they are in it.
As with a lot of this complexity, it's fine if there is a good reason for it, but I'd guess that only 5% of microservice are justified.
I think that caim like you either build monolith or microservices is too limited choice. I strongly believe we should build modular applications regardless of whether those are microservices or not. If this is done correctly multiple teams are able to work on the project realively independently. Some kind of coupliling will exist but it has to be well defined. If you need, for instance to achieve independent scaling, you may extract them into separate services. Consider pros and cons. Whatever you do, do it for a reason. It is unlikely you need hundreds or thousands of services. What is more you would rather prefer solutions which allow ypu to delay such decisions or even revert them if needed.
congrats on reaching the 110000 subscribers, but sorry i did not find you this video to be one.
Thanks!
I'm in favor of one large monolith that becomes anything based on what parameters you pass to the binary. Now either everything works or nothing works, which is a huge enhancement 😂
Using microservices for specific tasks is beneficial, but the tasks should be substantial enough. If they’re too trivial, you’ll end up with an overwhelming number of minions (huh I mean microservices 😅 ) that are too difficult to manage.
Absolutely no substance
You’ll be surprised to know that I actually agree with you, I have to keep this at a high enough level to make it interesting to those that are not interested in a deep technical discussion. I will be making more videos that dive down a bit deeper into this, even working through a case study or a used case. I don’t take criticism like this to hard, I take them as a message to improve.
most idiots don't even stop to think about the costs of serialization.
But they're your tech leaders, so they know stuff and you don't. I'm just an ant in the nest.
There is no black and white answer. It all depends on the application needs.
Mocroservices are not wrong, the person making the wrong choice is wrong.
Always chasing the price, then monolitic will get expensive, back to micro, and back again.
Everyone nowadays think that blaming microservices is the right thing to do.
I'd say microservices are just fine for most of the cases
I wouldn’t same most, but I get your point. The purpose of the video is to point out the fact that it’s situational, and largely micro services were not being applied for specific situations, but instead broadly. That’s where things went wrong.
The reality is that if you don't follow the coolest fads the coolest kids are not gonna join your company.
Consolidated & Distributed are a pendulum swinging back and forth.
Bookmarking will be greatly appreciated.
If I have AWS fargate service composed with many containers can I call it microservice architecture?
I think yes. What is the problem with microservice architecture then? It looks just fine to me.
I don’t think I’m asserting that there’s a problem with all use of micro services, or any fine grain service application. The assertion I’m making is that they’re typically overused, or leveraged when it’s not appropriate and causes an under optimization of the resources the application is able to use. I build dozens of micro service based systems over the years, there’s a time when you use it, a time when you don’t. That’s the point I’m trying to make.
@@CloudComputingInsider Okay. I probably misunderstood your point. Sorry.
Could you please give an example of a business problem that cannot be solved with microservice architecture? Or maybe it's not practical to solve it that way?
@@CloudComputingInsider If you have a problem answering my question that totally fine as there's only one business case for this. IF business absolutely sure that a service will never need scaling out THEN using monolith architecture is practical.
No need to say that this is extremely rare.
th-cam.com/video/9JPYCOpeDnY/w-d-xo.htmlsi=SyVYIZ8v5c4Fm9BO
my apologies for the late response, for some reason your comment doesn’t come up in studio, it just is accessible via the traditional TH-cam interface. Not sure where that’s happening, but I put a link below to the Amazon Prime Video monolithic versus micro Services case study, which is pretty well known.
Everything has it own benefits and drawback?
If you give a person a fish you feed them for a day. If you teach a person to fish you feed them for life. 😎🤖
AI will generate code. User will write user stories. Code is liabilty, not asset.
Its actually should be composable... instead of monolithic or microservices..
I agree, not just throwing monolithic at everything solves all of the problems. There has to be a it depends architectural approach to deal with each problems specifically.
It depends. Also what happens on entrrpricr is the whole sht show of weird programmers that add extra comolexity or just dont know the goal of the service. Thst happens even more on monolitic projects
Microlanguages are the future.
Nice clickbait title.
BTW Micorservices aren't necessarily (that) much more expensive vs monoliths. Cloud computing is getting pretty expensive though. Migrating from one cloud provider to a different one is awkward and difficult, once the whole solution grows and starts using proprietary cloud vendor tools extensively, e.g. for webseevices monitoring, you are pretty much locked and forced to accept any obscene cloud fees.
Great points. And I think one of the issues is that when you run micro Services on Cloud bases Systems, the patterns around the use of resources increases, so does your Cloud bill. It’s a bit more obvious when you’re paying for usage.
I don't get it. Why is cloud computing more expensive than an on premise server? Maybe you are talking about server less cloud vs on premise with a condition that you have a stable workload?
@@toooldtobejunior it's expensive because cloud providers charge hefty fees and not only for serverless processing. They do so becasue they can.
Some examples: we use ubuntu vms in Azure and they are not cheap!, some other cloud services are more expensive than others, but once your project grows and you want utilise the benefits that cloud could give you, then it's gonna cost you, some examples. out of the box monitoring (e.g. Application Insights in Azure, they charge a lot for storage), or Redis cache (really expensive in Azure) etc
I know medium sized comanies that decided to go back to on premises infra.
The Death of Microservices? - The content you presented in 24 minutes video is - Cost factor , Operational Complexity (architecture and Services wide spread etc ). Do you really need 24 minutes to say this ?. Disappointed with title spiked expectations.
Even to present such poor sessions, In order to give space, we need Microservices archetecture.
I think that the downside of Micro-services occurs when unneeded complexity is introduced. This causes added expense as well. The same protocol in developing software needs to apply; "loosely couple components that can stand alone, and be tested individually". So say, reduce the number and of types of request and responses. Also, attempting to have common libraries that are used across different services does not work. Reusing the work is fine, but the libraries evolve as new services are built. So not tying libraries to legacy services kind of takes the chains off.
This goes with deployment as well. It doesn't make sense to have a pile of micro-services connected to a monolith Continuous Integration/ Deployment (CI/CD) System. Smaller individual CI/CD Systems that are again, stand alone and loosely connected, is much easier to maintain.
Another thing I find helpful is to not be so obsessed with the micro end of things, So don't make 10 services to handle something that can be done with one service. So If I have an SPA an API Service and Database, I don't need to make them all interconnect with other SPAs, APIs and Databases. Just have one SPA, API, Database stack for each purpose, where multiple stacks build a large site. The thing that makes it seamless is a single common look, feel, and menu link system.
Anyone remember DCOM?🤕🤕🤕
cloud is dead
Well, I think the only way to go forward is Microservices Architecture due to the cutting-edge technology support of OpenShift and K8, however, once the Microservices system is badly designed, it doesn't mean that we go back to Monolith Architecture but you review if you have too much broken down your Microservices or too less, you should have minimum interdependencies and if needed you to resolve by tools like GraphQL Federation. I agree Microservices Architecture is not cheap and it is not for small to medium-sized companies.
Like any other tool, Microservices are only good *if used properly*.
That’s the point of the entire video.
Yeah, next will be mini services, then soon macro services.
Hybrid is the way to go. To go 100% monolith would be going backwards; massively, and as that direction may lower some costs and dependencies, it will reintroduce many of the problems (complexities) that remote microservices solved at a cost. But to push everything to desperate servers is not always ideal, but far less bad than monolithic. There is a happy medium to my mind, it would be to repatriate vetted remote services locally, and even locally, keep them stateless, decoupled, and independent. There is a happy medium, a sweetspot that will lower costs, remove complexity, speed up execution times, minimize dependencies, all while keeping the architecture as simple as possible. And keep in mind, monolith can add massive costs to maintenance of the code base, the database, the adding of features., and the addition of complexity. Go hybrid!
This is way too wordy. You could edit the content down to a couple of minutes without loosing any information.
I agree, I’m trying to speed up the remaining videos.
It is clear that you saw poor implementations of microservices, didn’t understand the underlying problems, recalled the good old days when there were no options and everything was kinda good. You made this video to throw dirt on something that brilliant minds on netflix like because they understood what is it for.