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..."
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...
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...
RSS Feed
