Microservices and the organizational Impact

Nowadays microservices are a highly discussed topic for software developers. Albeit it’s not a complete new story here — distributed systems have been an essential ingredient in modern system architecture for some time — the impact in organizational structure, team mixture and in every team members effort cannot be emphasized enough.@Goodbye 3-Tier Architecture

So let’s start to discuss it from a technical perspective: microservices means “goodbye 3-tier-architecture”. Yes, 3-tier-architecture: that was the technology they taught us as state of the art in our studies and in our first jobs (maybe EJB2 on Websphere, JBoss, etc.). And now years later we are so familiar with this approach, easily we convince customers with this idea: database (“the data”), backend (“there is the business logic”), frontend (“there you have to click”). Nearly blind we can draw this on every flip-chart: database barrel, service rectangle, a widget, some arrows, done!

And for the record: it’s not bad thing to it that way. 3-tier systems are highly evaluated and documented. There’re tons of books, courses and trainings — and people with years of experience. You can quickly setup a system. There are a limited number of components to do so (let’s say 3: a DB, an application server, a frontend technology). Most IDEs have very good integrations, wizards and templates to speed up your work. Setup a build stack with maven and jenkins is mandatory. If you only need a few deployments in production from time to time, everything will be fine. Even if your jenkins build is running over an hour.

Organizational Scaling

The problem begins with scaling. And with scaling I don’t mean scaling out or scaling up the system because of growing data or gaining requests (by the way: these are all perfect reasons to think over your system design). The problem is functional growth (which causes more side effects) and the increasing amount of developers participating on a project (they need more work that can be done in parallel).

Quickly your work becomes a battle for resources due to its horizontal layered nature: in 3-tier-architecture we have one or more fat DBs centralized, centralized services within an application server and a very narrow bounded (web) UI or even worse: a (RPC) fat client. A single change on a centralized system causes side effects and changes in other dependent components. So there is a lot of coordination, communication and testing needed because of a change in a tiny little high centralized and closely coupled resource everybody's connected to. If your amount of features increases and new team members joining your staff it becomes more difficult to pull all the strings (and this is literally a nice picture for the whole entangled system).

Those (monolithic) systems are inherent supportive for tight coupling — or more specific: the barriers in 3-tier-architectures are very low to query and join, inject and import and bind all other components of the system. You even don’t have to remember the name of a component, the IDE and refactoring tools will support you doing this. A modern IDE is both blessing and curse. On one hand the tooling holds all together, on the other hand it promotes the ease of change and refactoring without limitations and across contexts.

Set up Barriers

If you want to limit the interconnection between components and rise the parallelism of your work you don’t come around installing barriers vertically. You must set up restrictions. This is where microservices kicks in for me: wouldn’t it be nice to have a system architecture that supports different thinking about how to organize modern software development? For me the microservice approach is not only a technical decision, it’s a decision to change technical and organizational. Realizing microservices because of the benefits it might have in organizational structures totally makes sense for me — as long it’s going hand in hand with developers and project/team leaders.

The change of the architecture must be backed by the change in your teams. Microservices not only promotes the technical/functional separation of concerns (bounded contexts) it also promotes a organizational scaling, it provides a method to manage projects with a lot of staff and a huge backlog.

So, microservices are not a triviality. The list is long why not to do microservices. Doing it because of potential advantages in organizing a software project seems to be foolish. There is operations and process overhead, complexity of distributed systems and difficulty in asynchronous communication to name but a few challenges you will be confronted with. But I think operations and processes, distribution and asynchronicity are not technical issues per se. They are general problems you can find day by day in managing a development team. Think about it: if conway’s law is true, then there is an analogy between technical and organizational problems. Maybe we don’t come around to accept this overhead. Maybe it’s the price to pay for modern software development — organizing large scale, long running, feature-rich projects with many participants.

TL;DR

The microservice approach promotes the management of large scale software projects with a high degree of parallelism.