Go from Node.js app to microservices with MONOLITHSPL/T

I’ve been working a lot with microservices in the past couple of years. It is during this time that I found how many issues can arise from putting an accent on delivery while disregarding architecture.

This is why I decided to create MONOLITHSPL/T.

I want to help businesses migrate their monolithic Node.js applications to a microservices architecture, improve the quality of their products as well as their overall delivery. My goal is to provide clear, actionable steps, to move away from poor architectural decisions made under pressure.

Through MONOLITHSPL/T, I will provide microservices migration strategies, driven only by your business goals. I will be putting all the knowledge and experience I accumulated over the past years into the service of businesses struggling with monolithic Node.js application architectures.

To get notified about the launch subscribe to the pre-launch list. The launch date is close and the list is very tight.

READMORE

In a nutshell

If you feel like reading some marketing material, head over to monolithsplit.com and enjoy. On the other hand, if you’re not that much of a reading fan, here’s the core idea behind MONOLITHSPL/T and how I plan to help businesses implement microservices out of their Node.js monolith applications.

First, we need to talk. We will have one or two Skype calls to assess your current situation and more important, your goals. The whole strategy is built around and driven by your business goals. It will not be driven by software architects, developers, class hierarchies, etc. While highly valuable, their input will only be treated as reference material, used for guidance.

The architecture of your software ecosystem should represent your organisation and should be driven by it, not the other way around.

We will also create a list of people who could have valuable input regarding the past, present and future of your business. This may involve conducting interviews with people such as the head of the sales department, your software architect or the head of IT operations.

I will also go through your current codebase as well as your architecture/software documentation. I need a clear, unbiased ponit of view, before discussing with your technical staff.

This raw information will form the basis on which to identify your core needs. It is only after this information is gathered and processed that I will create a customized strategy for you to use in your microservices migration.

I want to make sure you are on track and making the best out of the strategy. I expect you and your team to have questions and need clarification and this is why I will follow up via email, periodically. The follow-up process consists of an email I will send out to you once every two weeks, for a period of up to six months.

For businesses requiring closer guidance I can also act as a sounding board. I will make myself available to a set of designated people who can contact me directly and I will grant them access to my knowledge and experience.

Everybody wins!

Yes, you and your business win! Remember that mobile app you postponed because it was too complicated to reuse your current data handling logic? Did you need to code extra functionality to pull the data independently, for the mobile app?

With microservices that problem doesn’t exist!

You can mix and match services and quickly experiment with any new business idea that comes to mind! The fun part is that the impact (blast radius) is close to none. If the experiment fails, there’s no harm done. It’s as simple as updating a load balancer configuration and switching off a feature flag.

Some might say you migrate from monolith problems to microservices problems.

I agree, but in the long run, microservices are easier to maintain than monoliths. A monolith’s increased complexity puts a lot of pressure on the team’s morale also, not only on their capacity to deliver. For each risk others bring up when talking about microservices, there’s also a 10-fold benefit.

Why not have problems that help your team grow and bond? Problems they actually want to solve, instead of dragging them from one release to the next!

There’s a nunce to this, though. Monoliths are not inherently bad. A monolith is just a different approach to solving a specific problem. Learn more about why both monoliths and microservices can be a bad choice when you don’t understand the problem.

t sdsdfslkj not innotinhe Photo credits: Steve Jurvetson — Beer Keg Blastoff!

P.S. In case you were wondering what is on the tip of the rocket, it’s a doughnut! 😋