Microservices

Coined by Melvin Conway in 1968, Conway’s Law states: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” In software development terms, Conway’s Law suggests that a given team will build apps that mirror the team’s organizational structure. Siloed functional teams produce siloed application architectures.

The result is a monolith: A massive application whose functionality is crammed into a few crowded parts. Scaling a simple pattern to the enterprise level often results in a monolith.

Monolithic applications are frustrating to work on. Feature teams have to communicate constantly to keep from breaking each other’s code. Database administrators have to write complicated queries to generate simple reports. Developers are increasingly and necessarily adopting an alternative architecture: Microservices.

The microservices architecture involves building separate components that handle individual tasks and communicate via interfaces. Microservices can benefit coders and business people alike.

A microservices app is completely modular: Each part can be upgraded or removed without disturbing the whole, making it much easier to push changes into production. Microservices teams often practice continuous delivery. This allows businesses to launch new features and respond to changing market conditions faster, improving the bottom line.

You also get the luxury of choosing the best tool for the job. In a monolithic app, developers must work with whatever language or framework is available, often bending it out of shape. In a microservices app, they can leverage the most appropriate technology. As better technologies become available, individual components can be migrated over one at a time. That prevents your app from becoming dependent on legacy software.

But according to Conway’s Law, if developers want to build anything other than monoliths, we need to embrace new organizational structures and new ways of collaborating. How can we best organize ourselves to take advantage of microservices?

One answer is Agile, the hot (though not new) development methodology that emphasizes communication, continuous delivery, and flexible response to change over an iterative project lifecycle. Agile breaks down the organizational barriers that would otherwise lead to monolithic apps, allowing developers to implement microservices and other evolved architectures.

But the microservices architecture has its drawbacks. Remote calls between components are slow and failure-prone. Decentralized data management makes it hard to maintain consistency across an entire system. And the pure breadth of technologies across an entire stack can be overwhelming. It takes an experienced, coordinated development team to handle the complexity of a microservices app.

The software development community is tackling these challenges with new tools. An alternative to virtual machines, Docker packages application code and dependencies into portable, lightweight containers. It allows developers to build and deploy components on any server without worrying about dependency collisions. Two additional examples are Prometheus and Swagger: Prometheus provides a monitoring toolkit specifically designed for distributed systems, and Swagger generates interactive documentation for REST APIs.

Leading technology companies are using microservices to deliver content to their users. An early adopter, Netflix publicly documented its transition from a monolith to a microservices app. Today, the Netflix app handles billions of requests per minute. It serves as a source of inspiration for other companies looking to make the leap. I think that’s a good indicator: Microservices are here to stay.