So..will micro services live up to the hype they are receiving?
Yes..probably..but they are far from “free” and there are important things to be aware of before you start down this particular road…
Micro services seem to be “on the rise” so before we get to the “peak of inflated expectations” let me jump in with some real world experience.
We began implementing H2, a fully fledged event driven micro services platform, at Hailo way back in June 2013 so I guess we were relatively early adopters. It has recently been open sourced at https://github.com/hailocab/h2
What is new about micro services?
“Micro services” is our latest attempt to take away all the peripheral overhead from writing software and allow developers to concentrate purely on new business impacting functionality when they write software.
By creating sets (100-200) of small, loosely-coupled, simple, reusable software components software should be quicker to write, less fragile, and easier to test and change.
Sounds great..what is the catch?
All the communication/consistency/coherency overhead that gets taken away from the micro services has to go somewhere..and it goes into your micro services platform.
Learning one is..
When adopting micro services don’t under-estimate the capabilities of the platform you will need. You will need more DevOps, automation and tooling than you expect to.
When we started building H2, our micro services platform, we pretty much had to build everything from scratch. These days a lot of the work around service discovery, service binding and general management can be provided by SaaS providers like ww.iron.io
Learning two is..
Don’t reinvent the wheel. Look to use open source software and micro services SaaS providers to save yourself time and money.
When we wrote our micro services our war cry was that each service “should do one thing and do it well”. That worked pretty well but don’t over do it. Hailo has more than 200 micro services now and maybe it’s too many. You have to find the right balance between maximising reuse and minimising dependency.
Learning three is..
Don’t be too purist. Start with fat “macro” services and only decompose them when experience tells you it will make things better.
As our platform matured we also learnt a lot about the general housekeeping processes you will need to perform when running a micro services platform. Feidhlim O’Neill wrote a great blog post about it here.
So would Holden Caulfield be right if he thought micro services were phoney?
No. They really can help you create an architecture that is very quick to develop on, resilient, performant and cost effective to run.
They aren’t “free” though..if you learn from other people who have already done it, leverage open source and SaaS whenever you can, and go into it with your eyes open you’ll definitely prove him wrong.
Contact gro.team here for a discreet, “no strings”, chat if you’re thinking of using micro services..we’d love to get involved.