Hybrid Cloud for Architects - Alok Shrivastwa - E-Book

Hybrid Cloud for Architects E-Book

Alok Shrivastwa

0,0
31,19 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.

Mehr erfahren.
Beschreibung

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:

EPUB
MOBI

Seitenzahl: 290

Veröffentlichungsjahr: 2018

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Hybrid Cloud for Architects

 

 

Build robust hybrid cloud solutions using AWS and OpenStack

 

 

 

 

 

 

 

 

 

 

 

Alok Shrivastwa

 

 

 

 

 

 

 

 

 

 

 

 

BIRMINGHAM - MUMBAI

Hybrid Cloud for Architects

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.io

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.

Why subscribe?

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

PacktPub.com

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.

Contributors

About the author

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.

We as humans need contrast, without which we cannot perceive. Because of this, to show something in a good light, something has to be made the villain. This book is about being pragmatic when looking at the cloud. I thank God for the perspective, and my family—my mother, father, sisters and my niece, Aarya—who helped me see it. I am thankful to each and every person who I meet and learn from.

About the reviewer

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.

 

 

 

 

Packt is searching for authors like you

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.

Table of Contents

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

Preface

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.

Who this book is for

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.

What this book covers

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. 

To get the most out of this book

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). 

Download the example code files

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!

Download the color images

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.

Get in touch

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.

Reviews

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.

Introducing Hybrid Cloud

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. 

Did you know?  Amazon started work on its cloud in the year 2000; the key years in its development were 2003, 2004, and 2006. In 2004, the AWS, or web services at the time, were simply a group of disparate APIs and not a full-blown IaaS/PaaS service as it is today.  The first service to be launched in 2003 was a Simple Queue Service (SQS) and then later, S3 and EC2 were added. In 2006, the cloud as we know it today gained popularity. 

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.

Did you know?The term cloud computing was first used in 1996, by a group of executives at Compaq to describe the future of the internet business.  - Technology Review 

In the remaining part of the chapter, we take a look at different definitions of the cloud and the different products used. 

The cloud's demographics

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:

"Cloud computing is an(IT) paradigm, a model for enabling ubiquitous access to shared pools of configurable resources (such as computer networks, servers, storage, applications and services), which can be rapidly provisioned with minimal management effort, often over the Internet"

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

Based on abstraction

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. 

Service down clouds 

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. 

Pets versus cattle: This analogy came up some time between 2011 and 2012, and describes the differences in treating your infrastructure in the cloud-based world or a traditional world. Read more about them by googling the term Pets vs Cattle in Cloud: http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ In brief:  Traditionally the infrastructure got treated as pets, we used to name them, nurture them, if they fell sick, we treat and care for them (troubleshoot them) and nurse them back to health.These days, the cloud infrastructure gets treated as cattle, we number them, don't get attached to them, and if they fall sick, we shoot them, take their remains, and get a new one in their place. 

Infrastructure up clouds 

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.

Differentiating service down and infrastructure up clouds 

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:

The following table is only what is offered as default, most capabilities that are not present can be added by automation/customization in both of the fields.
Features
Infra-up
Service down
Workflow engine
Present
Not present

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

Based on services offered

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: 

Cloud Type
Examples
IaaS
OpenStack, AWS, Azure, GCP, and so on
PaaS
Cloud Foundry, AWS, Azure, GCP, and so on
SaaS
ServiceNow, Force.com, and so on 

 

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). 

Based on consumers of the services 

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. 

Choosing different cloud combinations

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: