Markus Ziller: From Monolith to Microservices With the Strangler Pattern

In this talk, Marcus Ziller, a Solutions Architect at Amazon Web Services, discusses the transition from monolithic architectures to microservices using the Strangler pattern. He explains the challenges organizations face in modernizing applications, highlighting the necessity to adapt to cloud technologies in order to remain competitive. Ziller elaborates on the limitations of monoliths, such as tightly coupled codebases and difficulties in scaling, before introducing the concept of microservices, which promote independent deployment and flexible technology choices. With the Strangler pattern as a solution, he describes how to iteratively replace parts of a monolith while managing dependencies and data synchronization, ultimately fostering a more agile and innovative development process. The session underscores the importance of understanding domain contexts and utilizing established design patterns to navigate the complexities of microservice architectures effectively.

[Music] ladies and Gentlemen please welcome our next speaker Marcus Ziller presenting the topic from monolith to microservices with a Strangler pattern all right hi everyone uh my name is Marcus tiller I'm a Solutions architect at Amazon web services and as a Solutions arct at AWS I helped my customers solve their business challenges using AWS technology and in recent years one of the biggest challenges that my customers

face is the modernization of their existing applications and this quite often includes going from their monolithic systems towards a microservice based architecture so today I want to talk about the Strangler pattern which is a tried and tested way of approaching such a transition but before I dive deep into the pattern and discuss its ins and outs I want to take a step back and zoom out a

bit and discuss why this is happening why we see this happening in all Industries and at the end of the day it comes down to the fact that the playing field has been leveled cloud computing um open source Solutions Services um they really democratized the access to state-of-the-art technology and that removed the entry barriers into many Industries into to many markets and made it easier for new

startups to challenge the status quo and that's something we see across all industries that the old ways of doing things they get challenged by new ways of thinking before I joined AWS I worked in the media industry and I witnessed firsthand the disruptive power of the video streaming services that were coming up uh services that were born in the cloud and that is happening across all the

industries and the only thing that allows established companies to stay ahead of the curve is the ability to adapt and to innovate on the on themselves and in order to be able to do that you need a solid technological foundation so it is not surprising that for most customers app modernization is a key theme in everything they do and they look to the cloud as a as

an enabler to do exactly that customers migrate to the cloud for a large number of reasons but two of them are always high up the list one is cost and the other is the ability to innovate every customer wants to be cost-efficient and every customer wants to be more Innovative to to drive new features to deliver new products at are faster pace and if we look at

a typical Cloud chain I mean every cloud chain is a a bit different every modernization journey is different but there's a pattern that we see and that is that we start off on Prem so these are companies that have been doing it for decades and they started off in a data center because there was nothing else there but at some point the business really outgrew what the

data center was capable of delivering that's when they look to the cloud and most often this happens in the lift and shift fashion so what they do is they take all they have on Prem one by one all the applications all the tools all the scripts all the build over the last decad and move it to the cloud move it to AWS just as is and that

is an important First Step but it only gets you so far the gains that you get are comparably little so what then comes next is the phase of optimization that's where customers really are now in the cloud and they try to maximize the efficiency of what they are running in the cloud without changing the architecture itself that includes things like right sizing instances so find the right

instance size for your workloads going from self-manage databases to manage databases for instance using Amazon RS or relational database service and that gets them already quite but after you've done all the optimizations you reach a point where you get diminishing returns where the return on invest is just not given anymore so if you want to go even further you need to more embrace the cloud and go

into the modernization phase that's where we really think about how can we utilize what we have in the best way and that includes things like leaning heavily on serverless doing devops whatever that might mean for you but it's just the idea of doing it and that's where the existing applications start to get in the way because it's really hard to do server L with a monolith that

has like a million lines of code that is just not working out well and that's where customers think about okay what can we do how can we get from this point where we are now to this point where we want to be and in order to better understand like position they are they are in it's important to understand what like what is a monolith um how is

it more or less defined so when you have a monolith by definition you have a single code base everything that application does it within one code base all the features are in that code and that makes it tightly coupled so it's hard to separate those you share resources so you have a database mostly SQL but you also share things like CPU memory and so on if you

want to deploy the thing that's uh monolithic so regardless if you have a small change or a large change you need to build and deploy the entire thing if you want to scale the thing because your traffic pattern changes this is most of the time then done vertically so you add a bigger machine to be able to serve more traffic sometimes you can scale horizontally a bit

but usually that's that's not happening you're locked into a single technology stack so if you started your monolith in cobal 30 years ago that's what you're stuck with and that is not a very pleasant place to be with many dependencies and then a large code base that leads to longer build times uh because you need to compile build bundle test all that code all every time you

deploy which can cause a problem and lastly since everything is running in one machine regardless of how clean you build your code um it's still running on one physical machine and if that machine this virtual machine is having a bad day the entire thing goes down from an architecture perspective more or less looks like this I mean there's a bit of nuance but 99% of the monolith

look a bit like this so there's a database most of the time it's an SQL database then you have the the thing the monolith that is running on an ec2 vir machine or whatever with all the components in it there's some Ingress sometimes a load balancer sometimes you have an engine X running or sometimes you connect directly to the to the machine that's more or less how

monolith look like you've all seen that in contrast when we look at microservices they are by Design that's one of the characteristic characteristics of microservices are decomposed so you take the functionality and decompose it that creates a a loose coupling between independent pieces of your AR architecture each of those pieces solves a specific problem and you can on the one hand deploy them independently but you can

also develop them independently you don't not stuck to Cobalt anymore you cannot use python or Java or whatever prefer it also comes with a decentralized data management because again by Design the microservice architect you don't share state every microservice owns their own data their persistance layer and that's you find need to find ways to centralize this because at the end of the day you're going to need

all the data same goes for network communication you now need to have means to discover services and communicate wi the network it provides better degree of fault isolation so if the machine of microservice a goes down it doesn't affect the machine of microservice B there might still be interdepend tendencies that you need to manage and scaling is horizontally so you just add more containers more uh virtual

machines if you need to scale with the with the increased demand in terms of architecture um again 99% maybe 95% of the microservice arch just fall in that category in that like look like this so you have an Ingress or some low balancer that redirects traffic to some microservices they have a specific task they communicate at among each other synchronously asynchronously doesn't really matter and all they

they all have a persistence layer which they own and only they own and what we can consider this is this is two ends of a spectrum so it's not either microservice or monolith it's really a spectrum and our job as developers Architects whatever your role is is really to find The Sweet Spot on that Spectrum to understand what is the right design for your workload and that's

where things sometimes go wrong so we are all Builders you wouldn't join a session about the Strangler pattern if you're not a builder if you don't enjoy solving interesting technological challenges and that is a great thing but that often leads to make us leads us to make biased decision decisions and is there are good reasons and there are bad reasons to do microservices and unfortunately I've seen

a couple of attempts to microservices fail because they were started for the wrong reasons I don't want to dive too deep into all the reasons to do or not do microservices I just want to give a few of the reasons that I think are bad reasons or good reasons that I saw in past so I sometimes hear the sentiment that monolith are per say bad or slower

in efficient and that is not at all true um well-designed monolithic application with a moderately sized um database can handle a frightening number of requests per second so if performance is all you care about monolith might be well the thing that you you want to have for your workload that's just how it's done today also not really true there's a lot of bus in that area and

many companies are doing this and a vocal about this but there are plenty of high functioning monolith or Services would be considered a monolith that just continue to work and there's no need to change them another argument I sometimes hear is Amazon is doing it too or Facebook is doing it too that is true but Amazon literally has tens of thousands of developers building applications and if

you're at that kind of scale you don't have many options to manage the complexity microservice are easier uh I can guarantee you they're not easier micros service are actually really hard to do well because you need to manage a lot of distributed complexity and it's a really hard thing to do right and lastly um it's the idea that it will make scaling much easier when you get

to number X or number Y which is probably true um but I'd argue Focus your energy on getting to that number build your systems in a way that you can then easily decompose but don't optimize from the start I often see ceers with startups to optimize from the start W from the start um and they're never going to reach that number but that being said there are

also quite good reasons to do microservices so one of the good reasons is if the business wants to move faster but can't because the back end is holding it back um that's a good indication that you might want to decompose to manage the complexity better and to move faster and certain parts of your your TX deack also if you are afraid to touch the code or if

the deployments are really hurting and you don't really understand what is happening also a good indication to decompose and to be more flexible in what you are doing and to reduce complexity in in parts if you feel locked into technology taking the kobal example again um and you don't can't use the the best technology for the problems you want to solve all it's also a great indication

to maybe cough out some parts and use better tooling to solve those problems and lastly that one is rather rare but if your product really grows a lot in a short amount of time if you go through a phase of hypergrowth that's also an indication to really look towards this to make this more manageable and to to grow and to to support this growth so I want

to briefly talk about the Amazon story because that is a really a success story of when microservices were the right call and worked out really well so this goes back to the year 1994 where when um Amazon was founded and from the beginning it was a single monolith it was an Oracle database and then the business grew a lot like we went through a phase of hyper

growth and we grew in all Dimensions users items we shipped developers and this led to a point where the business really was hurting because updates were taking a long time features couldn't be delivered and we needed to change something and this then led to the famous I at least the Amazon famous Bezos API mandate so that was an email sent by Jeff Bezos where he essentially outlined

that the company should do microservices he didn't call it microservices at the times but he really outlined the parameters systems that communicate wi API small teams that can be fed by two pizzas to build those apis automate you build it you run it all those things that we now consider normal for microservices have been introduced at Amazon in 2002 already and that's how it is until today

so if we look at Amazon today um we have thousands of teams doing microservices doing cicd leaning heavily on serverless and that leads to a really mindboggling number of deployments that we see per year in the so now that we know why we want to do it and that we want to do it for the right reasons let's talk about the how and that's that's the Strangler

pattern that's one way to do it so if you look back at our earlier monolithic architecture um let's give it a name let's call it storefront and storefront is a super successful Global e-commerce company and well they are running on a monolith they have a SQL database and all the things we discussed earlier and that causes some problems in different dimensions they suffer from low Velocity Long

release Cycles features take a long while to be to be put in front of customers and that is hurting that is lost Revenue um and you can't just compete with those new startups that are much more Nimble and navigating um their requirements it also has operational inefficiencies so it takes a lot of effort to just keep the thing running there's a lot of undifferentiated heavy lifting that

the teams need to do to keep this thing a Flo float and make it work and that not only has cost in terms of people that need to do this but also has opportunity cost if you need to spend time maintaining the monolith you're not developing features and lastly storefront operates in a regulated environment so we handle payment Data customer data and there are compliance programs we

need to adhere to and those are changing and contrary to like features that come from the business side this is not optional we need to do this so if we're not doing this we get fined we lose customer trust that's a problem so we want to change this and well we have a few requirements well we want to go to market faster uh we want to lower

the total cost of ownership so less operational overhead more automation we want to have higher performance be better able to scale with our business and we want to have better security and isolation by Design so what we could do is we could freeze the monolith to nothing and do a rewrite from the get-go and really write this entire thing new sign a new architecture that does typically

not work well if your system is sufficiently complex that you want to rewrite it to microservices there are in practice too many moving Parts too much complexity hidden somewhere that if you attempt to do a big bang rewrite you're doomed to fail I have yet to see this to work U to work out and have a happy ending so there needs to be a better way and

in fact there is and that is the Strangler pattern it's sometimes also called the Strangler fig pattern because it is inspired by Major mother nature and it's quite fascinating the Strangler fig is a tree that when it grows it wraps itself around another tree up to the very top and it deprives the original tree of nutrition and of sunlight until the tree dies off and it gradually

replaces it because all that remain is then the is the Fig Tree and that's a very good analogy for what we are trying to do we want to wrap things around the original tree until there's nothing left and we can just turn this thing off and Let It Die In Peace So from a 10,000 ft view if we zoom out this sounds rather easy so we have

our monolith we lifted and shifted it then we move out a micros service we move out another microser service and then we are done all right let's get coding right let's do this uh not so fast so this is really important before you write the first line of code before you even touch the IDE make sure you understand where you want to go make sure you understand

your domain you cannot make this up on the go you need to have a clear picture where you want to go and that REM uh that requires a deep understanding of the domain and the problem you're trying to solve and a tool that is almost essential to do this is domain driven design so entire books have been written about this about domain driven design and if you

want to do this I really encourage you read those books and apply what what you learned from those books um they are an invaluable tool to help you on the on that journey in a nutshell what domain driven design tries to do is it tries to map the the entities you see in the real world World in your business to the technological space so and it does

so in creating what is called a bounded context so bound the context the idea is to take these those entities and group them into contexts where within one context you have a a high cohesion and between two contexts you have a loose coupling so if you look at these uh these lines between the boxes you want to have as many lines as possible within one context and

as few lines as possible between two contexts and that then Maps nicely to your microservices because that is exactly what you want you want to have little communication between those microservices and much in between when it comes to defining those contexts the most natural place to start is your business like how does your business look like and that is almost always the leading Factor but there are

others technology if you have different technology choices that might factor into it location if your teams are distributed across the globe that might be a factor compliance might be a factor or even the velocity that you want to see in the different parts of your microservice architecture so um really important to understand your domain and have a clear picture where you want to go and why you

there all right now that we've got all this out of the way let's look at our monolith so we have we've identified our domain uh there's the inventory there's an order there's a card feature now we want to get going we really want to bring this thing down and the first place you should start is the user interface if it has a user interface if not great

good for you but most applications have some sort of user interface and if you're lucky you already decoupled this you have some apis on the back end and some web um bundles that communicate with those apis that's the case again you're lucky just move them to some content delivery Network and you have your first success if not invest some time to make it like that to uh

Expose apis and extract the front end part because at the end of the day the monolith is going to go away you need to do this anyways so best start it um once you've done that the next thing you need is to introduce a proxy so what the proxy does is it makes routing decisions because at some point there will be requests that need to go to

the monolith and there will be requests that need to go to the new microservices and that's what the proxy is for when we have the proxy in the beginning all requests go to the monolith but that's about to change another thing that is important in an idea world you would like to freeze the monolith and not do any work on it while you strangle it in practice

that is not happening you can't explain this to your CPO so if new features come in really try to imp Implement them in the new architecture really try to make them your first microservice um because if you do it in a monolith you're just delaying the problem you're going to have to do this later on anyways so in this case now we want to have a recommendation

feature for storefront that is our first microservice we built that and that is routed to by the proxy but now comes the the real deal now we strangle the molth so we pick one of the features in this case the inventory take the code move it to a micros service have the proxy to the micros service and be done with it right unfortunately it's not that easy

because there are still dependencies within the code the card feature requires the code of the inventory feature same goes for the order feature and if we just remove those parts we're going to crash that's not going to work so what we need to do is we need to introduce something that is called the anti-corruption layer ACL and the job of the anti-corruption layer provide inside the code

the same interface to the dependencies of the piece we removed and know how to direct those requests to the to the new microservice VI the proxy so from the point of view of for instance the order feature nothing has changed they connect to the inventory feature that is just a stop that calls the ACL and the response comes back with a higher latency because we're now going

over the network but in terms of interface nothing has changed and that's um that's how you then make sure that you can remove bits from the code without breaking anything we introduced another challenge uh we have two data stores now as I mentioned the inventory microservice that owns the data regarded to inventory that's the principle of microservices so now we have a problem because the inventory microservice

owns the data for inventory but there might also be dependencies on on data related to inventory in the existing monolith um what we could do is we could write from the micros service to the common monolithic database but that's an anti- pattern you should avoid at L costs so the solution to this is the so-called synchronization agent and the synchronization agent has one responsibility and that is

to synchronize the data between um the microservices and the existing monolith the pattern that we apply here is called Event Source think some of you might heard of this already and every white operation that goes to the inventory microservice is written to queue an event uh bus whatever and then picked up by the synchronization agent and put back into the monolithic database once we've done that we

can continue strangling the monolith so now we pick the order Service uh remove it make the ACL call again um the order has a dependency of inv ventory previously this was a call in code you just called some functions some methods from within the code now this is an API call um this is a fundamental part of micros architecture that you now only communicate why ypi there's

no direct call to any datab base of another micros service again we would apply the synchronization agent here it's not in the in the diagram then we can continue now we can do the card micros service we apply in the same principles we do the same thing and once we've done that removed all the complexity all the functionality from the monolith um all the data resides within

the the data stores of the microservices and we finally can turn it turn this entire thing off and we arrived at the final strangle State and that is great now we have a microservice architecture uh we still have the proxy in place and that looks good and we gained a lot if we look at this from a bit of a different perspective from a more technical perspective

we now can use different Technologies we can use different programming languages uh we can use different um compute Services it's all Lambda here but this could also be containers or whatever we can use different databases that are more suited specific um specific workloads that for instance the the order service needs and that is a great thing but as I mentioned in the beginning we had to make

some tra tradeoffs so we achieved our goals where we wanted to go but what we traded off or what we got in return is that we now need to manage distributed complexity which as I said is not an easy thing to do again they have entire books been written about this and I really recommend to read those if you deal with microservice architectures they are fantastic books

and they what they do is they give you tools and design patterns that will make this much easier like patterns that have been battle tested in practice across many different architectures and proven to work and I don't want to dive too deep into this but I want to mention a few of the design patters that I consider most important for you to know about when you when

you approach such a journey of microservices so the first one is the circuit breaker and the circuit breaker is required in synchronous communication so if your apis call other apis where HTTP calls mostly that's when you need a circuit breaker because it regulates the calls between the apis because what otherwise can happen is you can have these cascading failures like microservice a calls B that called C

and if C is having a bad day suddenly you have like B not responding and a is depending on B A not responding and then you what can happen is that one microservice can bring the entire thing down that that's not what you want so use a circuit breaker pattern to to handle this timeouts this network congestion um that's that's a must have essentially another view on

a circuit breaker is a service mesh which is mostly seen in container applications it's a bit more than a circuit breaker and the idea is that you decouple the communication from the actual application logic so you have a side Cur container running next to your actual apption and the application communicates with that side Cur container and then side the side Cur container takes care of um the

communication why the network it knows why the packet needs to go maybe there needs some trap uh some throttling that needs to happen uh maybe he needs to apply some circuit breaker and that significantly increases the operational control you have over your distributed system it's mostly done for containers so if you're using containers uh service mesh is certainly something worth looking into an event driven architecture that's

often the Natural Evolution of a microservice architecture so if you come from a microservice architecture that is that you have built wi the Strangler pattern those tend to be synchronous in terms of communication in the beginning because that's just like closer to the mental model of building a monolith but over time most microservice architectures evolve to being event driven and I don't want to dive too deep

there are some great talks on this very conference on this topic but just be aware this is something that will likely happen and you should be equipped to this The Saga pattern um is important because when you have a complex system you handle transactions so that's just something that essentially every complex system does if you buy an item online you need to charge a credit card you

need to trigger the shipment and so on and so forth if you do this a monolith this is more or less a solved problem you have aset in the database you have all the tools in the programming languages to handle errors those mechanisms they mostly go away if you build a distributed system so you need to find ways to to handle this in your distributed system and

that is the Saga pattern so in The Saga pattern you define local transactions you have an overarching orchestration layer that handles this and if one of those trans trans action fails um all the local transactions get sort of reversed so that the entire transaction is also set back if you're doing this on AWS um I recommend the service called aw step functions because at the end of

the day what your building is a workflow and that is exactly what step functions is really good at modeling workflows in a cloud native way with all the control Logic for error handling and so on there are a number of predefined patterns out there that you can uh that you can reuse for your workload and this is really a fantastic service if you need to implement the

Saga pattern lastly data management we talked about this you will come at a point where you might be tempted to sort of not be disciplined anymore to just for this one feature because it needs to ship real quickly go to the database of a different service and violate the principle of no shared state do not do it if you do it once you're going to do it

twice and then you have essentially the worst of both words you have what is sometimes called a distributed monolith and that is not a pleasant place to be because that is really a painful thing to maintain really stick to the principles only communicate why a well-defined apis rest apis message cues never interact with the data that is owned by a different microservice when you have distributed data

at some point this data needs needs to be br together um if you have customers and they want to use your website or your app you need to bring all the data together and the pattern for this is called backend for front end so this is a dedicated layer in front of your microservices that knows how to get the data and just unify it and return it

to the caller and these days um graphql more less is a def Factor standard so graphql is a fantastic tool that does exactly that it solve the problem at it was developed at meta and solved the very problem at meta so really at a large scale it knows how to get data from different data sources and you can send a query where it just tell the graph

K resolver what data you want from what data source and you're going to get this back in one query uh if you want to get started with graphql on AWS I really encourage you to look into appn uh which is by far the easiest way to get started it's a serverless Services uh it's super easy to use uh the it's a it's a great tool to make

the the querying of data in a micros service architecture much easier clients there's also the the backend view so you also need to bring the data together for things like reporting auditing bi and there is another pattern for this which is called which is a really long name cqs the command query responsibility segregation pattern so I'm only going to repeat this once it's quite a mouthful and

the idea is we apply the same pattern that we did when we had the synchronization agent so we do event sourcing every change that is written to one microservice is persisted somewhere in some que often something that Kafka is used for this and then you have an event store and then you create a read data store essentially where bring all this together and that's where the name

comes from because you have your commands so the right operations at the top that's where the right goes and you have unified read operations that give you a view on the entire data store um by bringing those into the read database it's a advanced pattern but at some point if your micros service architecture is sufficiently large there is no real way around this if you want to

have um insights across data all right that brings us to the end and I want to have give you four key takeaways that I want you to take from this session the first one ask yourself why you want to do this and then only think about how you want to do this this is really important I think uh many attempts fail because they were done for the

wrong reasons understand your domains so have a clear picture of where you want to go and that doesn't mean you can't adapt on the way but start with a picture in mind where you want to end up don't make it go use proven patterns to manage the complexity you're going to have distributed complexity that is just inherent to microservices that is one of the the trade-offs you're

going to make and make sure to use established patterns to handle those that complexity and not reinvent the wheel and lastly stay disciplined the entire microservice thing that will only really work out if you stick to the principles and remain disciplined of how you build the architecture and don't try to take shortcuts that will really hurt you in the long run thank [Applause] you sorry um hi

now we have a few questions in slido if I may read it to you go ahead please so how do you make sure not to be totally depending on one supplyer for AWS how to keep supplies compete so that's something I hear quite often with customers and the general fear is when the L in and the simple answer is there's a trade-off again you need to make

if you want to stay window neutral you're not going to realize many of the the advantages that the cloud has to offer um then you're going to be stuck at the maybe the what I showed earlier the optimization stage for some companies that's a trade if they want to make but if you really want to maximize the benefits you need to commit to some degree um then

we have another one you may see it or on your screen as well are usually tightly coupled transactional and snc how do you deal with it while extracting micros service and all the this problems so this is importantly addressed by the anti-corruption layer so what the anti-corruption layer is it allows the communication to remain synchronous but it adds latency and that's something that you can't avoid you

can keep the lat ly low but there is the network call there is the marshalling of the data um that's something you need to account for but other than that going from a monolith to a synchronous microservice architecture has more or less the same mental model the just the calls just take a bit longer I would not recommend to try to go from a monolith directly to

an asynchronous architecture that way you use some event bus message broker because that is just too many things you're trying to attempt at the same time um and then again comes down to to patterns like circuit breaker managing complexity but as I said doing distributed things that is really hard and the moment you carve out one thing from the monolith it becomes a system does this answer

the question the monitor ah okay yeah that's great um hi soes separate the B for each microservice doesn't it lead to need of duplicity um there might be microservices that don't need a database but if the microservice micros by design has a certain task it needs to solve and most of the time you're going to need a data to need data for this and then you should

have a separate database what is an absolute anti- pattern is shared State because that leads to many problems down the road um so yes again it's about trade-offs but that is one of the trade-offs you're going to make separate data store for each microsof service if it needs to store somewhere a single common database between microservices an anti- pattern um there are a few reasons the most

common one is how do you update schemas for instance so imagine you have a distributed microservice architecture how do you control schema update if you think about SQL that is one of the big reasons when you have a monolith you can do that quite easily you update the schema you update the monolith you're done if you're not doing this then you lose all the advantages of microservices

because then you need to update the schema and you need to reflect that update in all the services that use the common database there are others I mentioned a book um building microservice architectures there's an entire chapter about this I think you can even read it online for free um where the author goes into great depth but that is just one of the most crucial ones I

believe uh what is your take on modulith modular monolith as a first step before going all into microservices that is a fantastic question and that is a very good pattern so as I mentioned it's a spectrum you have microservices on the one end that's the one extreme then you have monolith on the other side and there's in between and in between is a modular monolith and that

can work really well that's something you would I would encourage you if you're a startup and you have high Ambitions don't start with a microservice architecture start with a modular monolith so a modular monolith is a monolith this is that is designed in a way that it can easily be separated so you just don't write spaghetti code you don't anyways you're great developers I know that um

but don't do spaghetti code like in general write modules but have them as part of one monolith but be prepared to split it up so yes that is a first step you can take to make the the Strangling easier and and some way you're going to do this because you need to scope the code that you want to extract and that can then be also considered a

module what if monol LIF to be decomposed is full of hopeless technical death and dependency is making it complicated process maybe then a full rewrite makes sense this thing is when your code is complicated there are likely some edge cases hidden in the code that some smart developer implemented 15 years ago that are really crucial for your business because they catch this one exception where I don't

know a credit card number is a prime number just a silly example and you're not going to catch that and that's what I me if you start from scratch with all the good Ambitions but your business has like 30 40 Years of technical depth in itself you need to reflect this at some point and it's much easier to catch those edge cases when you gradually strangle this

this and you have like a reference how it is supposed to work and then you can like um do things like AB some requests go to the monolith other go to the microservice and you see if they behave the same that is really hard to do if you do a big um what is your opinion on using so architectural style instead of domain driven design for finding

finding bounding context only applying domain assign principles with stuff inside context I mean that's that that's hard to answer um it's pretty similar so can't really give a good answer on that it really it depends that's that's the typical architect answer so the architect is a great role to be because you can always say it depends if you don't want to answer a question if we want

to restructure our code based on domain design mve to micros service should we move to micros service first and only then refactor it's hard to separate those um because if you're at the place where you can just take the code and move it out of the micros of the monolith you're already at a good place you at a what's called a modular monolith that we had before

so there will be some refactoring in the process um C base should we move to M only then reflector I mean if you know the into refector and you can manage the complexity might make sense to start doing this in the monolith and refactor to a state where it makes it easier for you to to extract because if you not only change the overall architecture from monolith

to distributor but also refactor the code um that's again a lot of moving parts so if you feel you need to really refactor the code while doing the the Strangling probably do it first and make sure that the monolith keeps working and then take that refactor code out and probably the last question you assume that domain is well understood that is not always the case how do

you suggest to handle this uh yeah that's a problem if there's no one that there that understands the domain that is a bad place to be um I would say tough luck but what you can do I mean it's difficult you need to speak to the business um that's the one thing and other than that it is trial and error and the best you can do is

like raise awareness that this is going to be a painful process so you as the owner of the refactoring you need need to be transparent then you need to communicate to your stakeholders that this is really uh difficult journey and there will things will break and this is not going to be fun for everyone involved um and the less you know about the domain the harder it

is to mitigate this because then you are bound to run into those edge cases that no one is can foresee that's just a reality um try to gather as many information as possible but know that it might not be enough to avoid all the bad things that can happen scenario okay our time is up so thank you Marcus a lot thanks for having me oh thank you

and I want to remind you that Marcus may be at the ask me spot if you didn't have a chance to ask your question you can do that in person yes okay all right thanks