Speed, Agility, Resilience
Trusted Experts in Microservices, Cloud Native & Chaos Engineering
  • Home
  • EBooks
  • Contact Us
  • Consultancy
    • One-to-One Online Consultancy
    • Onsite Consultancy
  • Training
    • One-to-One Online Training
    • Building Reliable Systems
    • Building Antifragile Systems with Microservices Course
    • Fast Track to Cloud Native Java
    • Fast Track to Applying DDD for Effective Microservices
    • Fast Track to Running Production Microservices
    • Fast Track to Chaos Engineering
    • Autumn of Cloud Native
  • Speaking
    • Schedule
    • Slides and Videos
    • Brown Bag Events
  • Blog
  • FAQ
  • Client Feedback
  • Gallery
  • (Print) Books
  • Essais

Confessions of a former Monolith-aholic

2/10/2016

0 Comments

 
by Russ Miles, Wednesday 10th February, 2016
It's a dimly-lit setting. Stress fills the air. I walk into the comfortable anteroom of a church for my first meeting with my soon-to-be-fellow addicts...

As I sit down with a luke-warm cup of coffee, the opening rite begins:

"My name is CORBA and I was a great idea, with poor execution..."

"My name is the Monolith, and I seemed a great idea for domain discovery..."

"My name is Russ Miles and I used to promote the Monolith-first approach..."

Welcome to "Architectures Anonymous"

I have learned so much in the last year. Working on real projects I was a consultant all over the planet for the lovely folks at my company, Simplicity Itself, and now I'm a reformed Consultant, working on something new. More on that soon.

This post is inspired by this great article from a while back by Stefan Tilkov. Stefan puts it to us to:

"think about the subsystems you build, and build them as independently of each other as possible"

In other words, think about small, independent services (Microservices) early. Going for microservices first, rather than building a monolith.

So why have I in the past been much more hesitant to go in this direction? Why do I need to confess that I too hedged my bets and though that the monolith-first approach was the better way? I'd be the first to admit that many of these rules are entirely context (and that includes the people and skills, not just the domain!) dependent.

My take, and those of some great people like Sam Newman and Martin Fowler, was to recommend building a better monolith first (I use my Life Preserver process and tool to do this visually), so that you are ready for the options of microservices but you can still work speedily on the monolith as you are in an intense period of discovery at the beginning of a product's life.

And there lies the reason for my change of heart. It was an argument based on Speed.

The implication, and the evidence I'd seen until recently, was that while you were in the discovery phase of a product, when you were researching and developing the core domain itself, then a team hacking away on a monolith would be faster. It seemed to make sense, and I even conducted an experiment that, in a limited way, provided it.

More experiments have come and gone though, and I can say now that it is not easier to discover and develop a software as monolith, at least it shouldn't be easier...

If it were easier and simpler to create smaller, independently evolving microservices then we could be at least equally as fast as discovery of the domain as a monolithic approach. In fact, with the isolation it becomes possible for many people to work on the same discovery process and not step on each others toes, so in all likelihood we could be faster!

The problem is that it is not currently simple and easy to develop with microservices. It's painful. 

But that is changing.

I've seen that as the inertia of developing microservices-based systems using the emerging best-practice design patterns and tools that I talk about, so the approach becomes better and better suited to the green-field, microservices-first approach.

With better tools and understanding, the microservices-based approach will not be slower at domain discovery, it will likely be faster.

I think the industry is slightly in mourning for the monolith. There's a real chance we'll look back at it in 10 years and say "wasn't is simpler in the old days...". Of course it wasn't, but time does have a way of increasing the tint on rose-tinted goggles...​​
Click here to read "Microservices - Designing for Change & Speed"
0 Comments



Leave a Reply.

    Musings on software development

    Archives

    September 2017
    June 2017
    November 2016
    September 2016
    May 2016
    February 2016
    September 2015
    August 2015
    June 2015
    March 2015
    January 2015
    December 2014
    November 2014
    October 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    December 2013
    August 2013

    Categories

    All
    Announcements
    Antifragile
    Books
    Innovation
    Life Preserver
    Microservices
    Philosophy
    Psychology
    Reviews
    Software

    RSS Feed

Products

EBooks
​(Print) Books
Consultancy
Training
​
Speaking

Company

Essais
FAQ
Client feedback
Gallery

Support

Contact
Picture
© COPYRIGHT 2018. ALL RIGHTS RESERVED.


Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.