Chapter 1. Introduction to Application Development with Eclipse Vert.x This section explains the basic concepts of application development with Red Hat runtimes. It also provides an overview about the Eclipse Vert.x runtime. 1.1. Overview of Application Development with Red Hat Runtimes Red Hat OpenShift is a container application platform, which provides a collection of cloud-native runtimes. You can use the runtimes to develop, build, and deploy Java or JavaScript applications on OpenShift. Application development using Red Hat Runtimes for OpenShift includes: A collection of runtimes, such as, Eclipse Vert.x, Thorntail, Spring Boot, and so on, designed to run on OpenShift. A prescriptive approach to cloud-native development on OpenShift. OpenShift helps you manage, secure, and automate the deployment and monitoring of your applications. You can break your business problems into smaller microservices and use OpenShift to deploy, monitor, and maintain the microservices. You can implement patterns such as circuit breaker, health check, and service discovery, in your applications. Cloud-native development takes full advantage of cloud computing. You can build, deploy, and manage your applications on: OpenShift Container Platform A private on-premise cloud by Red Hat. Red Hat CodeReady Studio An integrated development environment (IDE) for developing, testing, and deploying applications. This guide provides detailed information about the Eclipse Vert.x runtime. For more information on other runtimes, see the relevant runtime documentation . 1.2. Overview of Eclipse Vert.x Eclipse Vert.x is a toolkit used for creating reactive, non-blocking, and asynchronous applications that run on the Java Virtual Machine (JVM ). Eclipse Vert.x is designed to be cloud-native. It allows applications to use very few threads. This avoids the overhead caused when new threads are created. This enables Eclipse Vert.x applications and services to effectively use their memory as well as CPU quotas in cloud environments. Using the Eclipse Vert.x runtime in OpenShift makes it simpler and easier to build reactive systems. The OpenShift platform features, such as, rolling updates, service discovery, and canary deployments, are also available. With OpenShift, you can implement microservice patterns, such as externalized configuration, health check, circuit breaker, and failover, in your applications. 1.2.1. Key concepts of Eclipse Vert.x This section describes some key concepts associated with the Eclipse Vert.x runtime. It also provides a brief overview of reactive systems. Cloud and Container-Native Applications Cloud-native applications are typically built using microservices. They are designed to form distributed systems of decoupled components. These components usually run inside containers, on top of clusters that contain a large number of nodes. These applications are expected to be resistant to the failure of individual components, and may be updated without requiring any service downtime. Systems based on cloud-native applications rely on automated deployment, scaling, and administrative and maintenance tasks provided by an underlying cloud platform, such as, OpenShift. Management and administration tasks are carried out at the cluster level using off-the-shelf management and orchestration tools, rather than on the level of individual machines. Reactive Systems A reactive system, as defined in the reactive manifesto , is a distributed systems with the following characteristics: Elastic The system remains responsive under varying workload, with individual components scaled and load-balanced as necessary to accommodate the differences in workload. Elastic applications deliver the same quality of service regardless of the number of requests they receive at the same time. Resilient The system remains responsive even if any of its individual components fail. In the system, the components are isolated from each other. This helps individual components to recover quickly in case of failure. Failure of a single component should never affect the functioning of other components. This prevents cascading failure, where the failure of an isolated component causes other components to become blocked and gradually fail. Responsive Responsive systems are designed to always respond to requests in a reasonable amount of time to ensure a consistent quality of service. To maintain responsiveness, the communication channel between the applications must never be blocked. Message-Driven The individual components of an application use asynchronous message-passing to communicate with each other. If an event takes place, such as a mouse click or a search query on a service, the service sends a message on the common channel, that is, the event bus. The messages are in turn caught and handled by the respective component. Reactive Systems are distributed systems. They are designed so that their asynchronous properties can be used for application development. Reactive Programming While the concept of reactive systems describes the architecture of a distributed system, reactive programming refers to practices that make applications reactive at the code level. Reactive programming is a development model to write asynchronous and event-driven applications. In reactive applications, the code reacts to events or messages. There are several implementations of reactive programming. For example, simple implementations using callbacks, complex implementations using Reactive Extensions (Rx), and coroutines. The Reactive Extensions (Rx) is one of the most mature forms of reactive programming in Java. It uses the RxJava library. 1.2.2. Supported Architectures by Eclipse Vert.x Eclipse Vert.x supports the following architectures: x86_64 (AMD64) IBM Z (s390x) in the OpenShift environment IBM Power Systems (ppc64le) in the OpenShift environment Refer to the section Supported Java images for Eclipse Vert.x for more information about the image names. 1.2.3. Support for Federal Information Processing Standard (FIPS) The Federal Information Processing Standards (FIPS) provides guidelines and requirements for improving security and interoperability across computer systems and networks. The FIPS 140-2 and 140-3 series apply to cryptographic modules at both the hardware and software levels. The Federal Information Processing Standard (FIPS) Publication 140-2 is a computer security standard developed by the U.S. Government and industry working group to validate the quality of cryptographic modules. See the official FIPS publications at NIST Computer Security Resource Center . Red Hat Enterprise Linux (RHEL) provides an integrated framework to enable FIPS 140-2 compliance system-wide. When operating in the FIPS mode, software packages using cryptographic libraries are self-configured according to the global policy. To learn about compliance requirements, see the Red Hat Government Standards page. Red Hat build of Eclipse Vert.x runs on a FIPS enabled RHEL system and uses FIPS certified libraries provided by RHEL. 1.2.3.1. Additional resources For more information on how to install RHEL with FIPS mode enabled, see Installing a RHEL 8 system with FIPS mode enabled . For more information on how to enable FIPS mode after installing RHEL, see Switching the system to FIPS mode .

Commands: