As we discussed in the last post, most of DevOps today focuses on the process blocks that mostly impact engineering or technical aspects of a product rather than the design aspect. Even though DesOps was primarily born out of the primary need of how to design at scale, the factors that shaped it are of a similar nature to the factors that shaped DevOps.
With recent software delivery processes, for example, the Agile process and Continuous Integration (CI) and Continuous Deployment (CD)of code, the DevOps approach provided a faster highway to ensure faster delivery with low risks. So the earlier SDLC model got redefined over time with Agile and then with DevOps to its current shape.
However, because design is an integral part of any product delivered, there is a need to ensure that gaps are bridged between the traditional design lifecycle and the fast track of the DevOps development lifecycle. DesOps and DevOps both are complementary to each other. The design delivery process improvements try to optimize the overall delivery process and thereby contribute to DevOps, for example, in aspects such as testing of the product that involves design aspects, usability, accessibility, etc.
The need for tighter integration between the design team and the engineering team became a necessity to ensure to design at scale. During the past two to three years, the top five big companies have made heavy investments in this area that have paved the way for other organizations and design communities to be more explorative in this area.
Continue reading “DesOps is “DevOps 2.0””
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”
This article is the final in a series taking readers on a journey to peek inside life in a Red Hat Open Innovation Labs residency.
This is the top-tier experience for any customer*, exposing them to open collaboration, open technologies, and fast agile application delivery methods.
This experience often escapes organizations attempting digital transformation, so through submersion in an Open Innovation Labs residency, Red Hat shares its experience in managing, developing, and delivering solutions with communities, open technologies, and open collaboration.
Join me as I share experiences from inside a real-life residency, watching Red Hat work intimately with a customer, exposing new ways of working, leveraging open technologies using fast, agile application delivery methods and open collaboration.
In the first part, I shared what’s in a Red Hat Open Innovation Labs residency. Then in part two, I looked at what I encountered as the residency progressed towards delivery. All that’s left now is to share the delivery week, known as Demo Day.
Continue reading “Inside a Red Hat Open Innovation Labs Residency (Part 3)”
This series (see Part 1) takes the reader on a journey, taking a peek inside a Red Hat Open Innovation Labs Residency. A top tier experience for any customer*, a residency exposes them to open collaboration, open technologies, and fast agile application delivery methods.
This experience often escapes organizations attempting digital transformation. Through submersion in an Open Innovation Labs residency, Red Hat shares its experience in managing, developing, and delivering solutions. This is about successfully achieving organizational goals using open communities, open technologies, and open collaboration.
Join me as I share experiences from inside a real life residency. Watch how Red Hat engages intimately with a customer by exposing them to new ways of working. It is demonstrated by leveraging open technologies using fast and agile application delivery methods with open collaboration.
Continue reading “Inside a Red Hat Open Innovation Labs Residency (Part 2)”
OpenShift and Kubernetes do a great job of working to make sure calls to your microservice are routed to the correct pods. After all, that’s one of the raison d’être for Kubernetes: routing and load balancing. What if, however, you want to customize the routing? What if you want to run two versions at the same time? How do Istio Route Rules handle this?
[This is part two of my ten-week Introduction to Istio Service Mesh series. My previous article was Part 1: Introduction to Istio; It Makes a Mesh of Things. Want to see this in a video? Check out the video edition here.]
Continue reading “Istio Route Rules: Telling Service Requests Where to Go”
This series takes the reader on a journey, taking a peek inside life in a Red Hat Open Innovation Labs residency. This is the top tier experience for any customer; exposing them to open collaboration, open technologies, and fast agile application delivery methods.
Continue reading “Inside a Red Hat Open Innovation Labs Residency – (Part 1)”
Logs are like gold dust. Taken alone they may not be worth much, but put together and worked by a skillful goldsmith they may become very valuable. OpenShift comes with The EFK stack: Elasticsearch, Fluentd, and Kibana. Applications running on OpenShift get their logs automatically aggregated to provide valuable information on their state and health during tests and in production.
The only requirement is that the application sends its logs to the standard output. OpenShift does the rest. Simple enough!
In this blog I am covering a few points that may help you with bringing your logs from raw material to a more valuable product.
Continue reading “Structured application logs in OpenShift”
Beta testing is fundamentally all about the testing of a product performed by real users in a real environment. There are many tags we use to refer to the testing of similar characteristics, such as User Acceptance Testing (UAT), Customer Acceptance Testing (CAT), Customer Validation, and Field Testing (more popular in Europe). Whichever tag we use for these testing cases, the basic components are more or less the same. To discover and fix potential issues, this involves the user and front-end user interface (UI) testing, as well as the user experience (UX) related testing. This always happens in the iteration of the software development lifecycle (SDLC) where the idea has transformed into design and has passed the development phases, while the unit and integration testing has already been completed.
Continue reading “Beta Testing in the Ever-Changing World of Automation”
APIs are critical to automation, integration and developing cloud-native applications, and it’s vital they can be scaled to meet the demands of your user-base. In this article, we’ll create a database-backed REST API based on the Python Falcon framework using Red Hat Software Collections (RHSCL), test how it performs, and scale-out in response to a growing user-base.
Continue reading Create a scalable REST API with Falcon and RHSCL
This article would help to configure http2 protocol support for the camel-undertow component.
- Camel’s undertow component use embedded undertow web-container of version undertow-core:jar:1.4.21. This version also supports the http2 connection.
- I have used camel version 2.21.0-SNAPSHOT from upstream https://github.com/apache/camel.
- Also, the curl version to test application using camel-undertow component is 7.53.1. This curl version supports –http2 flag for sending an http2 request.
- I have also used nghttp to test application from linux terminal. However, this article is not about http2 insights.
- For http2 details, I found articles  and  helpful.
Continue reading “Using Camel-Undertow component supporting http2 connection”