Cloud upon Cloud

Low-Cost Cloud

In a certain sense, Eight can be viewed as a lightweight cloud. Compared to current cloud technologies (such as Docker-based Kubernetes or Mesos), it is simpler, more agile, and easier to use. It is suitable for enterprises with weak software and hardware infrastructure, as well as users lacking professional technical teams. For small and medium-sized enterprises that lack financial and talent resources, it is an affordable cloud solution.

Eight has established a new cooperation model, delineating a more sensible boundary between software users and maintenance managers. This significantly reduces the resource and capability requirements for users while also lowering the access costs for maintenance managers. This new form can rapidly build complex software systems and service clusters in barren environments and with limited technical support, allowing quality technical capabilities to penetrate deeply into enterprises.

However, Eight occupies a different niche from cloud containers and is complementary to them. In fact, Eight can be used to overcome many issues present in current cloud technologies. Even for enterprises with mature cloud technology applications, such as internet companies or large private cloud enterprises, using Eight has profound significance.

Drawbacks of Microservices

Modern clouds primarily adopt a microservices architecture based on virtualization (hardware resource layer) and containerization (application service layer). The microservices architecture itself has several drawbacks.

Firstly, microservices complicate and fragment systems, leading to significant operational consumption:

(A certain company’s cloud environment architecture diagram, thanks to a friend’s great assistance)

• The fine-grained componentization and modularization of microservices turn a system into one with dozens, hundreds, or even more components, each requiring independent configuration, deployment, operation, and interconnection.
• Technologies like Docker, Kubernetes, and Istio can somewhat reduce this complexity, and intelligent Devops can assist in troubleshooting to some extent. However, configuration and deployment, service interconnection, daily maintenance, and fault handling still consume significant manpower.
• The extensive dependencies of microservices make the system sensitive to external environments. Many deterministic issues become uncertain due to service segmentation, complicating problem tracking.
• Numerous heterogeneous subsystems require maintenance personnel to have a certain level of understanding of various technologies, imposing high demands on personnel.

Moreover, cloud-native itself brings numerous issues:

(A certain company’s cloud-native architecture diagram, thanks to a friend’s great assistance)

• Microservices inherently bring numerous additional modules, such as service registration and discovery modules, message queues for asynchronous service request caching, service link analysis modules, service meltdown and degradation modules, service observation and fault tracking modules, distributed transaction schedulers, etc., which further increase system complexity.
• The development of microservices makes future software architecture cloud-native (e.g., Service Mesh, FaaS, Serverless), making it difficult to separate from cloud infrastructure, challenging to replicate, migrate, and widely use.
• Cloud-native will bring even more additional modules, such as multi-cloud hybrid deployment scheduling, FinOps cost management, AIOps intelligent operations, etc. These elements, originally brought by microservices, are not business requirements, and their usability and reliability also need DevOps to ensure, causing system complexity to spiral upward during cloudification.
• The construction, development, maintenance, and operation costs of cloud infrastructure are high and require high-quality teams for management and continuous optimization, which most enterprises cannot afford.

Secondly, microservices also bring numerous impacts to the application system itself:

• Service Dependency and Fault Tracking:
  • Excessive service orientation leads to complex system structure, causing service dependency and fault tracking issues. Microservices do not completely decouple dependencies but rather complicate them. The original intention of microservices is to decouple module connections through servitization, so local system adjustments do not affect the whole. However, in practice, this dependency often internalizes into the service’s internal logic (latent dependency), making the impact range difficult to assess, with core services becoming too complex to change;
  • Originally unrelated modules become related due to various indirect connections, causing the microservices architecture intended to break coupling to couple due to common services;
  • Service governance and fault localization become challenges, requiring tracking of the dependency chain for module issue troubleshooting;
  • Under extensive dependencies, the impact range of modules is difficult to assess, making module modifications and faults difficult to control.

• Service Unavailability:
  • The autonomous architecture of microservices necessitates handling service unavailability at any time, which is not easy to solve;
  • Using message queues for request caching is only applicable in scenarios without strong transaction requirements and service response speed requirements, unable to guarantee service quality and final service achievement;
  • Using service meltdown or degradation requires all business units to handle related business logic or load processing modules, increasing development and testing complexity;
  • Moreover, meltdown and degradation do not solve service unavailability issues, only providing degraded service responses (or merely indicating service exceptions).

• Data and Business Splitting, Transaction Consistency Challenges. Microservices split a business into several service stages because:
  • The business is only completed when all services are finished;
  • No single service can control and manage the state of other services;
  • Each stage’s module manages its own data;
  • These data need to be in a consistent state at the transaction level;
  • Consequently, a simple transaction becomes a distributed transaction, with transaction completion or rollback requiring other modules (like a transaction coordinator) besides the business module to ensure, increasing complexity and overhead, and making final consistency difficult to guarantee.

• RPC Consumption:
  • Microservices require modules to connect using inter-process communication, using network communication protocols (HTTP RESTful, RPC, etc.);
  • The RPC process (serialization, network interaction, fault reconnection, deserialization) brings significant consumption;
  • Moreover, microservices change data previously transmitted via memory (single system module calls) to network transmission, causing the system to demand rapid increases in network bandwidth and stability, posing high requirements on enterprise hardware infrastructure;
  • Even network issues themselves no longer affect only client-server requests and responses, with every business step potentially failing due to network faults;
  • This situation did not exist before using microservices.

There are many more such issues. In fact, for many business scenarios, the problems brought by using microservices outweigh the solutions. Their high usage costs and personnel requirements are challenging for ordinary enterprises to bear.

But are these problems really caused by cloud technology?

Not exactly. Docker-based cloud technology itself is a great technological innovation, establishing a controllable application layer management architecture. However, it has been misused, with problems not belonging to the application layer being fragmented into numerous services and handed over to it. This is the origin of the recent service-oriented transformation, further deriving cloud-native architectures. In fact, most problems concentrate on the business layer above the application layer, with more concise and elegant solutions available.

So what problems are these service-oriented approaches trying to solve? What was the initial cause of the problem?

Root of the Problem

To understand the root cause of the problem, one must understand why the microservices architecture was born and what problems it tries to solve. Compared to the monolithic architecture systems that microservices replace, microservices still have clear advantages:

• System Modularity. The biggest feature of microservices is modularity (service orientation), with benefits including:
  • Forcing developers to decompose the business domain using a modular method;
  • Forcing developers to delineate module boundaries from the design stage;
  • Forcing developers to standardize the functions, interface definitions, and input/output of each module;
  • Forcing developers to continuously abstract and extract new public modules as the business system evolves;
  • The benefits of modularity itself are numerous, such as:
    • Divide and conquer problem-solving;
    • Division of labor and collaboration in large systems;
    • Natural adaptation to the development model of internet enterprises.

• Rapid Development, Partly Deployment, Group Maintenance, and Micro-Iteration. For internet enterprises, the lifecycle of industry software is shortening, with demand changes and iterations becoming more frequent:
  • Common service components can quickly build a basic framework for new businesses;
  • Constantly changing demands reflect iteration needs for certain modules;
  • Microservices isolate changes within certain modules, facilitating rapid response;
  • Microservices can locally deploy new modules without changing the overall system, significantly reducing the cost of system iteration;
  • The entire iteration process of microservices is minimally invasive, causing relatively minor impacts;
  • Microservices facilitate personnel and work organization in internet companies, allowing different specialists to maintain different services of the system.

• Elastic Scaling, Partly Expansion, and Demand Adaptation:
  • Different businesses, different development stages, different time points, and different modules may have vastly different computation and response scales;
  • Dynamically increasing and decreasing cluster capacity as needed becomes very important;
  • Microservices divide businesses into different modules, allowing dynamic addition of processing nodes when modules overheat (sustained high-intensity response) and reclaiming computing resources when modules cool down. Additionally, since service modules are relatively small, these resources can be effectively applied to critical computing logic.

• Integration of Heterogeneous Systems and Introduction of Advanced Technologies. Each service unit of microservices, as long as the interface and input/output are specified, can be implemented using any technical framework:
  • It is easy to use more advanced and effective technical means to enhance the service capability of a specific independent module, thereby improving the overall system’s service indicators;
  • It is easy to analyze and compare the differences in service capabilities of different technical implementations under unchanged other environments, providing practical basis for technical choices;
  • It is easy to replace key parts of the system with advantageous technical modules (such as Python for data analysis, Go for network communication), thereby enhancing the overall system’s capabilities.

Careful analysis of the above advantages reveals that the first two points and the latter ones are not on the same level. The first two are about the business’s development and changes, while the latter ones are about the system’s operating resources and environment.

In fact, the core significance of microservices lies in the first two points. The background of microservices’ birth is the increasing complexity of businesses and the continuous expansion of system scale, making monolithic applications no longer sufficient. Microservices make the development, collaboration, management, upgrade, and maintenance of a large-scale system technically possible.

The third point is the convenience brought by containerization technology, allowing business system expansion to follow business scale changes. This is one of the most valuable features of containerization but is unrelated to the business implementation method. In other words, whether the business system is designed and developed using microservices, containerization can provide dynamic expansion elasticity, even if it is a monolithic application.

The fourth point is an optional feature with pros and cons. After all, as long as the function is completed, the application system does not necessarily have to adopt various different technologies. Using multiple technologies inevitably negatively impacts personnel capabilities, technology stacks, environmental resources complexity, and system maintainability.

Therefore, the containerized cloud architecture itself is still quite valuable (but not indispensable, especially considering its high cost), but the microservices system design philosophy may not be.

Cloud Upon Cloud

Through the above analysis, we can see that microservices essentially solve the problem of large-scale system segmentation and division. This problem was originally a business-level structural design problem, which ultimately became an application-level architectural solution. This unfortunate situation fundamentally stems from a cognitive bias, leading to a deviation in software engineering.

Previously, when introducing the principles of Eight, we discussed why dynamic systems are difficult to achieve, analyzing why systems are difficult to segment, develop separately, and dynamically assemble. We proposed that cognitive biases are the main culprits making systems difficult to modularize.

Eight’s unique worldview and design philosophy indicate another path. After all, the core problem microservices aim to solve is: modular development and collaboration of complex systems, rapid iteration, and partly updates, which Eight addresses in another complete way:

• Eight is a monolithic process externally but a componentized system internally. Its component architecture is within the process, combining the advantages of both;
• Compared to monolithic applications, any local part of the system can independently become a component, independently developed, deployed, and maintained, capable of partly updates. Components are completely decoupled, with no dependencies, and any changes do not affect other parts, allowing rapid iteration;
• Easy to expand nodes and deploy, suitable for elastic scaling control;
• Can dynamically update at runtime, achieving seamless switching without service downtime. Eight’s business update is a thread loading operation, with no process restart and no runtime state loss. Therefore, even if Eight completely replaces a system, the process is seamless and transparent. The previous request may still use the old code and data, while the new request simultaneously uses the new code and memory data structure. The old code and data are only released when no longer referenced, providing an unprecedented solution for continuous high-sensitivity business upgrades;
• Can easily deploy application systems to thousands of nodes, with very light application size, with individual component sizes often only tens to hundreds of kilobytes;
• Compared to microservices, Eight is a very lightweight cluster, requiring only one command to run a jar package, simple and convenient to build, with almost no skill requirements;
• Eight does not require a heavy cloud platform environment, with no complex support services such as service registration and discovery, service call chain management, service request message queues, meltdown, and fault transfer, significantly reducing application system complexity, making it easier for general enterprises to implement;
• Compared to Docker’s process restart, Eight’s component loading and unloading are lighter. Compared to Docker’s second-level updates, Eight’s updates are millisecond operations, consuming less network bandwidth and computing resources;
• Eight’s components have a naturally finer granularity than microservices’ services. They can better segment systems, with stronger observability, faster dynamic updates, and lower resource consumption;
• When combined with containerized cloud environments, it can combine many previously fragmented microservices modules into one node, reducing the number of microservices, simplifying system structure and complexity;
• Eight has the advantages of monolithic applications, such as no component unavailability issues, unified transaction management for the entire business process, no RPC calls, saving serialization and network operation consumption.

So, can Eight scale and shrink like microservices? With Eight’s capabilities, it is not difficult. After all, the number of components and systems running on Eight’s nodes are controllable. However, when combined with a cloud environment, there is an even more elegant solution.

Eight itself is very suitable to be packaged as a service into a Docker image and integrated into the cloud platform. As we can see, Eight’s seat is stable and unchanging, and it only requires one command to become a node. The business running on the node is dynamically changed and easily controlled through network publishing. Eight is naturally cloud-native.

If an enterprise already has a private cloud environment, deploying an Eight cluster is very convenient, easily expanding to thousands of nodes. At this point, it is best for the cloud platform to handle system elasticity, as Eight is more inclined to become the business layer architecture.

As mentioned earlier, cloud technology is a great advancement, but it has been misused. In fact, as a facility at the application layer, containers should provide application layer toolkits, such as various application services (Eight, Kafka, Nginx) and data services (MySQL, Redis, Hadoop) management, as well as the expansion and contraction of these service resources, service state monitoring, and maintenance. They should not involve business segmentation and module division, business layer matters should be handled by the business layer cloud.

As shown in the figure, the future cloud architecture will have more distinct layers, with clearer boundaries for each layer:

• OpenStack or similar public clouds mainly provide hardware infrastructure, centrally managing hardware computing resources and storage devices, and providing them as allocable units for upper layers;
• Docker-based cloud containers are applications built on hardware and operating systems, providing various application services, including service deployment, management, and scaling;
• The business layer based on Eight is the platform for business implementation and assembly, the center for component repositories and application management. Software development, module division, business segmentation, developer collaboration, application assembly, and deployment should all be realized at this level.

This architecture is the future direction for large-scale system development. After Eight-based transformation of the microservices architecture, we will gain a new cloud layer, greatly expanding the capabilities of the cloud architecture:

• Eight replaces microservices for business layer segmentation, omitting unnecessary segmentation of microservices, significantly reducing the number of microservices, simplifying system service dependencies, enhancing system robustness and manageability;
• Eight provides a new dimension for cloud systems: business layer virtualization, allowing cloud managers to delve into runtime business modules for observation, analysis, debugging, and fine-grained management;
• Eight can adapt to business changes more lightly and cost-effectively, providing better choices for handling transactions, RPC, and other issues.

Of course, for small and medium-sized systems, Eight’s architecture has many optional solutions and does not necessarily rely on cloud architecture:

It can be seen that Eight can easily deploy systems in various environments and conditions, and can deploy clusters in various hybrid environments, as long as these nodes are added to the same management platform.

Cloud Beyond Cloud

A basic feature of the cloud is to shield the differences of heterogeneous systems downwards and provide a unified functional interface upwards. Each layer of the cloud plays such a role:

• The IaaS layer virtualization shields hardware layer differences, providing unified, unitized hardware resources above, such as CPU, memory, network bandwidth, and storage space.
• The container layer masks runtime environment differences, offering a unified application execution environment above, such as the operating system kernel and various dynamic link libraries on which Docker is based.
• The Eight layer masks differences in business modules, providing a unified interface specification and connection method above, thereby decoupling business development from specific hardware resources, execution environments, and external business dependencies.

Simultaneously, just as Docker does not rely on IaaS, Eight does not rely on Docker or K8S. Each cloud layer masks the differences below it for the systems built upon it, so the systems above are not constrained by the differences below. When a virtual machine image runs in a virtual machine, it does not need to identify or be affected by the underlying hardware devices. When a Docker image runs in a container, it does not need to consider whether the underlying environment is K8S or a simple Docker setup. When a set of business operations runs in Eight, it does not need to consider whether it is in a cloud environment or an independent process running on a particular operating system (the differences in hardware and application layers have already been masked by the JVM).

This is particularly significant. Considering that Eight itself is a cloud management platform, it means that an unprecedented cloud can be established: a broad cloud that spans containers and various isolated, edge, discrete systems and nodes that cannot go upon the cloud, and allows for unified development, deployment, operation, maintenance, updates, debugging, and expansion. This is especially beneficial for enterprise environments where the information and organizational architecture is more complex than that of the internet:

• Enterprises have numerous branch nodes (such as bank branches, telecom offices, supermarket outlets, post offices, petrol stations, and other large enterprise branches).
• Enterprises have numerous isolated nodes, independent systems, and traditional applications (such as industrial intelligent devices, OA office nodes, legacy traditional systems).
• Enterprises have numerous edge nodes, which are widely distributed and difficult to reach (smart cars, smart homes, IoTs).
• These nodes and systems are scattered, operate locally, cannot be cloud-enabled, and cannot be centrally managed.
• Eight has excellent compatibility, low resource consumption, and is easy to deploy, enabling the integration of various nodes into the overall environment.

Eight can establish a new form of cloud, encompassing numerous discrete and edge nodes, complementing the enterprise’s overall system. Eight can create an environment that surpasses all current cloud forms, fostering new system architectures and business solutions, extending the enterprise’s reach into every corner.