Eric D. Schabell: Cloud-native development

Monday, June 8, 2020

Cloud-native development - On remote containers

Part 4 - Development on remote containers

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

In this article we're continuing on to 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 for developer environments that are using a remote container platform for their development environments. The integration of the developer tooling with a proper workflow for pushing their solutions to a remote development environment is crucial and is presented here from developer, to remote development environment, and finally to the test infrastructure.

Any environments beyond this example, such as acceptance or production environments, would be achieved by applying the same architecture shown in this example as the testing environment. Keep this in mind when exploring your cloud-native development on remote containers solutions.

Developer on remote containers (runtimes and integration)

This example starts with a cloud-native developer working on their local machines, using some form of integrated development environment (IDE) together with a roughly outlined here set of tooling. We realize that many different tool sets can be found in development teams, but for simplicity we collected the following major elements as the developer stack in the figure shown here.

Every development team uses some form of source code management systems (SCM), which these days is more likely than not some form of a Git-based repository. Along with this is a dependency management tool such as the Apache Maven repository shown here. In our example we've chosen to feature Java runtimes with frameworks like Spring Boot and Camel integration. This would be the development stack used to create both applications, front-ends, and microservices.

The last piece of the developer tooling is the container tooling used by the developer to push their code solutions to their remote developer container platform for building. In this remote container example, the tooling is focused on working with the OpenShift Container Platform so you see an OpenShift client and other variations of this client tooling.

Once the developer is satisfied with their code and dependencies they have some options for setting up the push of their work to the centralized development team infrastructure. They can setup one of the following options to generate or trigger the push to the continuous integration and continuous development (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

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 to build the container image, test the image, and place it in the development infrastructure image registry. At this point it has been tagged as devImage.

Development infrastructure

The task for the development infrastructure is to test this devImage, where we see the application and microservices are deployed from the image registry. Note that we've chosen for simplicity in this diagram for the image registry, shown as a centralized registry and omitting the image registries found in each OpenShift Container Platform cluster.

Once the development testing has been satisfied, the devImage is tagged in the CI/CD platform as a testImage and deployed to the test infrastructure.

Test infrastructure

The test infrastructure shows more details before this use case is completed, by taking the testImage from the image registry and deploying 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.

This use case example features runtime and integration frameworks for creating applications and microservices using remote containers by developers in your organization. It's featuring an architecture for mapping your cloud-native development process for deploying the developer solution through to your test infrastructure. This should be enough to help you in setting up a cloud-native development and deployment environment on towards your desired production environment.

Developer on remote containers (process automation)

Another example is provided in the figure shown here, this is the same development setup and deployment across developer machines, remote development infrastructure, and testing infrastructure. The featured development focus is now for process automation projects that deploy eventual process microservices with eventual microservices that they might need.

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.

To 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
a 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.