31,19 €
Hybrid cloud is currently the buzz word in the cloud world. Organizations are planning to adopt hybrid cloud strategy due to its advantages such as untested workloads, cloud-bursting, cloud service brokering and so on. This book will help you understand the dynamics, design principles, and deployment strategies of a Hybrid Cloud.
You will start by understanding the concepts of hybrid cloud and the problems it solves as compared to a stand-alone public and private cloud. You will be delving into the different architecture and design of hybrid cloud. The book will then cover advanced concepts such as building a deployment pipeline, containerization strategy, and data storage mechanism. Next up, you will be able to deploy an external CMP to run a Hybrid cloud and integrate it with your OpenStack and AWS environments. You will also understand the strategy for designing a Hybrid Cloud using containerization and work with pre-built solutions like vCloud Air, VMware for AWS, and Azure Stack. Finally, the book will cover security and monitoring related best practices that will help you secure your cloud infrastructure.
By the end of the book, you will be in a position to build a hybrid cloud strategy for your organization.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 290
Veröffentlichungsjahr: 2018
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Reviewers: David Duncan, Ganesh RajaCommissioning Editor: Gebin GeorgeAcquisition Editor: Rohit RajkumarContent Development Editor: Nithin VargheseTechnical Editor: Mohit HassijaCopy Editors: Safis Editing, Laxmi SubramanianProject Coordinator: Virginia DiasProofreader: Safis EditingIndexer: Rekha NairGraphics: Tom ScariaProduction Coordinator: Nilesh Mohite
First published: February 2018
Production reference: 1220218
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78862-351-3
www.packtpub.com
Chapter number
Software required (With version)
Free/Proprietary
If proprietary, can code testing be performed using a trial version
If proprietary, then cost of the software
Download links to the software
Hardware specifications
OS required
1
Samba 4.x Server Software
Proprietary
Yes
$600
http://www.sampleURl.com
Common Unix Printing System with 4GB RAM and Graphic Card supporting DirectX 11
Windows
Detailed installation steps (software-wise)
The steps should be listed in a way that it prepares the system environment to be able to test the codes of the book.
Software A:
Step 1
Step 2
Software B
Step a
Step b
Step c
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Alok Shrivastwa is a technologist from India, currently working as the director of special projects for Microland in the CMD's office. He currently runs special projects on cloud technologies. Having worked at multiple enterprises of varied sizes, designing and implementing solutions, public and private clouds, and integrations, he has created a myriad number of tools and intellectual properties in the operationalization of emerging technologies. He has authored two books on OpenStack alongside several white papers and blogs on technology, in addition to writing poems in Hindi.
David Duncan is a partner solutions architect at Amazon Web Services who specializes in enabling open source platform partners. He focuses on enabling Linux support on Amazon EC2, cloud native deployments, and hybrid cloud workloads with operating system partners such as Red Hat OpenShift, SUSE Cloud Application Platform, and the Canonical distribution of Kubernetes. David is a coauthor of the book AWS Quick Start for Red Hat OpenShift.
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Title Page
Copyright and Credits
Hybrid Cloud for Architects
Software Hardware List
Packt Upsell
Why subscribe?
PacktPub.com
Contributors
About the author
About the reviewer
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the example code files
Download the color images
Conventions used
Get in touch
Reviews
Introducing Hybrid Cloud
The cloud's demographics
Based on abstraction
Service down clouds 
Infrastructure up clouds 
Differentiating service down and infrastructure up clouds 
Based on services offered
Based on consumers of the services 
Choosing different cloud combinations
Summary
Hybrid Cloud – Why Does It Matter?
What does the world say? 
Pure-play public cloud strategy 
Public cloud benefits
Need for agility
Ability to experiment without upfront cost
Reducing operational overheads
Ability to consume enhanced services
Shortcomings of a public cloud
Cost 
Control/customizability
Compliance 
Fear of lock-in
Hybrid cloud case study
Summary – maximizing benefits
Hybrid Cloud Building Blocks
The story of a web application 
Transport level 
Case 1 – without a proxy
Case 2 – with a proxy 
Application level 
Web tier 
Application tier 
Database tier 
Putting it all together
Use cases of a hybrid cloud 
Isolated use case 
Distributed use case 
Co-Existent use case 
Cloud bursting 
Using cognitive services 
Supporting application use cases 
Backup and disaster recovery in the cloud
Decoupling the tiers
Case in point – architecture of OpenStack
Services to enable a hybrid cloud 
Network connectivity 
DNS service 
Public cloud services for hybrid deployment
Amazon Web Services (AWS)
Storage gateway
Direct connect
Route 53
Amazon EC2 run command
VMware cloud on AWS 
Microsoft Azure
Azure Stack
Azure Site Recovery (ASR)
Azure Traffic Manager
Summary – setting up hybrid cloud
Architecting the Underpinning Services
Networking
Underlay network
LAN architecture
WAN architecture
Overlay networking
GRE
VXLAN
Virtual Private Network (VPN)
Encrypting data using IPSec and SSL – concepts
IPSec VPN
SSL VPN
MPLS connectivity – direct connect
Routing table
Domain Name System (DNS)
How does DNS work?
Global load balancing
Identity and Access Management (IAM) 
Identity Federation 
Multi-Factor Authentication (MFA)
Application components
Global databases 
Using Cockroach DB in a hybrid cloud environment 
Database log shipping
Choosing the right components
Network connectivity 
DNS services 
IAM and Active Directory 
Conclusion 
Hybrid Cloud Deployment – Architecture and Preparation
Getting started with the public cloud – AWS
AWS terminology 
Account
Region 
Availability zones (AZ)
Virtual private cloud (VPC)
AWS services 
Architecting the AWS environment 
AWS account design
VPC design 
Designing an AWS environment 
Connectivity to the private cloud
Setting up a public cloud – AWS
Creating an account in AWS
Creating a VPC and subnets
Creating the IGW and VGW
Setting up AWS API access 
Setting up the private cloud 
Basics of designing an OpenStack environment
Choosing an OpenStack distribution 
Choosing the deployment method
Installing DevStack 
Configuring DevStack to enable Heat
Summary
Building a Traditional CMP-Based Hybrid Cloud
Supporting applications use case
Traditional operations 
Modern outlook
Using the AWS storage gateway
File gateway
Volume gateways
Tape gateway 
Isolated/distributed application use case
General architecture of CMP
ManageIQ
Installing ManageIQ
Preparing the host environment 
Containerization basics
Understanding and installing Docker
Installing a ManageIQ container
Configuring ManageIQ to connect to AWS and OpenStack 
Adding a new AWS EC2 provider 
Adding our OpenStack endpoint 
Provisioning virtual machines using ManageIQ 
Creating a catalog
Creating a Service Dialog
Creating a catalog item and catalog
Testing the catalog
Policies and user authentication
Creating cloud images
In conclusion – architecting with a CMP
Summary
Building a Containerized Hybrid Cloud
Evolving to containers
Container networking 
None – no networking
Bridge networking
Host networking 
Overlay networking 
Underlay networking 
Container orchestration engine 
Kubernetes architecture 
Basic concepts in Kubernetes
Pod
Controllers
Service 
Volumes
Namespaces
Kubernetes deployment
Introduction to Juju 
Installing the Juju client and bootstrapping clouds
Bootstrapping an AWS Cloud 
Bootstrapping an OpenStack Cloud 
Accessing the Juju controller using a GUI
Deploying Kubernetes with Juju
Deploying a second instance of Kubernetes 
Connecting to the Kubernetes clusters
Federation using Kubernetes
Reasons for consideration 
Application migration – avoiding vendor lock-in
Enforce policies 
High availability and application upgrades
Cloud bursting 
Federation challenges
Implementing a Kubernetes federation
Step 1 – setting up the federation controller 
Step 2 – combining the Kubernetes configuration (optional)
Step 3 – creating the federation 
Creating the DNS provider 
Initializing the federation 
Summary 
Using PreBuilt Hybrid Cloud Solutions
Azure Stack 
Getting the Azure Stack
OpenStack Omni 
Installing OpenStack Omni on DevStack
Removing the DevStack instance
Modifying the local.conf file
Running DevStack 
vCloud Air
Using the different hybrid cloud solutions 
Summary
DevOps in the Hybrid Cloud
The development cycle and DevOps 
The traditional development stages 
Merging the different teams
Creating the infrastructure
Configuring the infrastructure
Templatize
DevOps or NoOps
IaaC with Terraform 
Installing Terraform 
Configuring and using Terraform
Configuration management using Ansible
Installing Ansible
Configuring Ansible and a sample playbook 
Summary
Monitoring the Hybrid Cloud
The traditional concepts in monitoring
Availability monitoring 
ICMP monitoring 
TCP/UDP monitoring 
Enhanced monitoring 
SNMP-based availability monitoring
Performance monitoring 
SNMP monitoring
WMI monitoring and custom agent monitoring
Monitoring the hybrid cloud
Prometheus
The implementation architecture of Prometheus
Installing Prometheus
Downloading Prometheus
Setting up directories
Setting up startup script
Setting up node exporter
Configuring Prometheus
Grafana
Installing Grafana
Configuring Grafana to use Prometheus
Summary
Security in a Hybrid Cloud
Components of security
The CIA triad
Confidentiality
Integrity
Availability
Tools to protect against the breaches
IAM systems
Data encryption in rest and in motion
Network perimeter security
Firewalls
IDS/IPS
Proxies
Host controls
High availability and disaster recovery
Detection and analytics mechanism
Minimizing shared infrastructure
Compliance standards and controls
HIPAA compliance standards
Administrative controls
Physical controls
Technical controls
Security controls consideration in hybrid cloud
Common controls
Implementing the controls on AWS – public cloud
Security – shared responsibility model
Implementing the controls in private cloud
Security – best practices
Implementing a CMDB/asset list
User accounts and authentication
Provisioning and postprovisioning controls
Networks 
Other practices
Summary
Other Books You May Enjoy
Leave a review - let other readers know what you think
The book takes us on a journey of architecting, building, and operating a hybrid cloud while taking a very pragmatic approach towards it. The book starts by defining the different demographics of the cloud and the different use cases that need to be solved. It then introduces two modes of building a hybrid cloud, with the CMP and the other with containers—along with the use cases that each of them addresses. The book finally drops into operational mode with topics such as DevOps, monitoring, and security considerations in the hybrid cloud.
This book is targeted at cloud architects, cloud solution providers, DevOps engineers, or any working stakeholder who wants to learn about the hybrid cloud architecture. A basic understanding of public and private clouds is desirable.
Chapter 1, Introducing Hybrid Cloud, deals with the definitions and demographics of the cloud, the differences between service down and infrastructure up cloud, and its examples.
Chapter 2, Hybrid Cloud – Why Does It Matter?, starts with adoption statistics of the hybrid cloud and moves on to drivers for cloud adoption, public cloud benefits, and its shortcomings. Finally, we introduce a case for hybrid cloud and how to maximize the benefits using the best of both worlds.
Chapter 3, Hybrid Cloud Building Blocks, introduces the building blocks of the hybrid cloud using an example of a web application, use cases that potentially will need a hybrid cloud, making applications suitable for a hybrid cloud using decoupling, and services that are used to enable the hybrid cloud.
Chapter 4, Architecting the Underpinning Services, covers the concepts of networking, DNS systems, IAM systems, application components, and choosing the appropriate components for the use with a hybrid cloud.
Chapter 5, Hybrid Cloud Deployment – Architecture and Preparation, covers the concepts of AWS, architecting an AWS environment, the basic design of an OpenStack environment, setting up a DevStack, and connectivity between the cloud environments.
Chapter 6, Building a Traditional CMP-Based Hybrid Cloud, starts with AWS's storage gateway and use cases in the hybrid cloud scenario, the concepts of CMP, setting up Docker, and running a ManageIQ container in Docker.
Chapter 7, Building a Containerized Hybrid Cloud, introduces the basics of container orchestration platforms, an introduction to Kubernetes, deploying Kubernetes using Juju, and closes with using the kubefed project to federate a hybrid cloud based on Kubernetes.
Chapter 8, Using Prebuilt Hybrid Cloud Solution, introduces products that are available from different providers, including AzureStack and Project Omni.
Chapter 9, DevOps in the Hybrid Cloud, deals with the traditional development cycle and the steps involved, along with the concepts of DevOps and NoOps. We look at the introduction to IaaC, templatizer, and configuration management systems and their roles in the development cycle. We take an example of Terraform and its deployment with a sample to solidify the concepts of IaaC. Also, deploy Ansible and a sample to solidify the concepts of configuration management.
Chapter 10, Monitoring the Hybrid Cloud, introduces the basics of monitoring, along with Prometheus and Grafana, to help us monitor the hybrid cloud.
Chapter 11, Security in a Hybrid Cloud, starts with the concepts of security and compliance standards, and moves on to taking HIPAA as an example to elucidate some of the best practices that need to be used.
While a simple reading of the book will impart the different architectural and cloud concepts to the reader, in order to follow along, ensure that you have the following:
An internet connection to download the software.
A Ubuntu 16.04 machine to act as the management system.
A fully functioning OpenStack deployment or a Ubuntu 16.04 machine to run DevStack.
AWS user account—if you don't have the user account, ensure that you have your credit card ready in order to open a free account. (Remember that while we have taken care to use the
free-tier
systems in AWS, make sure you use the appropriate instance sizes and AMI IDs if you are creating the environment in a different region).
You can download the example code files for this book from your account at www.packtpub.com. If you purchased this book elsewhere, you can visit www.packtpub.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register at
www.packtpub.com
.
Select the
SUPPORT
tab.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box and follow the onscreen instructions.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR/7-Zip for Windows
Zipeg/iZip/UnRarX for Mac
7-Zip/PeaZip for Linux
The code bundle for the book is also hosted on GitHub athttps://github.com/PacktPublishing/Hybrid-Cloud-for-Architects. In case there's an update to the code, it will be updated on the existing GitHub repository.
We also have other code bundles from our rich catalog of books and videos available athttps://github.com/PacktPublishing/. Check them out!
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://www.packtpub.com/sites/default/files/downloads/HybridCloudforArchitects_ColorImages.pdf.
Feedback from our readers is always welcome.
General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
The word cloud has been commonplace in the industry and marketplace for over a decade. In its modern usage, it was first used in August of 2006, when Eric Schmidt of Google used it to describe an emergent new model (Source: Technology Review). However, now thanks to a, then, little-known company called Amazon Web Services (AWS), it has become immensely famous.
Once the term cloud computing became a part of common IT parlance, there was no dearth of definitions. Almost everyone had something to sell, and added their own spin on the terminology.
In this chapter, we will attempt to decipher this different terminology in relation to the definitions of the different clouds.
If you are wondering why this is important, it is to make and maintain the clarity of context in future chapters, as new concepts emerge and are commingled in the grand scheme of architecting the hybrid cloud.
In the remaining part of the chapter, we take a look at different definitions of the cloud and the different products used.
In trying to navigate through the maze of the several definition's that are available, it is clear that there are various ways in which we can take a look at clouds, however, we will focus on the main ones and simplify them for our understanding.
As a first step, let us define what could pass as cloud computing. The Wikipedia definition is as follows:
If we look at that statement from a technical standpoint, it would be fair to say that in order for something to be referred to as cloud computing, it must at least possess the following characteristics:
Self-service (reduces wait time to get resources provisioned)
Shared, standard, consistent (shared pools of configurable resources)
Cross-domain automation (rapid provisioning)
Consumption based chargeback and billing
The three main ways in which we can take a look at dissecting the clouds are as follows:
Based on abstraction
Based on the services offered
Based on the consumers of the services
The underlying principle of cloud is abstraction; how it is abstracted determines a lot of its feature sets and behavior. However, this aspect of the cloud is little-known and often ignored. It only becomes evident when dealing with different kinds of clouds from different providers.
We shall delve into the details and nuances. For starters, these are:
Service down clouds
Infrastructure up clouds
To understand these better, let's take a look at the following stack, (which is used to run an application). The stack assumes a virtualized infrastructure being used to run the application.
In the event of an application running on bare-metal, the Virtual Machine and the Hypervisor layers will be absent, but the remainder of the stack will still be in play.
In traditional IT businesses, different teams manage different aspects of this stack. For example, the Infrastructure management team manages the underlying hardware and its configuration, the Virtualization team manages the Virtual Machine and the Hypervisor, the Platform team manages the Middleware, the Operating System teams manage the Operating System and finally the Application team will manage the Application and the data on top of the stack.
Now, from the perspective of the Infrastructure management team, they see that the application runs on the Virtual Machine and from the perspective of the Application developers, they simply see that the Infrastructure team is providing a combination of three services namely Network, Compute, and Storage. This is the essence of the split.
The service down approach of building clouds was pioneered by AWS. This approach was created for developers, by developers. The salient feature of this kind of cloud is the fact that everything is a Lego block, which can be combined in different ways in order to achieve a desired function.
In the service down approach, the Create, Read, Update, and Delete (CRUD) operations on these Lego blocks are normally done using API calls, so that developers can easily request the resources they need using programming and not by operations.
In the service down cloud, everything, such as compute (RAM and CPU), storage, network, and so on is a separate service and can be combined to give us a Virtual Machine. The following diagram shows the three blocks (the service names used are AWS services, however all service down clouds will have equivalents) coming together in order to create a traditional equivalent of a virtual machine:
The Lego block idea works on a second level, which means you are free to move this between the different virtual machines. In the following diagram, as an example, you can see that the Storage 1 of Virtual Machine 1 is being remapped to Virtual Machine 2, using API calls, which is unheard of when we take into account the traditional infrastructure:
The examples of this kind of abstraction are seen in Hyperscale Clouds such as AWS, Azure, and Google Cloud Platform. However, OpenStack is also designed as a service down cloud.
Having understood the service down cloud, it is clear that this concept of Lego blocks that has enabled us to treat our infrastructure as cattle, or pets, means if one of your servers is sick you can rip it out and replace it rather than spend time troubleshooting it. You may even choose to have the same IP address and the same disk.
Infrastructure up, as a concept is simply appending a orchestrator to the existing virtualization stack that we saw before, thereby enabling self-service and increasing agility by automation.
The cloud purists would not even consider these clouds, but there is no denying that they exist. This concept was created to bridge the chasm that was created due to the radical shift of the paradigm of how the applications got created in the service down cloud.
In this kind of cloud, the smallest unit would request and get a virtual machine. There are several Orchestrators that would help provide these functionalities, some of the notable ones include, VMware vRealize Suite (https://www.vmware.com/in/products/vrealize-automation.html), Cisco CIAC (https://www.cisco.com/c/en/us/products/cloud-systems-management/intelligent-automation-cloud/index.html), BMC Atrium (http://www.bmcsoftware.in/it-solutions/atrium-orchestrator.html), to name a few.
The way this is created is by adding a Cloud Orchestrator solution on top of an existing virtualization environment. This provides features such as self-service and billing/chargeback/showback.
The Orchestrator then performs cross domain automation in order to provision virtual machines for the user. As you can see, in this case the life cycle management of the VM is automated, but the idea behind the provisioning has not changed so much. In the event that you decide to delete the VM, more likely than not, all the associated resources also get deleted.
An infra-up cloud is normally characterized by the presence of a workflow Engine, which allows integration to different enterprise systems. It should be no surprise that major infra-up clouds are used in private. There are some exceptions, for example the Vodafone Secure Cloud, which is a public cloud that runs on an infra-up approach.
Since this might be a new concept for some of us, let's look at a comparison between service down and infra-up and the features they provide by default:
Infrastructure as code
Not present
Present
Self-service
Present
Present
API endpoints
Present
Present
Smallest unit that can be consumed
Virtual machine
Compute as a Service
Network as a Service
Storage as a Service and so on.
Chargeback/billing
Not very well-developed/monthly
Hourly, per-minute (or) per-second
Integration ability with existing enterprise tools (for example, IPAM, CMDB, and so on)
Present
Not present
PaaS services (DBaaS, Containers as a Service)
Not present
Present
This is a very well-known piece of the cloud. Based on the services that a cloud offers, it could be divided into the following:
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Software as a Service (SaaS)
While I am sure that we are familiar with these demographics of the cloud, let us take a look at the differences:
As we move from the on-premises model to IaaS, PaaS, and SaaS, the ability to customize the software decreases and standardization increases. This has led to a lot of independent software vendors (ISVs) re-writing their applications in a multi-tenanted model, and providing it to the customers in an as a service model.
When developing bespoke applications, organizations are choosing PaaS and IaaS instead of the traditional model, which is helping them increase agility and reduce the time to market.
Some examples of this cut of data is as follows:
Yes, you read that right. AWS, Azure, and GCP all have IaaS and PaaS services (and arguably some SaaS services also, but more on that later).
This demographic is also extremely well known. Depending on who the cloud is created for, or who is allowed to use the services from a cloud, they can be categorized into three types:
Public
: Anyone is allowed to access
Private
: A certain set of users are allowed to access
Community
: A group of similar enterprises are allowed to access
This is easily understood by using a road analogy. A highway for example, can be used by everyone, thereby making it public. A road inside the grounds of a palace would be considered a private road. A road inside a gated community would be considered a community road.
Now, since we have that out of the way, let us take a look at a few examples:
Public cloud
: AWS, Azure, GCP, RackSpace (OpenStack), and so on
Private cloud
: Company X's vRealize Environment
Community cloud
: AWS government clouds and so on
As you will have realized, the three demographics are not mutually exclusive, which means we can use all three terms in order to describe the type of cloud.
Now we know the different combinations, let's try and answer the following questions:
Are all the infra-up clouds private?
Conversely, are all the service down clouds public?
Can infrastructure up clouds be used only to serve IaaS?
You get the idea! Now, let's take a close look at the answers to these questions, and then try to decipher what circumstances might impact our decision of which cloud to use.
So a statement of fact would be, while all infra-up clouds are not private, most of them are. As an exception to this rule, a public cloud provided by Vodafone runs on VMware vRealize Suite, thereby making it an infrastructure up cloud.
The same thing is applicable to service down clouds. They are mostly used as public clouds, however, if one has a private OpenStack deployment, then it is still a service down cloud. As an example, Cisco, SAP, Intel, AT&T, and several other companies have massively scalable private clouds running on OpenStack (thereby making it a service down cloud)
While infrastructure up cloud orchestrators technically provide IaaS by default, there have been some who take it to the next level by providing Database as a Service (DBaaS) and so on.
The following section attempts to provide a few circumstances and some points you should consider when choosing the right kind of cloud:
DevOps/NoOps:
