Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      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
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java 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

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • 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

My advice for transitioning to a clean architecture platform

April 17, 2023
Maarten Vandeperre Kevin Dubois
Related topics:
ContainersKubernetesMicroservices
Related products:
Red Hat OpenShift Service on AWSRed Hat OpenShiftRed Hat OpenShift Container Platform

Share:

    Now that you have become an application development expert, it’s time to look at how clean architecture would look when we map it to the infrastructure side of an application platform. In case you're not familiar with clean architecture, read part one in this series, My advice for building maintainable, clean architecture.

    Preferred application platform architecture

    Before we get into the clean architecture mapping of our application platform, let’s describe how it should look (Figure 1).

    We will have these four microservices:

    1. Personal data service: Capturing personal information (i.e., email, name, phone number, age, gender, and address). Since this kind of data is relational in nature, we would opt for a relational database for this service.
    2. Movies catalog service: A service to capture all movies from which we have collected data (i.e., name, director, actors, release date, and categories). We prefer to have this data stored in a NoSQL database.
    3. Movie tracking service: A service to store tracking information about who watched a movie. Data is very limited (i.e., person ID, movie ID, timestamp, and if the movie was completed). We prefer to have this data stored in a NoSQL database.
    4. Movie recommendation service: A service that consumes data from the previous three microservices to provide recommendations based on viewer habits, age, gender, and broad location). Since this is connected data, we prefer to have this data stored in a graph database. Here too, we let go of DRY - data copied to the graph.
    An illustration of the microservices outline of preferred platform architecture
    Figure 1: The microservices outline of our preferred platform architecture.
    Created by Maarten Vandeperre,

    Now that we have this outline, let's discuss how to implement it.

    AWS single cloud vendor

    Within company XYZ, developers played with AWS in the past. The management and architects supported the choice for AWS, so the development team started the design of the application platform on AWS cloud. The list of requirements to design their cloud infrastructure is as follows:

    1. The requirement of the person microservice is that it should run on a SQL database. Within AWS, there are various options, but the development team chooses AWS Aurora.
    2. The requirement of the movie microservice is that it should run on a NoSQL database. AWS only offers DynamoDB off-the-shelf, so they choose DynamoDB.
    3. The movie-tracking microservice has the same requirements as the movie service; hence they choose DynamoDB.
    4. The requirement of the movie recommendation service is that it should run on a graph database. Since AWS only offers Neptune off-the-shelf (at the time of writing), they choose Neptune. If they need machine learning models, the development team can opt for AWS Athena or a machine learning model running on the graph database.
    5. The development team thinks that Red Hat OpenShift on AWS (ROSA) is too expensive, so they choose the DIY solution provided by EKS or ECS (both Kubernetes implementations of AWS), not thinking or knowing about the risks going along with this decision.

    Now the development team has designed their cloud infrastructure for the cloud application platform (Figure 2).

    An illustration of the design of the cloud architecture for the application platform.
    Figure 2: The design of the cloud architecture for the application platform.
    Created by Maarten Vandeperre,

    In the next section, they will get back to the management team and the architects.

    The evaluation of dependencies

    In this section, we’ll look at the AWS services as if they were code dependencies. Instead of libraries referenced from the code (see our previous article), these dependencies will be cloud services referenced from the microservices. If we refer to clean architecture, the four microservices are the core-layer (i.e., the business logic that should stand the test of time) and the AWS services are the dependencies that should be easy to replace. We should not tightly couple (combine) with any specific AWS service (as interface layer, Camel can be used, but more on that in future articles). There is one exception. EKS or ECS is the hosting infrastructure and can be seen as the programming language within clean architecture.

    The management team and the architects looked at the design of the application platform’s cloud architecture and had the following recommendations (Figure 3):

    1. Usage of AWS Aurora: That’s fine. It’s recommended by AWS. It’s a stable solution. This choice is accepted (acceptance rate: green).
    2. Usage of DynamoDB: This choice is not well received. The reason is that they bought or installed an on-premise bare-metal MongoDB cluster last year. In order to have some ROI, the management team and the architects prefer to use this cluster. If there is no other choice, DynamoDB can be accepted (acceptance rate: orange).
    3. Usage of Neptune: This is a no-go. Although it’s provided off-the-shelf by AWS, it’s not the best graph database on the market (at the time of writing). The management team and the architects would prefer Neo4J or TigerGraph (acceptance rate: red).
    4. Usage of EKS or ECS: Accepted by the management team and the architects, but this discussion is only won on the short-term pricing argument. They may have thought that OpenShift on AWS is too expensive, but they forgot the risks and the hidden costs that go along with a DIY solution.
    An illustration of the evaluation of the dependencies.
    Figure 3: The evaluation of the dependencies.
    Created by Maarten Vandeperre,

    Because not everything was accepted, the development team must go back to the drawing board.

    Preferred dependencies

    The development team, good listeners as they are, take the feedback from the management team and architects into account and start adapting their architecture. Their preferred dependencies are as follows (Figure 4):

    1. AWS Aurora was accepted. So AWS Aurora stays.
    2. Management was not too happy with the lack of ROI on their investment in the bare-metal MongoDB cluster. If they don’t want to have repercussions on future requested investments, it’s maybe a good idea to reuse that cluster, which is what they’ll do. AWS DynamoDB will be replaced by the on-premise bare-metal MongoDB cluster.
    3. Neptune was a no-go. The development team invests some time in reviewing graph databases. The winner in this exercise is Neo4J, off-the-shelf, offered by Google Cloud. AWS Neptune will be replaced by Google Cloud Neo4J.
    An illustration adding the preferred dependencies to the architecture.
    Figure 4: Adding the recommended or preferred dependencies to the architecture.
    Created by Maarten Vandeperre,

    All of these changes should go relatively easy because the development team follows the principles of clean architecture. But it does not go easy. EKS or ECS has issues connecting to our on-premise MongoDB cluster and Google Cloud Neo4J (unless they spend quite some time and effort in fixing the network setup, which would even open the door for security flaws, as the development team is less trained in networking and operations).

    The development team does not know how to fix the cloud (i.e., core layer) issue regarding the dependencies and asks the architects for input. This will be covered in the next section.

    There is an analogy that can be made with Java and Python. Imagine that person service is a Java service and that the on-premise MongoDB is a Python library. If the programming language (like EKS or ECS) is Java, you won’t be able to access the Python libraries from within the person service. If you change the programming language to JVM and then to GraalVM, it would allow Java code to access Python scripts. It then would allow that the movie and movie tracking service are Python scripts (i.e., allow using these libraries) and that they can be called from within a Java service. Changing the programming language from Java to GraalVM, opened the options to a broader spectrum of third-party libraries.

    Hybrid cloud and multicloud solutions to the rescue

    The development team consults the architects with the issue: “We have isolated our dependencies (i.e., cloud services), but have issues with organizing our core layer (i.e., the third-party independent business logic, the microservices).” The architects look to see where the issue originated.

    Clean architecture is about keeping your options open. The development team did this, but they narrowed the options too much by limiting their programming language (i.e., the microservice hosting platform) to AWS only. What they really need to make full use of the options available in the cloud and on-premise, is a hybrid cloud and multicloud. With a hybrid cloud, we mean the combination of a part of the cloud located at a vendor and a part of the cloud located on-premise. With a multicloud, we mean that the cloud is located over multiple vendors. When hybrid cloud and multicloud solutions are enabled as programming language, the development team will be able to use the preferred dependencies: AWS Aurora, on-premise MongoDB, and Google Cloud Neo4J.

    This architecture will withstand the test of time as well. Whenever a new SaaS solution becomes available or a new cloud emerges, or new tooling is needed, it will be easy to plug it in the designed cloud architecture (Figure 5). This results in a more resilient platform that requires less maintenance and that fairly easily allows for future innovation.

    An illustration of the hybrid cloud and multicloud options.
    Figure 5: Hybrid cloud and multicloud.
    Created by Maarten Vandeperre,

    But how can they implement a hybrid cloud and multicloud solution?

    How to set up hybrid cloud and multicloud solutions

    How do you set up hybrid cloud or multicloud solutions? Red Hat OpenShift Container Platform is the answer. It is a container platform that has the ability to easily start building hybrid cloud and/or multicloud solutions.

    Although we used OpenShift as a solution for the issues that come along with EKS, OpenShift is more than just a Kubernetes installation or implementation. OpenShift Container Platform is a full application container platform. Check with the OpenShift specialists about how to bring the hybrid cloud and multi-cloud service to your company. Get started with a Red Hat OpenShift Service on AWS (ROSA) trial.

    Last updated: September 19, 2023

    Related Posts

    • Red Hat OpenShift 4 on your laptop: Introducing Red Hat CodeReady Containers

    • How to autoscale your SaaS application infrastructure

    • The rise of non-microservices architectures

    • Blueprint for Modern Application Architecture

    • How applications evolve from monolith to microservices

    Recent Posts

    • Meet the Red Hat Node.js team at PowerUP 2025

    • How to use pipelines for AI/ML automation at the edge

    • What's new in network observability 1.8

    • LLM Compressor: Optimize LLMs for low-latency deployments

    • How to set up NVIDIA NIM on Red Hat OpenShift AI

    What’s up next?

    MongoDB Coverage feature image

    Learn basic commands and tasks for using MongoDB. The MongoDB Cheat Sheet explains key concepts as well as how to perform common tasks, including tips on how to carefully execute dangerous tasks like dropping collections from a database.

    Get the cheat sheet
    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

    Red Hat legal and privacy links

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

    Report a website issue