Strangler pattern discusses a good migration path and I'm going through this process right now so we should compare notes sometime.
A few options suggested by Microservices authors:
In the existing monolith separate out the UI layer of your web app from the API layer. This fits in nicely with your wish to offload to another dev. Rails I'm unfamiliar with but sounds much like sails.js framework I use, therefore going api first on the server / UI split is a good move. This will allow you to discover the boundaries and potential scope of services with little disruption. The aim of the game here is to peel back the layers of onion to expose a core set of services, you would eventually end up taking this step but removing lockstep deployments early can give some early benefits to the mindset.
Create services for new features to stem the flow of legacy being built into the monolith
Consider taking any low hanging fruit features which exist today in the monolith which can be separated out into a service, to reduce complexity you can still use your existing dB as the data store. Infact on this point, to reduce stress and complexity it seems sensible to work through the tiers making changes until you hit the data storage layer last. I prefer this technique as the last thing I need to battle is data consistency and accuracy on a new service when I can use existing data models/tables to verify behaviours.
Ive seen many advocate breaking services out for things which change the most. However I have some quite critical components which I don't wish to disrupt whilst I'm still in discovery phase with Microservices so I've infact picked out 3 initial candidates which have changed maybe once a year compared to the weekly and daily services in my main app. This allows me to produce a well defined service knowing I don't have a change hitting amongst other deployments which just leads to tight deadlines and undue stress
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Strangler pattern discusses a good migration path and I'm going through this process right now so we should compare notes sometime.
A few options suggested by Microservices authors:
In the existing monolith separate out the UI layer of your web app from the API layer. This fits in nicely with your wish to offload to another dev. Rails I'm unfamiliar with but sounds much like sails.js framework I use, therefore going api first on the server / UI split is a good move. This will allow you to discover the boundaries and potential scope of services with little disruption. The aim of the game here is to peel back the layers of onion to expose a core set of services, you would eventually end up taking this step but removing lockstep deployments early can give some early benefits to the mindset.
Create services for new features to stem the flow of legacy being built into the monolith
Consider taking any low hanging fruit features which exist today in the monolith which can be separated out into a service, to reduce complexity you can still use your existing dB as the data store. Infact on this point, to reduce stress and complexity it seems sensible to work through the tiers making changes until you hit the data storage layer last. I prefer this technique as the last thing I need to battle is data consistency and accuracy on a new service when I can use existing data models/tables to verify behaviours.
Ive seen many advocate breaking services out for things which change the most. However I have some quite critical components which I don't wish to disrupt whilst I'm still in discovery phase with Microservices so I've infact picked out 3 initial candidates which have changed maybe once a year compared to the weekly and daily services in my main app. This allows me to produce a well defined service knowing I don't have a change hitting amongst other deployments which just leads to tight deadlines and undue stress