DesOps – The Next Wave in Design

sdash
By Samir Dash

DesOps, aka. DesignOps, refers to an approach to design that is inspired by the culture of DevOps. In this and the following posts, we will explore, the practical approaches for

  • How to prepare for the next wave in design that compliments the DevOps concepts of a cultural shift, collaboration, and automation.
  • We will also see what solutions are available today that contribute to bringing the full circle of design in the context of the software development lifecycle.

Today, design as a discipline is getting more and more recognition across the entrepreneur world and many industry efforts, such as IBM‘s Enterprise Design Thinking framework, RedHat‘s Open Studio and similar ones, are at a large scale, trying to create a synergy between the Agile approach to the software development lifecycle and the Design Thinking.  It is an interesting crossroad where the next big thing in product delivery is to bring scalability as well as automation to the creative process.

In the context of the software industry, I always see “design” as an intersection between creativity and technology where both shape each other—with help from user needs—and blend the results into successful products.

Any typical software product that is delivered involves many complex as well as divergent technologies, processes, people, and visions. Though software delivery mostly happens with team members segmented into two major groups—developers and designers—ultimately, the best outcome always depends on how the two teams communicate with each other and how efficiently their thoughts and ideas are shared, propagated, and translated.

Continue reading “DesOps – The Next Wave in Design”

Share

Next DevNation Live: Advanced Microservices Tracing with Jaeger, June 21st, 12pm EDT

burrsutter
By Burr Sutter

A significant challenge of moving from a traditional monolithic application design to a microservices-based architecture is the ability to monitor the business transaction flow of events throughout your entire distributed system. Join us for the next online DevNation Live on June 21st at 12pm EDT for Advanced Microservices Tracing with Jaeger, presented by Red Hat software engineers Pavol Loffay and Juraci Paixão Kröehling.

In this session, we’ll examine in detail the Cloud Native Computing Foundation (CNCF) OpenTracing API, a consistent, expressive, vendor-neutral API for distributed tracing and context propagation. We will also analyse Jaeger, an open source distributed tracing system inspired by Google Dapper and OpenZipkin.

Join us to gain an understanding of Jaeger’s open source distributed tracing system and how it can help you monitor and troubleshoot microservices-based distributed systems.

Register now and join the live presentation at 12pm EDT, Thursday, June 21st.

Session Agenda

Continue reading “Next DevNation Live: Advanced Microservices Tracing with Jaeger, June 21st, 12pm EDT”

Share

Troubleshooting Open vSwitch DPDK PMD Thread Core Affinity

echaudroredhat-com
By Eelco Chaudron

The most common problem when people are trying to deploy an Open vSwitch with Data Plane Development Kit (OvS-DPDK) solution is that the performance is not as expected. For example, they are losing packets. This is where our journey for this series of blogs will start.

This first blog is about Poll Mode Driver (PMD) thread core affinity. It covers how to configure thread affinity and how to verify that it’s set up correctly. This includes making sure no other threads are using the CPU cores.

Continue reading “Troubleshooting Open vSwitch DPDK PMD Thread Core Affinity”

Share

Red Hat Data Grid on Three Clouds (the details behind the demo)

slaskawi
By Sebastian Łaskawiec

If you saw or heard about the multi-cloud demo at Red Hat Summit 2018, this article details how we ran Red Hat Data Grid in active-active-active mode across three cloud providers. This set up enabled us to show a fail over between cloud providers in real time with no loss of data. In addition to Red Hat Data Grid, we used Vert.x (reactive programming), OpenWhisk (serverless), and Red Hat Gluster Storage (software-defined storage.)

This year’s Red Hat Summit was quite an adventure for all of us. A trip to San Francisco is probably on the bucket list of IT geeks from all over the world. Also, we were able to meet many other Red Hatters, who work remotely for Red Hat as we do.  However, the best part was that we had something important to say: “we believe in the hybrid/multi cloud” and we got to prove that live on stage.

Photo credit: Bolesław Dawidowicz

 

Continue reading “Red Hat Data Grid on Three Clouds (the details behind the demo)”

Share

Announcing .NET Core 2.1 for Red Hat Platforms

bdavismikeguerette
By Bob Davis and Mike Guerette

We are very pleased to announce the general availability of .NET Core 2.1 for Red Hat Enterprise Linux and OpenShift platforms!

.NET Core is the open-source, cross-platform .NET platform for building microservices. .NET Core is designed to provide the best performance at scale for applications that use microservices and containers. Libraries can be shared with other .NET platforms, such as .NET Framework (Windows) and Xamarin (mobile applications). With .NET Core you have the flexibility of building and deploying applications on Red Hat Enterprise Linux or in containers. Your container-based applications and microservices can easily be deployed to your choice of public or private clouds using Red Hat OpenShift. All of the features of OpenShift and Kubernetes for cloud deployments are available to you.

.NET Core 2.1 continues to broaden its support and tools for microservice development in an open source environment. The latest version of .NET Core includes the following improvements:

Continue reading “Announcing .NET Core 2.1 for Red Hat Platforms”

Share

Debugging Memory Issues with Open vSwitch DPDK

ktraynorredhat-com
By Kevin Traynor

Introduction

This article is about debugging out-of-memory issues with Open vSwitch with the Data Plane Development Kit (OvS-DPDK). It explains the situations in which you can run out of memory when using OvS-DPDK and it shows the log entries that are produced in those circumstances. It also shows some other log entries and commands for further debugging.

When you finish reading this article, you will be able to identify that you have an out-of-memory issue and you’ll know how to fix it. Spoiler: Usually having some more memory on the relevant NUMA node works. It is based on OvS 2.9.

Continue reading “Debugging Memory Issues with Open vSwitch DPDK”

Share

Using the STOMP Protocol with Apache ActiveMQ Artemis Broker

cpandeyredhat-com
By Chandra Shekhar Pandey

In this article, we will use a Python-based messaging client to connect and subscribe to a topic with a durable subscription in the Apache ActiveMQ Artemis broker. We will use the text-based STOMP protocol to connect and subscribe to the broker. STOMP clients can communicate with any STOMP message broker to provide messaging interoperability among many languages, platforms, and brokers.

If you need to brush up on the difference between persistence and durability in messaging, check Mary Cochran’s article on developers.redhat.com/blog.

A similar process can be used with Red Hat AMQ 7. The broker in Red Hat AMQ 7 is based on the Apache ActiveMQ Artemis project. See the overview on developers.redhat.com for more information.

Continue reading “Using the STOMP Protocol with Apache ActiveMQ Artemis Broker”

Share
Red Hat OpenShift

Remotely Debug an ASP.NET Core Container Pod on OpenShift with Visual Studio

rhtakayoshitanaka
By Takayoshi Tanaka

Last year, I wrote a blog post how to remotely debug your ASP.NET Core container on OpenShift with Visual Studio Code. Today I introduce how to remotely debug a pod using Visual Studio from your Windows computer. Sometimes you encounter an issue that happens only in the production environment. Remotely debugging a pod enables you to investigate such an issue.

Visual Studio and Visual Studio Code now support SSH as a transport protocol for remote debugging. If a remote host accepts an SSH connection, Visual Studio can do remote debugging using Visual Studio’s default feature. However, you need to use the oc command instead of an SSH client such as putty since Red Hat OpenShift pods don’t allow direct connections via SSH. The MIEngine debugger enables you to use any command for SSH connection.

Note:
All the steps below have been confirmed using a combination of Visual Studio 2017 (versions 15.7.2 and 15.8 preview2) on Windows 10 and OpenShift 3.9.

Continue reading “Remotely Debug an ASP.NET Core Container Pod on OpenShift with Visual Studio”

Share

EDI Transformations with Fuse Ignite and Trace Transformer

sigreen
By Simon Green

As part of Red Hat JBoss Fuse 7, Red Hat introduces a new Integration Platform as a Service (iPaaS) called Fuse Ignite. Gartner uses the term citizen integrators to describe the iPaaS target market: folks who aren’t regularly concerned with integration. In my opinion, this market includes Electronic Data Interchange (EDI) analysts who focus on business rules and validations, rather than worrying about lines of code or Apache Camel routes. Therefore, Fuse Ignite introduces a mechanism to separate concerns, allowing EDI analysts to focus on their business mappings and transformations. On the other hand, developers can focus on low-level integration with systems and on writing code. Fuse Ignite offers a platform on which both citizen integrators and developers can coexist, collaborate, and contribute to an end-to-end integration.

Continue reading “EDI Transformations with Fuse Ignite and Trace Transformer”

Share

Building Container-Native Node.js Applications with Red Hat OpenShift Application Runtimes and Istio

phayes
By Philip Hayes

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”

Share