loading...

re: Q: What Technologies Should I Use for Migrating a Rails Monolith to Microservices in 2020? VIEW POST

FULL DISCUSSION
 

I think you are putting too much risk (changes) on the table, and Microservices is not the right solution for all kind of projects and teams.

Analyze your business first and identify the minimum steps that you need to continue evolving.

 

I have 2 major pain points in my Rails app:

  • the UI is outdated (not responsive)
  • the configuration & deployment of the 4 different instances is a manual process

So for the UI part I am glad that I can shift this responsibility to another developer who's writing the SPA. Thus I can focus completely on the 2nd pain point.

I know a bit of Ansible and concluded, that it's not the right tool for my situation. But I'm sure that containerization is the right way. That's why my question is targeting the docker/kubernetes eco system. How much of it do I need? How much of it can I handle?

 

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

 

Yes, I agree. A lot of times there is this general pressure from management to get on with latest trends. Also writing everything as microservices does introduce more complexity in development, testing, deployment, troubleshooting and maintenance.

code of conduct - report abuse