{"id":1038,"date":"2019-06-21T16:50:23","date_gmt":"2019-06-21T14:50:23","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1038"},"modified":"2021-03-29T17:52:17","modified_gmt":"2021-03-29T15:52:17","slug":"writing-microservices-the-right-way","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/writing-microservices-the-right-way\/","title":{"rendered":"Writing microservices, the right way."},"content":{"rendered":"
In this final article of our 3 part analysis on how to break down a Monolithic application we will exploit some insights on how a microservice can be created from an existing one, what can we do to solve problems related to legacy code with high toxicity and in general what rules can be applied to decide when to migrate to microservices. <\/span><\/p>\n Let\u2019s get started!<\/span><\/p>\n In practice when we want to create a microservice we have two development choices:\u00a0<\/span><\/p>\n At first Code porting may seems a logical solution, mainly because the Dev team has a <\/span>cognitive bias<\/b> towards its own code BUT it can conceal some critical aspects that have <\/span>high cost<\/b> and <\/span>low value<\/b>:<\/span><\/p>\n So to sum it up always verify if the code you want to reuse has <\/span>High Intellectual complexity value <\/b>and <\/span>Low Toxicity <\/b>in terms of stickiness and technical debt<\/span>: this is a good candidate<\/b> for code extraction and reuse. An example can be a complex recommendation system for a customer with a lot of interactions, personalizations, machine learning algorithms and so on.<\/span><\/p>\n Writing new code is a very good approach in the sense that enforce the Dev team and the Business team to review the core logic of the functionality they want to rewrite and thus:<\/span><\/p>\n This approach can also be beneficial in the sense that the microservice will probably <\/span>be delivered faster<\/b>. An example can be <\/span>CRUD operations<\/b> because they don\u2019t contain any intellectual properties and may depend on new technologies and frameworks.<\/span><\/p>\n After rewriting most of your application with microservices, you\u2019ll be faced with the remaining of the legacy code for which the domain knowledge is uncertain. In this case, extracting your code and also your <\/span>data from the data layer<\/b> can be difficult although we would recommend approaching this part of your infrastructure as fast as possible because decoupling your entire data layer is by far the most important part of your job in migrating towards a microservice-ecosystem.\u00a0<\/span><\/p>\n We can safely say that if your data is somehow coupled you don\u2019t have a real microservice.<\/span><\/p>\nHOW TO WRITE A MICROSERVICE<\/span><\/h2>\n
\n
CODE PORTING<\/span><\/h3>\n
\n
WRITING NEW CODE<\/span><\/h2>\n
\n
HOW TO APPROACH STICKY CODE INSIDE THE MONOLITH<\/span><\/h2>\n