{"id":1067,"date":"2019-11-15T14:33:27","date_gmt":"2019-11-15T13:33:27","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1067"},"modified":"2021-03-24T17:28:13","modified_gmt":"2021-03-24T16:28:13","slug":"turning-monoliths-into-microservices-tips-and-tricks-2","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/turning-monoliths-into-microservices-tips-and-tricks-2\/","title":{"rendered":"Turning monoliths into microservices: tips and tricks"},"content":{"rendered":"
In the first article<\/a> of our 3 part journey on how to break down a Monolithic application we have started talking about the advantages of a distributed application composed of microservices over a monolithic one. In this second part, we will start approaching techniques and tips to help you overcome the migration process in a more secure and aware way<\/span><\/p>\n This is by far the most important step as it states clearly if <\/span>your knowledge<\/b> of your logic\u2019s domain is complete. In fact, one possible way to find which part of your application can be converted to a microservice is to check if you have a complete understanding of its domain, which means that it will be easier for your dev team to <\/span>isolate and migrate<\/b> the logic.<\/span><\/p>\n Understanding the domain of a feature also means that, probably, it\u2019s <\/span>entanglement<\/b> with the rest of the application is <\/span>very low<\/b>, ideally null, thus facilitating the separation from the main application.<\/span><\/p>\n Knowing your domain means that you can <\/span>define with clarity<\/b> which services are <\/span>vertical to the application<\/b>, or in other words, which services are most important and <\/span>target specific needs <\/b>of a user base (thus defining the goal of your application) or are strategic for your company.<\/span><\/p>\n Vertical services are by no means made of easy code and can be very big, but as said before, we are not referring to microservices by the quantity of code contained, but by <\/span>definition of scopes<\/b> and <\/span>context boundaries<\/b>.<\/span><\/p>\n Come to this point is important to clearly define our <\/span>technological target<\/b>, in the sense that we want to understand what kind of <\/span>platform<\/b> or <\/span>framework<\/b> we want to use for development and procedures of CD\/CI (e.g Serverless Framework and AWS Lambda as a development environment) and what kind of programming language is best suited for migrating that precise part of your business logic.\u00a0<\/span><\/p>\n Having clear this part is very crucial as it helps thinking about the <\/span>feasibility of that particular migration<\/b>. Also, we have to understand that, even if migrating to microservices is, in general, a good behavior, it doesn\u2019t mean that for your particular application, or part of it, it\u2019s a good choice, but we will analyze this aspect later.<\/span><\/p>\n In general, during the brainstorming involved in this step, we need to verify the costs in terms of <\/span>code migration<\/b> and <\/span>infrastructure migration <\/b>and the<\/span> strategic value <\/b>compared to<\/span> developing new features<\/b>.<\/span><\/p>\n Up to this point we have talked about preparations, let\u2019s start to explain how to effectively break our monolithic infrastructure and what characteristics a microservice must have to be considered one once it has been extracted successfully.<\/span><\/p>\n When we think about going from a monolithic approach to a microservice ecosystem we can think of two possible choices: a) to rewrite your code from scratch using the new paradigm or b) to migrate from the old one.<\/span><\/p>\n Starting fresh on rewriting the entire application in one go is generally not a good choice because:<\/span><\/p>\n So the best option is, as we have in a way discussed up to this point, to extract and convert the application <\/span>step by step<\/b>.\u00a0<\/span><\/p>\n This approach is called <\/span>Strangler Pattern<\/b>, a way <\/span>to <\/span>incrementally transform your monolithic application into microservices by replacing functionalities one at a time<\/b>. Once the new functionality is coded, the old component is <\/span>strangled<\/b>, substituted and finally <\/span>decommissioned<\/b> altogether.<\/span><\/p>\n <\/p>\n This approach is very good for a number of reasons:<\/span><\/p>\n To implement the Strangler Pattern, you can follow three steps: <\/span>Transform<\/b>, <\/span>Coexist <\/b>(coexistence is necessary for testing the new feature with part of the user base), and <\/span>Eliminate<\/b>.<\/span><\/p>\n Let\u2019s just spend two words on the co-exist part because it requires a little thinking as it requires your team to maintain both codebases and the relative user support for some time until the old component is put out of order, so always plan ahead to avoid bad surprises.<\/span><\/p>\n <\/p>\n To start extracting elements of your business logic, especially if you are new to this pattern, choose those that have:<\/span><\/p>\n Also:<\/span><\/p>\n Finally check for part of code that can be easily reused in other projects, which means that it is by its own nature <\/span>atomic <\/b>and<\/span> reusable.<\/b><\/p>\n There are tools that can help in the splitting decision, such as those for <\/span>Social code analysis<\/b> which enriches our understanding of the code quality by overlaying a developer’s behavior with the <\/span>structural analysis of the code<\/b>.\u00a0<\/span><\/p>\nCLEARLY DEFINE YOUR BUSINESS LOGIC\u2019S DOMAIN<\/span><\/h2>\n
DEFINE YOUR TECHNOLOGICAL TARGET<\/span><\/h2>\n
WHERE TO START TO BREAK A MONOLITH: THE STRANGLER PATTERN<\/span><\/h2>\n
\n
\n
\n
\n