VMs and Containers

What is a container, and how does it differ from a VM? Continuing on from the cloud terminology post I decided to go back to basics. As much for my own knowledge verification as for anything else.

Before going into a deep dive on the differences though I thought it might be worth starting at the basics. What are the components of a computer. Essentially there are four core components.

  • CPU
  • Memory
  • Network
  • Storage

On top of these you will install an Operating System, then one or more applications. These applications can be in isolation or can talk to each other through the OS or an Application Programmable Interface (API). The way that a user will interact with the applications is through a Graphical User Interface (GUI) via a keyboard, mouse, or touch screen.

A Virtual Machine takes the four key components and turns them into a file that then runs within another program. This creates a layer of abstraction between the underlying physical infrastructure and the VM. Why would you do this? Typically the physical infrastructure that is available today cannot be consumed by a single computer with programs running on it, and in fact lots of resources are wasted. By running multiple VM’s on a physical computer or server you can use more of those resources, giving a better use of money. From an environmental point of view this is also great as you need less physical tin, real estate, and associated power and cooling. Win Win so far.

So what are the downsides?

A VM still has lots of resources allocated to it, a full Operating System is required per VM which can be expensive, and boot times can still be quite high. Improvements in the underlying components though have resulted in some boot times dropping markedly. But you still need to deploy applications, keep them up to date through patching and have a fair amount of administrative overhead.

Along came containers

What is a container? Where a VM is an abstraction of the physical hardware a container is an abstraction at the application level. The container has the application and any dependancies packaged together. A single Operating System can then have multiple containers running on top, each in isolation from the next. This means you can have lots of applications with lower cost because you do not need to license multiple OS’s and boot time for the application is smaller because the footprint of the OS is smaller.

So which should you use? Well why not both together. Docker has a great article on the differences here.

Cloud Terminology

I was asked recently to describe the difference between some different services within the cloud. This seemed fairly straight forward to em however it did get me to stop and think about the nomenclature that we attach to different services and where someone new to cloud computing could get this information from. I’ve always referred to the NIST definition and thought it might be useful to share this, along with some other services that are frequently discussed.

IaaS – This is for a customer who wants to manage the components of the infrastructure such as the network layer, the storage, the OS, and the application layer.

PaaS – This is for a customer who doesn’t need to have granular control over the OS or application layer. This allows for the use of a specified version of applications, so would be suitable for someone who is ok with controlled environments where a specific version of code is in use.

SaaS – This is for someone who does not want or need to know the infrastructure or application details, and in fact only wants to take advantage of the service. The most prolific example that I can think of is webmail. Other services include the entire Office365 offering from Microsoft, Salesforce which I use every day in my job, as well as a number of online training providers such as coursera and codeacademy.

All of these different types of cloud services have as their key offerings some very specific requirements.

  1. No human intervention
  2. Ubiquitous access
  3. Secure, multi-tenancy
  4. Elastic Scale
  5. Incremental billing

If your cloud offering requires human intervention it isn’t a true cloud offering, rather a managed service, even if it sits on top of a hyper-scale public cloud provider such as AWS or GCP. And there are cases where this may be a preferred offering such as when you initially migrate an existing workload to cloud from on-premises, or even if you want to consume a service that you’ve never considered before and require support such as a migration to a new ERP system as your business grows beyond the scale of a whiteboard with post-it notes. But you should know that it is not a cloud offering.

The access to the cloud needs to be from any device, any where, at any time. A great example of this for me is coursera. I’m currently upskilling on a variety of different topics, one of which is delivered through coursera. I have access to coursera on my mac (thick client), iPad and Samsung tablet, and even offline training on my iPhone as lecture notes. This lets me access this training material at home, on the bus on the way to the office, or even on a plane whilst I’m travelling over a satellite service if the aircraft has this, or as offline lecture notes if it doesn’t. I can even compile code on my mac whilst listening to the notes on my iPhone whilst sitting at 38,000 feet sipping a red wine. For a training service that’s pretty awesome.

Secure multi-tenancy is absolutely key to the cloud. My services in AWS are running next to someone else’s physically, but logically separated. My trust in this has been earned through security audit results shared by AWS on their platform, but I am aware that the data and services that I run up are the weak points and most likely breach. To this end I follow the security best practices and constantly make sure my details are secure. However breaches occur and sometimes they are not even within something that can be controlled by you such as this example.

The elastic scale of the cloud is in my opinion one of the biggest draw cards. When you build a service sometimes you have no idea on if that service will be successful, or if it will be a flop. Being able to build so that if you have a requirement for lots of scale at a moments notice, or even better without notice so that your service can scale itself whilst you are notified but requires no intervention is truly an amazing feat. I spend a fair amount of time talking to my customers about how they have architected their new equipment, and a lot of the time it is their existing requirement plus 30%. Trying to explain to a CFO who you need 30% more budget is always hard, especially when you have limited metrics.

Cloud services are billed in increments of usage, which makes a lot of sense when you think that some services such as analytics may be especially bursty in nature. You may not want or need to have beefy servers on call 24/7 for months at a time as they could potentially sit there doing nothing, or even be the other way round where you use all your servers and don’t have enough capacity to run all the analytics you need. This is where cloud can make the most difference as if you run a service for 5 minutes, you pay for 5 minutes, or whatever the increment is that your cloud provider offers.

Now that we’ve defined the services and what the key characteristics are of cloud services, what are the different clouds that you can look at?

  • Community
  • Public
  • Private
  • Hybrid

A community cloud is where a group of like minded, or shared vision, consumers will purchase exclusive access to a cloud. Typically this has been public services customers who have requirements around data locality/sovereignty. This type of cloud could be on-premises, or off, through a public cloud, or private cloud, or some combination thereof.

A public cloud is an offering open to the general public, typically through a web portal and payment information upfront such as a credit card billing system. It exists on the cloud providers premises and examples include AWS, Azure, and GCP as hyper-scale providers of services.

A private cloud is a dedicated offering for a single organisation that could be provided to multiple consumers (e.g. business units). Typically this is on the organisations premises.

Finally we have a Hybrid cloud. This is a combination of the above and could see an organisation consume services from within an on-premises private cloud, and extend the services out to a public cloud for burst workloads as an example. Almost every customer I have spoken to is in this bucket.

There are other services such as BaaS (Backup as a Service) and DRaaS (Disaster Recovery as a Service) that are offered by managed services providers and may utilise the building blocks of cloud under the covers.

Storage by Software

The most expensive part of Enterprise Storage Arrays, which should not be confused with a SAN, is the software.  The majority of parts in most of the major vendors platforms are now made in the same factory, utilise drives from Seagate and Western Digital, and Intel chipsets where possible.  The reason behind this is quite simple, economies of scale.  the vendors can buy products at a lower price point, and use their Intellectual Property to create the fastest performing box of disk possible.

Software defined storage has a lot of buzz around it, and for good reason.  The promise of policy driven storage, controlled through software and not hardware is almost irresistible, like a good ice-cream on a hot day.  SNIA has a fantastic definition for SDS (https://www.snia.org/sds) and there are lots of articles on the pitfalls and tribulation of SDS, along with the amazing outcomes that it has given.  As with most things your mileage may vary. Continue reading “Storage by Software”

Veeam Data Lab – Part Two

In my previous article on the Veeam Data Lab I highlighted why you would utilise this functionality with a couple of real world examples.  In the next few posts I intend to show how you would accomplish this.

The first step in any Data Lab deployment, or the automated testing for backup (SureBackup) and replication (SureReplica), should always be the requirements gathering phase.  This phase is critical for the Data Lab as it identifies what you want to test, and the VMs required.  Once the VM or group of VMs to be utilised in the Data Lab have been identified it becomes quite easy to map out any dependancies on other VMs, as well as networking dependancies.

Let’s look at a fairly simple setup for a SharePoint environment.  The SharePoint environment to be tested is made up of:

  1. A WEB server (192.168.2.16);
  2. An APP server (192.168.2.15); and
  3. A SQL server (192.168.2.14).

They have dependancies on DNS, and Active Directory, both provided by a Domain Controller.

  1. DC (192.168.3.240)

All servers have been configured with static IP addresses, with the SharePoint servers inside of one subnet, and the DC in another.

For testing purposes a single static IP address within the Production environment that can provide access to the WEB server is configured sufficient.

In our example the two networks in the Production environment to be emulated are 192.168.2.0/24 on VLAN 302 (SharePoint) and 192.168.3.0/24 on VLAN 303 (DC), and the user network is 192.168.1.0/24 on VLAN 301, and all gateway servers are x.x.x.254.

The emulated environment inside the Data Lab will be:

  1. WEB 192.168.2.16/24 on VLAN 3302
  2. APP 192.168.2.15/24 on VLAN 3302
  3. SQL 192.168.2.14/24 on VLAN 3302
  4. DC 192.168.3.240/24 on VLAN 3303
  5. WEB access IP 192.168.1.216 on VLAN 301

This means that the emulated environment and the real servers will have the same IP addresses, and this is key as SharePoint servers will be looking for connectivity between each other and the DC on these IP addresses through DNS lookups.  To achieve this the Data Lab will deploy a virtual Proxy Appliance to provide network address translation on virtual NICs.

Production diagram

Data Lab diagram

Now that we have a basic design it can be applied to the environment as shown in Part Three.