A microservices architecture provides a highly scalable and distributed modern system
Modernizing applications in today’s world often means migrating to cloud-native applications built as microservices. They are then deployed using container technologies like Docker and Kubernetes. Netflix and Atlassian did it, as well as countless other organizations. The reason is, a microservices architecture improves scalability, development speeds, and service iteration.
A microservices architecture splits an application into a series of independently deployable services that communicate through APIs. This allows each individual service to be deployed and scaled independently. This approach allows for the rapid and frequent delivery of large, complex applications. In contrast to a monolithic application, a microservices architecture allows teams to implement new features and make changes faster, without having to rewrite a large portion of the existing code.
Some key characteristics of a microservices architecture are:
Multiple component services
Microservices consist of individual, loosely coupled component services that can be developed, deployed, operated, changed, and redeployed without compromising the function of other services or an application’s integrity. This allows for fast and easy deployment of individual features of an application.
Highly maintainable and testable
Microservices allow teams to experiment with new features and roll back if they don’t work. This makes it easier to update code and accelerates time-to-market for new features. Plus, it simplifies the process of isolating and fixing faults and bugs in individual services.
Owned by small teams
Small, independent teams typically build out a service within microservices, which encourages the adoption of agile practices and DevOps. Teams are empowered to work independently and move quickly, which shortens development cycle times.
Organized around business capabilities
A microservices approach organizes services around business capabilities. Teams are cross-functional and have the full range of skills required for development, working to fulfill an individual functionality.
Teams that build and maintain microservices typically use infrastructure automation practices like continuous integration (CI), delivery (CD), and deployment (also CD). This allows teams to build and deploy each service independently without affecting other teams. It also allows teams to deploy a new version of a service side by side with the previous version.
Example of a microservice architecture
Consider a hypothetical e-commerce software project as an example. The following diagram is of an e-commerce site with a web application and mobile application that interacts with multiple microservices, each of which provides specific capabilities for a domain.
Modern web applications run in browsers and are often served from a content distribution network (CDN). A CDN provides the benefit of distributing web applications to servers around the world, so they can be downloaded by web browsers quickly. CDNs are also used to serve media assets like images, audio, and video. For example, in this system, the images and videos of the goods for sale are served from the CDN.
The microservices in this graphic are:
Account service provides information about the customer account, such as address and payment information.
This offers up-to-date inventory information for goods the customer can purchase.
Shopping cart service
A customer uses this to select the goods from inventory they wish to purchase.
Customers pay for the goods in the shopping cart.
This schedules the packaging and delivery of the purchased goods.
The applications interact with the microservices via REST APIs that each of the microservices publishes. An API Gateway allows the applications to rely on the APIs provided by the microservices and allows the microservices to be swapped for other microservices with the same API.
Each microservice is composed of a service and database. The services handle the REST API, implement business logic, and store data in a database. For microservices, we isolate their resources such as databases and queues from each other, following the 12 Factor App contract.
How to build microservices
For many organizations, starting with a monolith architecture is the first step. Then, you will need to split the codebase into multiple services, implement the right patterns to fail gracefully and recover from network issues, deal with data consistency, monitor service load, and more. But that’s just the technical side. You’ll also need to reorganize your teams and most likely embrace a DevOps culture.
Then comes the hard part: you’ll need to decompose the monolith into microservices. Refactoring a monolithic database schema can be a delicate operation. It's important to clearly identify which datasets each service needs and any overlaps. Continuous delivery helps reduce the risks of release failure, as well as ensure your team is focused on building and running the application, rather than being stuck deploying it.
Microservices vs. monolithic architecture
A monolithic architecture is a traditional model of a software program, which is built as a unified unit that is self-contained and independent from other applications. A microservice architecture is like an inverse of a monolith, since it is an architectural method that relies on a series of independently deployable services. Monoliths can be favorable early in a project's life due to the ease of code management, cognitive overhead, and deployment. Once a monolith application becomes large and complex, it becomes difficult to scale, continuous deployment is challenging, and updates can be cumbersome.
While a monolithic application is built as a single, indivisible unit, microservices break that unit down into a collection of independent units that contribute to the larger whole. An application is built as a series of independently deployable services that are decentralized and autonomously developed.
Microservices fall under the category of a distributed system. By definition, a distributed system is a collection of computer programs that utilize computational resources across multiple, separate computation nodes to achieve a common, shared goal. Distributed systems help to improve system reliability and performance and allow easy scaling.
The nodes in a distributed system provide redundancy, since if a node fails the other nodes can replace the failure. Each node can scale horizontally and vertically, which improves performance. If a system undergoes extensive load, extra nodes can be added to help absorb the load.
Kubernetes vs. Docker
Docker is a commercial containerization platform and runtime that helps developers build, deploy and run containers. While Docker provides an efficient way to package and distribute containerized applications, running and managing containers at scale is a challenge with Docker alone.
Kubernetes is a popular open-source platform that orchestrates container runtime systems across a cluster of networked resources. It can be used with or without Docker. While Docker is a container runtime, Kubernetes is a platform for running and managing containers from many container runtimes.
Software configuration management is a process that manages, organizes, tracks, and monitors changes to a software systems configuration metadata. It is commonly used alongside version control and CI/CD infrastructure.
Configuration management helps engineering teams build robust and stable systems through the use of tools that automatically manage and monitor updates to configuration data. It helps to better manage software sprawl in a microservice architecture by creating a “source of truth” with a central location for configuration.
Bookmark these resources to learn about software development and ongoing updates about Compass