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?
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:
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.