Would Holden Caulfield Think Micro Services are Phoney?

Would Holden Caulfield Think Micro Services are Phoney?

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.

The best ways to utilise Agile

The best ways to utilise Agile

I’ve worked with a couple of companies that are taking very different approaches to “Agile” recently and it has caused me to pause and reflect on what the best ways to utilise Agile might be.

One company is following all the Agile Scrum strictures and processes to the letter (with an almost religious fervour) and the other thinks it’s doing “Agile” even though it’s hard to identify a single “Agile” artefact or ritual there.
They would both consider what they are doing as successful so neither of them are “wrong” ..but which one is “better”?
On reflection I think the best approach to agile crucially depends on the culture/environment it exists within.
The focus needs to be on the outcomes Agile is designed to achieve, and as as much or as little formal structures as necessary should be implemented to achieve them.
The company taking a more formal approach has quite a “traditional” company culture and obviously feels more comfortable using a “methodology” that can be described, taught, learnt and read about.
The other company has a much less formal company culture and implementing very strict processes around Agile would be very counter-cultural.
At the end of the day both approaches achieve the same things though…
– The production of working software is the goal and success measure.
– The sponsors and software developers think of themselves as one team and frequently communicate and collaborate.
– They don’t fight change..they see it as an opportunity to further optimise.
So..there is no right or wrong way of doing “Agile”.
Focus on the outcomes or “What”..if they are not what you want them to be then have a look at whether a different approach to the “How” would be better.
Rorie Devine is an Interim CTO and Growth Hacker for gro.team. Give them a shout if you need someone exceptional parachuted into your team on an interim basis to help make you and them successful.