Yes... Microservices REALLY ARE Technical Debt

[@ContinuousDelivery]

BLACK FRIDAY: The Biggest Sale of The Year Is Now Live! ❗ CD-BlackFriday-50 ❗ The first 100 buyers with this code get a massive 50% OFF ALL COURSES (including bundles) but even if you miss this, you can still get a HUGE 25% OFF ALL WEEK with this coupon: CD-BlackFriday-25 | Find your course HERE ➡ courses.cd.training/collections

[@frankpayne6902]

"If I have a microservice that is dependent on yours, and we can only release our services together after some form of testing, then what have we really got?" Absolutely brilliant.

[@marcio-si8xd]

Distributed Monolith is the best name.

[@Carewolf]

Then it isn't a microservice. So you have decoupled wrong.

[@ricardo6607]

Thats why You have APi versioning? hmmmmm

[@pawelparadysz]

The discussion tends to be microservices vs monolith. What about mid-size services? Like splitting a monolith into the biggest parts that can have reasonably defined boundaries?

[@davidbcg286]

Services

[@someguyO2W]

Services! You don't need them micro.

[@MrHaggyy]

You have this discussion a lot in service oriented architectures for embedded system. In a car for example you have real time constrained computation reguarding brakes, steering and even acceleration to make it complete. You could build one central control unit, like we did in the 80's and 90's. That ends up in a mess of cabeling and you can only close loops so fast. Part of the reason why the brakepedal on older cars vibrates in an emergency braking. You could also build one control unit per service. By how the automotive industry is layered with a supply chain, we have been there with some cars, and it's a nightmare because nobody can really reason about odd behaviors. Today you have view specialized units that combine services that require the same information. That way you can still puzzle around with different models, facelifts etc. But the core functionality is rather fixed. However it's not necessary obvious, which requirements are suited best for grouping things together.

[@itskittyme]

WE HAVE A NON BELIEVER !!

[@christianibendorf9086]

Microservices, if done right, have anopther advantage: if you don't need them anymore you can just delete them. Same if you need to drastically change them: create a whole new service and delete the old one. You'll rarely encounter these scenarios with bigger services. Also: what is a "reasonably defined boundary"? ;-)

[@alexaneals8194]

The problem that I have seen is that a company will have design issues (pain points) with their current monolith, so they decide to use microservices. However, instead of spending the time to understand why the monolith has design issues so that they can correct those issues when implementing the microservices, they just port the monolith over into the microservices. So, now instead of one big pain point, they have a thousand smaller, but as aggravating pain points.

[@purdysanchez]

Most companies don't even know what "microservices" means. They just buy into the latest consulting sales pitch, move everything to FaaS and think that's what microservices are

[@user-fq1gh]

Yeah, you split one monolith into many small monoliths. Aka "Microservice" . Problem successfully postponed and you can shine by chasing a trend.

[@ps2goat297]

@@alexaneals8194 I've seen the same with any tech. One place was against learning the tools they already had and using them correctly, so they moved onto new tools before learning those. They did this 3-4 times before I left, and never completely moved off the older tech so it made support worse. Shiny object syndrome. I had another place do microservices mostly well, but some were what I called nano services, but apparently that has an actual definition these days. One service was a wrapper around three others, basically the equivalent of an interface. The other three were implementations of that. All four should have been one service because they shared a db and the basic structure and flow. Instead they paid four times as much in resources, and more difficulty in testing and deployment.

[@ps2goat297]

Another good boundary can be dictated by some type of compliance requirements. E.g., PCI required multiple reviewers and a stricter release process. By putting that in it's own service and only paying along a token to other services, we limited the impact of the extra process.

[@craig2010a]

@2:03 Based on Conway's Law, team organization/dynamics DETERMINES the software architecture!

[@andrewgregovic1608]

"Technical debt" is a loaded term because it typically implies it needs to be paid back/rectified in some way- I nowadays prefer using "technical overhead". It's absolutely not controversial claiming that microservices incur various technical overheads.

[@meryplays8952]

tradeoffs

[@joesteel7837]

Technical debt is correct, even if it's unpalatable. I try and avoid branches like that myself, but they are what they are...

[@praecorloth]

"Technical debt" implies the existence of technical loan sharks.

[@Kasukke]

I think debt is a better term because it implies there's a trade off you're making. You take on debt for a reason. Short term gain that you think will be overall worth it for the longer term cost. When I take out a business loan, it's not "financial overhead"

[@mr-boo]

I use the same terminology actually!

[@jangelbrich7056]

"people didn't think" ... that sounds like the very root cause to me since a long time. As if the world ends at the API ...

[@adambickford8720]

I worked with a team that had multiple 'microservices' that had to share a lib that defines the DTO's between them. You had to update the DTO project, then update all the 'microservices' to depended on it, then all be deployed together. And no, you couldn't just upgrade 'some' of the endpoints, there was one jar to rule them all. The hilarious part? It was the *same team* maintaining all of the 'microservices'. All they did in practice was add a bunch of infra to support network vs in memory calls.

[@renanpolo]

Quick feedback: if you put your in video captions in the middle or top it helps those that rely on KZbin's closed caption 😊

[@ContinuousDelivery]

Thank you for the feedback. We'll see if we can change that....

[@NicodemusT]

@@ContinuousDeliveryyou should have run tests to make sure captions were considered. I can't believe you didn't have 100% test coverage! I've heard the excuses - "it's too hard to test on video", but it's just a skill issue.

[@maswinkels]

​@@NicodemusT😂😂😂

[@JP-hr3xq]

I have a new architecture that I'm calling "Mothership Architecture" for now. Basically it's a monolith which offloads frequent and high load operations to microservices. The "mothership" should be fairly stable and not change often while the "drones" can be updated frequently. I've not spec'ed it out completely yet, but my idea is to prevent a lot of the issues we are facing internally with interdependencies between microservices and the impossibility of coordinating development priorities between teams who rarely speak to one another and answer to different business units/program managers.

[@JohnHall]

The real point here is that micro services should not be interdependent. It makes the benefits moot. However, your hub (or even hubs) and spoke is a reasonable model for many designs. I would say however that my designs generally have a hub that is VERY rapidly changing, and micro services that are fairly stable. The rub is that the services are integration points to systems or processes that the particular hub system does not control. For example, ERP systems. So these services are more prone to failure and require more technical overhead to support them. So keeping them very small means we tie up top level talent less when errors occur.

[@purdysanchez]

You summed this up very well. Most companies aren't using microservices to solve technical problems. They are using them to increase speed of deployment and partition team repositories. The irony is despite 100x-ing the amount of deployments, it usually slows speed of feature delivery.

[@ericmackrodt9441]

I feel breaking a piece of a service into a microservice can be useful if that microservice is going to be used by two or more distinct services. An example I can think of is an Authentication service for a company that is shared between multiple of their products. Breaking apart code into a service that will only be used by the original product or building a single product from scratch using microservices is kinda pointless. Unless you can really do the thing where if a service is down, it doesn't bring the whole environment down. But that's rarely the case, especially if the thing that is down is, say, the Auth service or something else that is needed by a lot of other parts of the system.

[@bobweiram6321]

The criticism against microservices makes little sense. There's no requirement that each microservice must be implemented by separate teams.

[@ContinuousDelivery]

Fine, now try re-reading that and replacing the word "microservice" with "service" and you get the same result. The ONLY thing that distinguishes a "microservice" from a "service" is independence of deployment.

[@sunclausewitz2707]

Always felt like the kid that pointed out that the emperor had no clothes, when I criticized microservices back when it got popular 10 years ago. So much time wasted on network calls and parsing of json. All colleges " This is the new way of doing things, we can not stick to the old backwards way of doing things with our Monoliths, it's going to be be so much better in performance when it comes to scaling with microservices". Result was 10 times the complexity, 10 times slower (scaling the whole monolith is not a problem, but it is usually the response time and not heavy traffic that most teams deal with), and separation of concern was still and after thought so the microservices was still relatively dependent on each other.

[@fakt7814]

I don't understand the whole "monolith don't scale" point. You can run multiple instances of a monolith application by using a load balancer. Except the application is a really gigantic system or it's so poorly written it takes several minutes to boot up, it only utilizes resources needed for the task at hand, unless it takes RAM ahead of time for every possible use case for some reason. "Scaling" is already built-in in modern computers. If you use microservices to preemptively scale the application, you're doing wrong, since first of all preemptive optimization is always bad, and secondly, your problem lies somewhere else, since you don't really need microservices to make a scalable application most of the time.

[@jppittman6067]

Some applications are really big. I heard an estimate at work once that it would take 200 engineers 5 years to get an application to work on fewer than 100 racks. There are companies with code bases so large they won’t fit on any drive.

[@edgeeffect]

Well here's one of the main problems... it's not just about microservices but other architectural patterns, languages, frameworks, etc, etc, etc. A new pattern arrives that is useful in CERTAIN CIRCUMSTANCES and people see it as "the latest fashion" and desire so much to follow that new fashion that they never stop to think "Hey, those 'certain circumstances' where this pattern is useful... do they actually apply to us?"

[@zanderwohl]

The definition at 9:50 is basically the "true" definition of OO according to its inventors like Alan Kay. It's how languages like Smalltalk, Erlang, and Elixir handle dispatch and interfacing between objects.

[@CurtisYHMok]

yeah, I see both of them (microservice and OOP) are modeling paradigm, and microservice is aimed to model complicated human-enterprise/social system (that's why it's a socio-technical solution) when OOP is not enough (too many people!). Also echoing why Eric Evans gave small title of his book of DDD for "Tackling Complexity in the Heart of Software", where the heart of it is social system - people.

[@mleczakm]

Yeah, monolith isn't... Let's only ignore the fact that CI tooks hours to build and is failing on daily routine because some other team introduced randomly failing test to the codebase (because of no ownership ofc).

[@TNothingFree]

Another point is DB vs DSL Microservices usually dont share db structure but what happens people think of aervices as DB handlers (classic CRUD), but when logic is introduced they find out it doesnt work as intended and redesign everything The end talks about messaging which if done right you end up with a queue And if done wrong you gatekeep and do the proxy yourserlf. If you end up with an event driven system with msgs and services that do little or json parsing, just use built in tools like Netflix's python event driven system or Apache ecosystem

[@kdicus]

As it will ALWAYS and FOREVER be…select the correct solution for the problem needing to be solved - taking into account the short- mid- long-term, realizing your code will be maintained by someone else in the future.

[@edgeeffect]

Can I be pedantic and say that you should select "the nearest thing to correct" because there is no (perfectly) correct solution.

[@creo_one]

This will work for some cases, but after solution is used for many years it tends to evolve in unpredictable way. So more sensible way would be to not tightly weld specific solution to current design.

[@ricardo6607]

Thinking like this I can hardly agree that microservices are the way to long term. Most of the times each does whatever they want with theirs making it near impossible for other people to just start working on it in the future. But hey, AGI is right around the corner to start doing that so We don't need to worry?

[@creo_one]

@@ricardo6607 100% agree, microservices are solution to scaling issues, but in no way it is boilerplate for every application.

[@iAPX432]

I am not for monoliths nor for microservices: it all depends on your constraints and your available resources. There's definitely not one-size-fit-all approach. This is magic thinking. You might even consider mixing the two approaches, a monolith that use microservices when needed for specific operations that might need scalability, or are best handled through different tools (say languages/libraries/light frameworks/etc.), or to enable a small team using different tools to add the a project without having the full learning curve. Notice that you have to create solid contracts that will be able to be expanded for future usages. The design/Architecture part is essential. And this is were you will loose flexibility: boundaries and contracts. So you'd better make them great if not awesome at first!

[@salvatoreshiggerino6810]

The dumbest thing I've seen is where each team maintains dozens of services each, so you get the full overhead of microservices even where it isn't necessary because it's the same people doing everything.

[@AlanCzajkowski]

thank you for making a response video to that other video! my comment on that other video: microservices are not technical debt, if you're designing microservices and they are causing you pain then boy are you doing it horribly wrong, I'm getting tired of people taking a crap on microservices without understanding the architecture or how/why to actually break off a piece of functionality into its own microservice ... just because you're a bad engineer bad at design does not mean a particular architecture is bad the best way to build a microservice architecture is to actually start with a monolith, because if you try to design every microservice ahead of time then you will most likely get the design wrong, so you should start by building a monolith, and the way I prefer to slowly move towards microservices is I break off a piece of small functionality that I recognize can work on its own, preferably one that has little to no business logic, and I design the communication between the existing monolith and the new microservice as if the new microservice is a truly external product, and so the communication has to be designed properly using that type of mentality example: you need to send emails to your customers, but you have email templates that you first need to render before sending out some HTML email, well then break off your email sending functionality into a microservice, but DO NOT put the rendering portion into that microservice because that is highly specific to your business logic so keep it in your current "monolith" for now and just send the post-rendered HTML to the email microservice, and now you have a well-designed email microservice that you can scale easily and isn't tied to your business logic (your template rendering) building terribly designed distributed systems is not what microservices is about

[@AlanCzajkowski]

think of building out microservices like a hub and spoke model, you start with a hub and slowly break off into spokes 🛞 (but well-designed spokes!)

[@AlainLaguipo]

How do you justify to the business that you're doing some extra work for no value because you "didn't do it right" the first time?

[@AlanCzajkowski]

whenever you are doing work like paying off technical debt, such as fixing a broken implement, that is value ... so, just because you didn't release a new feature on the product does not mean you did not improve the quality of the product, the quality aspect here is that the product is now more resilient during runtime and easier to maintain in the long-term, which pays dividends for the business, which is the definition of value

[@zanderwohl]

The way people do microservices seems like they're making them wayyyyyy too micro. My company has a monolith, plus some new services that are added as their own services. That seems to balance our development speed well without giving us a ton of technical debt. There are some core functions in... well.. CORE! that prevent a lot of the sync deployment and version problems. Some business logic is super interdependent; that goes in Core. Some business logic is small potatoes that process messages to modify records from queues. Those go in services that have their own infra to scale up and down as needed. But the way people do MICRO services seems like a huge pain.

[@purdysanchez]

I have worked with some large companies that had 100s to 1000s of microservices. The fan out of requests makes the system is slower than just writing reasonably partitioned services. As a result they then force every service to service request to use gRPC. Still too slow given the fan out. Then they make more "bandaid services" to prefetch and cache everything. Essentially, creating microservices to mitigate the problem of having too many microservices.

[@purdysanchez]

It sounds like the sort of problems that Kafka stream evangelists create

[@shashank.c]

I believe a good way to start a new software product is to start as a monolith, specially if you just need a small team. Begin with Domain-Driven Design (yes, it can and should be done in a monolith). You will most probably get the domain boundaries wrong but it is easier to correct in a monolith. Over time, the team would grow in size. Divide the team along domain boundaries. If the teams have dependencies on each other, you still haven't got your domains defined well. Keep working on it till the teams dont have dependencies on each other. At this point, if you think there is an advantage of breaking the repo into microservices, then go for it. Take into consideration the complexities that Dave mentioned in this video that would need to be addressed as part of the decision making process of whether to move to microservices or not. Move one at a time in the beginning, but once you have underatood the process well go all in at once for the remaining microservices. Bottomline is that dont start with microservices but try DDD and keep evaluating your options at all times.

[@16randomcharacters]

This same dynamic often shows up with containerization; taking on the added complexity of a technology or architecture without adopting the organizational and strategic approaches that yield the benefits. I think there's a problem where people think function follows form intrinsically, rather than realizing that form facilitates function, but the function must be intentionally pursued as well.

[@no_more_spamplease5121]

@@16randomcharacters Yes. As usual, incompetent professionals in many organizations, driven by hype, keep cargo-culting without really understanding the work required for success. Buzzword-driven development.

[@CarrigansGuitarClub]

Message Queues have been around far longer than Microservices and will be in the future. Decoupling code is so much simpler with MQ's. Plus, you van use technology like .Net Channels for internal broadcasting and MQ's for external broadcasting - total decoupling.

[@टिरंजननकले]

Message Queue was/is great solution.

[@ddoumeche]

Message Queue is only a solution to asynchronous distributed calls, and carry its own problems : redundancy, non transaction, monitoring, etc

[@aay091]

@@ddoumeche You should not be doing "synchronous" calls in 99.999% of cases. Or any other P2P calls. That means you're doing it wrong.

[@ddoumeche]

@@aay091 please elaborate

[@aay091]

@@ddoumeche Building a highly distributed system of autonomous components means that those components should not be coupled. Introducing P2P communication introduces temporal and spatial coupling which leads to system fragility, cascading failures and, eventually, system being unavailable. So many people building "microservices" haven't bothered researching the foundation of this purely deployment approach (that's all "microserivces" are!) - specifically SOA, DDD and EDA. And EDA is what should be prevalent in cross component communication, not P2P. And no, I'm not talking about "request-response" messaging, as that is an abomination created to simulate P2P communication.

[@jadolphson]

The purpose of any organization is to avoid unnecessary collaboration.

[@capability-snob]

"Robust Composition", Mark Miller's PhD thesis, still sticks out today as one of the greatest articles on reifying the fact that the network is a source of a bunch of problems: performance, reliability, and security. Solid read.

[@raticus79]

Just looked it up, it's actually "Robust Composition"

[@monty156050]

I liked the point you made about tight coupling impacting team autonomy. It sounds obvious but if you cannot release services independently of each other then (a.) you're on your way to a distributed monolith (if you're not already there) and (b.) your teams clearly aren't autonomous.

[@mahdi5796]

Good video. I'm wondering why didnt you mention Domain Driven Design? It's a well known tool aims to tackle problem of defining service boundaries.

[@ContinuousDelivery]

See other videos!

[@gingdongfooee]

This episode I feel has got a lot right about Microservices, by putting Microservices primarily in the context of a management/social sustainability tool, rather than a technical solution, well done. What I feel you have missed is that tooling for Microservices is very beneficial. Not writing organization specific code, inuring that cost and secondly the numerous beneficial side effects of existing Microservice tooling, are for me very important benefits. I wish to highlight, the declarative deployment tooling, notably K8s, metrics based monitoring, notably Prometheus, tracing and observability typically via OpenTracing tooling, as real wins. A conglomerate, and a startup have different priorities, so also well done for being less proscriptive in this talk than is usual, which to me is a common failure of software engineering consultants.

[@hyau512]

As a former Java software architect. I really liked your insight that microservices are yet another distributed service implementation like CORBA. I've downloaded the CORBA specs and have used their 'simpler' cousins EJBs (Enterprise Java Beans), and to me they were neither trivial to understand or to use. I've not designed or used microservices, but I can totally see how all the issues I encountered with EJBs will still be relevant.

[@mjrmjr4]

This is a very thoughtful and well reasoned response to the completely unprepared conversation I had that started this "technical debt" idea. Designing good APIs between components is truly the hard part about software engineering in large organizations. Being intentional about taking tradeoffs is important, and in my experience it is increasingly difficult to be intentional as the engineering team size increases.

[@a0um]

Isn’t “micro” in micro services misleading then? If the value is the alignment between teams and deployables then a better qualifier may be “domain”, I.e. “domain services”.

[@kozlovskyi]

Distributed monolith is a tech debt.

[@rushas]

@@kozlovskyi writing any code comes with technical debt

[@stevecarter8810]

All code is a liability, only its correct actions are an asset

[@HerbieBancock]

Your English is garbage.

[@elpelicanojiji]

Define monolith

[@marcocoratella1556]

Distributing a product made by incompetent is the main debt

[@overlandkltolondon]

I worked for many years for a client that relied on microservices 'supported' by various disparate teams. The result was that nobody wanted to change anything in case they broke some unknown dependencies downstream. By the time I left, I spent most of my time carefully dockerising some perl services that had a very outdated dependency tree.

[@Biriadan]

There's just no reason for the lines between components to be fixed lines tht can never change. With adequate abstractions and good support, a chunk of code can shift from being a static inclusion in one deployment to a microservice to a hotswappable module. Why are we tying ourselves down to a single strategy when there's no need to?

[@Bozebo]

My current project has many independently scalable parts, but we don't complicate the code base for that too much - infrastructure can define how that deploys scalably and handles the workloads and requests in a "microservice" esque capacity (I am describing this very generally). One of the issues people take up against microservices is with codebase management and project management, again that doesn't have to be the case - you can if you want work from one ("mono") repo or mostly one without issues (not that we do that as much as I would prefer in a couple of areas). Again it's down to infrastructure definition, if you want separately deployable projects or scalable code paths (say multiple different daemons from one code base, depending on buld or image or launch params or config secrets because a few kb of empty code path on some containers isn't necessarily bad) you can do that fine. Re structuring to or from "micro"services for different parts is also not a major issue if you have thought ahead and know where your scalable working parts are and need to be (and if you profile you should've also been forced to consider that a lot). Remembering also here, if you needed to distribute and due to that have a network bottleneck and more complexity to consider you should be doing that because you had to anyway so that's what is worth spending time engineering around, which is quite common and the other challenges on the small scale are more "solved" hopefully. Basically just because a system runs with many nodes doesn't mean you have to develop it with a code structure split up to reflect that, which should be obvious... Running an enterprise worth hunderds of millions' back-end on mostly one repo? Absolutely doable and fine.

[@JohnHall]

As an architect, I chuckle over these conversations. I like to say that my team is a tech debt creating machine. We create tech debt faster than anyone else in our 40k person org. However we also retire tech debt faster than anyone else. We use non interdependent micro services everywhere for all projects and all functions except the handful of key integrations. We do this because we focus on all of the projects that are poorly scoped. We specialize in solving part of the problem immediately which grants us runway and credibility to solve the larger and longer term problems and therefore retire the technical debt. Our team delivers solutions that ultimately become the scope for the next solution. I will take on tech debt every day in this way because it grants us more budget/revenue to solve more problems and retire more tech debt.

[@colton2432]

I struggle with professionals that fall into what I see as a semantic argument of microservices versus monoliths. In my experience a sufficiently complex system will always have some distributed nature to it. The answer I seek is what scale boundary would best solve the problem. Do I understand the domain well enough to do anything less than one large system, will the domains change as I gain understanding, does the organization I'm working with function better in independent groups? It's taken years in my current organization to push against norms and identify what parts of our domain are flexible and only defined by previous systems and what parts are legitimately required for user needs.

[@acasualviewer5861]

Make things as simple as possible until no longer possible. Microservices don't make things simple they add a lot of complexity and you enter distributed computing performance issues that are harder to monitor, log and debug. So if you don't ABSOLUTELY need it, don't use it. Most projects with 100K users or less don't need it. Monoliths can easily scale to that level without the headache of microservcies.

[@alanmacmillan6957]

i'd agree. there's more time spent tearing down and rebuilding micro-services than we ever did with software installed on a server. there's a proliferation of micro-servers when traditionally one heavy weight process could do the work of many micro services.

[@nickbarton3191]

Worked on a big aerospace project late 90s. They were doing nightly builds and regression testing without staging. That meant that every day, every team was expected to have pushed at least a partially working sub-system. What a nightmare, the very opposite of having decoupled teams.

[@lucasjsantos2260]

The problem is not microservices, it’s nanoservices. In my company I see the over splitting of applications based on belief that’s microservices.

[@pazsaragi5501]

If you have a service that solves a business problem but has multiple ways of communication. Would you consider them separate microservices? Or the same?

[@ContinuousDelivery]

I'd probably make the communication a separate thing, two "gateway services" or maybe two different comms adaptors in a Ports&Adaptors relationship to the service that solves the biz problem.

[@erynmacdonald]

I've watched his talk elsewhere, and i will say this again. Most work you will encounter if with somewhat of a monolith backend. You will find that the natural progession is to move to services with event driven architecture in support and protecting the backends ...

[@ContinuousDelivery]

I agree, except you don't mention "microservice", and for a good reason. You can do all that you say and not use microservices, because they don't need to be "independently deployable" to achieve your goals unless you want to scale your team!

[@jimmy21584]

In practice, I use them whenever a component is used by multiple products and its interface will almost never change, ie a document renderer. Otherwise there are just too many performance and architecture benefits to having a monolithic project. I’m talking medium-sized services and app projects.

[@delturge]

Great discussion. Now, back to my quest to watch all of your content. 🙂

[@gabiold]

The communication issue and forced tracking of the other team's (breaking) changes is only a huge concern, if the microservice parts are developed by different entities. If the microservices are just used to separate concerns in a bigger coherent system deleoped by a signle entity, then the coupling, communication and scheduling the changes between the teams is an internal management issue, with the possibility of doing it right. You would need some sort of management anyway if you had the whole system as a monolith. In my opinion, after a certain complexity, it is better to think in loosely coupled microservices, unless the benefit of separating the concerns is too low to worth it, eg. if a small team could work on the system as a whole without issues anyways. If this is the case, then adding a management layer is just increasing the amount of total work, possibly also slowing everything down. There is an interesting aspect though, which wasn't covered in the video, maybe because it is just an another "technical design consideration" like anyhting else. Security and safety. While indeed it's just a technical thing, we are living in a connected world with countless privacy and vulnerability issues, security and safety is a bit more important and has much bigger impact nowadays than some other tech and financial aspects. So if you can make your system more secure or safe by separating concerns, then you should, in my opinon, even if it is harder or more expensive to develop that way. The problem is that the consequences rarely effect the developers and the company itself, rahther just their clients and users, so this concern is still negleted more often than not.

[@ContinuousDelivery]

But what you describe aren't, by definition, "microservices" because they aren't "independently deployable" without that what you have is a distributed, service oriented, monolith. Which is fine, but if you keep each service in a separate repo, and then evaluate them all together prior to release, you get the worst of both worlds, neither the speed and efficiency of more coupled systems that you can achieve with a distributed monolith, nor the org scalability and deployment independence of a microservice, so you pay a tax on your development twice for no gain. You final point on security, has nothing to do with "microservice" either, it may be about separation of concerns, but that is a bigger, more important, topic!

[@gabiold]

@ Why parts of a bigger system couldn't be idependently deployable? Yes, of course, you can make it deliberately that bad with bad design choices. Or might be your statement that you have to integrate and deploy everything together assumes the worst case scenario: an inmature API and under-development-everything. In that case, it's true, developing the whole thing in separated repos is a nightmare. However, once you have settled the fundamental aspects, the parts could be independently developed, deployed, taken out, replaced, with the need of coordination only if breaking (API) changes has to be implemented. Why this by definition isn't microservice architecture? A microservice in my opinion does not mean that it should exist in its own isolated world, without any dependency. Dividing a bigger system into smaller services, does not has to mean that it is still monolith just the parts are delegated here and there. It is not necessary to have just 1:1 relation between the parts. The components that makes up the whole could be reusable/universal, that's the whole point of factoring it out into a service. E.g. an authentication service could be used by multiple other services, an authorization service also. I can't see why these couldn't be independently deployable.

[@michaelutech4786]

I find this a bit misleading. Ever since I learned about design by contract, many decades ago, I changed my view on interfaces a lot. I understand micro services as services with very lean or small interfaces and a very strict and exhaustively defined interface (or contract). As such, a piece of code using a micro service should never need to be retested if a new version of the micro service is published, for as long as the new version of the service is complying with its contract. It's the new service implementation that needs testing. If the integration of the two need testing, that almost always means that they did not define the contract between them sufficiently. The very nature of micro services is that they are small enough to allow for the specification of an exhaustive contract. If that contract is not specified or if it's not tested, then this is the problem, not the architecture of micro services itself. It's one of the core concepts of the micro service architecture, that individual services can be deployed and maintained individually. But that does not mean that they need to be deployed as such or that their implementation need to maintain the boundary between services. Micro services can be deployed as a monolithic cluster and the implementation of individual services can take advantage of such a deployment, if that is an implementation detail. For example, the deployment modalities can be a compile time decision. A module implementing a micro service that uses other micro services can represent these dependencies internally as async calls that may either be tunneled over an http connection or call a library method. A resource shared between the two can be a third service or shared memory or a shared file system. That does not change the architecture of the software, only it's implementation. If both interfaces in this example (local and remote call) are semantically equivalent, a micro service architecture can result in an entirely monolithic implementation. The only thing that changes in this example would be that you loose runtime scalability by requiring a recompile of a dependency needs to be extracted from the monolith. Then again, if this flexibility is needed, it can be accounted for at the expense of performance or other factors. Micro service architecture (if done right), preserve the choice and that is actually their real value. To me, micro services offer an objective advantage by enabling and promoting contracts. The technical benefits of a micro service deployment are not in and of itself their primary advantage, it's only an option that can be used if it offers benefits in a specific scenario. You do not have this option if you use a monolithic architecture, because you cannot just untangle a tightly woven network of dependencies. You can of course design a monolith with this flexibility in mind, but as I see it, you just used a micro service architecture if you do that. All the above is ignoring how micro services are used and implemented in the industry. That's an entirely different story. There is no paradigm or technique that looks good once it sees the light of "business".

[@CallousCoder]

I totally agree, from day 1 I wasn't onboard with the microservices fad. Those trend followers never thought about the added complexity that loosely coupled services present -- especially in failure scenarios. The argument that was always uttered was; "Netflix and Amazon uses it". Yeah Netflix and Amazon aren't exactly dealing with time critical and immediate consistent systems like most other systems are.

[@jason8966]

You should change that bird in the outro for a butterfly since you're on it ;)

[@maxmad4771]

This channel has become click-bait, selling you lectures and consulting very fast. From very good source of information to a point where we have videos that are mostly sponsors and very little to no usable information. Really try to fix this as I don't think I'll follow much more with downfall...

[@adambickford8720]

I was annoyed when i had to skip the *second* embedded ad :-/

[@Kingmannie]

I tend not to get emotional about any technology choice, its a tool/solution not a member of your family. Having worked on both monolithic and microservice architectures I can say a well designed scalable microservice architecture can just handle so many more concurrent users - if it is a web facing application for example. A monolith simply cant cope, if you imagine one hosted on prem at least, on a windows server for example. Sharding and the hosting model plays a part as much as the queue integration, but the extra "ility" factor microservice architecture provides has its own benefits. Which has more technical debt? A scalable microservice solution that can handle concurrent users, or a monolithic solution that has one resource? I tell you what, when you open a monolith service layer its massive - loads and loads of files and folder. The readability factor on monolith where you are looking at a smaller service designed is neater. I suppose thats the team choice factor you mentioned. Its a tricky one, I feel like if microservices are implemented correctly its hard to call them technical debt.

[@Sapphireleadershipadvisors]

Honestly not even sure what I am shifting to is even microservices. I have a large system that has a customer/loyalty system, a reservation booking system and admin portal, inventory and product management, etc. I am trying to split these into separate subsystems that can essentially be their own products. Right now they are all one large monolith. I don’t even see how this is microservices as the word “micro” would suggest something very small in scope.

[@johnlehew8192]

Forget the word micro. Break up by domain first. If there’s a director over inventory and another over loyalty then split along those domains. If a shopping cart needs in-memory db processing with redis then separate from the regular db. If there is more than 150 tables in a database or 150k lines of code, that is a good candidate to split. If there’s a performance issue in an area of the code, that also might need separation. Don’t just split up your app just because the pieces are not micro

[@edgeeffect]

But really, if you think about it, whatever architectural choices you make (or if you choose not to make no choices at all and just a build a big ball of mud) - they will all lead to some measure of technical debt. Whatever you choose, at some point in the future, someone's going to say "this change should be easy but the architecture is making it really hard".

[@alexischicoine2072]

Really surprised about talk of xml. All APIs I use are using json these days.

[@ContinuousDelivery]

same thing really!

[@snowy8465]

In my country all banking/government systems HAVE TO use SOAP for communication. xml isnt going anywhere

[@JustinSunseri]

People are still using XML?

[@AntonioPetrelli]

The funny thing is that the same reasoning that you show here made me a microservices skeptic since I knew the concept.

[@lightningspirith]

First time watching a video of yours, thank you for your dedication on providing accurate information and engineering terms.

[@boomerau]

So macro services where is macro service is either a modular or a micro-services bundle that doesn't require outside negotiation.

[@adambickford8720]

The embedded upselling/ads feel like it's coming up on half the content here. Might want to tone that down.

[@Dalamain]

monolith lasagne is my choice

[@paolozavalloni]

Micro services and develop them in the spring boot platform for example are really a huge paradigm/solution with a nice set of tools to use but going from monolithic architecture to that concept can be too expensive. For example a complex erp software cannot be "ported" from one architectural concept to the other easily but requires a lot of analisys/redesign and development. And ok if your monolithic solution is not easily maintainable frankly speaking 99% of the time is because it's a bunch of spaghetti coding that can be improved easily with a good modularization in a real world scenery in Wich a huge percentage of developers haven't got enough skills to use even design concepts of 40 years ago like modularization, object orientation and design patterns. If this is the case the same mistakes in a real micro services architecture will cost you unbelievably more...

[@shaneoseasnain9730]

Surely the goal for good microservices is they can identify their own obsolescence, either muting themselves or evolving into something more useful

[@glebbondarenko67]

This year I hear more and more that microservices are bad (without any real alternative) So this video is the most mindful position about microservices that I've heard so far. Thank you

[@05xpeter]

I try to tell other developers your infrastructure diagram is not your architecture diagram. Your infrastructure should solve concrete problems regarding how your code run. I see so often developers design complex systems that are very hard to change and redesign because they have started in the distributed path and even worse when they do multi repo.

[@kayakMike1000]

Hmm... Little program that fits in your head with a reasonable API always seemed like the core idea of the object in object oriented programming.

[@krzysztofbuczak1212]

1000% agree on that.

[@garyleeson]

Microservices, monoliths, modular monoliths, and product and system architecture are technical debts because they become outdated and need updating as soon as they are completed or released.

[@leosousa7404]

Honestly, I haven't caught the technical debt of microservices

[@HerbieBancock]

If you ask a fan of "serverless" why they like it they will just point to a blog post their friend from college wrote and refuse to provide any further justification for their need to pepper their résumé with hipster buzzwords that have absolutely nothing to do with the product the company is trying to sell.

[@purdysanchez]

Serverless is extremely slow. I worked with the company that essentially invented it and hosts most of for the world. 200ms traditional request to a distributed app. 7s request to the serverless version.

[@dirkschannel5817]

Marmite is like Root Beer. You love it or hate it. I confess, i love it

[@BenRangel]

I find ”love it or hate it” is almost always a myth. As with marmite I bet most people are like ”Not something I usually buy but it can be ok s few times per year 🤷‍♂️”

[@somcho]

wasi component model seems better

[@armanrozika]

thing is people building microservices for the sake of microservices even tho it doesnt serve any functionality for the jobs

[@devinlauderdale9635]

neetcode mentioned in a Dave Farley video 🤯

[@black-snow]

Dammit, Dave stole my "first"!

[@ErazerPT]

That "time of flight" part was fun because it made me think a bit. A monolith is like a huge ball you balance on your head with some help from your arms. Split it into smaller services and you get to balance a smaller ball on your head while carrying a smaller one on each arm. Split the arm ones and you have to balance them on each other. Split them some more you're going to have to do some (easy) juggling. But keep doing it and pretty soon the juggling becomes a nightmare, and you have to thrown them further and further and implement a complex cycle to keep everything in sync. And that cycle isn't too forgiving about randomness. Cue heavy winds and it falls apart. So you put some safety nets that return you the balls that drop, but can't be picky of when and how, and they might come in at the worse time. So... Some, yes, good. Too many? No, really bad. Too fragmented is a real thing.

[@judgewest2000]

Yes

[@georgedavybarnen]

Who uses XML by choice anymore??!

[@udirt]

orly it's almost as if systems design is something you do with care instead of something you go do a conf talk about

[@marshalsea000]

Technical Debt or Operational Debt? If done correctly - both should reduce, but it does mean you need to be doing ATDD and DDD properly - which most companies aren't... and then wonder why it's a steaming pile of horse manure.

[@prashanthb6521]

I find this issue more of a bureaucratic problem.

[@drstrangelove09]

I pay for youtube premium but I still have to deal with commercials, in the video... arg!!! I'm out

[@saheemsiddiqi3220]

CODE is technical debt. There's just no way around it. So, pick your architectural style that suits your needs, i.e. the proverbial poison, and enjoy.

[@ElPolemista]

Microfrontends is directly a bug

[@jasonjimenez9116]

When you are a small team, avoid microservices.

[@jboss1073]

I only write service-agnostic code so I think you're all wasting time.

[@way.journey]

microservices...decayed to...comms via JSON over HTTP

[@joesteel7837]

Majesric monilyth FTW.

[@bobweiram6321]

Just because each microservice is distributed and independent doesn't necessarily mean its development must also be distributed and independent. There's nothing requiring all of them from being developed by a single team. The problem stems from project management mirroring software architecture, not microservices as a design.

[@ContinuousDelivery]

Well, I don't like arguments from authority much, but you could ask the inventor of micorservices why he invented them, or experts in microservices how people get them wrong, and they will all say, largely what I said. Conway's law en.wikipedia.org/wiki/Conway%27s_law says we are doomed to mirror the organisational structures that we use to develop code in the design of the code. But also this is less about the fact that microservices are distributed means that our teams must be too, but rather that we want small autonomous teams, because ALL the data says "That's what works!" so given that constraint, what architectural structures facilitate that. If you divide up the problem into a series of separate services in separate repos built by separate teams, and then force them to work in lock-step, you have lost ALL of the advantage that you payed for with that extra friction. Microservices, isn't really a design approach, by definition. "Services" are a design approach, and apart from "independent deployability", the core idea of microservices, you can get everything that microservice has to offer from service based design.

[@TheForge47]

Finance teaches that one person's debt is another person's wealth. But who is the 'other,' and what constitutes their wealth? 😂

[@brucem8448]

None of this is right. Microservices are just an antipattern. Microservices is sharding code. Sharding is typically for data, i.e. sharding a hotspot in a database table. This pattern is sharding code. Is it necessary? It takes 11.3 trillion LOC to reach 1 PB (1 byte/char, 100 char/line), which would need only 50 20TB drives. Google's codebase is ~2 billion LOC in 2015, Linux kernel at 27.8 million LOC in 2020. 1 PB of code is 10,000x larger than the largest organization, and it can fit on a single rack. Especially with disaggregated storage and compute. You don't need to disaggregate code. Have a global code repository. Large scale versioning and compilation are tricky, but microservices are much worse. There is no benefit to microservices.

[@judgewest2000]

ALL code is technical debt... eventually

[@johnk6757]

technical debt is fine when you're probably just gonna declare technical bankruptcy anyways

[@lukaszkulasek]

You can ask another team to make a change in your microservice and issue a pull request for you to review. And why do you claim you always need to deploy multiple services in order? If you need to then your micreservice design sucks.

[@Omnifarious0]

While I understand the necessity of ads, splicing them into your actual points makes your video useless. I'm following a line of reasoning, and then suddenly have to switch modes to "ad" and then back to thinking deeply about what you're saying. Splicing ads into content mostly works fine for news, but very poorly for things requiring focused attention to understand fully.

[@CripplingDuality]

Have you considered using the seek bar?

[@Omnifarious0]

@@CripplingDuality - No, I consider that to be rude and disrespectful to the person making the video.

[@ClimateChangeDoesntBargain]

Just use Sponsorblock

[@ContinuousDelivery]

Unfortunately I can't afford to donate my time wholly for free to do this without the support of sponsors. Sponsors need some form of return for their sponsorship, hence the ads. To get that return, we need people to see them, so they need to be in with the content. As you have seen, some people already skim past them, but that doesn't help to support the channel. I understand, I do that sometimes too. But, in effect, the ads pay for the production of the videos!

[@ClimateChangeDoesntBargain]

@@ContinuousDelivery ads are a very unethical and inefficient form of payment. Have you thought about locking the videos behind a membership (obligatory payment) or allowing liberapay donations (voluntary payment)?

[@parlor3115]

Lol, I imagine this guy getting horrified and grossed out at the sight of real code

[@youtubelisk]

Microservices help with the up time. If one service breaks, it does not influence the core, and you can continue to serve customers instead of the site being down. 1h of downtime can mean a lot of money, and that money is usually bigger than the mentioned cost of communication. This seems ideological, which is fine but boots on the ground tell another story.

[@ContinuousDelivery]

That's not really a feature of microservices, it is a feature of "services" you can do the same thing, just as easily.

[@hyau512]

@@ContinuousDelivery Also, you'll need to understand & test the consequence of each microservice going down on your application.

[@maasha2001]

Marmite is disgusting!

[@ContinuousDelivery]

Nah, it's great 😊

[@rj7855]

No, it isn't

[@acasualviewer5861]

so are most microservices

[@VV-nw4cz]

No. If MicroServices is a strategy to handle development team management, then it is engineering solution applied to non-engineering problem - TERRIBLE IDEA. No MicroServices don't enable changes in one part without changes to another, as there are logical dependencies, and if one believes in that - they simply are gaslighting. And that is a path to a tightly coupled bowl of mud. The only reason to use micro-services is if one wants horizontal scaling, as they already hit the limit of vertical scaling, which is false for 99.9% of the software built.