Web Application To Microservices (Microservices — Part 01)
Businesses today use a host of SaaS applications — Those applications generate terabytes of data. Oftentimes the data in multiple platforms can be related — such as an address on a credit card used for an eCommerce purchase, which is also useful as an address for a shipping platform — and that eCommerce transaction itself can be tracked by a company’s analytics platform.
Businesses have two broad choices when it comes to rolling out technology stacks: deploy a single platform that combines many functions or take a best-of-breed approach that uses microsystems to integrate discrete services from different vendors.
Monolithic architecture
Monolithic applications are designed to handle multiple related tasks. They’re typically complex applications that encompass several tightly coupled functions.
For example, consider a monolithic eCommerce SaaS application. It might contain a web server, a load balancer, a catalog service that services product images, an ordering system, a payment function, and a shipping component.
As you can imagine, given their broad scope, monolithic tools tend to have huge codebases. Making a small change in a single function can require compiling and testing the entire platform, which goes against the agile approach in today’s developer's favor.
Advantages of Monolithic
- Ease of development and monitoring
- Less latency
- Less complication about crosscutting concerns
Drawbacks of Monolithic
- This simple approach has a limitation in size and complexity.
- Application is too large and complex to fully understand and made changes fast and correctly.
- The size of the application can slow down the start-up time.
- You must redeploy the entire application on each update.
Microservices Architecture
Microservices are an approach to application development in which a large application is built as a suite of modular services (i.e. loosely coupled modules/components). Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other sets of services.
Instead of sharing a single database as in a Monolithic application, each microservice has its own database. Having a database per service is essential if you want to benefit from microservices because it ensures loose coupling. Each of the services has its own database. Moreover, a service can use a type of database that is best suited to its needs.
Advantages of microservice architectures
- Improved productivity
- Better resiliency
- Independently scalable
- Independently deployable and allow for more team autonomy
- Reduce downtime through fault isolation
- The smaller codebase enables teams to more easily understand the code, making it simpler to maintain.
Disadvantages of microservice architectures
- Microservices create different types of complexity than monolithic applications for development teams.
- Interface control is even more critical
- Up-front costs may be higher with microservices
One of the features was we should be able to scale independently.
Scale Cube in Microservices
Scale cube is a scaling model introduced by “The Art of Scalability” book. According to this model, the scaling is done in 3 main axises namely X, Y, and Z.
- X-axis: The application should be able to scale out through the x-axis.
- Y-axis: It should be able to functional decomposition
- Z-axis: Each server runs an identical copy of the code. However, each server is responsible for only a subset of data.
Characteristics of Microservices
- Microservice architectural style is an approach to developing a single application as a suite of small services.
- Services are built around business capabilities, independently deployable and packaged, each running in its own process.
- Each Service should have a separate database layer.
- Each Service can have an independent codebase, CI/CD tooling sets.
- Each Service can be tested in isolation without dependent on other services.
- Each service can pick the best technology stack for its use cases (no need to stick into one framework throughout the entire application).
- Each Service should have monitoring and troubleshooting capabilities for the operation team
- Services should implement Retry functionality in case of network failure or system failure
- Each Service can implement an independent security mechanism
- The main difference between SOA and MicroServices is that a microservice employs a practice that attempts to eliminate any dependencies on other microservices. SOA does not make this
practice explicit as a requirement. - Services can use HTTP(Rest) or message for communication or any other lightweight communication protocol.
- Well understood Distribution Transaction management
- Presenting API
- Clean and Clear Separation of Stateless and Stateful Services
- Do Not Share Libraries or SDKs
- Each Service can be run without waiting for another service to go online
- Implement a Self-Registration and Discovery Mechanism
- Service can use different language, framework, and technologies
- Maintain Independent Revisions and Build Environments to maintains compatibility with other services.
- An architect can explicitly check for rules and constraints.
Monolith vs. microservices
So which architecture is better? The answer depends on the needs of each individual organization. Businesses should consider several criteria:
- Ease of implementation — You might think that monolithic systems would be easier to implement since the software comes from a single vendor. That’s not always the case. Because monolithic systems tend to be complex, they may be as difficult to roll out as multiple individual platforms. One area where they can have an advantage is that monolithic systems are a one-stop shop for support — but that’s only an advantage if the vendor has a reputation for good support.
- Vendor lock-in — Typically, monolithic systems attempt to cover a broad set of related functions. A monolithic web hosting platform, for instance, might include not just a web server that handles HTTP requests on the server-side but also firewalls, load balancing, and a content distribution network. But because they’re designed to “do it all,” monolithic systems typically don’t work well with other systems.
- Control and ownership of their data — Monolithic systems don’t make it easy for organizations to integrate the data from their systems. You typically can use your data only within the monolith. For example, a monolithic analytics system that includes data integration, ETL data pipelines, a data warehouse, and analytics software may not provide tools that permit organizations to access their own data to integrate it with other systems or run analytics using different software.
- Return on investment (ROI) — There’s no point in rolling out any application without a positive ROI. Whether you’re developing your own applications or deploying SaaS solutions, your software engineering team can create microservices relatively quickly, roll them out as they’re ready, and let customers (external or internal, depending on the application) begin using them. You can get a faster time to market and a positive ROI from your services incrementally as you deploy them.
The industry seems to be moving from monolith to microservice because it’s hard to combine in a single platform all of the capabilities that businesses need and want, and that works the way they already run their businesses. Most businesses have a better overall experience by deploying the best or most suitable solution for specific needs and tying them together via application integration.
References:-
