If you are running the likes of the Raptor Blackbird for a POWER open-source desktop and wanting to run Fedora on it, currently you need to use the Fedora "server" CLI installer and from there install the desired packages for a desktop. But moving forward, Fedora is beginning to spin Workstation and Live images for PPC64LE.

Complementing Fedora's Power Architecture images of Fedora Everything and Fedora Server, Workstation and Live images are being assembled. This is much more convenient for those wanting an IBM POWER Linux desktop thanks to the success of the Raptor Blackbird with most Linux distributions just offering the server/CLI (non-desktop) images by default for PPC64LE.

There has been concern for nearly five years application servers are dead. Truth be told, they are not dead, but is their usage in decline? The simple answer is yes. Over the years, it appears corporate environments have decided the "return on investment" is not there when looking at Java application servers. On the surface, one might assume that the likes of WebSphere or WebLogic might be the ones in decline due to cost. Perhaps it is just affecting the proprietary choices, while their open source based derivatives are growing or remaining steady? Appears not. Whichever Java application server you choose, all of them are in a state of decline.

Whether it be proprietary options such as WebSphere or WebLogic, or open source alternatives JBoss or Tomcat, all are in decline based on employment listings we review. However, they are not declining at the same pace. From our collection of data, WebSphere and WebLogic's decline has been more muted. The rate of reduction for each of these application servers is in the neighborhood of 25-35% over the last couple years. At the same time, the likes of JBoss and Tomcat have declined around 40-45%. Not a drastic difference, but one that still is notable.

David Egts, chief technologist for Red Hat’s (NYSE: RHT) North American public sector division, advises federal agencies to adopt commercial open source software to help advance their information technology modernization efforts, GovCon Wire reported Aug. 23.

He said Aug. 22 in an FCW thought piece that agencies should seek software vendors that are well-versed in open source technology as well as government security certifications in order to successfully modernize federal IT processes.

Edge computing can mean different things to different technology leaders – from “anything that’s not in the cloud” to “the practice of capturing, storing, processing, and analyzing data nearest to where the data is generated.” As important as knowing what edge computing is, however, is understanding what it is not.

[...]

“Edge can vary based on computing, storage, and where you engage streaming data,” says Jason Mann, VP of IoT at SAS. It will also vary based on your point of view, adds Hopkins. The enterprise edge will look different than a cloud vendor’s or a telco’s edge.

Wondering how Red Hat is helping its customers to succeed? Last month we published six customer success stories that highlight how we've helped customers gain efficiency, cut costs, and transform the way they deliver software. Read on to find out how Ascend Money, Heritage Bank, Generali Switzerland, and others have worked with Red Hat to improve their business.

[...]

To improve the efficiency of its application processes, Ascend Money decided to migrate its legacy applications to a standardized platform using Red Hat technology. With assistance from Red Hat Consulting, Ascend Money moved both its legacy applications and new cloud-native services to OpenShift Container Platform, providing a single platform for IT and developers to collaborate across cloud environments.

In a previous blog, it was announced that Red Hat is making the OpenShift nightly builds available to everyone. This gives users a chance to test upcoming features before their general availability. One of the features planned for OpenShift 4.2 is the ability to perform a “disconnected” or “air gapped” install, allowing you to install in an environment without access to the Internet or outside world.

In my previous article, Run Red Hat Enterprise Linux 8 in a container on RHEL 7, I showed how to start developing with the latest versions of languages, databases, and web servers available with Red Hat Enterprise Linux 8, even if you are still running RHEL 7. In this article, I’ll build on that base to show how to get started with Node using the current RHEL 8 application stream versions of Node.js and Redis 5.

From my perspective, using Red Hat Enterprise Linux 8 application streams in containers is preferable to using software collections on RHEL 7. While you need to get comfortable with containers, all of the software installs in the locations you’d expect. There is no need to use scl commands to manage the selected software versions. Instead, each container gets an isolated user space. You don’t have to worry about conflicting versions.

In this article, you’ll create a Red Hat Enterprise Linux 8 Node.js container with Buildah, and run it with Podman. The code will be stored on your local machine and mapped into the RHEL 8 Node.js container when it runs. You’ll be able to edit the code on your local machine as you would any other application. Because it is mapped via a volume mount, the changes you make to the code will be immediately visible from the container, which is convenient for dynamic languages that don’t need to be compiled. This method isn’t the way you’d want to do things for production, but it gets you started developing quickly and should give you essentially the same development inner loop as you’d have when developing locally without containers. This article also shows how you can use Buildah to build an image with your completed application that you could use for production.

Additionally, you’ll set up the Red Hat Enterprise Linux 8 Redis application stream in a container that is managed by systemd. You’ll be able to use systemctl to start and stop the container just as you would for a non-container installation.

In my previous article, Run Red Hat Enterprise Linux 8 in a container on RHEL 7, I showed how to start developing with the latest versions of languages, databases, and web servers available with Red Hat Enterprise Linux 8 even if you are still running RHEL 7. In this article, I?ll build on that base to show how to get started with the Flask microframework using the current RHEL 8 application stream version of Python 3.

From my perspective, using Red Hat Enterprise Linux 8 application streams in containers is preferable to using software collections on RHEL 7. While you need to get comfortable with containers, all of the software installs in the locations you?d expect. There is no need to use scl commands to manage the selected software versions. Instead, each container gets an isolated user space. You don?t have to worry about conflicting versions.

In this article, you?ll create a Red Hat Enterprise Linux 8 Django container with Buildah and run it with Podman. The code will be stored on your local machine and mapped into the container when it runs. You?ll be able to edit the code on your local machine as you would any other application. Since it is mapped via a volume mount, the changes you make to the code will be immediately visible from the container, which is convenient for dynamic languages that don?t need to be compiled. While this approach isn?t the way to do things for production, you get the same development inner loop as you?d have when developing locally without containers. The article also shows how to use Buildah to build a production image with your completed application.

At the Cloud Foundry Summit in The Hague, IBM today showcased its Cloud Foundry Enterprise Environment on Red Hat?s OpenShift container platform.

For the longest time, the open-source Cloud Foundry Platform-as-a-Service ecosystem and Red Hat?s Kubernetes-centric OpenShift were mostly seen as competitors, with both tools vying for enterprise customers who want to modernize their application development and delivery platforms. But a lot of things have changed in recent times. On the technical side, Cloud Foundry started adopting Kubernetes as an option for application deployments and as a way of containerizing and running Cloud Foundry itself.

For a new sysadmin, storage can be one of the more confusing aspects of infrastructure. This confusion can be caused by lack of exposure to new or different technologies, often because storage needs may be managed by another team. Without a specific interest in storage, an admin might find one’s self with a number of misconceptions, questions, or concerns about how or why to implement different solutions.

When discussing enterprise storage, two concepts are at the core of most conversations: storage area networks (SAN) and network-attached storage (NAS). Both options provide storage to clients across a network, which offers the huge benefit of removing individual servers as single points of failure. Using one of these options also reduces the cost of individual clients, as there is no longer a need to have large amounts of local storage.

Modern application development essentially consists of composing an application from a variety of services. These services aren't just infrastructure components that live on a server any more. They're delivered via an API and could be almost anything underneath as the abstractions start to pile up.

COBOL code at the other end of a message bus with a lambda-function frontend? Okay. Ephemeral container running a Spring Boot service that connects to an RDBMS on a physical Unix server on the other side of the country? Sure, why not? Modern applications don't really care, because it's all about getting the job done. The name of the game is loosely-coupled modular components.

This is why Docker has joined forces with Microsoft, Bitnami, HashiCorp, and a few others to create the Cloud Native Application Bundle (CNAB) specification. Docker uses this spec as part of its Docker App tool, which behaves a lot like docker-compose to collect a variety of services together into a single application bundle that can be shared around. It's a lot like a container collection, and brings the same easy portability of containers to composed applications.

"[Docker App] allows you to describe not just containers, but other services around which the app is dependent," says Johnston. "And it allows you to do things that enterprises care about, such as signing the bundle, verifying that signature, and automatically promoting it based on that signature and things like that."

As Kubernetes and Linux-based infrastructure take hold in digitally transforming organizations, modern applications frequently run in a microservices architecture and therefore can have complex route requests from one service to another. With Red Hat OpenShift Service Mesh, we’ve gone beyond routing the requests between services and included tracing and visualization components that make deploying a service mesh more robust. The service mesh layer helps us simplify the connection, observability and ongoing management of every application deployed on Red Hat OpenShift, the industry’s most comprehensive enterprise Kubernetes platform.

Red Hat OpenShift Service Mesh is available through the OpenShift Service Mesh Operator, and we encourage teams to try this out on Red Hat OpenShift 4 here.

Red Hat is excited to once again be attending Sibos, an annual financial services industry conference exhibition and networking event that is hosted by SWIFT. This year, the event is being held in London, England from September 23rd through 26th. Red Hat will be attending to sponsor a number of activities and discuss how and why enterprise open source technologies offer innovative capabilities that can help firms thrive in their digital journeys.