Chapter 4: Designing System Deployment Architectures

How we deploy systems determines so much about how those systems will perform and how resilient they will be for years to come. A good understanding of design components and principles is necessary for us to understand in order to approach the design of the platforms that will carry our workloads. Remember, at the end of the day, only the applications running at the very top of the stack matter - everything beneath the applications, whether the operating system, hypervisor, storage, hardware, and others are just tools used to enable the final application-level workloads to do what they need to do best. It is easy to feel that these other components matter individually, but they do not. To put it another way, what matters is the results rather than the path taken to get to the results.

In this chapter, we are going to start by looking at the building blocks of systems (other than storage which we tackled extensively in our last...

Virtualization

Twenty years ago, if you asked the average system administrator what virtualization was they would look at you with a blank stare. We have had virtualization technologies in IT since 1965 when IBM first introduced them in their mainframe computer systems, but for your average company these technologies were relatively rare and out of reach until vendors like VMware and Xen brought these to the mainstream market around the turn of the millennium. The enterprise space did have many of these technologies by the 1990s, but knowledge of them did not disseminate far.

Times have changed. Since 2005, virtualization has been broadly available and widely understood, with options for every platform and at all price points, leaving no one with a need to avoid implementing the technology because it is out of technical or financial reach. At its core, virtualization is an abstraction layer that creates a computer in software (on top of the actual hardware) and presents a standard...

Containerization

Some people consider containers to be a form of virtualization, sometimes called Type-C virtualization or OS-level virtualization. In recent years, containers have taken on a life of their own and very specific container use cases have become such buzz-worthy topics that containers as a general concept have been all but lost. Containers, however, represent an extremely useful form of (or alternative to) traditional virtualization.

Container-based virtualization varies from traditional virtualization in that in traditional virtualization every aspect of system hardware is replicated in software by the hypervisor and exists uniquely to every instance or virtual machine (often called a Virtual Environment (VE) when talking about containers) running on top of it. There is nothing shared between the virtual machines and by definition any operating system that supports the hardware virtualized can run on it exactly as if it was running on bare metal.

Container-based...

Cloud and VPS

Any discussion of virtualization today is inevitably going to lead us to cloud. Cloud has become, that hot decade-long buzz-worthy concept that everyone wants, most people use, and no one has a clue what it is, what it means, or why anyone uses it. Few technologies are more totally misunderstood, yet widely talked about, than cloud. So we have a lot to cover here, much of it clearly up misconceptions and the misuse of terms.

The bizarre confusion of Cloud

It is a rare combination of being vastly technical and non-applicable to normal business conversations while being constantly discussed as if it were a casual high level non-technical business decision at nearly all levels. Considering only a minuscule fraction of IT professionals have any serious grasp of what cloud is, and even fewer have a clear understanding of when to choose it, that the average non-technical mid-level manager will toss around the term as if they were discussing the price of postage stamps...

On premises, hosted, and hybrid hosting

Now that we have talked about so many aspects of the underlying components that are used to provide us with a platform on which to deploy an operating system, we can finally talk about where those systems should exist!

This is, at least, the simplest of all our topics. Physical location is easy to explain, even if many businesses get confused about it in practice. Conceptually we really only think about two locations for a workload and that is as being either on premises or off premises. This can be a little convoluted, though, as companies own multiple locations so what is off premises to one site might be see as on premises to another. But we generally consider on premises to be all of a company's owned sites and off premises being any sites that are operated by a third party. Because of this we generally refer to off premises physicality as being hosted, as physical systems are being hosted on our behalf. However, there are reasons...

System Design Architecture

One of the more challenging aspects of system administration is tackling the broad concept of system architecture. In some cases, we have it easy, our budget is so low or our needs so simplistic that we simply do not need to consider any but the most basic options. But for many systems, we have broader needs and a great number of factors to consider making system architecture potentially challenging in many ways.

We now understand platform concepts, locality, and the range of services normally associated with providing an environment onto which we can install an operating system. Now we have to begin describing how we can combine these concepts into real world, usable designs. Most of system design is just common sense and practicality. Remember nothing should feel like magic or a black box and if we get services from a vendor, they are using the same potential range of technology and options that we are.

We are going to talk about risk and availability...

Summary

In summary, system architecture is complex and requires us to really dig into business needs, how operations works, talk to key roles throughout the organization and elicit input, and take a broad view of technological building blocks to construct solutions that deliver the performance and reliability that our workloads need at the minimum cost.

We looked at fundamental components with virtual machines and containers and should now be able to defend our use of them and choose properly between them, as well as be able to use traditional containers without becoming confused with more recent application containers. And we learned about locality. You should be able to navigate the complicated linguistic minefield that is managers attempting to talk about the placement and ownership of server resources, analyze costs and risks and find the right option for your organization. Colocation, cloud, traditional virtualization, on premises are all options that you understand.

And...