Service Oriented Architecture Construction, Every Line is Hard

I’ve not been coding as much as I should because as long as coronavirus has everything out of wack I’m trying to take care of some personal projects. But I am still coding and thinking about code. One of the things about being here at home is that I’m using my home automation stuff a lot more and make small tweaks to it. This means modifying code that I haven’t touched in more than a year, sometimes 5 years or more.

The experience of modifying code you haven’t worked on for so long that you don’t remember writing it is that you can view it for the first time. And without ego or defense of your mistakes. I’ve never met a developer yet that wouldn’t argue with why they coded something a certain way, even when their choices were clearly poor. It’s just the nature of performing a craft. I’m no different.

But now, after years of studying The-Method and following Tesla I’m trying to view my code with more of a first-principles view.

As developers we all have used an API and it was easy, natural, intuitive. Then you use a different API and it was like trying to untangle spaghetti. Why is this? Even the simplest of things are often difficult. I use .NET and config settings are just a disaster. They are so difficult to manage.

Part of the reason is that as soon as you say something like “config settings are just a disaster” you have an army of nerds that have memorized all the config setting APIs that leap to it’s defense. “You just don’t know how to use it!” To which I’m keen to say, “Why should I?” For crying out loud, I just want a setting, I’m not trying to disarm a freaking bomb (in which case you clearly cut the blue wire).

The problem with complexity and software is the same as all the other construction vocations. They are complicated and often specialized. In one case you’re building a skyscraper (an enterprise app) and the next you’re building a cabin in the woods (a one off script). The scope and breadth of the challenges are so great that it’s not clear what processes, techniques, and constraints that apply in each of the situations.

Also, software is fairly unique. Unlike the crews that build skyscrapers and bridges and single family homes in software we mix all our people together. If you work on a skyscraper or if you’re building an airplane the people that you’re working with are experts in building skyscrapers or planes.

In software we often work on teams where the qualifications are technical and not specific to the industry. One of the biggest challenges to implementing The-Method is that your peers probably have never built a SOA (service oriented architecture). Maybe you’re stepping up for the first time and you’ve not even built a SOA. Think about this for a minute. You’ve been out in the suburbs building single family homes or 30 unit apartment complexes and you get a call from the Space Shuttle Program to “come to work on Monday.”

That’s how software works.

Suddenly, you’ve got to work at an entirely different level. What do I mean?

If we stick to the Space Shuttle analogy for a minute it’s quite clear that you don’t go down to the local hardware store and buy parts. EVERYTHING is engineered. And it has to be EXACTLY right or the thing blows up. It was O-rings that blew up the Challenger because they couldn’t compensate for a slight temperature variation on the morning of the launch.

Most of the software frameworks do very little to help you build a SOA. They don’t help you implement many design patterns either. The current state-of-the-art in SOA is virtually custom end-to-end.

I have harped on the value of envelopes in some of my previous commentary. But I’m willing to bet this was lost on most readers. Why? Because until you’re actually exchanging every command over a message-bus, queue, or SOA-service-contract the notion of an envelope is built into the environment. In both Java and .NET webapps the envelope is the HttpRequest and HttpResponse objects. No need for an envelope because (whether you realized it or not) there already is one. SOA architectures are that times a 1000. With a SOA you go from having envelopes built into the environment to suddenly YOU-BETTER-CARE or you’re dead.

That’s a steep cliff and the majority of the teams step up to the edge in a fog so thick they don’t even know the cliff is there.

So what am I on about here?

Well, in an environment where everything is engineered and custom how do we communicate why something was engineered the way that it was and how do you use it? This is a very difficult challenge.

If we jump back to the config settings example for a moment the reason why it’s such a mess is that the answer is ALWAYS “just learn the framework and shut up.” Why? Because it’s a difficult engineering solution to make it any better. But think about this in terms of SOA. Unlike your apps of the past where all the config settings could just be in the start-up folder in a SOA many of the services will be deployed individually. The services are often deployed to different environments, sometimes different platforms. And yet, many of the config settings will be shared across these services. If you view settings as a simple “learn-the-config-api” problem you’re really missing the point.

Worse yet, most apps tie their behavior to config settings. While it can be desirable to share settings maybe they don’t change at the same time across all services or even versions of the same service (sounds like a volatility at the app level, right?).

In The-Method we talk about “hiding complexity.” But the INSTANT you go out and try to build such a system you’ll realize that Righting Software has zero guidance for HOW this is done at construction time. We learn how to do it at design time, but not at construction time.

Let me ask you a question. Containers have been all the rage for about 10 years now. Where are they in a Method design? In the red-line versions of the architecture Juval suggests a “deployment view” but there’s not really a container view.

For all their technical prowess and helpfulness containers don’t even make it to the architecture. From a communication and design perspective they are less than an implementation detail, they are nothing — LITERALLY. And yet, ask any developer from the past 10 years what one of the biggest changes has been and they’ll volunteer: CONTAINERS.

Think about the implications of that. Containers are useful. They really do help out. But they are not part of our architecture and they (should not) matter to the design.

I offer containers as a great example of what hiding complexity looks like in real-life. It’s so pushed to the background as to not matter anymore to our design. Remember, Juval was the guy saying that “one day every class will be a service” and he has recently even suggested that, “Hey, maybe every line of code will be a service.” With .NET we saw the introduction of “every class is a (COM) component” and in service fabric every class is a service.

With Azure every deployment is now a container. And with a little bit of infrastructure configuration VS will now deploy whatever you want pre-configured within a container. This incredible complexity is just delivered. [FYI — you’ll know Kubernetes is finally “right” when people quit talking about being good at Kubernetes.]

Back to our fine grained designs. How do we implement things like config settings (or envelopes or serialization or encryption or service discovery or …) in such a way as they are simple and clear to use?

I don’t know. But I do know that if you need to explain how it works it’s too complicated.

In the Storyboarder I implemented in the sandbox there are 3 main componets: ACCESSORS, ENGINES, and MANAGERS. ACCESSORS only accept AddBusinessVerb(), ENGINES only accept AddActivity() and MANAGERS only accept AddUseCase().

The idea was to make the wrong thing impossible and the designed thing, the desired thing, easy.

Today I ran across the cartoon above that captures all of this in one image.

Enjoy