What are microservices?
Microservices is an architectural pattern that divides a large application into a collection of separate, modular services. While there is no precise definition of this pattern, microservices can be loosely characterized by businesses decentralizing their data and application into multiple, self-contained code bases.
So, what does this all mean?
Monolithic architecture
To understand microservices, it’s helpful to first understand what monolithic architecture is. In the 1990s, internet companies would develop server-side systems with a single code base and application. The visualization below is an example (imagine that each block is a feature that is packaged into one application).
Now, say an online store has a series of features: searches, likes, ratings, etc. As the application expands, more features are “packaged” into a single application. With this monolithic design, certain challenges arise:
- Dependence: Components are heavily dependent on one another because they share libraries. When you make a change in one component, other components will be affected. When there are more and more components, it becomes increasingly difficult to track changes, which increaes the risk of bugs.
- Deployment: With a monolithic architecture, updating an application is difficult. If a feature ever stops working, the system must be shut down and re-deployed. This requires building and stabilizing the entire application each time, which consumes extensive resources and time.
- Framework & language: If the application is using a specific language or framework, it is difficult to migrate technologies because everything is very dependent upon each other.
Microservice architecture
Now that you understand the challenges associated with a monolithic architecture, here’s where microservices come in.
Businesses find it favorable to utilize this environment where services are split up so that they are self-contained and self-deployable. Each service (likes, search, ratings, catalog, purchase, etc.) is packaged in its own container and communicates with other applications through APIs. There are many benefits to this.
-
Iteration: Teams can focus on updating their application independently from other services and redeploy quickly. This design takes less time, uses fewer resources, and reduces the risk of other components breaking.
-
Language/Framework: Teams are not bound to one language or framework since each application is independent of one another. This increases overall flexibility and specialization.
-
Independent Scaling: As a service is being over-utilized, companies can add more CPUs, memory, etc. independently. This allows for more efficient use of resources as each VM profile is isolated per service.
