Although containers and Kubernetes and microservices seem to come up in every conversation, there’s a big chasm between talking about, demonstrating, and actually using a technology in production. Anyone can discuss containers, many people can demo them, but far fewer are successfully using containers and Kubernetes in a microservices architecture.
Why? There are likely many reasons, but a simple one may be that developers don’t know where to start.
Consider this series of articles your starting point. Relax, read on, and get ready to enter the exciting world of containers, Kubernetes, and microservices.
Continue reading “Containers, Kubernetes, and microservices: Start here”
Have you tried the Red Hat Enterprise Linux 8 (RHEL8) Beta yet? Read on to learn how to stand up a LAMP stack on top of RHEL8 Beta quickly, and play around with new features built into the operating system.
A LAMP stack is made up out of four main components, and some glue. The first main component in a LAMP stack is Linux. In my example, I’m using Red Hat Enterprise Linux 8 Beta for that, which gives me a secure operating system, a modern programming environment, and user-friendly set of tools to control it.
Continue reading “How to set up a LAMP stack quickly on Red Hat Enterprise Linux 8 Beta”
The rise of microservices architectures drastically changed the software development landscape. In the past few years, we have seen a shift from centralized monoliths to distributed computing that benefits from cloud infrastructure. With distributed deployments, the adoption of microservices, and system scaling to cloud levels, new problems emerged, as well as new components that tried to solve the problems.
By now, you most likely have heard that the service mesh or Istio is here to save the day. However, you might be wondering how it fits with your current enterprise integration investments and API management initiatives. That is what I discuss in this article.
Continue reading “Distributed microservices architecture: Istio, managed API gateways and, enterprise integration”
Java was introduced to the open-source community more than 20 years ago and it still remains popular among developers. In fact, Java has never ranked lower than #2 on the TIOBE Index. Java was born in the mid-1990s and has nearly 20 years of optimizations for running highly dynamic monolithic applications that assumed sole ownership of (virtualized) host CPU and memory. However, we now live in a world dominated by the cloud, mobile, IoT, and open source, where containers, Kubernetes, microservices, reactive, Function-as-a-Service (FaaS), 12-factor, and cloud-native application development can deliver higher levels of productivity and efficiency. As an industry, we need to rethink how Java can be best utilized to address these new deployment environments and application architectures.
We’d like to introduce you to Quarkus and Supersonic Subatomic Java!
Quarkus is a Kubernetes Native Java framework tailored for GraalVM and HotSpot, crafted from best-of-breed Java libraries and standards. The goal of Quarkus is to make Java a leading platform in Kubernetes and serverless environments while offering developers a unified reactive and imperative programming model to optimally address a wider range of distributed application architectures.
Continue reading “Introducing Quarkus: a next-generation Kubernetes native Java framework”
Firefox offers a simple way to enhance the browsing experience. With a little bit of configuration, you can turn the URL bar into a simple command-line tool to search bug databases, Internet RFCs, and CVEs. This comes in handy when you have an ID for a bug, but you do not have a link to click through. For example, if you have a Red Hat Bugzilla ID, just type
rhbz <bugid> into Firefox’s search bar and Firefox will take you directly to that bug in Bugzilla.
In this article, after I show how to set up keyword-based bookmarks, I share a list of my shortcuts that I think will be handy for developers working with Red Hat products, projects, and communities.
Continue reading “How Red Hat developers can create handy shortcuts with Firefox keyword bookmarks”
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 2 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 2.x for Red Hat OpenShift Application Runtimes”
In the world of distributed computing, containers, and microservices, a lot of the interactions and communication between services is done via RESTful APIs. While developing these APIs and interactions between services, I often have the need to debug the communication between services, especially when things don’t seem to work as expected.
Before the world of containers, I would simply deploy my services on my local machine, start up Wireshark, execute my tests, and analyze the HTTP communication between my services. This for me has always been an easy and effective way to quickly analyze communication problems in my software. However, this method of debugging does not work well in a containerized world.
First of all, the containers most likely run on an internal container platform network that is not directly accessible by your machine. A second problem is that, in compliance with container design best practices, containers contain only the minimal set of applications and libraries needed to execute their task. This means that a tool like
tcpdump is usually not available in a container. This makes debugging and analyzing network traffic between containers and, thus, debugging of inter-microservice communication a bit harder than in the non-containerized world. This article shows one solution.
Continue reading “Using sidecars to analyze and debug network traffic in OpenShift and Kubernetes pods”
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”
Red Hat Enterprise Linux (RHEL) needs time zone information in order for all applications in the operating system to correctly print local time. The GNU C Library (
glibc) makes use of the
tzdata package in order to make APIs such as
strftime() work correctly, while applications such as
/usr/bin/date make use of this information to print the local date.
tzdata package contains the data files documenting both current and historic transitions for various time zones around the world. This data represents changes required by local government bodies or by time zone boundary changes, as well as changes to UTC offsets and daylight saving time (DST).
This article describes three variants of the
tzdata time zone data format that were introduced in 2018 and how tzdata changes will be made in Red Hat Enterprise Linux.
Continue reading “Time zone data (tzdata): 2018 data format changes and Red Hat Enterprise Linux”
When deploying Red Hat Single Sign-On/Keycloak for a test or a proof of concept, most users will choose to use a self-signed certificate as explained in the official documentation.
The setup instructions are straightforward, but this self-signed certificate will trigger certificate error messages in your web browser and can also prevent some clients such as Postman from working properly.
This article explains how to use a public certificate from Let’s Encrypt with Red Hat Single Sign-On.
Continue reading “Using a public certificate with Red Hat Single Sign-On/Keycloak”