In our previous article from this series we introduced a use case around cloud adoption for retail stores.
The process was laid out how we’ve approached the use case and how portfolio solutions are the base for researching a generic architecture.
The only thing left to cover was the order in which you’ll be led through the architectural details.
This article starts the real journey at the very top, with a generic architecture from which we’ll discuss the common architectural elements one by one.
This will start our journey into the logical elements that make up the cloud adoption architecture.
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.
From specific to generic
Before diving in to the common elements, it might be nice to understand that this is not a catch all for every possible solution. It’s a collection of identified elements that we’ve uncovered in multiple customer implementations. These elements presented here are then the generic common architectural elements that we’ve identified and collected in to the generic architecture.
It’s our intent to provide an example for guidance and not deep technical details. You’re smart enough to figure out wiring integration points in your own architectures. You’re capable of slotting in the technologies and components you’ve committed to in the past where applicable. It’s our job here to describe the architecture generic components and outline a few specific cases with visual diagrams so that you’re able to make the right decisions from the start of your own projects.
Another challenge has been how to visually represent the architecture. There are many ways to represent each element, but we’ve chosen some icons, text and colours that we hope are going to make it all easy to absorb.
Core data center
The logical view splits this solution space into several identifiable collections where the cloud adoption solution is laid out. These logical collections ensure that your organisation can provide effective automation for deploying and managing workloads across multiple cloud infrastructures according to performance, security, compliance, and cost requirements.
The first collection on the left is tagged as the core data center and holds all the logical elements needed to put together the images for your infrastructure and workloads to run on. You find a source code management (SCM) system, an image store, and the server image build pipeline. All elements used by an organisation to create, manage, store, and testing images for distribution.
The infrastructure management collection is where intelligence is gathered, monitoring is performed, and based on the findings, triggers automated reactions and orchestrates updates to your infrastructure anywhere in your organisation.
A smart management element is used for tracking, managing, auditing, and collecting data on your entire infrastructure to ensure that baselines are met. Based on your choices and the results of data collected, your insights trigger corrections, updates, or even rolling out of new infrastructure across any of the cloud infrastructure your organisation might be using.
The automation orchestration element is tasked with orchestration of infrastructure tasks in a fully automated and pre-tested fashion. This element is directed to execute certain tasks in a certain order based on the findings of the
smart management element.
This collection of elements are all aspects of an organisations cloud infrastructure. The idea is that organisations are at the very least moving to put the cloud-native experience together for their development teams to execute on their business goals while supporting an agile customer experience.
To provide a cloud experience, existing physical data center resources might be the starting point to be offered to the organisation with a cloud-like experience. Once this is completed, the organisation then has a private cloud to build, test, and run its workloads on.
Finally, as needed, organisations can expand services and applications out into one or more of the public cloud providers. All of these are shown here as a Red Hat Enterprise Linux (RHEL) host element with an image registry to facilitate the deployment of infrastructure, services, and applications across the entire hybrid cloud infrastructure.
Last but not least, there is a need for cloud services that can facilitate all it takes to span the monitoring, analysing, and deployment of an organisations workloads across their hybrid cloud infrastructure.
The first element is that of enterprise operating automation which facilitates consistent, repeatable, and tested infrastructure automation tasks as needed by the other elements managing the hybrid cloud infrastructure.
Next, there is the insights platform. This is key to monitoring and data collection around the entire hybrid cloud infrastructure. Based on this data and working together with insights services, automated actions can take place around updates, security patches, infrastructure rollouts, workload management, and workload migrations. This is the key to an organisations ability to successfully adopt a truly hybrid cloud infrastructure.
This was just a short overview of the common generic elements that make up our architecture for the cloud adoption use case.
An overview of this series on the cloud adoption portfolio architecture:
Catch up on any past articles you missed by following any published links above.
Next in this series, taking a look at an example adoption architecture.
(Article co-authored by Iain Boyle, Chief Architect Retail, Red Hat)