{"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

CLEARLY DEFINE YOUR BUSINESS LOGIC\u2019S DOMAIN<\/span><\/h2>\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

DEFINE YOUR TECHNOLOGICAL TARGET<\/span><\/h2>\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

WHERE TO START TO BREAK A MONOLITH: THE STRANGLER PATTERN<\/span><\/h2>\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