Container-native development is primarily about consistency, flexibility, and scalability. Legacy Application Lifecycle Management (ALM) tooling often is not, leading to situations where it:
- Places artificial barriers on development speed, and therefore time to value,
- Creates single points of failure in the infrastructure, and
- Stifles innovation through inflexibility.
Ultimately, developers are expensive, but they are the domain experts in what they build. With development teams often being treated as product teams (who own the entire lifecycle and support of their applications), it becomes imperative that they control the end-to-end process on which they rely to deliver their applications into production. This means decentralizing both the ALM process and the tooling that supports that process. In this article, we’ll explore this approach and look at a couple of implementation scenarios.
Continue reading “Application lifecycle management for container-native development”
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”
How do YOU get your Java apps running in a cloud?
First you grab a cloud from the sky by, for example, (1) Getting started with a free account on Red Hat OpenShift Online, or (2) locally on your laptop using Red Hat Container Development Kit (CDK) or upstream Minishift on Windows, macOS, and Linux, or (3) using
oc cluster up (only on Linux), or (4) by obtaining a login from someone running Red Hat OpenShift on a public or on-premises cloud. Then, you download the oc CLI client tool probably for Windows (and put it on your PATH). Then you select the Copy Login Command from the menu in the upper right corner under your name in the OpenShift Console’s UI, and you use, for example, the
oc status command.
Great—now you just need to containerize your Java app. You could, of course, start to write your own Dockerfile, pick an appropriate container base image (and discuss Red Hat Enterprise Linux versus CentOS versus Fedora versus Ubuntu versus Debian versus Alpine with your co-workers; and, especially if you’re in an enterprise environment, figure out how to have that supported in production), figure out appropriate JVM startup parameters for a container, add monitoring, and so.
But perhaps what you really wanted to do today is…well, just get your Java app running in a cloud!
Read on to find an easier way.
Continue reading “Building Java 11 and Gradle containers for OpenShift”
In Part 1 of this series, we explored a use case around integration being the key to transforming your customer experience.
I laid out how I’ve approached the use case and how I’ve used successful customer portfolio solutions as the basis for researching a generic architectural blueprint. The only thing left to cover was the order in which you’ll be led through the blueprint details.
This article, which is Part 2 of the series, starts the real journey at the very top, with a generic architecture from which we’ll discuss the common architectural elements one by one.
Continue reading “Common architectural elements for modern integration architectures (Part 2)”
For the past few months, I’ve been digging into my new role with a group of Portfolio Architects, looking specifically at integration as the key to omnichannel customer experience.
It’s an interesting challenge in that we’ve been given the mission of creating architectural content based on common customer adoption patterns. That’s very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you’re basing the content on actual execution in solution delivery, you’re cutting out the chuff.
What’s that mean?
It means that it’s going to provide you with a way to implement a solution using open source technologies by focusing on the integrations, structures, and interactions that actually have been proven to work.
What’s not included is any vendor promises that you’ll find in normal marketing content: those promises that, when it gets down to implementation crunch time, might not fully deliver.
Enter the term architectural blueprint.
In this series of articles, let’s look at these blueprints, how they are created, and what value they provide for your solution designs.
Continue reading “How integration is key to customer experience (Part 1)”
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”