Microservices are only for mature products
Regarding using microservices from scratch, Martin Fowler concludes:
1. Almost all successful microservices start with a monolithic application that is too large to be split.
2. Almost any system built from scratch with microservices will eventually fail due to serious problems. This situation has led many to believe that even if you are sure that your application will grow rapidly, you should not start with microservices.
It is difficult to optimize the first version of the design well. The first few iterations of a new product focus on finding the real pain points of users. Therefore, success depends on being agile and being able to optimize and refactor quickly. In this regard, microservices are much worse than monolithic applications. If you adopt microservices without being sure about the original design, your journey will be more difficult, because refactoring microservices is much more difficult than refactoring monolithic applications.
Microservices are not the best option for on-premises deployments
Since all components are dynamically changing, microservice deployment needs to be paired with a more powerful automation mechanism. In a normal environment, we can rely on continuous deployment pipelines (continuous deployment pipelines) to get the job done—task developers deploy microservices, and consumers just use online services.
However, this does not apply to the local environment. If the developer publishes a package, the consumer needs to deploy and configure other services on its own local environment, which makes deployment more challenging.
To be precise, it is also possible to develop local microservice applications, just as Semaphore (a CI/CD platform) also provides a localized deployment mode. However, we need to overcome several challenges in this process:
1. Versioning rules for local microservices need to be stricter, you have to keep track of each individual microservice participating in the release.
2. You have to do full integration and end-to-end testing because you can't test in production
3. Troubleshooting a microservice application is much harder without direct access to production
A modular monolith may be a better solution
A common reason developers want to avoid a monolith is that the monolith is more likely to become a "mountain of code shit". It was hard to add new features back then because everything was interconnected.
But a monolith doesn't have to be a mess. Take Shopify as an example: at over 3 million lines of code, it is one of the largest Rails monoliths in the world. But there is one point, too large a system will bring a lot of pain to developers:
Applications are fragile, and new code can have many unintended effects. Making some changes could trigger a cascade of unrelated test case failures. For example, some codes are reused for calculating freight and calculating tax rate, so changing the code for calculating tax rate may affect the result of freight calculation. This is a result of high coupling and lack of boundaries, which also makes test cases hard to write and runs very slowly on CI.
Instead of rewriting the entire monolithic application as microservices, Shopify chose modularity as the solution.
Modularity helps to design better monoliths or microservices. If the modules are not carefully defined, we will either fall into the traditional layered monolith (big mud ball), or worse, become a distributed monolithic application, which has the disadvantages of both monoliths and microservices .
Modularity is a lot of work, but it also brings great value, making development more straightforward. New developers don't have to know the entire application before they start making code changes, just one module at a time. Good modularity can make a large unit easier to use.
Modularization is a necessary step before switching to microservices, and it may be a better solution. Similar to microservices, modular monoliths solve the problem of code coupling by splitting the code into independent modules. Unlike microservices that communicate over the network, modules in a monolithic application communicate through internal API calls.
Hierarchical Monolith Compared with Modular Monolith, Modular Monolith has many characteristics of microservices, but it does not have many challenges faced by microservices.
How to quickly modularize a monolith?
How to quickly modularize a monolith? Using the applet container is the easiest solution. It is not as good as the pluggable technical tools provided by FinClip: this is a small program technology as a carrier and developed into a modular enterprise application architecture technology.
From the perspective of the application layer, as long as the FinClip SDK is embedded in the enterprise's App, the ability to run the applet can be obtained immediately. Regardless of the software architecture of your project, you can use this embedded applet technology to obtain the capabilities of APP parallel development, hot update, and agile iteration.
The combination of small program container and monolithic architecture can realize the separation of front and back ends. Front-end developers can focus on the interface design and interaction logic of the applet, while back-end developers can focus on service implementation and data processing, and the interface between the two interacts through the network. This approach can improve development efficiency and deployment speed, while also reducing application coupling and maintenance costs.
From a development perspective, this is a hybrid development model of "Native + Mini Program" . With this mode, the Mini Program can run in its own App, break up the bloated App functions, and decouple the functional modules from each other. Modular development, each business module does not affect each other, real-time dynamic update and release can be realized through the management background. For some entrenched projects, adopting this less invasive, pluggable technology is a worthwhile solution.