In our previous article from this series shared a look at the logical common architectural elements found in a cloud adoption solution for retail organisations.
The process was laid out how we’ve approached the use case and how portfolio solutions are the base for researching a generic architecture.
It continued by laying out the process of how we’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.
Having completed our discussions on the logical view of the architecture, it’s now time to look at a specific example.
This article walks you through an example cloud adoption scenario showing how expanding the previously discussed elements provides an example for your own cloud adoption scenarios.
Architecture review
As mentioned before, the architectural details covered here are base on real solutions using open source technologies. The example scenario presented here is a generic common architecture that was uncovered researching those solutions. It’s our intent to provide guidance and not deep technical details.
This section covers the visual representations as presented, but it’s expected that they’ll be evolving based on future research. There are many ways to represent each element in this architecture, but we’ve chosen a format that we hope makes it easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.
Now let’s take a look at the details in this architecture and outline the solution for a cloud adoption architecture solution.
Cloud adoption
The key to this cloud adoption architecture is the focus on providing the ability to move workloads, be that traditional server hosted or more modern container hosted, from the traditional data center to private or pubic clouds as needed.
Keeping that in mind, this architecture starts on the far left with the generic elements showing how a core data center such as the development teams manage their production. They have their projects in a source code management (SCM) system, which makes use of a method to build out their applications and images shown as a
server image build pipeline, and some form of an image store or registry for distribution across their architecture as needed.
Moving to the right you encounter the destinations for these workloads, from the traditional physical data center, private cloud, to the representation of multiple possible public clouds. Closer examination of each destination shows a simplified generic RHEL host, which can be a physical, virtual, or container based machine along with the image registry used to manage the images for their particular destination as distributed by the central development
image store.
Next up, infrastructure management where we find the smart management element that’s gathering input from all the deployed host machines from every destination and working together automation orchestration element to manage workloads. From the gained insights into your organisations workloads, it’s possible to deploy new updates, manage security patching across all infrastructure destinations, roll out extra resources for surging demand on specific workloads, and so much more. The showcase model is that a workload is determined, based on organisational standards set by you, to be a candidate for migration from the physical data center to any one of the
public clouds. This could be due to cost reductions that are achievable due to changes in public cloud offerings, or due to managing performance by putting a certain workload closer to the customers actual physical location.
Finally, to assist with analysing the data provided by the running hosts, there are cloud services meant to help you manage responses and maintain your repository of automated actions. Over time your automation needs change such that you have a repository of actions you might want to take, which is managed by the enterprise operating automation element. These are fed to the infrastructure management elements for use across the organisation. Also over time you’ll develop plans to react on certain insights as they happen and this collection of plans can be found in the
insights platform that works through insight services to support the infrastructure management elements.
As you can see, automating your cloud infrastructure requires insights based plans and actions that are distributed by management elements that monitor and initiate actions ensuring workloads are deploying to the right destinations for your organisational needs.
Cloud adoption data
This look at a cloud adoption architecture data flow is not meant to be an all encompassing view of the exact flow. The idea is to give an architecture that you use to understand how elements and their data works through the entire cloud adoption architecture.
With that in mind, the data flow shown is from the core data center on the left and works its way through the
image repositories (images), automation orchestration (playbooks), and smart management (packages). From the
image registries in each destination the data shows rolling out the workloads and server images onto the RHEL hosts.
In the cloud services, data flows show the gathering of insights and distribution of the automation action along with recommendations for the smart management to apply across the entire organisations architecture.
This concludes the look at the cloud adoption architecture.
What’s next
This was just a short overview of the example adoption architecture that makes up our architecture for the cloud adoption use case.
An overview of this series on cloud adoption portfolio architecture:
Catch up on any past articles you missed by following any published links above.
This completes the series and we hope you enjoyed this architecture for cloud adoption.
(Article co-authored by Iain Boyle, Chief Architect Retail, Red Hat)
Published on Java Code Geeks with permission by Eric Schabell, partner at our JCG program. See the original article here: Cloud Adoption – Example adoption architecture Opinions expressed by Java Code Geeks contributors are their own. |
