If we are developing a server
side enterprise application for
- Variety of client like Desktop Browser, Mobile Browser and Native Mobile Applications.
- Exposing APIs for 3rd parties to consume.
- It might also be able to integrate to other application via web services.
- Application handles HTTP request and messages by executing business logic, accessing database exchanging data with other system and returning a HTML/XML/JSON response.
- The application has a layered architecture and consists of different types of components like
- Presentation components - responsible for handling HTTP requests and responding with either HTML or JSON/XML (for web services APIS)
- Business logic - the application’s business logic
- Database access logic - data access objects responsible for access the database
- Application integration logic - messaging layer, e.g. based on Spring integration.
We have two kind of architecture to manage applications.
Monolithic Application
When the application becomes
larger then this approach many number of drawbacks …
- The application can be difficult to understand and modify resulting development goes slows down.
- Larger the code base will slow down the IDE resulting the less productive developers.
- Overloaded web container, longer it takes to respond.
- Continuous deployment is difficult because a minor update in any component resulting re-deploy whole application.
- Scaling the application in terms of transaction volume is bit easy by running same code on multiple servers but scale with an increasing data volume is too difficult because all app instance will be accessing the same database.
- Scaling the application in terms of development is also difficult, even if we divide team with their responsibilities. Because it prevent teams working independently, teams have to coordinate their development effort to each other.
- Requires a long-term commitment to a technology stack - a monolithic architecture forces you to be married to the technology stack (and in some cases, to a particular version of that technology)
The microservices
architecture is an
alternative pattern that addresses the limitations of the monolithic
architecture.
Microservices Application
Architect the application by
applying the Scale Cube (specifically y-axis scaling)
X-axis scaling – consists of running multiple copies of an application behind a load
balancer.
Y-axis scaling – splits the application into multiple, different services. Each service is
responsible for one or more closely related functions. There are different ways
of decomposing the application into services.
Use verb-based decomposition
and define services that implement a single use case such as checkout.
Use noun-based decomposition
and define services responsible for all operations related to a particular
entity such as customer management.
An application might use a
combination of verb-based and noun-based decomposition.
Z-axis scaling – splits are commonly used to scale databases. Data is partitioned across
some servers. Like primary key of the table is used to partition the rows
between two different database servers.
Benefits
- Each server only deals with a subset of the data.
- This improves cache utilization and reduces memory usage and I/O traffic.
- It also improves transaction scalability since requests are typically distributed across multiple servers.
- Z-axis scaling improves fault isolation since a failure only makes part of the data in accessible.
Drawbacks
- It increases application complexity.
Benefits
- Each microservice is relatively small
- Easier for a developer to understand
- The IDE is faster making developers more productive
- The web container starts faster, which makes developers more productive, and speeds up deployments
- Each service can be deployed independently of other services and easier to deploy new versions of services frequently also.
- Easier to scale development. Suppose there are multiple team working on different services then each team can develop, deploy and scale their service independently of all of the other teams.
- Improved fault isolation. If there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests.
- Eliminates any long-term commitment to a technology stack. Because for new service we are free to be upgrade technology.
Drawbacks
- Developers must deal with some complexities of creating a distributed system.
- Testing is more difficult.
- Developers must implement the inter-service communication mechanism.
- Deployment complexity. In production, there is also the operational complexity of deploying and managing a system comprised of many different service types.
- Increased memory consumption. The microservices architecture replaces N monolithic application instances with NxM services instances.
