Breaking the monolith – How to design your system for both flexibility and scale – Part 6: The Service

This post is part of a series. you’d probably like to read it from the beginning. Or check out the previous post in the series

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 questions 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!

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?

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.


First Blood

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


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.. how about :

A service:

  • 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 fist 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.

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

Breaking the monolith – How to design your system for both flexibility and scale – Part 6: The Service

Leave a Reply

Your email address will not be published. Required fields are marked *