The introduction to a blueprint for cloud-native development laid out groundwork for a deeper exploration of it’s logical diagram.
In this article we continue with a look at the common architectural elements. A description is provided to guide you with aligning what we’ve presented here with 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 foundation of our cloud-native development blueprint, the logical diagram with it’s architectural elements.
This diagram sorts architectural elements in to groups, of which we can look at in detail below.
The developer
The developer elements consists of what she uses to produce code artefacts that are pushed in to the cloud-native development process to create containerized workloads.
For this blueprint the researched customers provided, as you could image, a diverse set of developer elements to choose from. We’ve chosen to group some and selected the elements shown in the image.
The developer IDE is pretty universal, the tooling that the developer is coding in. Some form of source code management repository is used, but all research pointed to a Git-based repository. The remaining three elements encompass as selection of the enterprise frameworks encountered, but are not by any means definitive. We encountered Spring Boot, integration based on Camel and Fuse, and often some collection of Java runtimes.
While not illustrated as a distinct component, some form of dependency management was employed. In all researched cases it was an
Apache Maven repository, but we’ve chosen to leave them out of this logical overview for the reasons of simplicity.
Container platform CI / CD
A container platform hosting the continuous integration (CI) and continuous development (CD) tooling is the main element in this group. The CI / CD platform can be an number of available tools, but as a concrete example, many implementations are using Jenkins tooling.
An exception to the normal generic elements is the
Skopeo element. This is a tooling element used to manage images across image registries by setting up automated copying from one registry to another, even across container platform infrastructure.
Deployments
There are numerous elements that developers generate for deployment on their target container platform. To capture them all would become both messy and always incomplete, so instead the elements shown here in the container platform figure are representative of what you can expect.
A large focus of cloud-native development is based on microservice delivery. With that in mind the example elements encountered in our research were categorized into the following service groups:
- caching data microservices
- decision microservices
- process automation microservices
- integration microservices
- integration data microservices
- messaging services
Note that last one is not always in the form of microservices, as we’re talking about the services that provide topics, queues, and brokers around servicing the message and event layers of the application architecture.
Infrastructure services
These services are more traditional in nature and don’t always have to be in the local environment. For example, API management can be an external SaaS hosted solution for managing, metering, and monitoring of service APIs.
An SSO server element is shown to complete the story of what’s backing the connectivity from microservices to the authentication and authorization back-end system(s) that one encounters in an organization. As security is prevalent across all the elements, it’s noted here as core infrastructure for any cloud-native development solution.
Storage services
The storage services uncovered in customer solution research were diverse and numerous. For that reason there is no single common architectural element shown at the highest level. Everything from container native storage to traditional block storage was found.
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 logical diagram as shown in the image.
This is the collection for the logical 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 local 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 – Common architectural elements Opinions expressed by Java Code Geeks contributors are their own. |
What is the proxy design pattern in Java? The object oriented Proxy Design Pattern is a structural design pattern which is concerned with how classes and objects compose to form larger structures. The proxy design pattern in java takes a similar approach by providing a proxy object that acts as a placeholder for another object. Commonly a proxy is a class that functions as an interface to something else. The proxy design pattern can be best understood with the help of a real-world example.