CODEWITHSUNDEEP
migrationjhipstermicroservices
ValerioZ
ValerioZ

Reputation: 31

jhipster 3 Migrate from monolithic to microservices

Currently I've a JHipster 3.3 monolithic application and I would like to migrate to microservices architecture. I've already created the registry, the gateway and the uaa service. Now I need to migrate the core business of my application into a microservice. Is there a facility to perform it? Can I make it automatically?

Upvotes: 3

Views: 1621

Answers (2)

duderoot
duderoot

Reputation: 987

For start I want also to subscribe to the last part of the answer of Gaël:

think about why you're migrating?

Personally I am at the moment in a migration process. I start in 2015 a JHipster monolith app (at that time that was the only option :) ) which I still develop and add new features. For my monolith I decide to migrate to microservice because we gone increase the team and want to go with a DDD in the future. I must admit that there is some overhead at the begin and the learning curve is quite steep but in the end the results are very rewarding especially if you believe in CI (y)

This is how I migrate my monolith:

  1. be sure that you have all your sources commited and sync with your VSC (I use git as DVCS)
  2. without any changes just run the jhipster generator and overwrite all the old sources
  3. make a git diff to have an overview of the files that are generated from jhipster and which you have modified
    1. if you have not changed the format of the files that jhipster generates it should be just some files in webapp folder and configuration file
    2. if you have differences only because of formatting I will recommend to check the code and then update your base code of your monolith app
    3. the target is to have a few as possible differences when regenerating the the monolith app with the jhipster generator (is better to have fewer files to check when migrating to microservices)
  4. at this moment I imply that you are on clean workspace (i.e. all your changes are sync with the VCS) and if you will run a yo jhipster you will have as few as possible file to recheck manually
  5. in the root folder of the app there is a .yo-rc.json file
    1. in that file you should change the applicationType from monolith to getaway and authenticationType from what you have to jwt e.g.

.yo-rc.json

"jhipsterVersion": "3.5.1",
"serverPort": "8080",
"applicationType": "gateway",
"jhiPrefix": "jhi",
  1. after merging the new generated files you should have now the gateway of the microservice (it can be that you need to delete some classes depending on which authenticationType your monolith use to have)
    1. personally I am working now on moving some of the responsibilities(all the staff that the old monolith did) which exist in the gateway to migrate to sand alone microservices
    2. the migration of the services mentioned in 6.1 is something that goes parallel with adding new features to the app and those will be added as new microservices

My recommendation is to go in small steps/increments and it will be nice if you have a CI so that you can have asap also a feedback about your migration ;)

Good luck. Cheers, duderoot

Upvotes: 3

Gaël Marziou
Gaël Marziou

Reputation: 16284

You could either convert your monolith into a service, or re-generate it from your entity definitions.

First approach requires a good understanding about Spring Cloud, you'd start by annotating your app with @EnableEurekaClient, add missing depdendencies on Spring cloud to your pom.xml, add missing properties to your application*.yml, create bootstrap*-yml files. Then you would move your client part to your gateway. This is not easy especially if you're new to spring cloud.

Second approach requires you to generate a microservices app with same options as your monolith, then copy to it your .jhipster folder which contains your entity definitions and re-generate them running yo jhipster:entity <entityName> for each entity in same order as you created them initially and then generate htem also on gateway for generating the client part.

You should also take time to think about why you're migrating, if you turn your monolith app into a single service then it might be a bad idea as you'll only add complexity, it makes sense only if you are planning to add more services and/or split your monolith into several services. There is a good free ebook and video at O'Reilly: "Microservices AntiPatterns and Pitfalls"

Upvotes: 4

Related Questions