Architecting Cloud Computing Solutions

Build cloud strategies that align technology and economics while effectively managing risk

Kevin L. Jackson, Scott Goessling

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781788470742
• Edition: 1
• Topic: Informatique
• Subtopic: Administration du système

Accelerating Business and Mission Success with Cloud Computing.About This Book• A step-by-step guide that will practically guide you through implementing Cloud computing services effectively and efficiently. • Learn to choose the most ideal Cloud service model, and adopt appropriate Cloud design considerations for your organization.• Leverage Cloud computing methodologies to successfully develop a cost-effective Cloud environment successfully.Who This Book Is ForIf you are an IT Administrator, Cloud Architect, or a Solution Architect keen to benefit from cloud adoption for your organization, then this book is for you.Small business owners, managers, or consultants will also find this book useful. No prior knowledge of Cloud computing is needed.What You Will Learn• Manage changes in the digital transformation and cloud transition process• Design and build architectures that support specific business cases• Design, modify, and aggregate baseline cloud architectures• Familiarize yourself with cloud application security and cloud computing security threats• Design and architect small, medium, and large cloud computing solutionsIn DetailCloud adoption is a core component of digital transformation. Scaling the IT environment, making it resilient, and reducing costs are what organizations want. Architecting Cloud Computing Solutions presents and explains critical Cloud solution design considerations and technology decisions required to choose and deploy the right Cloud service and deployment models, based on your business and technology service requirements.This book starts with the fundamentals of cloud computing and its architectural concepts. It then walks you through Cloud service models (IaaS, PaaS, and SaaS), deployment models (public, private, community, and hybrid) and implementation options (Enterprise, MSP, and CSP) to explain and describe the key considerations and challenges organizations face during cloud migration. Later, this book delves into how to leverage DevOps, Cloud-Native, and Serverless architectures in your Cloud environment and presents industry best practices for scaling your Cloud environment. Finally, this book addresses (in depth) managing essential cloud technology service components such as data storage, security controls, and disaster recovery. By the end of this book, you will have mastered all the design considerations and operational trades required to adopt Cloud services, no matter which cloud service provider you choose. Style and approachThis book will teach you how to architect effective and organizationally aligned Cloud computing solutions by addressing Cloud computing fundamentals, Cloud architecture considerations, Cloud technology service selection, and Cloud computing security controls.

Hands-On Lab 1 – Basic Cloud Design (Single Server)

Cloud architecture can be difficult; at times, we make it more difficult than we need to. Cloud is shifting everything because it is an economic innovation, not a technical one. Cloud is driven by economics rather than technology. Each new service continues to drive progression via economics by enabling the realignment of strategy, technology, and economics. Containers and serverless are using new economic models to change the way infrastructure and software are deployed. Because the cloud is primarily economics and strategy, it requires updates to skill sets and additional data for decisions.

The cloud is an answer, but not the answer to everything. Cloud does not make bad decisions better. The cloud is a tool. The cloud is a philosophy, a strategy, a mindset, and an attitude. Above all, cloud is a process. A single aggressive move from CAPEX to OPEX is likely to be expensive; it will probably fail, and probably will not solve much. Fork-lifting the same design from an on-premises data center to an off-premises service provider will move the problem, but not solve it. Cloud success requires research, change management, governance, and comparative design. Every design choice affects economics, strategy, technology, and risk.

Hands-on labs and exercises

The next three chapters will discuss the impact of design choices at increasing levels of complexity. These chapters are meant to be used as a step-by-step hands-on guide that will navigate through designs and design choices, yielding real-time insight each step of the way.

This chapter will start with a single-server infrastructure, then we will accelerate into more complex insight and scenarios in Chapter 19, Hands-On Lab – Advanced Cloud Design Insight and Chapter 20, Hands-On Lab 3 – Optimizing Current State (12 Months Later). It is suggested to navigate these example chapters in order, as each one builds on the previous. Complexity with each example grows, adding considerations for applications, application stacking, utilization, and general market and current trends. The examples and exercises in the book will also be accessible via the Burstorm platform, with unlimited use for 30 days.

Complexity

Cloud is typically associated with outcomes such as lower cost, speed, and simplicity, yet cloud can be very complex even in its most basic form. For example, a single server can have many attributes that must be considered. How many cores? How much RAM? How much storage? Is it a virtual server or a physical one? What operating system? What type of connectivity? Is the server on a shared or dedicated environment? What about going serverless? What about containers?

The answers to these seemingly simple questions have a drastically different economic impact and a huge effect on strategy. Each attribute feels somewhat technical in nature, yet they are more about economics and how economics affect strategy. Why would virtual servers be chosen over physical? Better utilization? Isn't utilization really about maximizing the use of an expensive resource? Virtualization allows for the acquisition of only what is needed for as long as needed. Not really. Virtualization has been around since the 1960s. Recent billing innovations are what allow partial resources to be consumed in very short increments of time. Virtual servers can be deployed faster. True, but why does that matter? Physical deployments are very manual, expensive, time-consuming, and potentially filled with human error. Virtual machines can be deployed very quickly and programmatically, eliminating much of the expense, time, and effort associated with deployments.

Virtualization and its benefits are well known. Designs using virtualization have been around for several years now. What is so different? For the first time, we see economic models driving design decisions, for example, reserve instance versus current market rate. Reserve instances require a large upfront fee with a very low monthly fee. What situations are better suited for a longer-term commitment with significant money up front? What strategy does this line up with? How does this affect risk? With the high fees up front and longer commitment requirements, reserve instances are better suited for persistent workloads with fairly flat traffic patterns. Cyclical or seasonal traffic patterns do not fit here, as resources would be paid for when they were not being utilized fully. A major change, as mentioned earlier, is that designs can now be created for the low point with burst or up-cycle moves to support increases in the traffic pattern.

Eliminating the noise

Successful next-generation designers are able to quickly triage true requirements from wants and wishes. Much of the truth is drowned by emotions, agendas, hype, marketing, and other forms of distracting noise. Simplify, then build. Quickly get to the lowest and simplest common denominator and add where truly needed. Every server and GB of storage requires monitoring, administration, management, and all other care-and-feeding type activities. Poor choices at basic infrastructure levels can dramatically affect economics as all of the other requirements are piled on.

A single server is not as simple as it sounds. The following diagram shows a set of basic options that can be applied to any server. There are a number of options for each attribute, of which one is chosen. The chart shows almost 6.3 billion potential combinations for this single server. Considerations for other attributes, such as external storage, port configuration, software, patch level, and so on, have not been accounted for. The potential combinations can quickly reach into the trillions for a single server when all attributes are considered. Add in additional combinations when adding in additional servers, licensing options, additional devices, additional potential locations, potential providers, pricing options, business models, consumption rules, deployment rules, and the many other nuances that permeate every solution design.

In the following example, we see three different term options. This may equate to 12-, 24-, or 36-month terms, with only one term being chosen. We see that cores, in this example, can be any number between 1 and 12. RAM could be anything between 1 and 16. Obviously, there are many other options and add-ons, such as monitoring, management, licensing, and so on. But just basic server configuration choices already place this single server into the 6+ billion combination range:

Burstorm lab 1 – background (NeBu Systems)

All of the hands-on exercises will be for a company named NeBu Systems. NeBu creates software for the automotive industry. New cars have almost as much processing power within them as full data centers in recent years. With all of the sensors gathering IoT data and the tremendous compute power available for processing, NeBu is trying to transition away from large monolithic legacy applications to highly flexible cloud-based modular functions aimed at changing the automotive experience. The goal is to be positioned to adapt as some functions become widely adopted while others are driven to satisfy certain niche markets. Ideally, functions are added as custom apps similar to adding apps to cell phones or picking car colors and upholstery types.

In this first lab, NeBu is developing a new application that will be engineered for the cloud from the beginning. No legacy code to deal with. No legacy dependencies or specific hardware requirements complicating things. The code will be written using modern languages, eliminating concern over hardware compatibility.

Burstorm lab 1 – getting started

Please send an email to [email protected] with the following:

• (Required) current ...