The previous articles were introducing the foundations of a blueprint for cloud-native development, starting with a logical diagram and its
common architectural elements.
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 local container tooling for their cloud-native development environments and see how that’s mapping to a productive working architecture for deploying their solutions.
This first use case focuses on developer environments that are using any variety of local container tooling in their development environments. The integration of these tools is of vital importance when pushing their solutions beyond the local development environment and is presented here from developer, to 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 local containers solutions.
Developer on local 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 test building and deploying their code solutions into a container. In this local container example, the tooling most often used was Docker or an open source container project tool called Podman.
Once the developer is satisfied with their local machine testing of their code, the dependencies, and results of a local container deployment, 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 development infrastructure:
- 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 file upload features from the container tooling
Development teams are free to use the method that best suits their own needs when pushing their code to the centralized development infrastructure.
Development infrastructure
The pushed code from the developer is picked up by the continuous integration and continuous development (CI / CD) platform, in this case most often was a Jenkins-based platform. Here the same local developer tooling is used to create a container image, test the image, and place it in the development infrastructure image registry. At this point it has been tagged as devImage.
The task for the development infrastructure is to test this devImage, using the CI / CD platform and any other methods deemed necessary. Once these requirements have been met, a tool know as Skopeo is used to copy images from one registry to another. This marks the point where development on local container tooling is left behind as the image is now tagged as testImage and copied to an OpenShift Container Platform image registry in the testing 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 local container tooling 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 local containers (process automation)
Another example is provided in the figure shown here, this is the same development setup and deployment across local developer machines, central development infrastructure, and testing infrastructure. The featured development tooling 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
- a 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:
- A blueprint
- Common architectural elements
- Cloud-native development on local containers
- Cloud-native development on remote containers
- Cloud-native deployments
- 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 development using remote container tooling.
Published on Java Code Geeks with permission by Eric Schabell, partner at our JCG program. See the original article here: Cloud-native development – On local containers Opinions expressed by Java Code Geeks contributors are their own. |
