Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Are Microservices a Divestiture of Architectural Oversight?

DZone's Guide to

Are Microservices a Divestiture of Architectural Oversight?

Let's talk about the role of the software architect in an industry where microservices are becoming more and more prevalent.

· Microservices Zone ·
Free Resource

Learn how modern cloud architectures use of microservices has many advantages and enables developers to deliver business software in a CI/CD way.

There were two related themes presented and discussed regularly at this year’s O’Reilly Software Architecture Conference in NYC. The first was the idea of separation of concerns in software architecture and its enforcement with developers. The second was the momentum around microservices and the notion that they provide the building blocks for evolutionary software architectures.

An interesting observation is that the concern for the first seemed to be less of an issue for those talking about latter. It feels as if an evolutionary architecture approach relieves architects from the need to enforce architecture principles. But be careful, this is a slippery slope. Let’s pick this apart and discover why.

The Role of the Software Architect

First, let’s elaborate on the role of the architect. They have long been considered ‘enablers’ for developers to do their job better. But what do we mean by enabler? How does that play out in development organizations? There are two ways to think of enabler – that of a service bureau, i.e. to provide what developers tell you they need. The second is to take more of a leadership role and help developers do more of the right things, i.e. by dictating how software should be designed and structured.

From our experience, the most effective architects are those who lead, while providing support, over those who only do service bureau work. The challenge that came up in numerous contexts during the event was that of how to enforce the architectural principles that are being defined, particularly in large development organizations. Or having any architectural principles at all. How to ensure that software architecture designs are being followed. There were some anecdotal band-aid suggestions made, such as revoking or denying developers access to the database, but those tend to be short-sighted and have ill consequences. Of course, at CAST we believe in a rigorous approach that involves the seamless integration of non-intrusive architecture checker is the best solution, but that’s not the point of this column.

The point of this piece is to call attention to the fact that this concern over the enforcement of architecture seemed to dissipate with the conversation around microservices and the notion of evolutionary software architectures. And in our opinion, to the demise of those organizations that make this mistake.

Microservice Software Architecture

So, let’s talk microservices for a moment. The recent popularity in Microservices represents a periodic, but regular, re-emergence of the dream of reuse. Only this time with some new bells and whistles, like containerized deployment.  Microservices offers a way to break an application down from a monolithic structure to something more modular. The use of microservices as a structural principle is an example of implementing an evolutionary architecture. One that supports incremental, non-breaking change.

Traditionally applications are costly and time-consuming to change. This is mitigated by building software architectures with evolutionary change in the actual design – the age-old goal of achieving modularity. Microservices seems to be the ideal construct for evolutionary software architecture, because each service is decoupled from all other services at a structural level. Their strongly bound context approach makes for a Lego-like assembly.

CAST Imaging

Figure 1: Imaging of Software Architecture.

With evolutionary change built into the very architectural design with microservices, and the notion that it supports the idea of Continuous Delivery, the focus shifts to enabling developers to move quickly. The purpose of controlling software architecture was to help us build new things quickly, right? So now we have that taken care of. Well, there are other reasons to control the software architecture. Like to ensure data consistency, to avoid redundant functionality, to ensure security at a fundamental level.

The whole point is that if we need to change something we can. RIGHT??? Right? Right. But be careful. That’s like taking the attitude of not worrying about the architectural design of a house, because any of the bricks can easily be interchanged and replaced. We still need software architecture oversight and enforcement. But it must support an evolutionary change mentality and must be both rigorous and non-intrusive, non-inhibiting.

Is microservices and evolutionary software architectures the next thing in CI/CD now that the DevOps craze as faded a little? It appears so. Is it a reason to overlook software architecture enforcement and guidance? Not in our opinion.

If you missed the O’Reilly Software Architecture Conference in NYC, you can access the slides and recordings free of charge here. If you’d like to learn more about how to enhance architectural governance, watch the video here.

Discover how to deploy pre-built sample microservices OR create simple microservices from scratch.

Topics:
microservices ,software architecture

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}