Skip to main content
Redhat Developers  Logo
  • Products

    Platforms

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat AI
      Red Hat AI
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • View All Red Hat Products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat Developer Hub
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat OpenShift Local
    • Red Hat Developer Sandbox

      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Secure Development & Architectures

      • Security
      • Secure coding
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • Product Documentation
    • API Catalog
    • Legacy Documentation
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Introduction to cloud-native application environment architecture

July 2, 2019
Christina Lin
Related topics:
ContainersMicroservicesKubernetes

Share:

    Cloud-native environment architecture can be challenging to understand. To help make sense of it for application developers and software/system architects,  I will attempt to explain the various parts and how they work together. Toward this end, I find it helpful to think about the architecture in four separate layers: application software development, service scaling, application network, and container orchestration platform.

    In this article, I will describe the first technology layer: application software development. I drew the following diagram to make these concepts easier to visualize.

    Container native or cloud-native application development is often referred to as a common greenfield system, where applications are broken down into microservices. Each microservice tends to have its own source of data, be independent from the others, and also be deployed in a distributed way.

    The benefit of such implementation makes applications ever more agile and polyglot, isolating problems, and making the codebase smaller and supposedly easier to maintain.  If I tell were to you that this means life will be good from now on, I would be lying.

    To achieve the benefit of an agile, truly scalable, automated container/cloud-native system, a lot of thought needs to go into considering factors like applications, platforms, and personas, including:

    • Using the right technology for the scenario
      • Complex solutions can sometimes be overkill
      • Using the wrong solution in the wrong place can cause displaced responsibility
    • Domain-driven design with continuous integration
      • Async events or API
      • How to integrate with existing brownfield applications

    The diagram shows a rough overview of how various elements of container/cloud-native system work together, and I hope it also helps you decide when or whether to introduce a particular piece of technology.

    To make more sense for application developers and software/system architects, I deliberately divided the architecture into four planes. Each plane itself can be broken into much more detail. It consists of many pieces of technologies, and these are abstracted based on the fundamental functionality they bring to the cloud-native application environment.

    Application software development layer

    The application software development layer is about modeling domains, how microservices are defined, how they should be deployed, and the software patterns applied in the system that can help to develop a loosely coupled and continuously evolving system. It’s also about the communication technology and patterns between applications.

    Service scaling — Knative

    Scaling to zero when the application is not in use will allow resource optimization. This layer takes the characteristic of cloud computing to the fullest, but not all services need it.

    Application network — Service mesh

    This is a very common architecture functionality in the distributed microservices environment. Having this layer allows better and more uniform control over the communication between microservices and better observability, too. DevOps can use this layer to apply common security, failure recovery, rollout policies, etc., as well as setting customized ones. This layer takes away much redundant work for developers.

    Container orchestration platform — Red Hat OpenShift

    This is the foundation of cloud-native environment architecture. It provides basic and essential capabilities, such as container orchestration, service discovery, CI/CD automation, logging, etc.

    Domain-driven design and Agile Integration

    Domain-driven design (DDD) principles apply to the way we develop applications in cloud-native world, by allowing better communication between business users and developers, modeling objects according to the domain, and setting boundaries to segment the complex business requirement. An important aspect of DDD is continuous integration.

    Agile Integration evolved from the basic concept of microservices and DDD. In software development other than modeling the business logic, many other factors also need to be taken into account. Agile integration on top of DDD helps you better define not only the model and the boundaries but also how they should be separated by different functional concerns and how they can be physically deployed. There are three main responsibilities for agile integration:

    • Core — The majority of the microservice that implements business logic or domain capability belongs to this category. They are a good example of typical small simple microservices that are lightweight in both runtime and how it communicates to each other.
    • Composite — Setting the right granularity of the service, handling transactions, orchestrating, and transforming data for various types of events are all handled here. Aggregation and separation of data and events are done in this category. This acts as the simple stateless pipe that directs the events from one point to another in the desired and suitable format and sometimes needs to be the gateway to external SaaS, brownfield application or even services outside the bounded context.
    • Control and dispatch — If the system only interacts with a handful of external systems, you may not need this category. This category allows you to have more insight and meaningful business control over the services your system provides. It's a place to hide the constant bothersome customization from external client requests that require quick and ad hoc changes. Facade pattern applies in this category.

    Applying the above principles will allow you to:

    • Capture the model and entities from the business requirement.
    • Set the boundaries between business domains.
    • Categorize the nature of the code and separate it into independent, separate, deployable microservice instances.

    Another important fundamental problem is the communication between these microservices. I believe the communication backbone of these microservices should mostly be event-driven and asynchronous, so the distribution of data can be loosely coupled, and the system will become reactive. A drawback is that this type of design can make transactions rather complicated, but this can be overcome by implementing techniques like event sourcing. For communication between boundaries or external clients/partners, I strongly suggest using API simply because:

    • Most of these processes are in the form of request and reply, which is the natural default behavior of REST API.
    • Contract definition and repository management technology are more mature in the API space.

    Next time, I will talk about different types of data in the events and how to handle them, as well as how to achieve data consistency in the cloud-native application environment. I'll also look at all the other layers in my cloud-native application overview: service scaling, application network, and container orchestration platform.

    Last updated: July 12, 2019

    Recent Posts

    • Migrating Ansible Automation Platform 2.4 to 2.5

    • Multicluster resiliency with global load balancing and mesh federation

    • Simplify local prototyping with Camel JBang infrastructure

    • Smart deployments at scale: Leveraging ApplicationSets and Helm with cluster labels in Red Hat Advanced Cluster Management for Kubernetes

    • How to verify container signatures in disconnected OpenShift

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue