Should you virtualize an edge computing server?

How does virtualization factor into your edge computing plan?

The need to pack a lot of compute power into a small package leaves many wondering whether containers and serverless frameworks could replace virtualization at the edge.

Robert Sheldon

Contributor – SearchSQLServer

IT teams have been steadily moving their workloads to the network’s edge to process data closer to its source. Many of these workloads run in virtual environments, but some IT professionals question whether it makes sense to virtualize an edge computing server at all.

The exact meaning of edge computing and how it’s implemented outside of the data center is still up for debate. Some think of edge computing in terms of intelligent devices. Others envision intermediary gateways that process client data. Still others imagine micro data centers that service the needs of remote workers or satellite offices.

Despite the disparity in perspectives, however, they all share a common characteristic: Client-generated data is processed at the network’s periphery as close to its source as possible.

Edge computing is much different than using a centralized data center. For example, administrators usually manage edge computing servers remotely, often using tools with intermittent network access. In addition, edge sites typically have space and power restrictions that make it difficult to add capacity to an existing system or to significantly modify the architecture. In some cases, an edge site might require specialized hardware or need to connect to other edge sites.

A number of factors push organizations to the edge, particularly mobile computing and IoT, which generate massive amounts of data. The mega data center can no longer meet the demands of these technologies, which results in an increase in data latencies and network bottlenecks.

At the same time, emerging technologies are making edge computing more practical and even more cost-effective than traditional approaches, as it addresses the limitations of the centralized model.

The edge computing server and virtualization

To keep edge processing as efficient as possible, some teams run containers or serverless architectures on bare metal to avoid the overhead that comes with hypervisors and VMs.

In some cases, this might be a good approach, but even in an edge environment, virtualization has benefits — flexibility, security, maintenance and resource utilization, to name a few. Virtualization will likely remain an important component in many edge scenarios, at least for intermediary gateways or micro data centers. Even if applications run in containers, they can still be hosted in VMs.Virtualization will likely remain an important component in many edge scenarios, at least for intermediary gateways or micro data centers.

Researchers view the VM as an essential component of edge computing and believe that admins can use VM overlays to enable more rapid provisioning and to move workloads between servers. But researchers are not the only ones focused on bringing virtualization to the edge.

For example, Wind River’s open source projectStarlingX makes components of its Titanium Cloud portfolio available through the OpenStack Foundation. One of the goals of the project is to address common requirements for virtualizing an edge computing server. The code already includes a virtual infrastructure manager (VIM), as well as VIM helper components.

VMware is also committed to edge computing and is working on ways to virtualize compute resources throughout the entire data flow, including edge environments. For example, VMware offers hyper-converged infrastructure software powered by vSAN. Shops can use the software to support edge scenarios through VMware vSphere and the VMware Pulse IoT Center. This provides a system that includes secure, enterprise-grade IoT device management and monitoring.

Other vendors are also moving toward the edge, and virtualization is playing a key role. Although edge computing doesn’t necessarily imply virtualization, it by no means rules it out and, in fact, often embraces it.

Administration on the edge

Along with edge computing come a number of challenges for admins trying to manage virtual environments. The lack of industry standards governing edge computing only adds to the complexities.

As computing resources move out of the data center and into the network’s periphery, asset and application management are becoming increasingly difficult, especially because much of it is carried out remotely. Admins must come up with ways to deploy these systems, perform ongoing maintenance and monitor the infrastructures and applications for performance issues and trouble spots, and address such issues as fault tolerance and disaster recovery.

If an IT team manages only one edge environment, they should be able to maintain it without too much difficulty. But if the team must manage multiple edge environments and each one serves different functions and is configured differently, the difficulties grow exponentially. For example, some systems might run VMs, some might run containers and some might do both. The systems might also operate on different hardware, use different APIs and protocols, and execute different applications and services.

Admins must be able to coordinate all these environments, yet allow them to operate independently. Edge computing is an industry in its infancy, and network-wide management capabilities have yet to catch up.

But management isn’t the only challenge. An edge computing server often has resource constraints, which can make it difficult to change the physical structure or accommodate fluctuating workloads. These challenges go beyond such capabilities as VM migration.

In addition, admins might have to contend with interoperability issues between the source devices and edge systems, as well as between multiple edge systems. This is made all the more difficult by the different configurations and lack of industry standards.

One of the biggest challenges that admins face is ensuring that all sensitive data is secure and privacy is protected. Edge computing’s distributed nature increases the number of attack vectors, which makes the entire network more vulnerable to attack, and the different configurations increase the risks.

For example, one system might run containers in VMs and the other on bare metal, resulting in disparity in the methods IT uses to control security. The distributed nature can also make it more difficult to address compliance and regulatory issues. And, given the monitoring challenges that come with edge computing, the risks of undetected intrusions are even greater.

How does virtualization factor into your edge computing plan?

Engage with the expert.

This was last published in August 2018

Steps to install Docker on Ubuntu 16.04 servers

What issues have arisen during your Docker installation?

If IT wants to maximize Docker’s potential on Ubuntu 16.04 servers, know these steps and commands to ensure a smooth installation.

Jack Wallen

Linux expert – SearchDataCenter

Containers enable organizations to expand beyond the standard server in ways that traditional technologies cannot.

With containers, you can bundle a piece of software within a complete file system that contains everything it needs to run: code, runtime, system tools, system libraries and so on. When you deploy an application or service this way, it will always run the same, regardless of its environment.

If you want to containerize a service or an app, you’ll need to get up to speed with Docker, one of the most popular container tools. Here are some guidelines to install Docker on Ubuntu 16.04 servers and fulfill Docker’s potential.

What to know before you install Docker on Ubuntu 16.04

Before you install Docker on Ubuntu 16.04, update the apt utility — a package manager that includes the aptcommand — and upgrade the server. If apt upgrades the kernel, you may need to reboot. If you need to reboot, do it when the server can be down for a brief period. It’s important to note that you can only install Docker on 64-bit architecture, with a minimum kernel of 3.10.

To update and upgrade, enter the following commands:

sudo apt-get update
sudo apt-get upgrade

Once the update/upgrade is complete, you can install Docker with a single command:

sudo apt-get install -y docker.io

When the install completes, start the Docker engine with the command:

sudo systemctl start docker

Finally, enable Docker to run at boot with the command:

sudo systemctl enable docker

Running Docker as a standard user

Out of the box, you can only use Docker if you’re the root user, or by way of sudo. Since either running Docker as the root user or with sudo can be considered a security risk, it’s crucial to enable a standard user. To do that, you must add the user to the Docker group. Let’s say we’re going to add the user “Olivia” to the Docker group so that she can work with the tool. To do this, issue the following command:

sudo gpasswd -a olivia docker

Restart the Docker service with the command:

sudo systemctl restart docker

Once Olivia logs out and logs back in again, she can use Docker.

Docker terminology

Before we get into the commands to work with Docker, you’ll need to understand some of its terminology.

  • Image: a frozen snapshot of live containers. Images are generally pulled from the Docker Hub, but you can create your own images. Images are read-only.
  • Container: an active, stateful instance of an image that is read-write.
  • Registry: a repository for Docker Images.

 In a nutshell, you pull images from a registry and run containers from those images.

Let’s say you want to run a Debian Linux container so you can test or develop a piece of software. To pull down the Debian image, you should search the registry first. Issue the command docker search debian. The results of that search (Figure A) are important.


Figure A. Docker search command results.

The first two listings are marked as “official.” To be safe, always pull official images. Pull down that debian image with the command:

compliance_article_010.jpg

When the image pull is complete, Docker will report the image debian:latest has been downloaded. To make sure it’s there, use the command:

docker images

Figure B. Debian is ready to run.

You are now ready to create the debian container with the command:

compliance_article_010.jpg

The above command will return a hash to indicate that you’ve created a container.


Figure C. How to create a Debian container.

To run the container, issue the command:

docker run -i -t debian /bin/bash

The above command will run the debian container. It keeps STDIN (standard input) open with the -i option, allocates a pseudo-tty with the -t option, and places you in a Bash prompt so you can work. When you see the Bash prompt change, you’ll know that the command succeeded.


Figure D. The Debian container is now working.

You can work within your container and then exit the container with the command exit.

Commit changes

After you install Docker on Ubuntu 16.04, let’s say you want to develop an image to be used later. When you exit a running container, you will lose all of your changes. If that happens, you cannot commit your changes to a new image. To commit those changes, you first need to run your container in the background (detached), by adding the -d option:

docker run -dit debian

When you run the container like this, you can’t make any changes because you won’t be within the container. To gain access to the container’s shell, issue the command:

docker exec -i -t HASH /bin/bash

HASH is created after running the image in the background — it will be a long string of characters.

Now, you should be inside the running container. Make your changes and then exit the running container with the command exit. If you re-enter the container, your changes should still be present.

To commit your changes to a new image, issue the command:

docker commit HASH NAME

HASH is the hash for our running container and NAME is the name you’ll give the new image.

If you now issue the command docker images, your newly created image will be listed alongside the image you pulled from the Docker Hub registry.


Figure E. The newly created test image.

Next Steps

This was last published in April 2017

80 Linux commands you’ll actually use

Enterprise administrators and managers who use this guide of essential Linux commands, utilities and tools will find ways to manage files, get process status updates and more.

Jessica Lulka

Associate site editor – SearchDataCenter

Linux administrators cannot live by the graphical user interface alone. That’s why we’ve compiled useful Linux commands into this convenient guide.

By learning how to use a few simple tools, command-line cowards can become scripting commandos and get the most out of Linux by executing kernel and shell commands. 

A

alias
The alias command is a way to run a command or a series of Unix commands using a shorter name than those that are usually associated with such commands.

apt-get
The apt-get tool automatically updates a Debian machine and installs Debian packages/programs.

AWK, Gawk
AWK is a programming language tool used to manipulate text. The AWK utility resembles the shell programming language in many areas, but AWK’s syntax is very much its own. Gawk is the GNU Project’s version of the AWK programming language.

bzip2
A portable, fast, open source program that compresses and decompresses files at a high rate, but that does not archive them.

cat
A Unix/Linux command that can read, modify or concatenate text files. The cat command also displays file contents.

cd
The cd command changes the current directory in Linux and can conveniently toggle between directories. The Linux cd command is similar to the CD and CHDIR commands in MS-DOS.

chmod
The chmod command changes the permissions of one or more files. Only the file owner or a privileged user can change the access mode.

chown
The chown prompt changes file or group ownership. It gives admins the option to change ownership of all the objects within a directory tree, as well as the ability to view information on the objects processed.

cmp
The cmp utility compares two files of any type and writes the results to the standard output. By default, cmp is silent if the files are the same. If they differ, cmp reports the byte and line number where the first difference occurred.

comm
Admins use comm to compare lines common to file1 and file2. The output is in three columns; from left to right: lines unique to file1, lines unique to file2 and lines common in both files.

cp
The cp command copies files and directories. Copies can be made simultaneously to another directory even if the copy is under a different name.

cpio
The cpio command copies files into or out of a cpio or tar archive. A tar archive is a file that contains other files, plus information about them, such as their file name, owner, timestamps and access permissions. The archive can be another file on the disk, a magnetic tape or a pipe. It also has three operating modes: copy-out, copy-in and copy-pass. It is also­ a more efficient alternative to tar.

CRON
CRON is a Linux system process that executes a program at a preset time. To use a CRON script, admins must prepare a text file that describes the program and when they want CRON to execute it. Then, the crontab program loads the text file and executes the program at the specified time.

cURL 
Admins use cURL to transfer a URL. It is useful for determining if an application can reach another service and how healthy the service is.

D

declare
The declare command states variables, gives them attributes or modifies the properties of variables.

df
This command displays the amount of disk space available on the file system containing each file name argument. With no file name, the df command shows the available space on all the currently mounted file systems.

E

echo
Use echo to repeat a string variable to standard output.

enable
The enable command stops or starts printers and classes.

env
The env command runs a program in a modified environment or displays the current environment and its variables.

eval
The eval command analyzes several arguments, concatenates them into a single command and reports on that argument’s status.

exec
This function replaces the parent process with any subsequently typed command. The exec command treats its arguments as the specification of one or more subprocesses to execute.

exit
The exit command terminates a script and returns a value to the parent script.

expect
The expect command talks to other interactive programs via a script and waits for a response, often from any string that matches a given pattern.

export
The export command converts a file into a different format than its current format. Once a file is exported, it can be accessed by any application that uses the new format.

F

find
The find command searches the directory tree to locate particular groups of files that meet specified conditions, including -name, -type, -exec, -size, -mtime and -user.

forwhile
The for and while commands execute or loop items repeatedly as long as certain conditions are met.

free
With the free command, admins can see the total amount of free and used physical memory and swap space in the system, as well as the buffers and cache used by the kernel.

G

gawk
See AWK.

grep
The grep command searches files for a given character string or pattern and can replace the string with another. This is one method of searching for files within Linux.

gzip
This is the GNU Project’s open source program for file compression that compresses webpages on the server end for decompression in the browser. This is popular for streaming media compression and can simultaneously concatenate and compress several streams.

H

history
The history function shows all the commands used since the start of the current session.

I

ifconfig
The iconfig command configures kernel-resident network interfaces at boot time. It is usually only needed when debugging or during system tuning.

ifup
With ifup, admins can configure a network interface and enable a network connection.

ifdown
The ifdown command shuts down a network interface and disables a network connection.

iptablesThe iptables command allows or blocks traffic on a Linux host and can prevent certain applications from receiving or transmitting a request.

K

kill
With kill signals, admins can send a specific signal to a process. It is most often used to safely shut down processes or applications.

L

less 
The less command lets an admin scroll through configuration and error log files, displaying text files one screen at a time with backward or forward navigation available.

locate 
The locate command reads one or more databases and writes file names to match certain output patterns.

lft
The lft command determines connection routes and provides information to debug connections or find a box/system location. It also displays route packets and file types.

ln
The ln command creates a new name for a file using hard linking, which allows multiple users to share one file.

ls
The ls command lists files and directories within the current working directory, which allows admins to see when configuration files were last edited.

lsof
Admins use lsof to list all the open files. They can add -u to find the number of open files by username.

lsmod
The lsmod command displays a module’s status within the kernel, which helps troubleshoot server function issues.

man
The man command allows admins to format and display the user manual that’s built into Linux distributions, which documents commands and other system aspects.

more
Similar to less, more pages through text one screen at a time, but has limitations on file navigation.

mount
This command mounts file systems on servers. It also lists the current file systems and their mount locations, which is useful to locate a defunct drive or install a new one.

mkdir
Linux mkdir generates a new directory with a name path.

N

neat
Gnome GUI tool that allows admins to specify the information needed to set up a network card.

netconfig/netcfg
Admins can use netconfig to configure a network, enable network products and display a series of screens that ask for configuration information.

netstat
This command provides information and statistics about protocols in use and current TCP/IP network connections. It is a helpful forensic tool for figuring out which processes and programs are active on a computer and are involved in network communications.

nslookup
A user can enter a host name and find the corresponding IP address with nslookup. It can also help find the host name.

od
The od command dumps binary files in octal — or hex/binary — format to standard output.

passwd
Admins use passwd to update a user’s current password.

ping       
The ping command verifies that a particular IP address exists and can accept requests. It can test connectivity and determine response time, as well as ensure an operating user’s host computer is working.

ps
Admins use ps to report the statuses of current processes in a system.

pwd
The print working directory (pwd) command displays the name of the current working directory.

read
The read command interprets lines of text from standard input and assigns values of each field in the input line to shell variables for further processing.

rsync
This command syncs data from one disk or file to another across a network connection. It is similar to rcp, but has more options.

screen
The GNU screen utility is a terminal multiplexor where a user can use a single terminal window to run multiple terminal applications or windows.

sdiff
Admins use sdiff to compare two files and produce a side-by-side listing indicating lines that are dissimilar. The command then merges the files and outputs the results to the outfile.

sed
The sed utility is a stream editor that filters text in a pipeline, distinguishing it from other editors. It takes text input, performs operations on it and outputs the modified text. This command is typically used to extract part of a file using pattern matching or to substitute multiple occurrences of a string within a file.

service
This command is the quickest way to start or stop a service, such as networking.

shutdown
The shutdown command turns off the computer and can be combined with variables such as -h for halt after shutdown or -r for reboot after shutdown.

slocate
Like locate, slocate, or secure locate, provides a way to index and quickly search for files, but it can also securely store file permissions and ownership to hide information from unauthorized users.

Snort
Snort is an open source network intrusion detection system and packet sniffer that monitors network traffic. It looks at each packet to detect dangerous payloads or suspicious anomalies. Snort is based on libpcap.

sort
This command sorts lines of text alphabetically or numerically according to the fields. Users can input multiple sort keys.

sudo
The sudo command lets a system admin give certain users the ability to run some — or all — commands at the root level and logs all the commands and arguments.

SSH
SSH is a command interface for secure remote computer access and is used by network admins to remotely control servers.

tar
The tar command lets users create archives from a number of specified files or to extract files from a specific archive.

tail        

The tail command displays the last few lines of the file. This is particularly helpful for troubleshooting code because admins don’t often need all the possible logs to determine code errors.

TOP
TOP is a set of protocols for networks that performs distributed information processing and displays the tasks on the system that take up the most memory. TOP can sort tasks by CPU usage, memory usage and runtime.

touch
Admins can create a blank file within Linux with the touch command.

tr
This command translates or deletes characters from a text stream. It writes to a standard output, but it does not accept file names as arguments — it only accepts input from standard input.

traceroute
The traceroute function determines and records a route through the internet between two computers and is useful for troubleshooting network/router issues. If the domain does not work or is not available, admins can use traceroute to track the IP.

uname
This function displays the current operating system name and can print system information.

uniq
With uniq, admins can compare adjacent lines in a file and remove or identify any duplicate lines. 

vi
The vi environment is a text editor that allows a user to control the system with just the keyboard instead of both mouse selections and keystrokes.

vmstat
The vmstat command snapshots everything in a system and reports information on such items as processes, memory, paging and CPU activity. This is a good method for admins to use to determine where issues/slowdown may occur in a system.

wget
This is a network utility that retrieves web files that support HTTP, HTTPS and FTP protocols. The wget command works non-interactively in the background when a user is logged off. It can create local versions of remote websites and recreate original site directories.

while 
See for.

whoami
The whoami command prints or writes the user login associated with the current user ID to the standard output.

xargs
Admins use xargs to read, build and execute arguments from standard input. Each input is separated by blanks.

How to choose a server based on your data center’s needs

What are the most important elements for your enterprise when you’re buying servers?

In an effort to optimize performance in the enterprise, IT should evaluate top priorities to determine how to choose a server and create the most efficient workloads.

Stephen J. Bigelow

Senior Technology Editor – TechTarget – SearchWindowsServer

Servers are the heart of modern computing, but the contemplation around how to choose a server to host a workload can sometimes create a bewildering array of hardware choices. While it’s possible to fill a data center with identical, virtualized and clustered white box systems that are capable of managing any workload, the cloud is changing how organizations run applications.

As more companies deploy workloads in the public cloud, local data centers require fewer resources to host the workloads that remain on premises. This is prompting IT and business leaders to seek out more value and performance from the shrinking server fleet.

Today, the expansive sea of white box systems is challenged by a new wave of specialization with server features. Some organizations are rediscovering the notion that one server may indeed fit all. But you can select or even tailor server cluster hardware to accommodate particular usage categories.

VM consolidation and network I/O add benefits

A central benefit of server virtualization is the ability to host multiple VMs on the same physical server in order to utilize more of a server’s available compute resources. VMs primarily rely on server memory (RAM) and processor cores. It’s impossible to determine precisely how many VMs can reside on a given server because you can configure VMs to use a wide range of memory space and processor cores. However, the rule of thumb on servers includes selecting one with more memory and processor cores will typically allow more VMs to reside on the same server, which improves consolidation.

For example, a Dell EMC PowerEdge R940 rack server can host up to 28 processor cores and offers 48 double data rate 4 (DDR4) dual in-line memory module (DIMM) slots that support up to 6 TB of memory. Some organizations may choose to forego individual rack servers in favor of blade servers for an alternative form factor or as part of hyper-converged infrastructure systems. Servers intended for high levels of VM consolidation should also include resiliency server features, such as redundant hot-swappable power supplies, and resilient memory features, such as DIMM hot swap and DIMM mirroring.

A secondary consideration on how to choose a server for highly consolidated purposes is the added attention to network I/O. Enterprise workloads routinely exchange data, access centralized storage resources, interface with users across the LAN or WAN and so on. Network bottlenecks can result when multiple VMs attempt to share the same low-end network port. Consolidated servers can benefit from a fast network interface, such as a 10 Gigabit Ethernet port, though it is often more economical and flexible to select a server with multiple 1 GbE ports that you can trunk together for more speed and resilience.


When choosing a server, evaluate the importance of certain features based on the use cases.

Container consolidation opens up RAM on how to choose a server

Virtualized containers represent a relatively new approach to virtualization that allows developers and IT teams to create and deploy applications as instances that package code and dependencies together — yet containers share the same underlying OS kernel. Containers are attractive for highly scalable cloud-based application development and deployment.

As with VM consolidation, compute resources will have a direct effect on the number of containers that a server can potentially host, so servers intended for containers should provide an ample quantity of RAM and processor cores. More compute resources will generally allow for more containers.

But large numbers of simultaneous containers can impose serious internal I/O challenges for the server. Every container must share a common OS kernel. This means there could be dozens or even hundreds of containers trying to communicate with the same kernel, resulting in excess OS latency that might impair container performance. Similarly, containers are often deployed as application components, not complete applications. Those component containers must communicate with each other and scale as needed to enhance the performance of the overall workload. This can produce enormous — sometimes unpredictable — API traffic between containers. In both cases, I/O bandwidth limitations within the server itself, as well as the application’s architectural design efficiency, can limit the number of containers a server might host successfully.

Network I/O can also pose a potential bottleneck when many containerized workloads must communicate outside of the server across the LAN or WAN. Network bottlenecks can slow access to shared storage, delay user responses and even precipitate workload errors. Consider the networking needs of the containers and workloads, and configure the server with adequate network capacity — either as a fast 10 GbE port or with multiple 1 GbE ports, which you can trunk together for more speed and resilience.

Most server types are capable of hosting containers, but organizations that adopt high volumes of containers will frequently choose blade servers to combine compute capacity with measured I/O capabilities, spreading out containers over a number of blades to distribute the I/O load. One example of servers for containers is the Hewlett Packard Enterprise (HPE) ProLiant BL460c Gen10 Server Blade with up to 26 processor cores and 2 TB of DDR4 memory.

Visualization and scientific computing affect how to choose a server

Graphics processing units (GPUs) are increasingly appearing at the server level to assist in mathematically intensive tasks ranging from big data processing and scientific computing to more graphics-related tasks, such as modeling and visualization. GPUs also enable IT to retain and process sensitive, valuable data sets in a better-protected data center rather than allow that data to flow to business endpoints where it can more easily be copied or stolen.

Generally, the support for GPUs requires little more than the addition of a suitable GPU card in the server — there is little impact on the server’s traditional processor, memory, I/O, storage, networking or other hardware details. However, the GPU adapters included in enterprise-class servers are often far more sophisticated than the GPU adapters available for desktops or workstations. In fact, GPUs are increasingly available as highly specialized modules for blade systems.

For example, the HPE ProLiant WS460c Gen9 Graphics Server Blade uses Nvidia Tesla M60 Peripheral Component Interconnect Express graphics cards with two GPUs, 4,096 Compute Unified Device Architecture cores and 16 GB of graphics DDR5 separate video RAM. The graphics system touts support for up to 48 GPUs through the use of multiple graphics server blades. The large volume of supported GPU hardware — especially when GPU hardware is also virtualized — allows many users and workloads to share the graphics subsystem.

What server features do you look for?

This is the first article of a two-part series. The second article discusses  server features, such as data servers and security.

Next Steps

This was last published in November 2017

Learn the major types of server hardware and their pros and cons

What type of server has benefited your organization the most?

Servers protect data, centralize resources and enable remote worker productivity, but buyers must understand which server types works best for their data center.

Robert Sheldon

Contributor – SearchSQLServer

Servers host applications, manage files, process emails, stream media and perform analytics. Any organization can benefit from the power and versatility that servers provide, but it can be difficult to know which types of server hardware to choose.

Today’s servers are primarily available in three forms: racks, blades and mainframes. The majority of IT teams turn to rack and blade servers to meet their server requirements. Some teams opt for mainframe computers to handle their workloads, although not nearly to the extent of rack and blade servers.

Rack, blade and mainframe servers all have their advantages and disadvantages, and buyers should carefully weigh these different types of server hardware before deciding on a product. Buyers do not need to limit their selection to any one type, however. Organizations can choose what’s best for the workloads they need to support with an eye on budget and space constraints.

What is a server?

A server is a type of computer that provides processing and memory resources for different workloads. The term server can refer to the computer itself or to a program that delivers a service, such as an email management system. Most hardware-related references concern the physical machine. The server operating system (OS) is designed to process large workloads, deliver services and support network-based operations. Common server OSes include Linux, Unix and Windows Server.

Servers are usually set up to provide one or more specific services. Servers are commonly used to manage network resources and make them available to client devices. A server is often referenced to based on the purpose it serves. For example, a print server provides network users with access to shared printers, and a media server streams video and audio content to network users.

A server’s physical configuration is usually specific to the types of services it provides. For example, a database server might include more processing or memory resources to handle the influx of concurrent transactions. Many data centers also implement server virtualization to deliver services more efficiently. Server virtualization can help better utilize the server’s physical resources, while also increasing flexibility and security and reducing energy consumption.

Editor’s note

With extensive research into the server market, TechTarget editors have focused this series of articles on server vendors with considerable market presence and that offer at least one product among blade, rack and mainframe types. Our research included Gartner, Forrester and TechTarget surveys.

Why purchase a server?

Any organization that supports more than a handful of users can benefit from different types of server hardware. For most organizations, servers are essential to carrying out business and protecting sensitive resources. Organizations might need to purchase servers when they set up new data centers, expand or update existing ones, open satellite offices, or spin up development projects.

Although servers add to the number of computers that an organization must support, they can also help consolidate resources; different types of server hardware make it possible to share printers, disk drives and applications with network users. Although users can share resources across peer-to-peer networks, a server is much better equipped to manage those resources and deliver them securely across the network, especially with a large number of users.Any organization that supports more than a handful of users can benefit from different types of server hardware.

This use of servers can also lead to greater productivity because resources are centralized, which allows workers to easily share data with their colleagues. Users can access the resources they need when they need them without worrying about managing them. For example, they do not have to keep a copy of the data on their own systems, implement and maintain a backup, or manage multiple copies of the same data.

In addition, servers enable users to access the applications and data they need from remote locations, which makes it easier for workers to stay productive when they travel or work remotely.

Servers also add business value via data protection, providing the structure necessary for admins to control which users can access files, applications, peripherals and other resources. In addition, admins can control the security mechanisms that they implement on the servers, as well as centrally monitor systems for issues related to security and compliance.

Different types of server hardware also make it easier to back up system and user data and implement disaster recovery strategies. Admins can also more easily ensure the reliability and availability of data, whether by clustering servers or building redundancies into system components. In addition, the consolidated model makes it possible to centralize other management operations, such as maintaining workstations, controlling domains and monitoring software.

Because servers can consolidate resources, streamline management and increase productivity, they can ultimately reduce costs. In addition, their centralized management capabilities make it easier to track application usage to better control licensing costs and avoid expensive software audits.

Because servers better protect the data, it is less likely to be compromised, helping to avoid costly fines, tarnished reputations and the lost business that comes with both of these.

Rack servers

A rack server, also known as a rack-mounted server, is a standard-size computer designed to be mounted in a server rack along with other rack servers or standard-size components, such as network or storage area network devices. A rack server is considered to be a general-purpose machine that can support a wide range of workloads.

Rack servers take up a lot less space than tower servers because they’re not encased in bulky cabinets and users can stack them in a single rack along with the other components. In addition, because providers have standardized the size of racks and rack servers, admins can easily add or replace servers if one should malfunction. The design also makes it simple to add components gradually to accommodate growing workloads. Best of all, the servers in the same rack don’t have to be the same model or come from the same vendor.

One of the biggest challenges with rack servers is managing all the cabling that ties the components together. Rack servers require cables for power, networking, management and storage, all of which hang off of the back of the stacked components, making it difficult to manage the cables and servers. The cables can also affect cooling, which is already challenging with rack servers because of their proximity to each other.

Blade servers

A blade server is a modular component — blade — that fits into a server chassis along with other blades. Each blade has its own processors, memory and integrated network controllers. The blade might also include a Fibre Channel host bus adapter, as well as other I/O ports. Blade servers offer more processing power in a smaller space than rack servers while providing a simplified cabling structure.

Because blades are so tightly configured within the chassis, the chassis itself is sometimes referred to as the blade server and the individual blades are called modular motherboards or circuit boards even though they’re servers in their own right. This is because the chassis provides consolidated resources such as power, cooling and networking, which are shared across all the blades within the chassis. Admins can also mount the chassis on a standard-size server rack.

One of the biggest advantages of a blade server compared to a rack server is its ability to provide greater processing density within a smaller space. This can result in a price-to-performance advantage even though blade servers are themselves more expensive than rack servers. This efficient use of space can increase redundancy to better ensure the reliability and availability of applications and data.

In addition, the blades and chassis components are hot-swappable, including the cooling system, controllers and switches. Plus, because of the chassis structure, cabling is simpler when compared to the rack server. The blade system also provides a centralized management console to control and monitor the system’s components.

Although blade servers offer state-of-the-art computing capabilities, they also come with a few drawbacks. For example, the server chassis and blade architecture are proprietary, which makes vendor lock-in a strong possibility. This proprietary nature can also limit upgrade options if the vendor does not release new or updated components in a timely manner.

Although blade servers are more expensive than rack servers, savings in space, power and management can offset expenses under the right circumstances. However, the rack server provides a lower entry cost, which can be an advantage to an organization that wants to start out small and work its way up gradually. Also, with blade servers, an organization might need to update its data center to accommodate power and cooling needs.

Despite these concerns, a blade server can be a good fit in a number of circumstances, particularly for data centers with high-density server rooms in which space is limited. Blade servers are well-suited to a single task that requires clustered servers, such as file sharing, web hosting, video streaming, database management or virtual desktop infrastructure.

Mainframe servers

mainframe server is an extremely powerful computer; it’s about the size of a large refrigerator. Unlike its predecessors, which could take up an entire room, today’s mainframes are much more compact and powerful and include sophisticated encryption capabilities, as well as multiple layers of redundancy. Mainframes are still much bigger and bulkier than rack or blade servers, as well as a lot more expensive. However, mainframes are also much more powerful and reliable than anything else out there.

A mainframe is designed for high throughput; it can support a large number of simultaneous transactions and heavy I/O loads without affecting performance. IBM leads the way in the mainframe market, producing systems that can perform 12 billion encrypted transactions per day.

In addition to its massive transaction processing capabilities, a mainframe is extremely configurable, supports dynamic reconfigurations and provides hot-swappable hardware components. A mainframe normally runs its own OS, such as IBM’s z/OS, but recent models also support Linux, running on bare metal or in virtual machines, considerably increasing the mainframe’s capabilities.

Mainframes have a reputation for being resilient, reliable and secure, incorporating some of the most advanced hardware technologies available. Multiple layers of redundancy exist throughout the system to ensure continuous reliability and availability. In addition, admins can cluster mainframes to deliver even greater reliability and availability, especially if the cluster is geographically dispersed, which can help protect against a disaster in any one location.

Mainframes are primarily suited for high-volume, data-intensive workloads with many concurrent, real-time transactions, such as the transactions of banks or other financial institutions. Industries such as utility companies, government agencies and health care systems can also benefit from the power a mainframe computer can offer.

However, a mainframe’s high price tag also means that it’s not a system for organizations that are simply testing the waters or implementing types of server hardware incrementally. A mainframe might be more cost-effective in the long term depending on the supported workloads, but the initial capital outlay could be too much for many businesses.

Mainframes also require skilled technicians to implement and operate — a type of admin getting harder to find as much of the attention turns to rack and blade servers. For many organizations, a mainframe comes with a learning curve that might be too steep to take on.

Hyper-converged infrastructure

Organizations in the market for data center servers might also consider hyper-converged infrastructure (HCI), a software-centric system for delivering compute, storage and networking resources in a tightly integrated system. Vendors offer HCI platforms as self-contained appliances, software-only packages or reference architectures.

An HCI platform typically consists of multiple server nodes, a hypervisor for virtualizing resources on each node, and an intelligent software layer that manages and orchestrates resources across the server nodes. In addition, HCI systems usually include built-in data protections, such as mirroring, replication or erasure coding, as well as backup, redundancy and other disaster recovery capabilities.

The compute nodes that make up an HCI platform can be standard, off-the-shelf servers. In addition to the processing and memory resources, each server also includes its own direct-attached storage. Most HCI appliances include at least three nodes, with the ability to add nodes to accommodate growing workloads.

The intelligent software consolidates the resources from each server into a shared resource pool, delivering a high degree of flexibility while also simplifying management. Scaling the system is merely a matter of adding another server node. However, the server nodes must be identical, so adding a node can sometimes mean purchasing resources that are not always necessary in order to boost the compute resources.

This was last published in December 2018

Top server maintenance tips to extend hardware lifespan

IT administrators can upgrade CPU, RAM and networking hardware to maintain smooth server operations and to maximize resources.

Alastair Cooke
SearchVirtualDesktop

There are many server maintenance tips that can help you protect servers over their three-to-five year lifespan in the corporate data center, such as refreshing RAM and network cards and keeping software up to date.

Physical cleanliness is an important aspect of server maintenance. It should not be an issue in a large and adequately maintained data center, but there are plenty of dust bunnies in smaller data centers, which should make you wonder what accumulates inside those servers.

It’s important to clean out servers every year or two — shut them down and blow them clean with compressed air — but you should also vacuum regularly. Make sure the air conditioning filters are clean, too. When it comes to routine tasks, prevention is far better than unexpected downtime.

Midlife upgrades one of the top server maintenance tips

Organizations often buy servers or specific server configurations to match their budget or expected workload profile. However, a year or two after deployment, more money for hardware might become available, or changes to the workload might warrant a midlife server hardware upgrade. Upgrades can offer improved performance, capacity and utility.

To do a midlife server upgrade, start by identifying which servers need new hardware. Use server monitoring software such as Nagios, SolarWinds Orion Network Performance Monitor, Hyperic HQ or GFI Network Server Monitor to measure uptime, process success, thread count and application responsiveness. These metrics show how much hardware and storage space your applications need to run properly.

You can add RAM to a server by filling empty dual in-line memory module (DIMM) slots or by replacing all of the DIMMs with larger-capacity modules. Keep memory DIMMs consistent within each server; ideally, they should be the same size and speed and be from the same vendor, if possible. This provides consistent electrical and timing characteristics, and it reduces column strobe access latency.

With this approach, you should put the new RAM in one server and move the old RAM modules so one server contains all the new DIMMs and the other is all older DIMMs. This practice ensures the most efficient storage performance; when you mix and match too many different DIMM characteristics, such as timing, types and architectures, your storage quality can degrade over time.

If you homogenize your DIMMS, check that the process won’t disrupt any active data center workloads before you start shifting hardware.

You can also update CPUs so they are internally consistent. Sometimes, it makes sense to buy servers with prefilled DIMM slots and CPU sockets. Having a pre-upgraded server maintenance model is mandatory when the finance team requires that any upgrade on a server start a new three-year depreciation period.

Network upgrades

In addition to expanding RAM and CPU as a part of your upgrades, another server maintenance tip is to evaluate how well your servers support the network. The gap between hardware performance and network speed can cause a bottleneck, which makes it essential that you upgrade your networking hardware over the server’s lifetime.

New network standards such as 40 Gigabit Ethernet and 32G Fibre Channel offer consistent data transfer and low latency rates for server-to-server communication, but installing the latest network switches or cabling won’t automatically improve network speeds or eliminate bottlenecks. You must ensure that the server’s PCIe cards support the increased bandwidth and that they are compatible with the network interface cards.

The best option is to buy new servers with the fastest network cards available and plan to use replacement servers when faster networks are available. If you cannot buy new servers, a server maintenance tip is to refresh the network cards. Newer network cards require more CPU resources on older servers, especially if there are no changes to the workload, resource management or server utilization.

Address software health

Software and firmware version updates should already be part of your normal server upgrades. These bring stability and performance improvements, so a regular update cycle can help prevent outage incidents and maximize the value of the server infrastructure.

Routine upgrades can help keep you in alignment with support service contracts and prevent you from working with out-of-date firmware or software. If minor updates are a routine operational procedure, you can easily roll out major version updates and remain on supported versions.

Most organizations are well set up for operating system and hypervisor updates, but they often overlook basic input/output system and firmware updates. Make sure you apply all the possible updates to keep your servers and data center healthy over time.

This was last published in January 2019

What issues can arise from hardware debug exception flaws?

How does your enterprise protect against hardware debugging vulnerabilities?

Misinterpretation of Intel’s System Programming Guide resulted in a hardware debug exception vulnerability. Expert Michael Cobb explains how attackers can gain unauthorized access.

Michael Cobb

CISSP-ISSAP – SearchSecurity

CERT issued an advisory regarding a problem with Intel’s documentation, which inadvertently caused OS and hypervisor developers to create a hardware debug exception vulnerability in their software. What is the underlying hardware debug exception and what problems does it cause?

There are plenty of cases in which security vulnerabilities have been introduced into software programs because developers failed to correctly implement a third-party library or component, often due to a failure to read the relevant vendor documentation.

Vulnerability CVE-2018-8897 is somewhat different though, as the entire community of operating system and hypervisor developers appears to have misinterpreted a statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer’s Manual.

This has resulted in a hardware debug exception vulnerability being introduced into developers’ software, enabling an attacker to gain unauthorized access to kernel memory by submitting a specially crafted sequence of commands, either using malicious software or a user logged into the system. An attacker who successfully exploits this vulnerability could run arbitrary code in kernel mode, enabling them to install programs; view, change or delete data; and create an account with full admin rights.

Nick Peterson of Everdox Tech, along with Nemanja Mulasmajic of Triplefault.io, discovered the vulnerability and turned it into a local privilege escalation exploit. The vulnerability arose because of the way OS developers implemented hardware debugging commands for Intel x86-64 architectures. When Intel released its 8086 16-bit microprocessor chip in 1978, it added a special caveat for loading two stack segment (SS) registers: MOV SS and POP SS.

The SS register is usually used to store information about the memory segment that stores the call stack of the program that is being executed.

“Even though system software developers could add interrupt guards to code loading SS, Intel added functionality where loading SS with either of the two previously mentioned instructions would force the processor to disable external interrupts, non-maskable interrupts (NMI) and pending debug exceptions until the boundary of the instruction following the SS load was reached,” Peterson said.

The purpose of this change was to prevent an interrupt from being recognized and used immediately after loading SS, but before loading a stack pointer — a useful precaution based on the design of operating systems at the time — but Peterson discovered an undocumented side effect of these changes.

After this functionality was added, system software developers assumed that when interrupts are disabled, debug exceptions are also disabled. However, a pending debug exception, NMI or machine check can still occur.

The occurrence of a debug exception executing before the interrupt handler can set up a good state, though that is admittedly an edge case, and can be used to trick the system into employing a user GS-BASE value. This may enable an attacker to utilize operating system APIs to gain access to sensitive memory information or to control low-level operating system functions.

All the main operating system and virtualization software vendors have already issued patches for the hardware debug exception flaw, which Microsoft assessed as unlikely to be exploited. However, it does show that not only do developers need to carefully read implementation documentation, but vendors also need to ensure that their documentation and guidance is complete, clear, easily understood and not open to misinterpretation.

Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email.

(All questions are anonymous.)

This was last published in September 2018

Cloud and backup top storage priorities for 2019

Deploying the cloud for primary and secondary storage and backup and archiving project top project priorities in 2019. SAN, NAS and hyper-convergence also prominent

Antony Adshead

Storage Editor – Computer Weekly – ComputerWeekly.com

13 Feb 2019 9:36

Cloud-based initiatives and backup and archiving dominate UK IT departments’ storage projects for 2019.

Cloud storage and backup/archiving projects feature in five of the top six storage priorities reported by more than 250 respondents to this year’s Computer Weekly/TechTarget IT Priorities research.

Top of the list for primary storage projects is cloud backup as a service, which is a priority in 2019 for 33% of those asked. After that come virtual server backup (29%), backup software refreshes (27%), public cloud storage (26%) and data archiving (23%).

Of the top six, the only one not directly related to cloud storage or data protection is data management, which is a priority for 28% of respondents.

Traditional shared storage is still very much a key primary storage initiative for many IT departments, however, with about one-fifth planning storage area network (SAN) and network-attached storage (NAS) projects in 2019 (21% and 19% respectively).

Meanwhile, hybrid storage arrays will be a focus for 16% of those asked, while 12% plan object storage deployments.

Hyper-converged infrastructure (HCI) was listed as a key primary storage initiative for 2019 by 14% of respondents, although elsewhere in the survey 21% said they would use HCI in production and 67% said they expected the share of HCI in their organisation’s compute capacity to increase.

When asked about secondary storage projects, the cloud and backup/archiving also dominated.

Cloud backup as a service came out on top again, with 37% citing it as a key initiative for 2019. After that are backup software projects (30%) and data archiving (26%). These are followed by projects in on-premise disaster recovery (21%) and backup hardware deployments (19%).

The survey also asked how much storage capacity organisations retain. The largest number (32%) of those asked have between 10TB and 99TB, while 30% have less than 10TB. Meanwhile, 17% have between 100TB and 249TB and 5% have more than 10PB.

Read more about cloud storage

Which IT security roles fall to the ops team?

What priority should an IT operations team give to security tasks?

To help secure data and applications, an IT ops team needs to do much more than put up firewalls and apply other traditional security measures. Here’s where to begin.

Chris Moyer

VP of Technology – ACI Information Group – SearchCloudApplications

Specter, Meltdown and similar zero-day vulnerabilities are the scary sorts of things that keep operations teams — especially those with IT security roles — awake at night. Fortunately for most cloud-based companies, those vulnerabilities can be addressed with the latest software updates or an adjustment to your Amazon Elastic Compute Cloud machine images. Organizations that run on serverless platforms have it even easier, needing only to wait for Amazon, Microsoft or Google to apply the patches to the underlying hardware.

Still, these vulnerabilities account for only a small fraction of the attack surface that modern-day operations teams must watch over.

To take their IT security roles seriously, these staffers need to be concerned with stolen credentials and corrupted code repositories, among numerous other threats. Custom alerts can help ops teams detect abnormal conditions, and software-testing procedures can be adjusted to include security risk detection. There’s plenty for ops to do.

Consider a Node.js application launched using the serverless platform on AWS Lambda. Every dependency included in an application could potentially become compromised and lead to malicious code being installed on your site. Such a calamity could result in the loss of your users’ data or your intellectual property.

Systems for continuous integration (CI) and continuous delivery (CD) allow developers to iterate much faster. This is generally a good thing, since it produces much smaller deployments and generally results in fewer bugs. Unfortunately, these CI/CD tools tend to rely on third-party systems to gather packages and requirements, and those repositories can become compromised.

One recent outage, for example, showed a critical vulnerability in the NPM code repository. Supposedly safe packages were replaced with nearly identical ones containing attack code. Since NPM packages can include build and deployment hooks as well, this could do anything from stealing AWS credentials used to deploy your application to harvesting credit card numbers and passwords. Even packages you’ve completely validated as safe and have been using for years could have been compromised during a new deployment.

Previously, operations teams could mitigate some of this risk simply by controlling the hardware. Also, they could put in place specialized firewalls to prevent suspicious network traffic from causing issues, such as a site trying to upload credit card numbers to a known malicious IP address. With the move to cloud serverless technologies, much of this control has been taken away from ops, even while their IT security roles remain.

Adding Detection to the CI/CD Process

For teams with well-defined CI/CD practices, the build process should already have automated unit testing in place for bugs. It’s a natural progression to also require that build step to add in tests for security vulnerabilities. Many tools and organizations can help with this sort of thing, including Snyk and the Open Web Application Security Project, or OWASP. Ops teams are typically responsible for setting up these types of tools, and many of them can be set to run one-time scans before a build, as well as perform ongoing checks of production systems.

Additionally, ops teams with IT security roles or concerns may choose to create a custom in-house repository. For example, NPM Enterprise allows companies to include a feature-compatible version of NPM. This can be maintained by an internal team, behind a firewall, and it prevents the installation of third-party plug-ins that aren’t pre-approved. This can lead to faster, more secure and more reliable deployments.

Anomaly detection and manual approval of suspicious requests can be useful in preventing unwanted activity.

Some attacks result from things that cannot be identified before a system is in production. For example, users’ accounts can be breached. Or, even worse, a developer’s account can be compromised.

With AWS, it’s critically important that each service has strict identity permissions. For example, a user’s API probably shouldn’t have the ability to create new Elastic Compute Cloud instances or to delete users. Developers should be brought along slowly and not granted write access until after they’ve proven they aren’t going to accidentally wipe out the entire database. And no one should have root AWS credentials, except maybe the CTO.

It’s also important to make sure all identity and access management (IAM) users are required to have multifactor authentication (MFA) tokens set up, and it may be useful to turn on S3 versioning as well as require an MFA token to delete S3 objects.

It’s always a good idea to back up critical data in another location — and encrypt it, if it’s sensitive. It’s important to note, however, that when you store backups in different locations, you’re increasing the exposure of that data to attackers. More backups are not always better.

Most cloud providers offer managed backup options. Those should always be the first choice.

Monitor for unusual activity

Even with strict policies in place and personnel focused on IT security roles, it’s inevitable that something will go wrong. Credentials will either be leaked accidentally or be exposed through some malicious code installed on someone’s computer.

It’s important for operations teams to monitor cloud activity. For AWS users, this is typically done via CloudWatch. In Azure, consider Operational Insights, Application Insights or other monitoring tools.

It’s also worth setting up custom alarms. These help you spot abnormalities, such as when an IAM account performs operations that deviate from normal patterns; that unusual behavior could indicate a system compromise.

It can be trickier to identify issues with end users. While some problems can be obvious — such as when a user tries to log into their account from China an hour after logging in from California — other situations aren’t as readily apparent. Anomaly detection and manual approval of suspicious requests can be useful in preventing unwanted activity. Several services can help manage these types of rules, and most authentication services, such as Auth0, already provide built-in anomaly detection.

Web application firewalls can also provide added protection to your web-based access points by blocking traffic using pre-defined rules from communities, as well as custom logic based on patterns your operations team identifies.

For example, if someone is trying to access a wp-admin URL on your custom in-house application, chances are they’re trying to hack into something. Many of the targeted vulnerabilities are for WordPress and applications in the PHP scripting language, so operations teams should be on the lookout for requests for suspicious URLs and be ready to block all traffic from offending IP addresses.

This was last published in May 2018

Application performance tuning tips and tricks

What common causes lead to slow application performance?

Tune hardware, resource allocations and prioritizations to make applications perform their best. Just don’t do it without tracking the results.

Brian Kirsch

IT Architect, Instructor – Milwaukee Area Technical College – SearchServerVirtualization

A slow application is a challenge for IT operations teams, as the problem generally comes with about as much background information as a warning light on a car dashboard that just says Service.

Application performance tuning covers a wide range of possible options. You might hear calls to fix the code, but often, the issue slowing down an application isn’t as deep as faults in the source code. Similarly, routine server and application maintenance — clean up the application install points and remove old logs and temporary files — helps but won’t correct larger issues. Application performance tuning comes down to the things that surround the application and matching the right IT resources to a given application.

Not all applications run the same on the same hardware, virtual or physical. It’s a myth that slow applications simply need more resources. In fact, too liberal resource allocation can do damage to the overall environment, causing unnecessary contention. For example, a single-threaded application won’t run faster with multiple CPUs, no matter how many it gets, and other workloads in the virtual environment might end up starved for processing power. Overallocation is similar to overeating — not good for your health — and it’s expensive and time-consuming as well. Sometimes, more expenditures are worth it: Choices such as network bandwidth or storage tiers are much deeper than just a cost question if the application fails to function properly due to constraints.

Performance tuning starts with resources

Approach application performance tuning through the idea of proper-sizing resources. Proper-sizing also sets applications up well for a move to the cloud, where the organization pays for however many resources the application consumes monthly, rather than in cyclical data center capacity refreshes.

To properly size and scale a deployment, start with the application requirements as a guideline — but don’t treat them as laws. Every application designer has optimal settings for the application’s resources. Optimal might cover only the top of the range of acceptable application performance, however. And IT teams should query what the optimal resources are for the expected user base: 100 or 10,000? Balance the app designer’s settings with the available environment, and use this information as a starting point for reliability and performance from day one.

We often focus on restrictions and limitation in virtualized resources, but setting priority on workloads can be just as critical to the overall operations of the application.

To start application performance tuning, dig into the resource usage profile. Does the application have a highly transaction-driven process or a more intense lookup process? The answer can quickly shift attention from a CPU-driven process to a memory-driven one. In virtual environments, set priority for CPU usage for high transactional loads and memory reservations for intense lookups. Use the same types of settings with both networking and I/O traffic priorities.

We often focus on restrictions and limitation in virtualized resources, but setting priority on workloads can be just as critical to the overall operations of the application. The actual delivery of the application from a VM, container or cloud resource must be configured correctly and tuned in each case, so take a narrow case-by-case approach rather than one for the whole IT deployment overall.

In cloud, sky’s the limit

Cloud resources are essentially infinite, so resource availability is not a challenge for application performance. However, the budget is limited, so strongly consider where and how your company wants to spend its money. Careless resource management wastes money when it occurs on internal IT systems, but when the same problems move to the cloud, the cost is more apparent. When it’s in black and white on a bill, you tend to notice skyrocketing consumption quickly.

Relationships between the resources are critical. A change in one affects the others, and one change, in isolation, could fail to help performance. The move from a spinning disk I/O platform to solid-state drive to tune performance in a storage-heavy application might require additional memory for caching before the improvement is noticeable to the user, for example.

Observe the effects of application performance tuning

Let monitoring tools be your guide. As you make a change in the deployment or how it is managed, follow its effect on application response times and resource utilization. Compare the pre- and post-change metrics to see what impact allocation changes and prioritizations have.

Monitoring data also provides insight into what changes to make next. Application performance tuning can move the hotspot or pinch point from one resource type to another.

Ideally, tuning eliminates any possible slow points in application operation — along with the complaints from users. At this point, apply the acquired performance information to the deployment setup. None of the effort to get the application to work correctly will matter if the changes are not reflected back in the initial deployment stage. Correct the base deployment, and avoid making the same mistakes repeatedly.

Adjust deployment best practices and expected ranges carefully. These changes have wide-reaching effects. If you didn’t do enough monitoring and adjustments beforehand, mistakes will propagate across all new deployments.

This was last published in August 2018