Red Hat CodeReady Workspaces provide developers with containerized development environments hosted on OpenShift/Kubernetes. DevOps teams can now use a hosted development environment that’s pre-built for their chosen stack and customized for their project.
CodeReady Workspaces can help you rapidly onboard developers for your project as everything they need to develop is running in a containerized workspace. In this post, we’re going to use CodeReady Workspaces to get up and running quickly with an existing open source project, Peak. Peak is a multi-container Kubernetes application for performance testing web services, and it allows you to create distributed performance tests using the Kubernetes Batch API for test orchestration. We’ll make some modifications to Peak’s Flask front end, a stateless web interface that interacts with a Falcon RESTful API to return data about performance tests. You won’t need the complete Peak application deployed, though if you like, you can find steps to deploy it to OpenShift here.
To follow along you’ll need a Red Hat OpenShift Container Platform 3.11 environment. You can use the Red Hat Container Development Kit on your Windows, macOS, or Linux laptop or a hosted Red Hat OpenShift instance to do it on online.
Continue reading “Creating a containerized Python/Flask development environment with Red Hat CodeReady Workspaces”
Microservices architecture is taking over software development discussions everywhere. More and more companies are adapting to develop microservices as the core of their new systems. However, when going beyond the “microservices 101” googled tutorial, required services communications become more and more complex. Scalable, distributed systems, container-native microservices, and serverless functions benefit from decoupled communications to access other dependent services. Asynchronous (non-blocking) direct or brokered interaction is usually referred to as messaging.
Continue reading “Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online”
Nowadays, API development with proper lifecycle management often takes days if not weeks to get a simple API service up and running. One of the main reasons behind this is there are always way too many parties involved in the process. Plus there are hours of development and configuration.
First, the system analysts negotiate the API interface with the API consumer; then the developer writes the actual API to implement the interface. They then pass the API on to the DevOps team that is in charge of deploying the API. And it is not done yet; then the deployment info needs to be passed to the operations team that is in charge of setting up the API endpoints in the management system and also applying the access policies.
The speed of providing managed API services can be one of the major factors in the success of a company’s business.
This article, which is the first in a series of three articles, describes how the new Red Hat Integration bundle allows citizen integrators to quickly provide an API through tools that make creating an API in five simple steps effortless.
Continue reading “Effortless API creation with full API lifecycle using Red Hat Integration (Part 1)”
In the first part of this series, we saw how effective a platform as a service (PaaS) such as Red Hat OpenShift is for developing IoT edge applications and distributing them to remote sites, thanks to containers and Red Hat Ansible Automation technologies.
Usually, we think about IoT applications as something specially designed for low power devices with limited capabilities. IoT devices might use a different CPU architectures or platform. For this reason, we tend to use completely different technologies for IoT application development than for services that run in a data center.
In part two, we explore some techniques that allow you to build and test contains for alternate architectures such as ARM64 on an x86_64 host. The goal we are working towards is to enable you to use the same language, framework, and development tools for code that runs in your datacenter or all the way out to IoT edge devices. In this article, I’ll show building and running an AArch64 container image on an x86_64 host and then building an RPI3 image to run it on physical hardware using Fedora and Podman.
Continue reading “IoT edge development and deployment with containers through OpenShift: Part 2”
Usually, we think about IoT applications as something very special made for low power devices that have limited capabilities. For this reason, we tend to use completely different technologies for IoT application development than the technology we use for creating a datacenter’s services.
This article is part 1 of a two-part series. In it, we’ll explore some techniques that may give you a chance to use containers as a medium for application builds—techniques that enable the portability of containers across different environments. Through these techniques, you may be able to use the same language, framework, or tool used in your datacenter straight to the “edge,” even with different CPU architectures!
We usually use “edge” to refer to the geographic distribution of computing nodes in a network of IoT devices that are at the “edge” of an enterprise. The “edge” could be a remote datacenter or maybe multiple geo-distributed factories, ships, oil plants, and so on.
Continue reading “IoT edge development and deployment with containers through OpenShift: Part 1”
This is the finale of a series on whether Kubernetes is the new Application Server. In this part I discuss the choice between Kubernetes, a traditional application server, and alternatives. Such alternatives can be referred to as “Just enough Application Server”, like Thorntail. There are several articles on Thorntail (previously known as Wildfly Swarm) on the Red Hat Developer blog. A good introduction to Thorntail is in the 2.2 product announcement.
Continue reading Curse you choices! Kubernetes or Application Servers? (Part 3)
This is the second half of my series covering how to use Red Hat CodeReady Workspaces to develop a Java Enterprise Edition (now Jakarta EE) application using Red Hat JBoss Enterprise Application Platform (JBoss EAP) in the cloud on Red Hat OpenShift/Kubernetes. In the first part, we saw how to:
- Bring your own tools by extending Red Hat’s provided stacks
- Register your own stack within Red Hat CodeReady Workspaces
- Create your workspace using your stack and embedding your JEE project located on a Git repository
For this second part, we’ll start configuring the workspace by adding some helpful settings and commands for building and running a JBoss EAP project. We’ll then see how to use the local JBoss EAP instance for deploying and debugging our application. Finally, we’ll create a factory so that we’ll be able to share our work and propose an on-demand configured development environment for anyone that needs to collaborate on our project.
Continue reading “Streamline your JBoss EAP dev environment with Red Hat CodeReady Workspaces: Part 2”
It has been just one month since the announcement of the release of Red Hat CodeReady Workspaces 1.0.0 Beta. Because the cloud/browser-based IDE may be full of promises, developers are usually suspicious, considering them as toys for occasional coders but not suitable for software craftsmen. But you’ll quickly see that Red Hat’s offering can be a good companion for building tailor-made environments.
The goal of this two-part series is to give a walk-through of using Red Hat CodeReady Workspaces to develop a Java EE (now Jakarta EE) application using Red Hat JBoss Enterprise Application Platform (JBoss EAP). I’ll give you details on how to bring your own tools, configure your workspace with helpful commands for JBoss EAP, and share everything so you can easily onboard new developers.
Continue reading “Streamline your JBoss EAP dev environment with Red Hat CodeReady Workspaces: Part 1”
In Part 5 this series, we looked into details that determine how your integration becomes the key to transforming your customer experience.
It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint. Now it’s time to cover various blueprint details.
This article covers the final elements in the blueprint, storage services, which are fundamental to the generic architectural overview.
Continue reading “Integration of storage services (part 6)”
Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.
In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.
This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.
Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”