DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Software Design and Architecture
  3. Microservices
  4. On Monoliths, Microservices and Critical Thinking

On Monoliths, Microservices and Critical Thinking

Martin Fowler discusses the microservice-oriented trend, and the history of the movement associated with architecture at scale vs. monolithic applications.

Sander Mak user avatar by
Sander Mak
·
Jun. 10, 15 · Tutorial
Like (3)
Save
Tweet
Share
8.47K Views

Join the DZone community and get the full member experience.

Join For Free

something very interesting happened last week. at first i wasn't sure whether it was a misguided attempt at humor. sure enough, twitter timelines switched en masse from advocating microservices to glorifying monoliths. what a strange world we live in.

microservices

microservices burst onto the conference scene, blogosphere and other echo-chambers with blunt force in the past years. like all movements, the microservices movement offers some good points amongst the propaganda. we are dealing with increasingly complex problems at an increasingly large scale. it's good to pause and reflect on these challenges.

except, that's not what happens. instead, microservices frameworks, microservices books and other microservices paraphernalia convert large swathes of developers into 'early adopters' of the golden age. vendors create microservices platforms, including some sweet lock-in of course. suddenly we're counting lines of code like a weightwatcher counts calories. must. not. exceed. <insert arbitrary figure here>. it's unhealthy.

monoliths

then, pendulum swings back. martin fowler publishes his monolithfirst post. and the people rejoice. it's ok to officially push back against the cool kids again. now you're scolded for ever starting from scratch with a service oriented architecture. yagni, silly! and if you do need it, just chop up your monolith and season to taste. easy, right?

as you might have guessed by now, this post is not about technical arguments either for or against monoliths and microservices. if you're looking for that, read fowler's post. then, read stefan tilkov's counterpoint (graciously hosted on fowler's site as well). i'm much more interested in what this all means for our profession. what does it mean if public software engineering opinion flips 360 degrees in a matter of weeks? it's too easy to chalk it all up to people needing authority figures. yes, i know: not everybody was all over microservices. but you have to admit there's something fundamentally unsound going on here.

the art of problem solving

software development (and by extension, software architecture) is often characterised as a form of problem solving. there's a problem (requirements, input), and we need to create a solution (software, output). it's not wrong per se, but framing it like this primes your thinking in a dangerous way. if there's a problem, there must be an exact solution, right?

solution space

however, we all know that there's no single perfect solution. there's a vast solution space and it is our task to navigate it and arrive at a reasonable location in this space. all hypes like microservices are doing, is prematurely pruning our solution space. without knowing anything about the problem. that's wrong. we all know it. still, the solution space is often so enormous, it is tempting to think "this time it's different" when a new voice of (apparent) reason appears. hopefully, the monolith vs. microservices farce brings us back to reality. critical thinking cannot be done for you.

risk management

instead of problem solving, a much better characterisation of software architecture is risk management. there are trade-offs in every dimension of the solution space. a software architect must quantify, disqualify and hedge the risks. this is a tough job. there's no substitute for experience here. books like 'the architecture of open-source applications' , containing case-studies, are much more valuable than books on architecture patterns in that sense. managing risks means building up your architecture from first principles. not arriving at some architecture through elimination of fashionable trends.

architectural patterns are tools for navigating the solution space we must explore. ultimately, the problem we're solving dictates which direction to go. not our philosophical preference for certain solutions, unless it is based on similar problems we have solved before. if technical debt is like that irresistible car loan - costly but typically harmless -, then choosing the wrong architecture is more like a sub-prime mortgage. hey, everybody does it. and when you are left homeless, there's nothing else to blame than your own critical thinking skills.


microservice Critical thinking Software development Architecture

Published at DZone with permission of Sander Mak, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Choosing the Best Cloud Provider for Hosting DevOps Tools
  • The Role of Data Governance in Data Strategy: Part II
  • Why Does DevOps Recommend Shift-Left Testing Principles?
  • How to Develop a Portrait Retouching Function

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: