APIs are the cornerstone of so many recent breakthroughs: from mobile applications, to the Internet of Things, to cloud computing. All those technologies expose, consume, and are built on APIs. And those APIs are a key driver for generating new revenue. Salesforce generates 50% of its revenue through APIs, Expedia generates 90% of its, and eBay generates 60% of its. With APIs becoming so central, it becomes essential to deal with full API lifecycle management. The success of your digital transformation project depends on it!
This article describes a set of full API lifecycle management activities that can guide you from an idea to the realization, from the inception of an API program up to management at scale throughout your whole company.
Continue reading “Full API lifecycle management: A primer”
What Red Hat is providing
Red Hat OpenShift Application Runtimes (RHOAR) is a recommended set of products, tools, and components for developing and maintaining cloud-native applications on the Red Hat OpenShift platform. As part of this offering, Red Hat is extending its support to Spring Boot and related frameworks for building modern, production-grade, Java-based cloud-native applications.
Spring Boot lets you create opinionated Spring-based standalone applications. The Spring Boot runtime also integrates with the OpenShift platform, allowing your services to externalize their configuration, implement health checks, provide resiliency and failover, and much more. To learn more about how Spring Boot applications integrate with the wider Red Hat portfolio, check out the following OpenShift Commons Briefing by Thomas Qvarnstrom:
Continue reading “Extending support to Spring Boot for Red Hat OpenShift Application Runtimes”
In the previous article, we took a quick look at a new source-to-image (S2I) builder image designed for building and deploying modern web applications on OpenShift. While the last article was focused on getting your app deployed quickly, this article will look at how to use the S2I image as a “pure” builder image and combine it with an OpenShift chained build.
Continue reading “Modern web applications on OpenShift: Part 2 — Using chained builds”
An Introduction to Thorntail
Today Red Hat is making Thorntail 2.2 generally available to Red Hat customers through a subscription to Red Hat OpenShift Application Runtimes (RHOAR). RHOAR provides application developers with a variety of application runtimes running on the OpenShift Container Platform.
Thorntail is the new name for WildFly Swarm, and bundles everything you need to develop and run Thorntail and MicroProfile applications by packaging server runtime libraries with your application code and running it with
java -jar. It speeds up the transition from monoliths to microservices and takes advantage of your existing industry standard Java EE technology experience.
Continue reading “Announcing: Thorntail 2.2 General Availability”
At the recently concluded Microsoft Ignite 2018 conference in Orlando, I had the honor of presenting to a crowd of Java developers and Azure professionals eager to learn how to put their Java skills to work building next-gen apps on Azure. Of course, that meant showcasing the technology coming out of the popular MicroProfile community, in which Red Hat plays a big part (and makes a fully supported, productized MicroProfile implementation through Thorntail, part of Red Hat OpenShift Application Runtimes).
We did a demo too, which is the main topic of this blog post, showing how easy it is to link your Java MicroProfile apps to Azure services through the Open Service Broker for Azure (the open source, Open Service Broker-compatible API server that provisions managed services in the Microsoft Azure public cloud) and OpenShift’s Service Catalog.
Here’s how to reproduce the demo.
Continue reading “Deploying MicroProfile apps on Microsoft Azure using the Azure Open Service Broker”
Have you ever wondered why you are deploying your multi-platform applications using containers? Is it just a matter of “following the hype”? In this article, I’m going to ask some provocative questions to make my case for Why Kubernetes is the new application server.
You might have noticed that the majority of languages are interpreted and use “runtimes” to execute your source code. In theory, most Node.js, Python, and Ruby code can be easily moved from one platform (Windows, Mac, Linux) to another platform. Java applications go even further by having the compiled Java class turned into a bytecode, capable of running anywhere that has a JVM (Java Virtual Machine).
The Java ecosystem provides a standard format to distribute all Java classes that are part of the same application. You can package these classes as a JAR (Java Archive), WAR (Web Archive), and EAR (Enterprise Archive) that contains the front end, back end, and libraries embedded. So I ask you: Why do you use containers to distribute your Java application? Isn’t it already supposed to be easily portable between environments?
Continue reading “Why Kubernetes is The New Application Server”
For developers working on a Kubernetes-based application environment such as Red Hat OpenShift, there are a number things that need to be considered to fully take advantage of the significant benefits provided by these technologies, including:
- How do I communicate with the orchestration layer to indicate the application is operating correctly and is available to receive traffic?
- What happens if the application detects a system fault, and how does the application relay this to the orchestration layer?
- How can I accurately trace traffic flow between my applications in order to identify potential bottlenecks?
- What tools can I use to easily deploy my updated application as part of my standard toolchain?
- What happens if I introduce a network fault between my services, and how do I test this scenario?
These questions are central to building container-native solutions. At Red Hat, we define container-native as applications that conform to the following key tenets:
- DevOps automation
- Single concern principle
- Service discovery
- High observability
- Lifecycle conformance
- Runtime confinement
- Process disposability
- Image immutability
This may seem like a lot of overhead on top of the core application logic. Red Hat OpenShift Application Runtimes (RHOAR) and Istio provide developers with tools to adhere to these principles with minimal overhead in terms of coding and implementation.
In this blog post, we’re specifically focusing on how RHOAR and Istio combine to provide tools for DevOps automation, lifecycle conformance, high observability, and runtime confinement.
Continue reading “Building Container-Native Node.js Applications with Red Hat OpenShift Application Runtimes and Istio”
(Edit: November 22, 2019) The Node images used in this post, both community
product, are no longer being updated and maintained. For community images, please use the Universal Base Image (UBI)-based node images located here: registry.access.redhat.com/ubi8/nodejs-10
For a fully supported Product version of Node.js, please check out the Red Hat Software Collections Node.js image, RH SCL Node.js.
Recently, I wrote a post called Zero to Express on OpenShift in Three Commands, which shows how to get started using Node.js, Express, and OpenShift together as fast as possible using the Node.js s2i (source-to-image) images that were recently released as part of Red Hat OpenShift Application Runtimes (RHOAR).
This post will add to the last one and show how we can start to debug and inspect our running code using the Chrome Developer Tools (DevTools) inspector.
Continue reading “How to Debug Your Node.js Application on OpenShift with Chrome DevTools”
[Cross posted from the OpenShift blog]
About a year ago Red Hat announced its participation as a launch partner of the Istio project, a service mesh technology that creates an application focused network that transparently protects the applications from abnormalities in environments. The main goals of Istio are enhancing overall application security and availability through many different capabilities such as intelligent routing, circuit breaking, mutual TLS, rating, and limiting among others. Ultimately Istio is about helping organizations develop and deploy resilient, secure applications and services using advanced design and deployment patterns that are baked into the platform.
As part of our investments in making the technology easily consumable to Kubernetes and OpenShift users, Red Hat has created a ton of content:
- learn.openshift.com: A web-based OpenShift and Kubernetes learning environment where users get to interact through the web browser with a real running instance of OpenShift and Istio service mesh with zero install time and no sign-up required.
- Istio tutorial: Want to try the web-based scenario yourself from scratch? This Git repo contains instructions on how to set up an environment for yourself.
- Introducing Istio Service Mesh for Microservices book by Christian Posta and Burr Sutter
- Blog posts on the OpenShift and Red Hat Developer blogs
Continue reading “Getting Started with Istio and Jaeger on Your Laptop”
What does this mean for your enterprise? Where does it fit, and how can Red Hat OpenShift Application Runtimes help you use this technology?
Join this session for the answers. We’ll also demonstrate how quickly you can set up non-trivial enterprise-grade Node.js applications on Red Hat OpenShift Container Platform. We’ll explore how to integrate with other open source technologies, such as Istio, and discuss strategies for your Node.js development and deployment pipeline, including canary and blue/green deployment strategies.
Register now and join the live presentation at 12 p.m. EDT, Thursday, April 19th.
Continue reading “Next DevNation Live: Enterprise Node.js on OpenShift, April 19th, 12 p.m. EDT”