In the book Building Microservices by Sam Newman, on chapter one in the section Ease of Deployment there's a sentence that has left me bothered:

"A one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change."

This doesn't seem true to me. If I have my monolith divided into different packages (e.g. .dll or .jar) if I make a change to my monolith I can just replace the package that has that change in the deployment without affecting the rest of the application.

Can someone shed some light on this? Did the author mean something different from what I'm interpreting?

  • 2
    The author could be referring to a company policy which requires full regression and deployment for any change, no matter how small. I have worked under such a policy. It has more to do with fear than methodology, but it was a real thing. – Dan Wilson Oct 8 '18 at 17:41
  • And to expand on @DanWilson's comment, an automated test suite can assist with reducing the administrative burden, but it also requires that QA be given the final decision on when a regression test is needed (and QA be educated enough on the product to make that decision). – Greg Burghardt Oct 8 '18 at 17:43
  • 3
    If you divide your monolith into different packages, it stops being a monolith. – Pieter B Oct 9 '18 at 9:31
  • When I read Sam Newman's book, I immediately visualised a million LoC application as a single source code. A hilarious one. Jar, libs, modules, plugins etc are a sort of modularization that allows us to split that hilarious amount of code. Thanks to them, we break a single SDLC into several, easier to handle (but not necessarily easier to manage) and that's (or should be) the main purpose for us to break the monolith. IMO. – Laiv Oct 24 '18 at 10:10

A change can require the whole thing to be deployed, and there are cases where it doesn't.

Many times a monolith application is split into multiple libraries/jar files/assemblies.

A monolith web application, for instance, might have the following libraries:

  • A "business logic" library
  • A "data access" library
  • A "Web site"
    • And the "Web site" could have a bunch of template files for each page

If you make a backwards compatible change to the "business logic" library that doesn't cause other code to be recompiled then you could just recompile that 1 library and deploy that. An example would be a defect fix that does not affect the public or protected interface of any class in the library.

If you make any sort of change that causes other projects to need to be recompiled, then you must deploy the entire thing.

If you have a "web site" project with template files (like JSP or Razor templates for .NET applications) then you might just need to copy the one template file out to the web servers.

So that true answer is "it varies" and you shouldn't let the need to deploy an entire monolith be your deciding factor to split things into micro services, or even a more traditional service oriented architecture.

  • 1
    Just dropping in a new jar/dll is a major hack. Do not do this. Set up a proper CI/CD pipeline instead. – Esben Skov Pedersen Feb 14 at 15:40
  • @EsbenSkovPedersen: It depends on the organization. I've worked at places that simply would not trust developers or QA testers to deploy newly created binaries that didn't go through a full regression test of the entire application and/or application suite, but for some reason deploying a jar or DLL was less traumatic and required less testing. – Greg Burghardt Feb 14 at 16:20
  • Especially if they say "nothing changed in those binaries." The fact the timestamp on those files changed implies a much larger testing effort for them. – Greg Burghardt Feb 14 at 16:25
  • Also, the person asked if the entire monolith needs to be deployed. Technically speaking, it doesn't. Though to be honest, I agree with you that it's just as easy to deploy the whole thing. – Greg Burghardt Feb 14 at 16:26
  • Personally I trust a commit id much more than a timestamp. But yes I understand your point. – Esben Skov Pedersen Feb 14 at 19:15

Actually, that is true. Because a monlolithic application is a single tiered, self contained application with no modularity to speak of. Monolithic applications share no code with other applications. But, these are not unicorns. They do exist in a lot of legacy code bases, mostly as monolithic programs, though I have yet to see a million line monolithic application. That would be a nightmare of epic proportions. Most legacy and modern applications, even those written in languages that predate Java are rarely fully monolithic any more as they make calls out to other programs or procedures, and this allows them to be updated without updating the entire application. It is possible that this book advocating micro-services is just building up a straw man so he can more easily tear him down.

If you are using modules and DLLs, the application is no longer monolithic.

  • Shhh...if you don't create a straw man then you can't sell a new idea to software development managers. :) – Dan Wilson Oct 8 '18 at 19:58
  • 1
    FWIW, "The monolithic application consists of a single application layer that supports the user interface, the business rules, and the manipulation of the data all in one. [...] Even if there are multiple DLLs that handle the different functionality, it is still a monolithic application." tinyurl.com/ycx6fdol – Rick Smith Oct 9 '18 at 11:59
  • I couldn't follow your link, but the key point you missed is that a monolithic application is all compiled into a single program and does not share any logic or data with any other system. Once DLL's are introduced, there is implicit sharing of logic. Whether or not that sharing actually occurs in practice is immaterial. It seems that the term monolithic has been extended from what it once was if you can include DLL's and other modular techniques in a monolithic program. web.archive.org/web/20070902151937/http://www.its.state.nc.us/…. – jmarkmurphy Oct 9 '18 at 13:00
  • The definition of monolithic has two usages: 1. formed of a single large block of stone; 2. (of a ... system) large, powerful, and intractably indivisible and uniform. In the first sense, monolithic vs. modular, monolithic would apply, figuratively, to a single executable. The OP's question refers to the second sense with emphasis on "large" and "intractably indivisible". In the second sense, DLLs and even multiple languages may be used. The quote in my earlier comment comes from docs.microsoft.com/en-us/previous-versions/office/developer/… – Rick Smith Oct 10 '18 at 14:32

The author is correct, but that point is irrelevant. For example, let's consider a monolithic server application. What do we have to do if a library changes that is part of our server application?

  • create a new build for our server (which is potentially quite cheap given that we are only modifying a library)
  • launch a new server process with that build
  • switch new requests to the new process
  • gracefully shut down the old server process

In-process library changes are not generally possible, but also not necessary if you can simply switch over to a new process using some load balancing mechanism.

Re-deploying a monolith is not fundamentally more difficult or dangerous than re-deploying a microservice.

There is one caveat: many server processes benefit from caching, and need some time to warm up. If you deploy very often, the process cannot reach its optimal performance. Separating parts that are developed independently so that they can be deployed independently could then be beneficial.

There's also a divide between theory and practice. Whereas a microservice architecture is impossible or at least very painful without fairly automated deployment, this is less strongly the case for monoliths. So if any monolith deployment is manual then every deployment will be very cumbersome, and will be avoided. But that's not a problem of monoliths, that's a problem of tooling and culture.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.