Cloud-native environment architecture can be challenging to understand. To help make sense of it for application developers and software/system architects, I will attempt to explain the various parts and how they work together. Toward this end, I find it helpful to think about the architecture in four separate layers: application software development, service scaling, application network, and container orchestration platform.
In this article, I will describe the first technology layer: application software development. I drew the following diagram to make these concepts easier to visualize.
Continue reading “Introduction to cloud-native application environment architecture”
Quarkus continues its cadence of delivering a release every 2-3 weeks. This latest release (0.17.0) contains 125+ changes that include new features, bug fixes, and documentation updates.
Continue reading “Quarkus 0.17.0 now available”
Building responsiveness applications is a never-ending task. With the rise of powerful and multicore CPUs, more raw power is available for applications to consume. In Java, threads are used to make the application work on multiple tasks concurrently. A developer starts a Java thread in the program, and tasks are assigned to this thread to get processed. Threads can do a variety of tasks, such as read from a file, write to a database, take input from a user, and so on.
In this article, we’ll explain more about threads and introduce Project Loom, which supports high-throughput and lightweight concurrency in Java to help simplify writing scalable software.
Continue reading “Project Loom: Lightweight Java threads”
Container-native development is primarily about consistency, flexibility, and scalability. Legacy Application Lifecycle Management (ALM) tooling often is not, leading to situations where it:
- Places artificial barriers on development speed, and therefore time to value,
- Creates single points of failure in the infrastructure, and
- Stifles innovation through inflexibility.
Ultimately, developers are expensive, but they are the domain experts in what they build. With development teams often being treated as product teams (who own the entire lifecycle and support of their applications), it becomes imperative that they control the end-to-end process on which they rely to deliver their applications into production. This means decentralizing both the ALM process and the tooling that supports that process. In this article, we’ll explore this approach and look at a couple of implementation scenarios.
Continue reading “Application lifecycle management for container-native development”
Strimzi is an open source project that provides container images and operators for running Apache Kafka on Kubernetes and Red Hat OpenShift. Scalability is one of the flagship features of Apache Kafka. It is achieved by partitioning the data and distributing them across multiple brokers. Such data sharding has also a big impact on how Kafka clients connect to the brokers. This is especially visible when Kafka is running within a platform like Kubernetes but is accessed from outside of that platform.
This article series will explain how Kafka and its clients work and how Strimzi makes it accessible for clients running outside of Kubernetes.
Continue reading “Accessing Apache Kafka in Strimzi: Part 1 – Introduction”
We are pleased to introduce Red Hat CodeReady Workspaces version 1.2, which provides a cloud developer workspace server and browser-based IDE built for teams and organizations. CodeReady Workspaces includes ready-to-use developer stacks for most of the popular programming languages, frameworks, and Red Hat technologies.
Red Hat CodeReady Workspaces 1.2 introduces:
Continue reading “Announcing Red Hat CodeReady Workspaces 1.2”
If you weren’t lucky enough to attend the recent Red Hat Summit or you went but couldn’t make it to all the container-related sessions, worry not. We teamed up with Scott McCarty, Principal Technology Product Manager–Containers at Red Hat, to bring you an overview of what you missed.
Choosing the right container base image for your applications
The Red Hat Universal Base Image (UBI) gives you three options for building containers with the full power of Red Hat Enterprise Linux (RHEL) underneath. The goal is to create the smallest possible image that fully supports your application. You select a base image depending on the application you’re packaging in a container. For example, if you have a Golang or .NET application, all of that application’s dependencies are built in. That means you can use the minimal image (
ubi-minimal), which contains
microdnf, a package manager that only supports install, update, and remove functions. It also includes, well, a minimal set of tools.
Continue reading “Container-related content you might have missed at Red Hat Summit”
If you’re like me—a developer who works with customers who rely on the tried-and-true Red Hat Enterprise Linux (RHEL), works with containerized applications, and also prefers to work with Fedora Linux as their desktop operating system—you’re excited by the announcement of the Universal Base Images (UBI). This article shows how UBI actually works, by building the container image for a simple PHP application.
With UBI, you can build and redistribute container images based on Red Hat Enterprise Linux without requiring a Red Hat subscription. Users of UBI-based container images do not need Red Hat subscriptions. No more extra work creating CentOS-based container images for your community projects or for your customers that prefer self-support.
I tested all these steps on my personal Fedora 29 system, and they should work on any Linux distribution. I am also a big fan of the new container tools such as Podman, which should be available to your favorite Linux distribution. If you are working on a Windows or MacOS system, you can replace the Podman commands with Docker.
Continue reading “Working with Red Hat Enterprise Linux Universal Base Images (UBI)”
On June 27th, Red Hat will not only be hosting one of the best technical gatherings of 2019, but it will be doing so in Washington D.C. — not San Francisco, Seattle, or <insert tech hub here>. DevNation Federal conference will bring together industry experts and key maintainers of popular open source projects in a one-day immersive conference for federal developers.
Continue reading “DevNation Federal brings open source to the Beltway”
Red Hat OpenShift is part of the Cloud Native Computing Foundation (CNCF) Certified Program, ensuring portability and interoperability for your container workloads. This also allows you to use Kubernetes tools to interact with an OpenShift cluster, like
kubectl, and you can rest assured that all the APIs you know and love are right there at your fingertips.
The Kubernetes Python client is another great tool for interacting with an OpenShift cluster, allowing you to perform actions on Kubernetes resources with Python code. It also has applications within a cluster. We can configure a Python application running on OpenShift to consume the OpenShift API, and list and create resources. We could then create containerized batch jobs from the running application, or a custom service monitor, for example. It sounds a bit like “OpenShift inception,” using the OpenShift API from services created using the OpenShift API.
In this article, we’ll create a Flask application running on OpenShift. This application will use the Kubernetes Python client to interact with the OpenShift API, list other pods in the project, and display them back to the user.
Continue reading “Use the Kubernetes Python client from your running Red Hat OpenShift pods”