Cloud-native development – Advanced deployment blueprint

The previous articles were introducing the foundations of a blueprint for cloud-native development, exploring a logical diagram, and diving into the first use cases with cloud-native development on localremote containers, and a look at a deployment blueprint.

This article completes the series with a look at the advanced cloud-native deployment blueprint. A description providing you with guidance for aligning this blueprint to your organizational architecture follows.

Part 6 – Advanced deployment blueprint

These details should help you understand both what the elements contain and how they might align and how their functionalities are grouped. Let’s look at the use case where developers are leveraging a remote container platform for their cloud-native development environments and see how that’s mapping to a productive working architecture for deploying their solutions.

We’ll be exploring this blueprint for advanced deployments from a developers local machines to development, testing, and finally production environments. It’s a deeper look into how the enterprise image registries are structured to ensure secure, certified, and trustworthy images for your production environment.


This example starts with a cloud-native developer working on their local machines, shown here simplified as workstation tooling. Pushing their code solutions [1], using their container tooling to initiate a build in their continuous integration and development workflow (CI/CD).

(*Note: all numbered steps found in the below image are presented in the text as [#], so step one with label one is shown as [1] in the deployment storyline as it appears.)

In this blueprint, the tooling is focused on working with the OpenShift Container Platform so you see an 
OpenShift client is used to trigger an initial build in our CI/CD OpenShift platform. This occurs when the developer is satisfied with their code. Triggering a build and testing request to the CI/CD platform shown here as being hosted on an OpenShift Container Platform cluster:

  • using git hooks, triggering a code push when it’s committed to the local code repository
  • using Maven plugins, triggering a push to the development infrastructure when activated
  • using oc client container tooling (featured in the diagram)
Deployment blueprint with numbered labels.

Development teams are free to use the method that best suits their own needs when pushing their code to  their CI/CD platform.

CI/CD infrastructure

The pushed code from the developers local working environment is picked up by the CI/CD platform, in this case most often was a Jenkins-based platform. The CI/CD platform can, for example, use a source-to-image workflow to build the container image, test the image, and place it [2] in the transient image registry. At this point it has been tagged as
appImage:dev and is pushed to the OpenShift cluster hosting the enterprise image registries managed with Quay.

Enterprise registries

For an advanced deployment we’ll be looking at how to make sure we have a playground or sandbox registry for development and testing of untrusted container images. Our appImage:dev image has been pushed to the sandbox registry [3] where we find any imported third-party images, external images, and other images [4] that have yet to be tested against in-house security and certification requirements.

All eventual dev tagged images, such as our appImage:dev container image is pushed out to the development infrastructure for further testing. As container images are certified, found to meet security requirements, and pass further in-house testing requirements, they’re moved to the second
enterprise registry. At this point they are considered trusted images and can be further pushed in this blueprint to testing and production infrastructure as describe in more detail below.

Development infrastructure

The development infrastructure image registry is loaded with a copy of the 
appImage:dev tagged container image [5], which then deploys [6] the application and microservices associated with our workload. The development infrastructure is contained in it’s own OpenShift cluster for further testing and validation of the developed application and microservices.

Once the development testing has been satisfied along with any other certification and security requirements, the  appImage is tagged as  appImage:test and pushed from the sandbox registry to the  enterprise registry [7].

Test infrastructure

All images tagged as test are pushed from the Quay enterprise image registry to the test infrastructure [8] into the test OpenShift cluster image registry. The  appImage:test is used for deploying [9] the containers with the  application and  microservices as needed. At this point the testing cycle starts again with new test infrastructure data and requirements on the road to a production deployment.

Once the testing has been satisfied, the appImage is tagged as appImage:prod and updated in the enterprise registry.

Production infrastructure

All images tagged as prod are pushed from the Quay enterprise image registry to the production infrastructure [10] into the production OpenShift cluster image registry. The  appImage:prod is used for deploying [11] the containers with the  application and  microservices as needed. At this point the workload is live for use in the production environment.

This use case example features the advanced deployment architecture for your workloads using cloud-native development in your organization. It’s featuring a blueprint for mapping your cloud-native development process for deploying the developer solution through to your production infrastructure.

Exploring the diagrams

As mentioned in the introduction to this series, we’ve pulled together an  examples repository for all our architecture blueprint diagrams. The  Portfolio Architecture Examples repository makes it possible to collect and share individual images from each diagram element as well as the entire project as a whole.

This is the collection for the schematic diagrams associated with cloud-native development:

  • in this case it’s a single image you can click to view
  • a project file you can download to your local machine using the Download Diagram link
  • Load Diagram link that you can click to automatically open the project diagrams in the diagram tooling used in this blueprint

Give it a try and feel free to explore the collection of logical, schematic, detailed, solution, and community diagrams. This should allow you to get started much quicker than from scratch if you can kick-start a project with existing diagrams.

Should you design your own diagrams, please contribute the project file (ending in .drawio) by raising an issue with the file attached. We’d love to continue collecting these projects for others to use.

Finally, there is a free online beginners guide workshop available focused on using the diagram tooling, please explore to learn tips and tricks from the experts.

What’s next

An overview of the series on the cloud-native development portfolio architecture blueprint can be found here:

  1. A blueprint
  2. Common architectural elements
  3. Cloud-native development on local containers
  4. Cloud-native development on remote containers
  5. A deployment blueprint
  6. Advanced deployment blueprint

Catch up on any articles you missed by following one of the links above. This wraps up the entire series on cloud-native development, so thanks for your time and feel free to provide any feedback in the comments.

Published on Java Code Geeks with permission by Eric Schabell, partner at our JCG program. See the original article here: Cloud-native development – Advanced deployment blueprint

Opinions expressed by Java Code Geeks contributors are their own.

Eric Schabell

Eric is Chronosphere's Director Technical Marketing & Evangelism. He's renowned in the development community as a speaker, lecturer, author and baseball expert. His current role allows him to coach the next generation of technical marketers & evangelists helping the world to understand the challenges with cloud native observability. He brings a unique perspective to the stage with a professional life dedicated to sharing his deep expertise of open source technologies and organizations. Follow on
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Back to top button