This is a journey through what microservices architecture is and why the company’s structure might be the biggest threat in implementing it.

Nowadays, most companies have stopped just eyeing Microservices architecture and have started actively seeking to implement it in their organizations. The Microservices trend is augmented by the even more increasing rate of moving entire systems to the Cloud as it becomes more mature, reliable, easier to scale, and overall, cheaper to maintain.

When looking at how to adopt and implement Microservices ecosystems, most companies mainly focus on the hard technical aspects of the development, leaving behind the organization of the IT department itself.

Engineers mainly consider challenges related with the infrastructure, the container and virtualization technology, network latency, and the challenge of distributed datasets, but only a few of them consider the importance of the company’s processes, methodologies, and the organizational structure that are required in such an endeavor.

Microservices represent a big shift in the way software is developed, which is equally important when moving from traditional waterfall methodology to embracing a truly Agile software development process (where microservices fit well naturally).

To go deeper into this, we will walk through what Microservices are and will explain why the company’s structure might be their biggest threat when implementing them.

What is a Microservices architecture?

Although there is no formal definition for Microservices, we can think of them as an architectural style comprised of a suite of independently deployable, small, and modular software components (services).

The prefix micro is used to differentiate Microservices from the typical Service-Oriented Architecture (SOA), which is the traditional term to refer to a distributed system. You can think of Microservices as a special subset of SOA where the services have some specific characteristics: being built around business capabilities, communicating through lightweight interfaces (REST JSON style requests, in general there is no need for an Enterprise Service Bus or complex XML SOAP envelopes), and having a decentralized control of data where each service manages its own data.

The word micro also refers to the fine-grained nature of the service. Each service has a single well-defined purpose and interacts with other services in order to provide a more complex functionality.

A Microservices architecture may consist of a dozen and even hundreds of services. Therefore, the development toolchain to support and maintain these services heavily depends on automation. Building, regression testing, and deploying them to production must be fully automated in order to deliver the changes on time.

Dealing with Microservices architecture is challenging from the technical point of view due to not only the amount of work that needs to be automated but also the intrinsic nature of building a distributed system. One needs to know about robustness, reliability, distributed transactional workflows, fault tolerance, and resilience.

Nevertheless, there is an equally important aspect that crosscuts all these technical challenges: the organizational structure of your IT department. How teams are formed and how the requirements are tackled by the different IT areas will determine how successfully a Microservices ecosystem is implemented.

Let’s have a deeper look into this.

Content related: Serverless Architecture: From buzzword to reality – Part I or Working with Serverless Architecture – Part II

Monoliths and the organizational structure

First, let me quote Conway’s law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”.

Management is all about communications, and when IT managers start thinking about the necessary structures to build a new software product, they naturally tend to split the application to build it into components with a communicational structure quite similar to what shapes the rest of the organization.

In terms of teams and departments, we end up with an architecture that explicitly defines these boundaries (with a proper communication interface) for the back-end, the UI, and the database, to name some of them.

At the beginning of the development, the company will gather people from these different areas to work as a team to implement a given feature. Once the feature is implemented, the project finishes, and the team begins working on something else. As time goes by, there will be more features to implement, and they will likely be added to the existing same base code.

As the business grows, the organization needs to add more people to the development team, which is now touching hundreds of lines of the same base code and sometimes generating conflicts between what every team needs to modify. In this situation, you end up with a monolith base code, which is harder to maintain with every new change.

Many problems arise when your monolith starts growing, and some of them are related to the tremendous cost of the full development cycle that must be accomplished in order to deploy a new version of any component of such a system.

With the aim of releasing a new version of the software, the traditional approach to IT operations involves these factors (among others):

• Requirements analysis
• Design
• Coding and testing locally (in their own developer environment)
• Committing its changes to a source control system
• Building and delivery of artifacts to QA/UAT team
• Deploying to the production environment, once all validations passed

Although automation and different layers of unit and integration tests help, the time and effort necessary to keep up with a high-quality product tend to increase while the system augments its complexity with each new added functionality. Sometimes, following this pipeline from development team to QA team to UAT team to Operations simply cannot deliver the changes at the required speed.

Agile development encompassing well-defined product boundaries

Agile Movement introduces a series of practices to cope with all these steps needed to ship a new version of your software without compromising quality and at the same time improving customer satisfaction.

However, Agile Movement still has a hard battle against the established procedures and policies nowadays. Most companies proudly talk about and affirm they apply Agile techniques, but few of them actually do so as they were originally intended.

Regardless of successfully applying Agile procedures, it may not be enough to manage a large codebase with ever-growing interdependencies and integrations with external parties (i.e., a given functionality that exposes a service that is consumed by the application).

By definition, Microservices are small and designed to accomplish a single goal; therefore, testing and integrating is limited to ensure the change does not break such a purpose. The modularity and independence you gain by designing each service allow you to produce components that can be safely tested and isolated from the rest of the system so you reach production status without sacrificing quality.

In order to successfully implement this type of architecture, you must first tackle the problem that emerged from the initial system. If you started with a small well-defined system that evolved to a monolith, how would you avoid having the same problem with the small well-defined services that form your initial Microservices environment?

The organizational barriers, mainly your pyramidal communication structure, may be your main threat. One of the key factors within the organization is to stop thinking about delivering projects and start working on building and maintaining products. If the systems developed are for internal usage, think of them in the same way: products, not projects!

Microservices is all about developing well-defined services with a single purpose that can live and evolve independently. It would be a very difficult task to do if, after the project finishes, you are dismantling the team that built the service.

The whole idea of a project-based development that starts and ends after adding a new feature to the system is also very hard to achieve in this scenario. You would need to switch from specialized teams –focused on adding a feature to a single layer of a system (i.e., database or UI) as part of a project– to a multidisciplinary team working on a product (across all its layers) during its entire lifecycle.

Each Microservice may potentially become an independent product, with its full lifecycle, owned by the team that created it initially.

Your first task before beginning to design any Microservices architecture will be to gather IT management and project leaders to reorganize and redefine their tasks and roles around this product-centric approach. Managers (or product owners) must become facilitators, and project leaders need to become product leaders, deeply involved in the full lifecycle of the software they are building.

Having everybody on board, committing to this new vision, and forming a new structure of the organization is key to moving forward to a truly decentralized and scalable Microservices architecture.

To Sum Up

Microservices architecture represents a shift in the way we think, plan, and build systems. Focusing on creating independently maintained components that can scale and evolve to hundreds not only requires talented people and an automated development pipeline but overall requires rethinking the whole IT organization.

You need to create self-organized multidisciplinary teams that take ownership of every service they work on. They must be able to design and code not only a given feature but be able to test and to deploy the software to production environments.

Supporting a decentralized structure like this becomes a big challenge for enterprises, and counting on a true commitment from management is the key to success.

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.