As a software engineer or system architect, when constructing a large application system, we often need to draw an architecture diagram to represent the software architecture of the application system to be developed.

I think a lot of software developers have this question: what’s behind all the talk of microservices, containerization, for years? What kind of technical architecture should be used for new or existing software systems? If you need a makeover, what should you do?

Hope to give you some inspiration through reading this article.

Application server is the mainstream deployment environment for application development in recent decades. Taking the Java language community AS an example, Java EE application server is a major product in the field of software middleware development, including Weblogic, Websphere Commercial products, JBoss AS(Wildfly), Glassfish open source products, There are also Servlet container servers such as Tomcat and Jetty, and Spring Framework application Framework, which together constitute the most important part of commercial business software.

Container Docker, container programming Kubernetes and so on have brought the wave of containerized microservice software technology. Internet companies, as pioneers, have led the method reform of software design at home and abroad. Cloud Native has become an essential factor to be considered in current software design.

So, is there a technical correlation between a “traditional” application server and Kubernetes? If so, what are their internal connections?

I found two pictures in the professional technical website, which are respectively the complete JavaEE implementation Wildfly application server domain pattern and kubernetes architecture architecture diagram.

Photo credit:

https://kb.novaordis.com/index.php/Wildfly_Domain_Mode_Concepts

Photo credit:

https://x-team.com/blog/introduction-kubernetes-architecture/

The above two diagrams do not represent all the technical architectural details of the two products, but they do represent the architectural characteristics and the relationships between the components.

We found a lot of similarities between the two architectures:

  1. Each has a master node. Kubernetes is called Master Node. Wildfly contains Host1 of domain Controller, which is also the Master Node.

  2. Manage multiple working nodes through the master node. Kubernetes has two Worker nodes, and the Wildfly diagram also has two Worker nodes host2 and Host3.

  3. Administrator through the management interface (Rest API) to manage the entire system, Kubernetes is through Kubectl access API server, Wildfly is through jboss- CLI tool access management interface, The server processing component is the Domain Controller. Of course, they also provide graphical management tools.

  4. Kubernetes is kubelet and kube-proxy. Wildfly is host controller and process controller. Among them, Kubelet and host Controller have similar functions, both of which play the role of communication between the working node and the master node and management of the working process of the node.

  5. There are multiple worker processes on each worker node, except that Kubernetes manages pods by containers, while Wildfly manages worker threads by JVM processes.

In addition, it is not shown in the diagram. There are other similar concepts in logic:

  1. The controller-manager in Kubenetes consists of various functional controller modules. There are similar modules in Wildlfy, and in Domain Controller, which are extensible.

  2. Rest API external interfaces are in simple Json format. For high efficiency, the communication mode between each node is binary data flow, and encryption mode can be configured.

  3. In the worker process, though, pods and threads are different. But they are also logically similar: separate bodies of work; Have a full life cycle; Pods share network, storage, and other information, and context can be passed between threads. I personally prefer to think of a Pod as a higher, more isolated “worker thread pool” of one or half dimensions.

  4. Service work units on different nodes or processes can dynamically form service groups. Wildfly has the Server Group concept. An application can be deployed to all units of work in a Server Group at the same time. Kubernetes’ pods can be selected by a defined Label, that is, they can be selected to provide services as a service group.

  5. Kubernetes has a Service to provide the Service, the information behind the Pod Service provider is transparent to the Service consumer, and the Ingress further exposes the Service capability to external applications. Wildfly provides wildfly-cluster as a reverse proxy of Service components. Although it cannot directly map network access ports through the underlying mechanism of Iptables like Service, it also has powerful features of adjusting the amount of forwarding requests according to the load capacity. More plays the role of Ingress.

  6. Kubernetes supports stateful components by hooking up Persistent Volumes with StatefulSet, and rebuilding working containers with the same state at startup. State management in Wildfly, including Stateful SessionBean, Servlet session, etc., was used to replicate state to multiple nodes through the distributed mechanism of Infinispan. There is also a remote Infinispan configuration method that logically matches Kubernates’ state management.

  7. For the security management of the Master control node, both have complete RBAC user management authentication and authorization mechanism, complete encryption mode, key configuration management and other functions.

Java EE technology has always been a complete development ecosystem, and Kubernetes is rapidly evolving into a larger ecosystem, which we analyze in terms of some aspects that are important to development.

  1. JavaEE has a standard package approach, such as building a jar, combining it into an application war, and then packaging it into an enterprise complete application ear. Kubernetes uses container images, docker’s packaging mechanism, to manage containers. On top of Docker, Kubernetes proposed the concept of Pod. For overall application deployment, the Kubernetes community currently provides the HELM tool and chart package format. It is also similar to the RPM format managed by the YUM tools.

  2. Kubernetes dynamic scaling, defined by ReplicaSets to create a specific number of instances, is arguably one of the most important features of Kubernetes. The Stateless SessionBean defined by JavaEE, in the application server implementation, will create a pool to instantiate multiple instances. Although the control granularity of the number of instances is not so fine, the number of instances can also be defined through the console. The instance pool is guaranteed by the container to ensure the number of available instances.

  3. Kubernetes uses ConfigMap to define configuration information and Secrets to define security configuration information. JavaEE has similar definitions, such as Resource and Securtiy annotations. In terms of application server extensions, Wildfly can define its own XML Schema, provide friendly and readable XML configuration information, and Security Domain/Realm to define Security configuration information.

  4. The Operator Framework, defined by Coreos (later acquired by Red Hat), is based on Kubernetes CRD (Custom Resource Definitions) and defines a complete set of methods for packaging, deploying, and managing applications. With such tools, third-party software products can provide containerized products in a relatively “standard” way. Custom Resource Definitions are an extension mechanism for Kubernetes, and we can expect three-way extensions of Kubernetes to spring up like wildfire. Wildfly, on the other hand, has sub-systems that can be developed on top of the Wildfly server kernel to extend functionality. All of Wildfly’s Java EE is implemented through sub-systems. They both extend the functionality of the Controller and hook the management commands to the API server. The design idea is surprisingly consistent!

  5. Wildfly can be managed by exposing information to the master node, or sending data to the distributed data center (for example, jolokia can be loaded) by JMX, Java Agent, Interceper, etc., and then managed by an independent or unified console. Similarly, the Istio project uses the Sidecar mode to attach an envoy module to the POD worker process, which performs traffic assignment, security management, policy setting and other functions, and is managed by the console.

  6. Kubernetes is called a container orchestration product, which describes the ability to orchestration different applications to run components that are robust according to their dependencies, according to rules defined by the implementation. There are dependencies between Java EE specifications, such as Webservice, which relies on servlets, and Wildfly, which has a component called DeploymentFramework that also handles dependencies between components. Servers declare the final state as defined by the application. Start each service one by one according to the dependency principle to ensure that the application is finally available.

After all, Kubernetes is an evolving technology with a host of new features:

  1. Storage features, Kubernetes can mount all kinds of storage, including common file system, NFS, cloud S3, open source storage solution Ceph and so on. Wildfly also uses standard operating system files and directories. Using containers, Kubernetes makes it easier to define and limit file quotas, resource usage, etc.

  2. Network features: Wildfly defines network interface configuration properties that allow you to set network IP addresses, ports, and offsets. But this is nothing compared to Kubernetes, in the Service layer, using iptables and other methods to do network request routing mapping, and commercial Kubernetes products will join SDN (software defined network) solution, Network management becomes an important part of the application system.

  3. A very important component in Kubernetes is the Scheduler scheduler, which is not fully functional in Wildfly because enterprise applications are clustered as a whole by group. Wildfly provides console tools to deploy to different nodes, and while the process can be automated and even introduce some intelligence to “schedule,” it is nowhere near as powerful as Kubernetes.

  4. The scale of management of work nodes varies. Enterprise application server clusters are generally in the tens of or so, and the Internet is tens of thousands of servers are several orders of magnitude different. The consistency requirements for transactions are also different, and they differ in the distributed distribution and replication of state information.

  5. In enterprise application servers, application context information contains transaction, security and other information, which is transmitted between threads. After application distribution, security and transaction information should also be transmitted between microservices, so distributed schemes such as OIDC/Jwt, TCC/Saga should be used. The business goals are the same, but the implementation methods are very different, and the software architecture design is very demanding.

There is no doubt that Kubernetes has won the container wars, even replacing Docker as the most important open source product in container technology. Development engineers and architects will also need to adapt to changes in microservices technology and deploy applications to the cloud, a trend that has already begun. At the same time, Kubernetes and its ecosystem also put higher demands on application development and operation. Enterprises should also consider multiple aspects when developing software applications, including application complexity, traffic, transaction requirements, operation and maintenance capabilities, etc. Then choose technical solutions and middleware products/cloud computing platforms. There is no silver bullet in software design, the best fit is the best.