Home » DevOps » Cloud-native development – On remote containers

About Eric Schabell

Eric D. Schabell
Eric is Red Hat’s Portfolio Architect Director. He's renowned in the development community as a speaker, lecturer, author, and baseball expert. Follow on https://www.schabell.org.

Cloud-native development – On remote containers

The previous articles were introducing the foundations of a blueprint 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 architectural blueprint. 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 blueprint 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 a blueprint 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 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.

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
  • 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. Cloud-native deployments
  6. Cloud-native advanced deployments

Catch up on any articles you missed by following one of the links above. Next in this series, taking a look at cloud-native deployments.

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

Opinions expressed by Java Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
1 Comment Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

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

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Mamta Sharma
20 days ago

Frameworks and Libraries that are high in demandIn today’s date there are hardly any applications that have not been built using a framework or a library. They make development so much easier. They abstract out the underlying complexities and makes it easier to implement what we want within a few lines of code. There are libraries and frameworks for different purposes but the majority of them are used for web application development and are JavaScript based. With Machine Learning on the rise, there are a lot of python libraries as well that are used heavily for the same. Although many… Read more »