Eric D. Schabell: Cloud-native development - A deployment architecture

Tuesday, June 16, 2020

Cloud-native development - A deployment architecture

cloud-native development
Part 5 - A deployment architecture
The previous articles were introducing the foundations of an architecture for cloud-native development, exploring a logical diagram, and diving into the first use cases with cloud-native development on local and remote containers.

In this article we're continuing on with example use cases within the architecture. Descriptions are provided to guide you with aligning the landscape your organization works with every day.

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 the use case detailing deployments from a developers local machines to development, testing, and finally production environments.


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 example, 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:
cloud-native development
Deployment architecture with numbered labels
as workloads are built, tagged, and deployed.
  • 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)
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. Here we see the CI/CD platform uses a source-to-image workflow [2] to build the container image, test the image, and place it [3] 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 registry managed with Quay [4].

For this architecture we've kept the enterprise image  registry storyline simple, just a single Quay instance, but in reality it's important to have stages for security testing, segregation of development and untested images, and to only allow fully certified images to be put into production. In our next article we'll expand on these more advanced deployments.

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, the appImage is tagged as appImage:test and pushed from the CI/CD platform [7] to the Quay enterprise image registry.

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 pushed from the CI/CD platform [10] to the Quay enterprise image registry.

Production infrastructure

All images tagged as prod are pushed from the Quay enterprise image registry to the production infrastructure [11] into the production OpenShift cluster image registry. The appImage:prod is used for deploying [12] 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 deployment architecture for your workloads using cloud-native development in your organization. It's featuring an architecture 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 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.

cloud-native developmentTo access the diagram covered in this article, you scroll down to the file listings on the main page, you can locate a schematic diagram as shown in the figure here.

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 architecture
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 can be found here:
  1. An architectural introduction
  2. Common architectural elements
  3. Cloud-native development on local containers
  4. Cloud-native development on remote containers
  5. A deployment architecture
  6. Advanced deployment architecture
Catch up on any articles you missed by following one of the links above. Next in this series, taking a look at advanced cloud-native deployments.