What Are Microservices

Microservices design has become a go-to architectural framework for teams developing distributed enterprise software. But what is this design, and how does an organization build or transition applications to properly become part of the microservices movement?

In this article, we’ll explain the basic concepts of microservices, their advantages over traditional monolithic architectures, and how to build a culture that thrives using this design approach.

What Are Microservices?

Microservices are small discrete software services communicating via an Application Programming Interface (API) that collectively form a business application. Each microservice is aligned with a business functionality and owned by a small team responsible for maintaining and testing each microservice. 

As such, a microservice-based architecture is a type of software design that modularizes a system into a collection of services and sub-modules. The paradigm of separating software modules into services has existed since the dawn of computing including when Service Oriented Architecture (SOA) articulated it at the turn of the millennium. At a high level, the difference is that microservices are more granular and lightweight than ever conceived before.

These software modules each serve a unique purpose (such as login, user profile, search, reviews), but together make up one application.  From a technical perspective, this architecture aims to create network-accessible services that meet the following criteria:

  • Organized around single-purpose functionality
  • Highly maintainable and testable
  • Loosely coupled
  • Independently deployable
  • Owned by a small team

Let’s use the example of an e-commerce platform to depict the benefits of a microservice-based architecture. At a micro level, you have business-specific workflows like inventory management, order management, shipping, and payment processing. To achieve a workflow, one or many microservices can be used to build the application feature; each microservice communicates with the front-end User Interface (UI) and each other via an Application Programming Interface (API).

Microservices are tied to APIs

With a model based on specific business domains, each microservice is treated as a black box accessible only via its API from the outside. As long as the API remains stable and consistent, the functionality of the microservice may independently change over time. 

4 Ways to Embrace Microservice Design

Contrary to what some may think, microservices as an idea represents more than just a technical architectural model.  It actually represents a culture-first approach to designing software that emphasizes development autonomy, accountability, flexibility, and technical freedom to achieve application excellence.

The success of microservice-style architecture requires mature and efficient communication to appease Conway’s law, which suggests that organizations are destined to build design systems that mirror their communication structures. After all, it is easy to imagine that a poorly communicating organization would struggle to create a seamless application experience devoid of glaring inconsistencies such as conflicting schemas, unhelpful errors, etc.

Fortunately, there are four clear ways you can ensure that your organization is set up for success when building applications through microservices. Let’s take a look.

1. Structure Teams by Business Service

In most businesses, teams operate in silos which creates a very conventional and inefficient approach to developing and delivering software.  A traditional organization separates functions such as:

  • Product management
  • Product marketing
  • User experience design
  • Front-end development
  • Backend development
  • Database administration
  • Test engineering
  • IT operations

Instead, under the microservices model, a multidisciplinary and cross-functional team owns a particular business service. Each team then consists of individuals who make up the respective service’s lifecycle from end to end. This structure improves understanding of business requirements, team cadence, and software delivery.

Spotify has expanded on this theme to create an often-referenced matrixed organizational model (made up of squads, tribes, chapters, and guilds). Spotify’s model creates teams aligned by business functionality while still keeping a role-based domain affinity for each contributor.

Teams Aligned with Business Functionality Implemented in Microservices

2. Make Deployment Streams Independent

Since microservice teams work on services independent of other components of the larger system, they can adopt agile practices such as Continuous Integration and Continuous Delivery (CI/CD). A centralized, cross-functional team develops, tests, problem-solves, deploys, and updates services much faster than traditional teams who might get bottlenecked by other supporting teams.

For example, a microservice team working on a payments service for an application can add support for a new payment method and independently release it into a live application environment; a traditional team would likely have to coordinate with back-end, front-end, product, and potentially other service teams affected by their development changes. With so many additional complexities, simply aligning on scope, bandwidth, and priority often drags the velocity down for everyone involved.

3. Grant Technology Heterogeneity

One of the biggest lures to a microservice architecture is the technical heterogeneity that it offers. As you can imagine, technology heterogeneity only works if teams have strong service ownership (independence) instead of collective service ownership.

In a strong ownership model, each microservice team is in control of its own programming paradigms, technological decisions, deployment practices, and tools. They can independently choose technology stacks that are best suited for their respective microservices without worrying about scaling niche skillets across a broad team.

The strong ownership model is not without its downsides. As each team standardizes on a different technology, the movement of personnel across teams becomes constrained, as does procurement management and training. Spotify solves this challenge by introducing “guilds” where subject matter experts coordinate their selections of technologies, best practices, and tools.

4. Avoid Tight Coupling

Errors have a wide blast radius in a tightly coupled software system. In some cases, a single bug can render an entire application unusable. With microservice-based architecture, any given software fault or error can only ever impact that one underlying service. The remaining system can continue to function normally as long as dependent services don’t require its functionality. Additionally, resolutions can be turned around faster due to the smaller troubleshooting scope and strong ownership of the responsible team.

The Modernization Challenge

As infrastructure ages and new solutions become available, application owners must choose between modernizing or maintaining their products.

Modernizing ApplicationsMaintaining Applications
Requires costly long-term investments that may take months to complete.Keeps additional costs at a minimum for higher margins.
Ensures competitiveness against emerging players.Prevents user loss due to significant experience changes and instability.
Requires an organization to make structural changes.Avoids risky organizational turmoil if changes are controversial.
Requires motivating employees to adopt new practices and technology.Avoids the costly search of recruiting new experts.

As you can see, there is a lot of risks involved in modernizing your applications -- however, the payoff is arguably the only thing that matters: continued application relevance in a fast-evolving landscape. That being said, you can find many applications that still run on backend technologies from the 1980s that have survived on UI updates alone.

Modernizing your applications and adopting a microservices approach should happen only when you choose to move away from the client-server application model for a Software as a Service (SaaS) model. This transition typically happens either when an application requires to scale beyond its originally designed capacity or when end-users no longer wish to install client software on their desktops. The investment required to support such a transition would be an ideal trigger to adopt a modern application architecture. 

Conclusion

Adopting the microservices design for building applications requires setting up a culture of service independence, multi-disciplinary team ownership, and open communication. Transitioning to this model of development can be expensive and it is not without risks to both application stability and organizational harmony, however, the rewards can be great. Applications built using a microservices design are less vulnerable to global performance issues, faster to release, and easier to upgrade.