Microservice Architecture for New Technologies
Part Ⅱ of Chapter Three The Container Structure in the IT Field
TL; DR
- Pros of microservices: independent deployment, high scalability, simple development and maintenance.
- Cons of microservices: complex testing and deployment, high automation.
Microservice architecture refers to an architectural style that advocates breaking the monolithic application into small, coordinated services, to provide users with the terminal value. Each service runs a specialized process. Services communicate with lightweight communication mechanisms (usually Restful API based on HTTP). They are tailored for businesses and published independently using automated deployment tools. A bare minimum of centralized management runs the architecture; multiple languages write the services; distinct data stores keep the data.
New to trading? Try crypto trading bots or copy trading
Microservices decompose a monolith into small services with high cohesion and low coupling according to business areas. Unique processes for separate services are developed and maintained by independent teams. Services communicate with lightweight communication mechanisms, such as HTTP RESTful API. Written in multiple languages, they are deployed independently and automatically and stored separately. Microservices manifest a decentralized, distributed nature. Hailed as the technical framework for the middle platform to be embedded in the IT systems, the architecture lends a hand to fast business growth and innovation, adapting to low flexibility and scalability, fast iteration, and technical-driven innovations.
Strengths of Microservice Architecture
a. Easy to develop and maintain: the services are relatively small and easy to understand.
b. Independent deployment: the modification in one service does not need coordination from others.
c. High scalability: each service scales independently of one another as required by hardware resources.
d. Match with the organizational structure: the architecture better accords with the team structure; siloed teams focus on their own priorities for higher productivity.
e. Technology heterogeneity: settles the most desirable tech for each service; trims cost for new tech trial.
f. Distinct enterprise demands: the balance between decentralization and centralized control or governance; the tradeoff between distributed database and enterprise closed-loop data model.
Cons of Microservice Architecture
a. Microservices have all the associated complexities of the distributed system. Choice has to be made between the inter-process communication mechanisms based on message passing or RPC. Codes are written for faults and fallacies of distributed computing are pondered upon.
b. Separate databases are created. Transactions must update data owned by multiple services. Challenges escalate for developers.
c. Testing comes with more complexity compared to the monolith. Similar tests force the service itself as well as its dependencies to start (or at least configure stubs for them).
d. Cross-service changes encounter mounting obstacles. Even a minor modification calls for well-tended plans and coordination.
e. Deployment unfolds in multiple steps. A microservice application typically consists of many services, each of which has multiple runtime instances. Each instance goes through configuration, deployment, scaling, and monitoring, where deployment operates in a highly automated environment.
Highlights and setbacks for monolith and microservices are not absolute as the scene or the demand may change. Preference for small services and granularity correlates with experience as well as the actual situation.
The picture above is taken from an article called Microservice Premium by Martin Fowler, revealing the relationship between productivity and complexity. At low complexity, monolith generates higher productivity. As complexity kicks in, productivity starts falling sharply. At that time, only the decoupling of microservices saves the dropping curve.
Organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations– Melvyn Conway, 1967
Simple words won’t do justice to Conway’s Law, which are condensed into four:
The First Law: Communication dictates design
The Second Law: There is never enough time to do something right, but there is always enough time to do it over.
The Third Law: There is a homomorphism from the linear graph of a system to the linear graph of its design organization.
The Fourth Law: The structures of large systems tend to disaggregate during development, qualitative more than with small systems.
The Law is hailed as the 1st law for software architecture design, a collection of laws in the business world. Conway’s Law was summited to a major IT publication and then cited by the Mythical Man-Month, the bible in the IT field. Hence, the Law first got its name and went viral since then.
The Writer Says...
NetX aims at building the Web 3 organism. We try to figure out solutions confronted by the present IT industry. To do that, we will look into every module of it to find out setbacks. Then we’ll focus on finding solutions through experiments. It’s a dynamic evolving process. To get the best solution, we have to be clear about the problems and this will be the main idea of Chapter Three. It makes me feel excited when thinking about sharing my thoughts and I do invite you to join me in this exploration and contribute to the evolvement of NetX.📚 Must Reads
NetX series 1.1 | NetX series 1.2 | NetX series 1.3 | NetX series 2.1 | NetX series 2.2 | NetX series 2.3 | NetX series 3.1
