Este post también está disponible en español

What do we talk about when we talk about software architecture? Truth is there is no fixed definition but a wide range of debates and opinions about it. Each and every one of them objetable and discussable.

Architecture can be considered to be the fundamental organization of a system, meaning the most important aspects of a software system’s internal design or how the higher level components are connected. But how or who defines what is fundamental or high level? Tricky, huh?

We could also think that the architecture is the decisions that must be made at the beginning of a project, although to be honest, it’s mostly about the decisions one wishes to have made correctly at the beginning of a project. As simple as that sounds, it kind of blew my mind the first time I encountered that idea.

All in all, there seems to be consensus on the fact that architecture is about something important that has a great influence in the development of a project. Architecture is about the important stuff. Whatever that is.

Once again, this definition leaves us with a whole bunch of questions.

What elements are important? What elements can be a source of problems if not controlled? Everything seems to be pretty subjective to me. What is important to you, may not be important to someone else.

This is where one of the main ideas arises: architecture is a social construct. It depends on group consensus on what’s important.

Situation #1: a group of developers builds a large software system and agrees on persistence being crucial. They define without an inch of a doubt that they’ll use Oracle for their database and that they’ll build a persistence layer to map objects.

Situation #2: another group of developers is working on a diagnosis by image app. They use Oracle, but they do not consider this aspect to be part of the architecture because the main challenge in a system like this one resides on how to analyze images, not in how to store them.

To sum up, it all comes down to defining what’s important and generating consensus about it.

What’s the difference between architecture styles and patterns?

Before moving forward, we should learn to broadly differentiate architecture styles from architecture patterns.

Architecture styles are macro-oriented. They are related to the general structure and organization of the user interface, the backend code and how that code interacts with the stored data.

Architecture patterns, on the other hand, are micro-oriented. They are related to lower level design structures that help create specific solutions within an architecture style.

Some considerations on distributed systems

There are basically two types of systems: monoliths and distributed.

The biggest difference is that monoliths consist of a unique deployable unit, while distributed systems consist of multiple deployable units that are connected by remote access protocols such as REST or SOAP.

Along with the hype of using distributed systems -such as the superstar microservices- come a series of fallacies that lead us to ignore some very important considerations, which we should carefully reflect on when thinking about opting for this kind of systems.

Let’s demystify.

  1. The network is NOT trustworthy. This is extremely important because all distributed systems rely on communication between networks to services, from services and between services.
  2. Latency is NOT cero. Time in local method or function calls is measured in nano or microseconds. When that same call is made through a protocol such as REST, time is measured in milliseconds.
  3. Bandwidth is NOT infinite. For example, when microservices are used, communication between them uses a a lot of bandwidth and this slows the network down, thus impacting latency and reliability.
  4. The network is NOT safe. Security measure must be taken on every endpoint, which slows the system down.
  5. Topology is NOT always the same. One needs to be in continuous communication with network and operation admins in order to define what changes should be made and adjust the systems.
  6. There is NOT one single admin. Same as point five. Distributed systems require lots of collaboration and communication.
  7. Transport DOES cost money. Distributed systems are more expensive than monoliths.
  8. The network is NOT homogenous. ****Protocols need to be adjusted, for example.

Some other things to take into account are distributed logging -it’s hard to identify the problem when there are a lots of different logs to go through-, distributed transactions -sometimes consistency and data integrity needs to be sacrificed-, and contract maintenance and versioning -it’s specially difficult to maintain contracts due to service decoupling because systems belong to different teams.

These are some of the things one should keep in mind when it comes to implementing a distributed architecture.

Final Thoughts

Martin Fowler states that one of the architect’s most important tasks is to remove the architecture. How? By looking for ways of getting rid of irreversibility in software design. Because irreversibility if one of the main causes of complexity.

Think about traditional architecture and construction. One of the main differences with software architecture is that many of the decisions made while building an apartment building are hard to change. If I want my basement to be different, it’s going to be -at the very least- complicated.

Meanwhile, there is no physical reason why software should be hard to change. You can choose different aspects and make them easy to change. Nonetheless we don’t know how to make everything easy to change and, even if we managed to make everything easy to change, we would be incrementing the overall system’s complexity. And complexity is what makes software difficult to change. Moreover we don’t know which aspects should be changeable, thus we don’t know when it’s good to change things and when it’s not.

Exhausted already? Yeah, me too.

To sum up, software is not limited by physics like buildings but by our own imagination, by design and by organization… all human properties; not the world’s.

We have met the enemy and he [or she] is us - Ralph Johnson

Thanks for sticking around. See you on the next post!

Sources

This article is heavily based on Martin Fowler’s article Who needs an architect? and Mark Richard & Neal Ford’s book Fundamentals of Software Architecture. An Engineering Approach.