So I'm off on a new coding adventure! I've left the stuffed shirt world of finance for the flip flops and shorts world of online marketing. It’s a homecoming for me as I've worked in this field for a number of years before and have always enjoyed the challenges it presented. My current focus is a re-architecture of our existing system. Microservices!
My new position is with Centerfield Media, a growing, successful company specializing in search marketing. Our codebase is a big old monolith and were looking to break up that beast. Microservices is the approach!
I'm fired up to be working on a building a microservices architecture! We are seeking most of the wonderful well known benefits of a microservice approach: technology flexibility, easier deployments, faster compilations, independent scaling, system resilience, and ease of service replacement.
The Goals In Depth
Why do we want to do all this again? Its seems risky to split everything and go over the network for lots of stuff, so let's discuss a bit more about why.
In a microservices architecture, each business domain has its own independent service to handle its business needs. Each service is in a separate github repository. Each has its own independent database. Each is deployed independently. Each is tested independently. Each communicates over http (or other standard mechanism.) Each piece of the system is autonomous! That means it is independent! A lone wolf!
If each piece of the system is autonomous, then the whole system doesn’t really have to use the same technology does it? Is NodeJS the right tool? Use it! Is MongoDB the best database for your task? Use it! Developers will be happy because they can play around with new stuff and actually have the flexibility use it if it's appropriate.
Ease of Service Replacement
What if your technology choice turns out to be a disaster? Behold! Since a microsystem is limited in scope and small, it's much less daunting a task to actually replace the thing. And it shouldn't have any effect on the rest of the system!
Having smaller independent services means smaller independent deployments, usually. As long as you don’t change a service contract. Easier deployments should lead to more frequent deployments and faster response to change, quicker squashing of bugs and, streamlined development of new features.
A big hulking monolith for us, means a hulking, plodding .Net solution and long compilation times. The more you develop, the longer compilation takes. Microservices can be split into smaller solutions for faster compilations and faster development.
If one of your lone wolf microservices is getting stretched, you can put it on its own server, autoscale it separately, or do any other scaling technique you like independent of the other services. Let the wolf run wild!
Ideally microservices allow you to create circuit breakers in between the services. So, if one services is lagging, you stop sending it traffic and fail fast. Rather than let that misbehaving service drag everything down, you open the circuit breaker, handle the problem gracefully, then close the breaker and send it traffic when it's being a good service again.
This is just the beginning of my microservices adventure. This post is the first in a series - if I don't get too lazy. I'd like to document our journey to Microservice Shangri La. It's going to be magical, heart breaking, and glorious!