Look around you.
Look around you.
Look around you.

Most websites don’t exist. When you type ‘google.com’ into Safari, you might think you’re visiting Google’s website server, but you would be wrong. “Google’s website server” is not a thing. Google, the software package, is much too large and complex to be served out of a single web server. When you browse to any Google website, what you are actually getting is a large, complex set of interacting parts that all work together to give you the seamless experience of interacting with a single (virtual) website.

As with any complex system of interacting parts, the crux of the challenge is not in building the parts, but instead concerns how those parts and interactions are structured. In the world of web software, this feeds into a debate between two opposed strategies for designing these structures.

In the past, the traditional strategy is referred to as the “Monolith”. This is largely what it sounds like: One massive software project that does everything. The benefits of this are obvious: it’s very easy to figure out how to get started. Your one project already does everything, just make it do one more thing. Everything is centralized in one location, which means it is easy to manage and administer. Global changes become editing one configuration value. Everybody working on the same project means anyone can fill in for anyone else in a pinch. You don’t have the overhead of multiple projects. Performance improvements become simple: buy more powerful hardware. Finally, it’s a natural way of working. When the business people come and say “We want the computer to do X and Y and Z”, you write a program that does X and Y and Z and give it to them.

This worked, for a while. But as time went on, our requirements increased and project complexity followed, this started to suffer from some crippling tradeoffs. The centralized administration struggles to find the flexibility to account for myriad edge cases. Management thinks programmers are interchangeable, but people develop specializations around certain areas of code that are hard to see or communicate. When everything is together with everything else, a project bogs down under its own complexity, as a change to any element can cause subtle effects anywhere else. And there comes a point where you’re running the best hardware money can buy, and increasing performance beyond that point is a hard project.

A few years ago a new web project architecture arose, offering an alternative design pattern. Called “Service Oriented Architecture”, the idea was to identify the natural services in your project. You build each service as a separate project, have them all communicate with each other through a common interface, and so long as you design this interface well, you gain benefits.

The most obvious benefit is flexibility. As long as you conform to the shared interface, you can hide as much complexity as you want within your service. This makes it a lot easier to be flexible and handle edge cases. Say a given project needs to hit external services. In the monolith case, you must expose everything. With SOA, only the service that needs external access gets it, minimizing attack surface area. Or consider that a different programming language is better suited for a particular problem domain. As long as you conform to the standard interface, you can write in whatever language you like.

The encapsulation of services that are not strongly coupled to other services also has benefits in localizing the effects of changes. In the monolith, you never really know if a change to part X will cause a bug in part Y. With the service oriented architecture, the common interface acts as a hard check on errors. It doesn’t matter how you change service A, it can never introduce a bug in service B. Most changes in behaviour can’t cross the lines of the interface without a change in the interface itself. And, provided your interfaces are well tested, any bugs that do get through the interface will get caught there.

There are organizational gains, too. By allowing developers to specialize on certain sets of projects, they can become more effective on them. The separation of concerns into independent projects also allows more work to be done in parallel, free from the fear of colliding with someone else’s work

Many companies have adopted service oriented architectures after they’ve grown to a certain size. The top-down centralized management of a single codebase is just not able to handle the needs of a large, modern project or company. It chokes under its own complexity, and SOA helps to mitigate this.

Making things service oriented is difficult. I’ve hand-waved the process of designing the interface, and this is not a simple endeavour. But it’s an important one. It forces you to clarify the boundaries of things upfront, and to think carefully about the rules and the process for changing them. It also requires a large amount of trust. In a monolith, you can often code defensively around a bug, monkey-patch it, or edit the original code. With services, you must trust the services you interact with to fully and correctly implement your communication interfaces, and to satisfy their contracts and documentation. This cuts both ways, as the same expectations are held over you.

Monoliths encourage laziness and slop. Can’t make a timely and useful decision? Well, it’s a monolith, so build something higher up that forces the behaviour you want. Weird edge case? Ehh, code a one-off, what’s the worst that could happen? The worst is that, over time, these ad hoc decisions pile up into unmanageable complexity. SOA avoids this by forcing you to think it through upfront. It offers you a smoother, easier time, but only if you’re willing to do the work it requires.

Ultimately, as we discover time and time again, one size solutions do not fit all, and implicit design is no substitute for the real thing. Splitting up projects into smaller, localized, focused concerns, each with a small, dedicated set of people responsible, delivers more effective solutions than one massive unified team with one complex software dream.

Look around you.
Look around you.
Look around you.
Have you figured out what we’re looking for?