WHAT SHOULD MY ARCHITECTURE LOOK LIKE?

Adam Lev-Libfeld
Jul 26, 2017 · 7 min read

It’s hard to say for sure, but the only thing that can be, is that unless you are building an accounting or stock management system, OOD is not for you. Try and construct your system around the data flow in the different business processes of your value chain — your code should be separated into well-defined blocks with well-defined objectives (one objective each!) be it functions, microservices, services or something else.

Write down (or draw) the journey of that single user input (for every user input you have). What is it doing? Where does it go? What is it waiting on and where? All the way through the system where it becomes output again (consider long-term DB storage as output).

You want to see the different data flows through your system. See what tasks are in common (to all? to some?), and which are unique. See where different flows merge or diverge and where one flow is waiting for another. All these are friction points, and we will have to address them sooner or later.

Most cloud providers today will allow you to auto-scale the overloaded parts of your system, but for that, they need to be scalable themselves. This means we will be able to add or remove computing units (which we will call nodes from now on) from the problem without harming the other nodes doing the task. In other words — each task should be a self-contained process. Sometimes it’s easier said than done, and yet the basic idea is to find where different events/messages do have some interaction and moving it as far of the compute-critical areas as possible.

When designing a system, my favorite tricks are:

  1. Processing is totally separated from data handling
  2. Dividing complex processing tasks into a very basic pre-processing stage, and short bursts of processing followed by a reevaluation of the work — up until your heuristics score (for example, calculation accuracy) is “good enough”[1]
  3. Every DB is written to by no more than one element

But every (worthwhile) system is somewhat unique, with its own brand of quirkiness. To find yours, some good leading questions might include:

  • How big is the interaction between two random messages? Does this change if they are closer in time? And if they arrived at the same exact time?
  • What parts of the system have no interaction at all?
  • What is the compute-critical part of the system? (=what tasks are the most complex (computationally) parts of the system)
  • Is any part of my system doing more than one task?
  • Should my datastores be fast-in-slow-out? Or slow-in-fast-out?
  • Must I have a datastore, or would a cache do just fine? can the entire data needed on a node fit into its memory? If not, what would it take to make it fit?
  • What happens if I fail to answer on a small part of these? What is the most I can fail to answer?

By asking the right questions, you will able to separate many of the tasks into their sub-elements. Enabling you to shift some tasks around, advancing your understanding of the flow and the stress points we might encounter.

THE CATHEDRAL AND THE BAZAAR

As a paraphrase on Eric Raymond’s famous book under the same title[2] let us, for a moment, think of the church as a computing system. The service[3] () is led by the priest, and has a single, general, output, it is very reliable (when comparing to other medieval services) but given under very strict terms (start time, end time, location, donation). If you don’t like your town’s priest, the next best option (if you are a medieval peasant) probably involved some serious walking and certainly was not the safest things you could do on your day off (how’s that for a captive audience?).

The Bazaar, On the other hand, is a whole different animal — if you look at it from afar, it has some of the same traits — it is time and space bound (though quite loosely, when comparing to church service), and it serves the same people. That said, taking a closer look will expose a major difference — the service provider is not encapsulated in a uniform entity. There is no “market manager”, that bearded man who walks around wearing funny clothes and mumbles in a language you don’t understand is not in charge, he’s just plain crazy.

Without a unified ceremony, everyone has to perform to the letter (though there are some standards, like currency and common language[4]), the bazaar gives its clients another kind of service: it is highly distributed, highly parallel, highly flexible and thus, a better-personalized experience. The downside is low reliability in the single transaction scope, but you can always try again later or go to that next portion lady/swordsmith a few steps away.

Basically, the strength of the bazaar comes from the fact that everybody can play a role in it. From child pickpockets to old leper beggars, there is not a single soul in the city that is left out the marketplace, and all services are supplied as needed exactly, no more, no less (what Adam Smith called “forces of the market”). This is all nice in market theory (even if I got a bit carried away with the metaphor) but this exact trait — any needed task for any free performer, is the basic idea that enables us to build software that is both scalable and flexible. As the great Bruce Lee once said: “Be Water my Friend”.

SO SOA

If you have any experience with software developers, and I assume you do, you would know that we are prone to religion wars — windows vs. Linux, Python vs. JS, Visual Studio vs. Sublime vs. Emacs vs. Vim, even DC vs Marvel. Just name an idea or a product and sit back and watch us preach for hours on end why it’s either the most awesome thing in existence (or a steaming pile of out of date tyrannosaurus manure).

Taking that into account, it’s no surprise that a question like “is SOA good or bad?” have been sending architects, engineers and programmers to the ring to try and punch a decision out of each other since the biblical times (someone had to engineer the shit out of those pyramids). The bell rings, we’re up!

A concept is an abstraction or generalization from experience or the result of a transformation of existing ideas. The concept is instantiated (reified) by all of its actual or potential instances, whether these are things in the real world or other ideas.

— Wikipedia

Before we get to the punching part, let me just note that the question “is design concept X good or bad?” can futile at best, foolish at most, and detrimental at some. As far as I can tell, the notion that a concept (= the abstraction of a set of ideas) can be judged detached from the circumstance in which it will operate is risky at best. Will you judge a business without knowing in which market it is operating?

Now that that’s out-of-the-way, let us tackle that exact question I raised before: “is SOA good or bad?“. As you may have guessed, it’s neither. Well, it is bad, but only if you look at it as a silver bullet to all your software problems. The key to doing SOA in a good way is to not to use the SOA (or micro-services, or whatever the next same style hype will be) sticker on the box, but living the SOA concepts as part of your product coding style.

A service:

- Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports).

- Is self-contained.

- May be composed of other services.

- Is a “black box” to consumers of the service.

— Opengroup

Does this sound familiar? It should! these are the same concepts we learned in programming 101 back in kindergarten (someone had to engineer the shit out of those Legos). If you still can’t see the resemblance, let me help you… what about:

- Has some data model, and some actions it can perform with respect to that model. All of it should be documented.

- Can run by itself.

- May use other services (meta much?).

- Can perform perfectly without the user needing to know how (encapsulation++)

Better? These are all things that your code should be doing in the first place. Moreover, you want each class and most functions to be like that also (this is a private case of state minimization). You want to have good documentation of what is your input and output data model and the actions you can perform. You want code to be self-standing — for anything from testing (unit or other) to automatic error recovery and instantiation. Believe it or not, you even want the freaking thing to work even if you forgot how you wrote it in the first place (and you will forget, let me promise you that). These are all “more of the same” concepts we should be doing since the dawn of time, and you know why it keeps popping up? culture.

Culture is what it’s all about. each generation of programmers wants to feel superior over their predecessors, to show them “the new thing”. But let me tell you. I am not half the engineer the worst Atari programmer ever was. There’s nothing new here, just the same concepts wrapped in a new shiny box for you to stare at, including a new sticker for your buzzword collection.

Sticking to those principles throughout your codebase will not only minimize state, but will also, increase maintainability (and from that velocity), and most likely improve readability and make life easier for the ops guys. The downside (there is always a downside) is that you have to be the one to ask the hard questions, again.

[1] Seth Godin: Good enough is not perfect, it’s when you can say:

good, enough.

[2] Open format: http://www.catb.org/esr/writings/cathedral-bazaar/

[3] No pun intended… see https://xkcd.com/559/

[4] See: http://xkcd.com/148/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade