• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Paul Clapham
  • Rob Spoor
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Carey Brown

Convert monolithic app to microservices

Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In our company we have complex java monolithic applications, which are the guidelines and the recommendations to follow in order to decide if it makes sense to migrate each application?  What do you think are (if exist) architectural patterns that can be leveraged to build microservices implementation strategy? Do you think there are specific area where the migration can be more complicated?

Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Takaya,

This is a question I get a lot.  The trick is not to bite off big pieces at first.   A few thoughts.

1.  Look for natural boundaries in your data model and strong relationships between the entities in your data model.  Microservices tend to follow the natural layout out of data entities.
2.  Pay attention to granularity.  Its better to start with a coarser grained service that does too much and refactor then it is to have to consolidate services.  
3.  Make sure your microservices do not just become simple CRUD services.  Your services should have business logic in them and if you find yourself with very simple CRUD services your too fine-grained in your approach.
4.  Use the URL to express relationships between data.  For example if you have a route /customers/{customer-id}/addresses/{address-id} you naturally start defining a natural vocabulary.   It also gives you a way of migrating your services.  So for instance, you
    might have customer information and address information under the same data model that your service is going to talk to.  By masking the data with a URL you can always refactor your address data object into a separate microservice (if it warrants it), while
    having the original URL simply forward the request to the address service.
5.  I personally like to use a version number for my services right in the URL.  It makes it very visible on invoking the service and if you do make a breaking change between versions, you can still allow clients to call the old routes until they have successfully migrated.
6.  I mentioned there is Microservices pattern book in the works at Manning by Chris Richardson.  I have gotten a early version of the book.  It is a great book and goes into far more design patterns then I can cover here.

    Bookmark Topic Watch Topic
  • New Topic