Master
ThoughtWorks
Menu
Close
  • What we do
    • Go to overview
    • Customer Experience, Product and Design
    • Data Strategy, Engineering and Analytics
    • Digital Transformation and Operations
    • Enterprise Modernization, Platforms and Cloud
  • Who we work with
    • Go to overview
    • Automotive
    • Healthcare
    • Public Sector
    • Cleantech, Energy and Utilities
    • Media and Publishing
    • Retail and E-commerce
    • Financial Services and Insurance
    • Not-for-profit
    • Travel and Transport
  • Insights
    • Go to overview
    • Featured

      • Technology

        An in-depth exploration of enterprise technology and engineering excellence

      • Business

        Keep up to date with the latest business and industry insights for digital leaders

      • Culture

        The place for career-building content and tips, and our view on social justice and inclusivity

    • Digital Publications and Tools

      • Technology Radar

        An opinionated guide to technology frontiers

      • Perspectives

        A publication for digital leaders

      • Digital Fluency Model

        A model for prioritizing the digital capabilities needed to navigate uncertainty

      • Decoder

        The business execs' A-Z guide to technology

    • All Insights

      • Articles

        Expert insights to help your business grow

      • Blogs

        Personal perspectives from ThoughtWorkers around the globe

      • Books

        Explore our extensive library

      • Podcasts

        Captivating conversations on the latest in business and tech

  • Careers
    • Go to overview
    • Application process

      What to expect as you interview with us

    • Grads and career changers

      Start your tech career on the right foot

    • Search jobs

      Find open positions in your region

    • Stay connected

      Sign up for our monthly newsletter

  • About
    • Go to overview
    • Our Purpose
    • Awards & Recognition
    • Diversity & Inclusion
    • Our Leaders
    • Partnerships
    • News
    • Conferences & Events
  • Contact
Global | English
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
Blogs
Select a topic
View all topicsClose
Technology 
Agile Project Management Cloud Continuous Delivery  Data Science & Engineering Defending the Free Internet Evolutionary Architecture Experience Design IoT Languages, Tools & Frameworks Legacy Modernization Machine Learning & Artificial Intelligence Microservices Platforms Security Software Testing Technology Strategy 
Business 
Financial Services Global Health Innovation Retail  Transformation 
Careers 
Career Hacks Diversity & Inclusion Social Change 
Blogs

Topics

Choose a topic
  • Technology
    Technology
  • Technology Overview
  • Agile Project Management
  • Cloud
  • Continuous Delivery
  • Data Science & Engineering
  • Defending the Free Internet
  • Evolutionary Architecture
  • Experience Design
  • IoT
  • Languages, Tools & Frameworks
  • Legacy Modernization
  • Machine Learning & Artificial Intelligence
  • Microservices
  • Platforms
  • Security
  • Software Testing
  • Technology Strategy
  • Business
    Business
  • Business Overview
  • Financial Services
  • Global Health
  • Innovation
  • Retail
  • Transformation
  • Careers
    Careers
  • Careers Overview
  • Career Hacks
  • Diversity & Inclusion
  • Social Change
MicroservicesSydneyTechnology

Monoliths are Bad Design... and You Know It

Sam Gibson Sam Gibson

Published: Mar 13, 2015

Tightly coupled software presents the biggest difficulty when teams are looking to extend or change systems. As systems get larger, coupling limits the scope of change and self perpetuates. The easiest way to extend tightly coupled code is often to weave in even more interdependence.

One can think of coupling as the measure of effort to separate a logical module from its reliance on another. Languages and frameworks provide a means of abstraction that help to manage the cost of this effort. Object-oriented languages generally provide some methodology to organise and segregate functionality – viz. classes, interfaces, modules, etc. The protection they offer developers against logical coupling is weak, and the barrier to entry for introducing coupled code is very low.

Traditional monolithic design tends to amplify and enable coupling. While it’s possible -  with good software design, testing, and great rigour - to avoid increasing coupling over time, it is rarely seen in practice.

In contrast, microservices enforce decoupled solutions. Maintaining a level of coupling that enables change in large systems is a virtually impossible task. As a system grows, its code coupling inevitably increases. These monoliths by definition have sprawling functionality.

As the functionality continues to increase, large systems experience code entropy: module specificity decreases, and coupling increases. The design encourages this. Very often the immediate incentive for a developer to finish a feature on time runs counter to reducing coupling across an application, even if this long term success of the software might depend on it.

While it’s not wholly impossible to create a tangled spaghetti mess of tightly coupled code within a microservice, their very nature discourages it. Microservices increase the cost of changes that introduce coupling. They do this by making these negative changes harder by design in several ways:

First, microservices force a distinction between the interface for external consumers to interact with them and their implementation.

Second, they limit the scope of coupling within their own code. When an application is only a couple hundred - or thousand - lines of code, the magnitude of coupling is limited. In comparison, many monolithic systems have deeply nested coupling that spans hundreds or thousands of classes!

Third, microservices break the biggest source of shared state, in most applications: the database as a global variable. This forces consumers to decouple their domain representation of state from that of others in the distributed system.

Of course, this isn’t the only approach to encouraging good design. Another (and more common) approach is to modularise domain concerns into libraries. These libraries can then be managed and versioned through some dependency management tool, for e.g. Maven, NPM, and RubyGems.

Indeed, shared libraries are not incompatible with a service-based approach, and complement much of the common boilerplate of cross-cutting concerns. For example, an HTTP client library, circuit breaker, or metrics gathering component all provide shared benefits to microservices in a distributed system.

Shared libraries, however, do not offer many of the other benefits that microservices bring. When they are the only form of modularisation, they make using a different language and/or platform impossible, limiting solutions that might be more appropriate for specific domains. They don’t enable many of the advantages of process isolation, and they cannot be made to scale independently as load requires. Shared libraries also mean shared or planned releases, coupling your release process across teams.

In principle, it is possible to create independent modules within a single monolithic application. In practice, this is seldom implemented. Code within the monolith most often, and quickly, becomes tightly coupled. Microservices, in contrast, encourage architects and developers the opportunity to develop less coupled systems that can be changed faster and scaled more effectively.

Master
Privacy policy | Modern Slavery statement | Accessibility
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.