Tag Archives: software

A Single Deployment Target is not a Monolith

Since the dawn of software architecture, we mostly knew that ‘Monolithic Architecture’ was more or less a synonym for ball of mud architecture. It mostly referred to code which was so entangled and coupled that it could not be separated out into components (or layers, or modules, or libraries, or equivalent). God classes, lack of information hiding, a change in one place means 20 other changes. That kind of thing. A failure of Modularity.

Recently the term Monolith has been taken to mean having a Single Deployment Target at runtime. This is a quite different meaning.

If you think that Monolith as described in para 1 above is the same as Monolith in para 2 above, then I suggest that you have confused, not separated, your concerns.

This is easy to understand if you are comfortable with architecture views. The para 1 definition is about the logical and (in 4+1 lingo) development views: the structure and relationships of classes, components, packages, and other kinds of modularity. The para 2 definition is only about the runtime deployment view (in 4+1: physical view).

The point is that you are at liberty in pretty much any operating system, runtime or language devised in the last 30 years, to structure your code and components as carefully and modularly as you like, whilst choosing your runtime deployment scenario independently of that modularity: it’s okay for 2 uncoupled components to run on the same machine. Honestly. *nix does it all the time. Ooh, so does Windows. And .Net and Java and Android and iOS and ….

The CTO at intilery.com showed me a couple of years ago how their server codebase can be deployed as either a single .war for a single webserver or split as separate .wars for separate machines by flicking a switch in the build config.

It’s not rocket science, it’s Separation of Concerns: the codebase is not the runtime.

DistributedMethodCallError: The belief that calling across a network is better than calling within a process

Distributed Method Call Error
The belief that methods and functions communicating across a network is somehow better than communicating within a single process on a single machine.

Process this error by politely throwing a verbal exception, inquiring as to what, exactly, is better. And then explain how the answers you’re getting back are the wrong answers.

Here are templates for the three main areas on why a distributed architecture does not make X better:

If X is one of: Response
Separation of Concerns, Coupling, Cohesion or similar But X is not primarily about deployment scenarios, so distributing your deployment does not improve X.
Reliability, Performance, Robustness or similar But as you’ll know from the Fallacies of Distributed Computing, if not from bitter experience, distributed computing makes things harder not better.
Deployability, continuous deployment or integration But deploying to multiple hosts is harder, not easier, than deploying to a single host.

Yes, there are problems for which distributed computing appear to be part of a solution. Redundancy as a reliability tactic appears to push you to distributed computing. So does horizontal scaling as a performance or capacity tactic. But these things are done extremely well at the infrastructure level by a black box: a load balancer. Notice that load balancing does not force a decision on whether each instance of your application-or-service is deployed entirely on a single box or is distributed.

So if you think that microservices or any other form of distributed deployment address issues such as dependency management, coupling, cohesion, continuous deployment, avoiding domino failure, then may I put it to you that you have confused, not separated, your concerns. In 4+1 terms, you may be confounding your physical and process models (i.e. the runtime models) with your logical & development (‘coding-time’) models. As Simon Brown pithily put it, “if you can’t build a structured monolith, what makes you think microservices are the answer?”.

PS

Yesterday I read a blog about ‘Monolithic’ architecture which said – with pictures and everything – that if your problem is how to carry on coding effectively (add new features, fix bugs, resolve technical debt etc) as the size and complexity of the code base increases, then the solution is a distributed deployment architecture with synchronous calls over http using xml or json.

I could weep. You manage your codebase by managing your codebase! Not by making your runtime deployment and threading models 50 times more complicated. This is what I mean by confounding the logical & development models with the process & deployment models.

PPS

If you’re not familiar with the 4+1 architecture views: The

  1. Logical view describes your classes’ behaviour and relationships; the
  2. Development view describes how software is organised and subdivided into e.g. modules, components, layers, and how they are turned into deployable artefacts; the
  3. Process view describes what threading and processes and distributed communications you use and the
  4. Physical view (though I’d rather call it the Deployment view) describes what machines run what code on the running system

The ‘+1’ is the use cases, or user stories.

When I first saw 4+1 I only really ‘got’ the logical view. As years passed, I realised that this reflected a lack of experience on my part. When you first do distributed or asynchronous computing, you begin to see why you’d want a process view and a physical (or deployment) view.

4+1 is quite long in the tooth and has evolved in use. There are other sets of viewpoints. Rozanski & Wood’s seven viewpoints show the benefit of a decade’s more experience. You may think 7 is a lot, but for a small or simple system some of them need only be a sentence or two.

Estimates and NoEstimates

We had a debate&discussion at XP-Man on NoEstimates for which I did some notes. Reading the NoEstimates stuff, I was most attracted to the sense of “Let’s not be satisfied with second rate” and of a thirst for continuous improvement.
I was left with the sense (possibly because I already believed it) that there are contexts in which NoEstimates works, and contexts in which it doesn’t. But I was very glad to be provoked to ask in each case, “What value if any is our estimate/planning effort adding?” and “Isn’t there a better way to deliver that value?”

What is an Estimate?

An estimate for a Project is (1) a list of things to work on; (2) a cost-range for those things; and (3) a list of risks, that is (3a) of Dependencies that 1&2 rely on, and (3b) of things that might cause significant change.

An estimate or plan for a sprint is (1) a list of things to work on, (2) a “cost” (eg story points) for those things and (3) a list of things we are uncertain about, or (4) need to get help with.

The value of a project estimate is to feed-in to (1) A go/no-go decision and (2) seeing things we want to see sooner rather than later (e.g. should we hire more people, do we need help from specific 3rd parties, is releasing in time for Christmas possible)

The value of a sprint estimate is, to see things we need to ask for in advance (ie external help or resources); to give everyone a sense of confidence about what we’re doing; to fail-faster, that is to see sooner what we can’t achieve.

When Agile isn’t Agile

Reading I Fear Our Mobile Group Being Forced To Follow Scrum crystallised in my mind what can go wrong when you treat Agile as a methodology. It describes a team successfully using kanban which is to potentially be required to use scrum — because that’s becoming the company standard.

Making a team follow an agile methodology is exactly *not* Agile.

Agile is “Individuals and interactions” being valued more highly than processes. Imposing Scrum looks like valuing the process more than the team.

Agile is “self-organising teams” and letting “the team [reflect] on how to become more effective, then tune and adjust accordingly.” Imposing conformity on a team that has already adjusted is a backwards step; you’re asking a team that has optimised somewhat for the individuals in the team to de-optimise again.

This doesn’t mean that you can’t teach an agile team anything. The manifest starts with “We are uncovering better ways of developing software by doing it and helping others do it.” A team that can’t be corrected, or won’t learn better ways, isn’t agile. For that matter, a team that won’t learn in any walk of life has started the downhill path to decline.

For what it’s worth, I’m sure that a competent lean team that tries Scrum for a while will learn from it, even if they end up optimising back to something more fluid.