單體式與微型服務有何差別？

Both terms “monolithic” and “microservices” refer to software architecture approaches used in designing computer applications. Often they are compared, and microservices are presented as a solution to the deficiencies of monolithic architecture, and this is mostly true. However, both approaches have historical underpinnings that date back to early distributed systems, but can be thought about as distinct ways to solve software design problems given limited resources and technology. Modern technology, especially virtualization and containerization, grants new capabilities that elevated microservices as a significant engine for efficiency in the cloud computing world, but because many legacy systems were built before these technologies, they relied on single-tiered application approaches.

Monolithic architectures are single-tiered applications, including all the data access and user interface in one package for a single platform—think back to buying software in a box at a local store. For home users, this may seem manageable. For enterprise level applications, these monoliths can be problematic to debug, update, and develop new releases, especially while maintaining smooth business operations. Microservices architecture, on the other hand, is not a single application, but several small services working together, contributing to the whole user experience. A microservices approach and monolithic approach seem to be on opposite ends of a spectrum, but the idea of microservices is a response to the unwieldy mess that many monolith codebases have become.

Oftentimes, it is advised not to develop microservices-based applications from the ground up. It is better to begin with a central code base and migrate functionality to microservices. While at first skipping the monolith altogether seems like a plan for potentially saving huge chunks of engineering time. But, by developing initial iterations into one application, teams actually save time, money, and management headaches because the code base is centralized and the inherited microservices dependency structure is not needed. In these beginning stages of development, this is simpler. Eventually, as services within the monolith demonstrate stability, they can be cleaved off into their own microservice, and removed from the monolith code.

Those microservices are now independent, capable of scaling as needed. Cleaving off the code which is most suited for scaling makes a good first microservice candidate. Individual teams can then be assigned to manage those microservices with dramatically less difficulty, and better efficiency.

Compared to monolithic code bases, microservices architecture approaches use virtualization and containerization as a vehicle for service delivery. Service functionality is contained within microservices, and tens, even hundreds of unique microservice can comprise the total functionality of a monolith application.

Microservices are small apps designed to fulfill a single purpose. Each microservice is principally in charge of a single “concern” within the larger system, perhaps surrounding a business line, and operates like a black box, communicating with the outside through REST APIs, event streaming, and message brokers. Microservices architecture commonly aims at breaking down larger applications into smaller services, each acting as their own service component to other microservices, or larger programs, giving information upon request, but also creating an interworking set of independent services.

An independent microservices approach to deployment affords organizations several capabilities over traditional monolithic approaches:

●       Code is partitioned into microservices, encapsulating just that code specific to the concern of the component, updates can be more easily made, new features more easily added, all without disturbing other application code.

●       Universal communication through APIs allows microservices to be written in whichever language is necessary, convenient, or available, and still be able to interact with other microservices.

●       Microservices can be individually scaled to fit the demands on the system with ease.

Conceptually, microservices are an idea born out of service-oriented architecture (SOA). But, technologically, microservices are an evolutionary step from SOA, thanks to the supporting technology of virtual machines, containers, and container orchestration software.

The main advantage of microservices comes from its flexibility in subdividing and compartmentalizing large programs into the basic functional units, and then encapsulating those functions in virtualized containers provisioned with the exact resources that container needs. This allows modern server technology to scale these services on-demand, quickly, by simply making copies of those service containers when the existing services reach their capacity. This style grants developers several advantages.

●       Market Readiness Increased — Microservice architectures support agile deployment reducing development cycles, ultimately bringing services to market faster.

●       Improved System Scalability — With containerized microservices, as demand increases, additional servers can be deployed quickly and easily.

●       Heightened Resilience —  Independent services are fault isolated, if one service fails, it can be destroyed without impacting any other services.

●       Enhanced Development and Deployment — Microservice-based applications are easy to deploy, localize complexity, increased developer productivity, simplified debugging and maintenance, and enable smaller more agile development teams.

●       Future-proofed Applications — In many ways, microservices are future-proofed apps: innovation is easier to adopt in virtual environments; microservice size reduces experimentation risks; microservices can be built around business lines improving developer and business user alignment.

When should a development team use microservices? The time to use a microservices approach may not be at the beginning of development. While microservices do impart many advantages that successful applications use, the technologies pose other developmental concerns beyond developing the underlying application logic. At the beginning stages of development, especially during MVP stage, it is helpful to develop in a monolith method, in order to minimize the overhead of delivering services. Once areas of functionality become stable within the main code base, then they can be separate from the monolith into their own microservices. Shifting to microservices is useful when scaling will be critical, or when disparate services use other languages.

Choosing an approach to software architecture design depends on the end use. The following table with factors for comparison, should help to align decisions over monolithic or microservices with the end need.