Microservice Re-architecture Part 1: A New Adventure

Tags: microservices

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!

Going Micro

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!

Our technology stack is predominantly Asp.Net C# MVC web app code with javascript, React, and Angular on the front end. MSSQL is our database; stored procedures and ADO.Net comprise the data access layer. RabbitMQ is used extensively. Windows services are consuming the queues. We also use Redis as a cache and MongoDB for some redundant storage.

Why Microservices

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!

Technology Flexibility
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!

Easier Deployments
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.

Faster Compilations 
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.

Independent Scaling
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!

System Resilience
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!

No Comments

Add a Comment