Is Microservices the future of all architectures? Is it "the" silver bullet for any company with a business critical IT?

      We all start there, with the famous Monolith Architecture. Why? Because it’s easy, it’s fast, it suits our needs just fine. Remember the first rule when distributing your systems – “Do NOT distribute your systems”, until you need it, then “Do NOT distribute your systems”, unless you really really really need it.
So the Monolith is the perfect start for any start-up and can suit your need for a very long time, potentially forever.
 

So why bother understanding what Microservices is all about?

There might come a day, when you feel you grow out of your Monolith. The size of your organization has grown quite a lot, your dev department is getting bigger, perhaps dev centers separated geographically. All you know is that growth is the only thing that will stay stable for the near future. Sooner or later I think you will start to see the typical signs of you outgrowing your Monolith (if not – congratulations, please tell me and the world how you did it);
You start to realize that small changes within your intercoupled Monolith impact areas you didn’t think of, leading to costly incidents. Things are getting complex due to all dependencies. KISS becomes harder. 

      You realize you want to, you need to be agile, but deployment is hindering you as it takes too long time and too much effort to deploy. You can’t deploy the small parts you updated in isolation so you have to do the whole thing.

      You realize there’s legacy parts of your system you don’t dare to touch, no one does, so you build around.
Developing new features (business or tech) will be more and more expensive since the only compensation for you systems growing complexity is increased quality. And we all know how expensive increased quality is, both for dev in itself but also the additional QA work required.

      Eventually things will in a larger extent break and you will spend more and more time on failure demand, cleaning up the mess, than on value demand, developing your business. By now your REAL problems are likely to start show and you will probably start see the frustration around. Dev will most likely get a hit on her self-confidence, the pressure from the organization will grow and the joy you used to have will be jeopardized. From the business perspective one start see things taking longer time and Business people will have to fight more and more to get their things into the three-months-roadmap. They will most likely start interfering into dev work, dev processes and dev decisions like never before. Things like mistrust, control, processes will start becoming the words on peoples lips. 

      Sadly this will often lead to growing bureaucracy and hierarchy; your organization will most likely become more top-driven and politics and individualism become a fact. 
What it does to your previously so lively and joyful dev teams? I think it will have a great impact on the inspiration, energy and commitment of your dev teams – hurting the innovation and engagement. Unfortunately it will risk your most driven tech people, seeking new adventures.
 In all together you start to realize that your baby that used to be so small and sweet, over the years has grown and become a monster, something like the famous “big ball of mud”

So what to do, what’s the cure? Which architectural solution to go for?

It all depends on what you want to achieve and that’s where you need to start. Telling by the symptoms above I assume what you want to achieve, I would, is for your dev department to continue its joyful and innovation-driven journey together with the rest of the organization and business. Then I believe what you need the most are;

• Independent scalability
• Independent failures
• Independent deployment
  

These three qualities will provide wonderful things since it pulls out dependencies and by that removes complexity. Dev teams can again focus in isolated areas; scale, handle quality, handle failures and deploy independently from all other teams.
So which architectural solution to go for? Use anyone as long as you fulfill the three qualities.

What about Microservices, could that be the solution for my organisation?

Yes, Microservices will definetly help you support the three qualities; Independent scalability; Independent failures; Independent deployment. But Microservices will as well support you creating a new “big ball of mud”. 
To me Microservices is a mindset more than anything else. Initially, being new to Microservices, you will make mistakes, no question about it, but if you’re eager to success, if you use your architect experience well in combination with a great portion of common sense and continuously seek new competence and experience from others – you have a promising and exciting future in front of you, and full of hard work.
 The main fundamental capabilities of Microservices and the resons to go for Microservices according to me are;

• The super qualities - support of the three qualities that are so crucial for successful long-term business critical IT development; Independent scalability, Independent failures and Independet deployment.
• Burn it to the ground (including your darlings), over and over again – to me one of the most important and valuable mindset of Microservices is to avoid making anything too big or beloved to mentally be prepared to burn it to the ground, at any time.
• Remember the old scary legacy code in the Monolith that no one dare to touch but would build around? In the world of Microservices just burn it to the ground and rebuild it.
• In the Monolith when introducing a new feature you tend to bring in the generic perspective too early, just in case because you know the code will stay around. In the world of Microservices you're permitted to have a much more healthy mindset; don’t bring in the generic perspective (that will add complexity and extra code to maintain, ie cost) until you really need it. When you really need it, you have the option to expand an existing Microservice or to burn it to the ground and rebuild.
• In our agile world the only thing we know for sure is that things will change. In the world of Microservices you can really embrace change. When the basic requirement change too much we all know it’s better and more cost effective to rebuild from a clean slate but in the Monolith you don't always get that option, it's too risky and costly. In the world of Microservices - burn to the ground and rebuild!
• New to Microservices? Of course your services and structure will suck initially. A year later you and your organization will know so much more. Burn to the ground and rebuild!
• Just knowing your Microservice can be burned to the ground and rebuilt makes you a better developer and architect. You may focus on what is important then and there. You don’t have to spend too much time weighing pros and cons back and forth regarding patterns, frameworks and tools. In the Monolith you tend to build with high quality all the time, in your Microservice landscape you don’t have to, depending of what you need to achieve.
• A single Microservice is the perfect (in theory) container of coherent logic. An isolated component or system doing one thing and that thing very well.

• Polyglot – Microservices support polyglot where any team (in theory) can choose the language, architecture, protocol, tools, frameworks of preference. A beautiful way of supporting the innovation and creativity of your dev teams and the best setup for any given situation and challenge can be used. The teams can themselves take full responsibility.

Last words for now…

Yes, Microsoft provides great powers and used right it could be the answer for many companies, which I see already looking at our (Netlight’s) clients.
In the post, however, we haven’t talked that much about the pitfalls, which of course are many (spared for a later post, perhaps). But we should all understand that transforming your Monolith into Microservices means an enormous amount of work and something your entire organization must be involved and committed to. And be careful, designing your Microservices too small, will just move your current complexity into your integration layer. Designing them too big will divide your huge Monolith into a couple of smaller ones, still Monoliths. There is no such thing as the correct size of a Microservice, don’t believe anyone saying there is, and of course the number of lines of code is a very bad metric. What I like is the mindset that any of your Microservices should be rebuildable in roughly a month of time. Then you will still be able to burn it to the ground and rebuild when its time has come. At the speed technology, knowledge and organisations develops today, after 2-5 years I bet the majority of your complete Microservice landscape will have been rewritten. That’s healthy evolution to keep you a competitive player and a healthy company. 

What's your experience of Microservices and/or Microservice Transformations?

 Folllow me on twitter: mandus_engman