[noenzyme]

Experience Report: We just went through the decision to build as a monolith or via microservices. The original decision was to go with microservices as the rest of our systems are designed that way.

As the time pressure mounted the microservices that communicated naturally combined. The driving force was just the cycle time. Testing and deploying microservices took longer. Mind you, not minutes vs hours. Just a few extra minutes makes a difference if you do it often enough.

One decision that give us confidence we will be able to split the system back out again was to use the stuartsierra/component library. By using DI we can be fairly confident we don't build dependencies we aren't aware of. We simply substitute a client that talks over the network in for the one that does the calculation locally.

We are still in the stabilization zone but have already started to split out services. Code velocity is the driving force for the splitting. Certain components are well understood and fairly robust other still young and poorly understood. We want to limit our ability to accidentally screw up something we have already gotten right. So the components that haven't changed in a while get spun out.

[fmstephe]

It must be a sign that I am getting old, but your story of considered pragmatic compromise warms my heart. :)

[sinzone]

You may want to check KONG as open-source solution to manage microservices so you don't re-build common functionalities across the stack.

Repo: http://github.com/mashape/kong