What is Exoscale Compute?
Exoscale Compute is a service that lets a customer rent a virtual computer in the cloud. This is often referred to as Infrastructure as a Service (IaaS). What does this mean, how does it work, and why would you want that?
What does IaaS mean?
Exoscale buys giant machines to run services on. These have dozens of terabytes of hard drives, hundreds of gigabytes of RAM, and so on. Unfortunately, these machines are too large for the average consumer, so Exoscale uses virtualization technology to create multiple virtual machines, known as instances.
The customer can use the Exoscale Portal to create such a machine at the click of a button, and the Exoscale system will provide it and install the operating system within a couple of seconds.
IaaS stands in contrast to PaaS (Platform as a Service) and SaaS (Software as a Service). With IaaS, the end user can and must run the operating system themselves. On PaaS and SaaS, this is not the case.
PaaS is intended for developers, where the cloud provider offers a platform, such as a runtime environment, managed database, etc. Developers can use PaaS to deploy code without the need for trained ops personnel, but it also means that the application is often explicitly developed for one cloud platform.
SaaS means that not even a developer is needed, the software is running by the cloud provider, and an end user can simply start to use it. Notable examples are Dropbox, Google Docs, etc.
Who uses IaaS?
Traditionally certain types of software (file sharing, websites, collaboration tools) are hosted on a machine hosted in a data center. One could operate this machine in a regular office. The data center provides a couple of significant benefits: a good internet connection, redundant power supply, uninterruptable power supply, a diesel generator, cooling, a fire suppression system, and trained staff. These ensure that the machine runs pretty much all the time, and there is no service interruption due to a power outage.
Building a data center is quite cost-intensive, so only big companies can afford to build one. Smaller companies or companies that do not want to build a data center typically rent a space for their machines in an existing data center.
However, these machines are not your average, run-of-the-mill machines you might buy as laptops or desktop PCs. They run the same operating system, but the hardware is different. These are called servers. Usually, they are built with a dual power supply unit that can be replaced without shutting down the server. They also include hot-swappable disks to replace disks while the machine is running. Some servers even have hot-swappable cooling fans.
To ensure consistency, companies running servers usually want to buy the same server for multiple years. That’s why the procurement for these servers can sometimes take a couple of months, and they often cost upwards of 5.000 EUR, so they represent a significant up-front investment.
Also, nowadays, demands are more dynamic and don’t allow us to wait a couple of months for a server order to complete. Think Black Friday: suddenly, a webshop may get ten or even a hundred times its regular load. From a business perspective, keeping 100 servers in the data center for just a few days of high traffic does not make sense. Instead, these companies can avail themselves of an IaaS provider to rent servers for these days. Exoscale charges on a per-minute basis for running servers, so the company renting these servers can save significant amounts of money.
It is also worth noting that very few companies can plan for 3-5 years, which is the average time a server operates due to the cost. So IaaS may make more sense here, too.
To conclude, IaaS has two main benefits:
- It makes you more dynamic. Servers can be started and stopped as needed without the up-front cost.
- It takes out the complexity of having to buy, repair, or in general, deal with physical hardware.
When creating a server on Exoscale, you will have to fill out several fields.
This field is optional and serves two purposes:
- It helps you identify the compute server on the dashboard. If you have multiple servers, it is helpful to name them for easier identifiability.
- It sets the server hostname in the operating system being installed. This is useful so the software running on the server knows which server it is running on.
If you do not provide a hostname, Exoscale will generate a random hostname for the server.
In this section, you can select where the server will run. (Geographical) zones are entirely independent, so if a wide-scale outage occurs in one zone, other zones are unaffected. It is considered a best practice to build your system so that it is run in multiple zones, failing over to another zone.
Note that Exoscale does not automatically failover your machines to a different zone, nor does it move the data to a different location it was uploaded.
You can select the to-be-installed operating system on your server. Note that for some templates, such as Windows, an additional license fee is charged. Other operating systems, such as Ubuntu Linux, are available for free, and the base price only is paid for the machine. For details on pricing, see www.exoscale.com/pricing/.
If the customer wants to use their license, they can opt to use one of the BYOL (Bring Your Own License) models to start compute instances, or if the customer does not want to use a pre-made template, they can also build their specific custom templates.
Using custom templates is usually desirable for enterprises because they typically maintain and use their operating system images and want to use them in the cloud. However, when using custom templates, the customer is solely responsible for obtaining the proper licenses for the operating system and any other software running on it.
This setting lets you choose the CPU and RAM available on the server. These affect the performance of the server. Note that CPU and RAM can only be adjusted together. Some instance types are not available to everyone and have to be requested via the support interface.
GPU Instances contain a hardware graphics card. These are useful for compute-intensive mathematical operations such as video conversion, distributed ledgers, or machine learning. However, access to these instances is limited and must be requested using the support interface.
For details on the service level agreement (SLA) for GPU Instances, check the terms.
These instance types contain a large disk, which is useful when large amounts of data need to be stored in a single instance. However, due to the large disk size, certain features are not available, most notably snapshots. Therefore, access to these instances is limited and must be requested using the support interface.
For details on the service level agreement (SLA) for Storage Instances, check the terms.
The disk size can be adjusted independently from CPU and RAM, within reason. However, the maximum disk size depends on the instance type, as smaller instances cannot have massive disks. It is also important to note that the disk attached to the instance is a local SSD, and at this time, no additional disks can be attached.
Having a local SSD means that if the instance has an unexpected hardware failure, the disk may die with it, and the data will be lost. This is one reason why backups and redundancy are essential, especially when moving into the cloud.
Some operating systems, such as Linux, allow for login with keys instead of passwords. The keypair option lets you specify which key you want to use.
In addition to the public Internet, Exoscale instances can be connected within one zone with a private network. For more information, see the “Networking” section.
By default, all virtual machines on Exoscale receive a public IPv4 IP address to communicate on the Internet. Besides, you can enable the IPv6 option to request a public IPv6 IP address.
Both the IPv4 and IPv6 addresses are assigned to the machine for its lifetime. Even if the machine is stopped but not destroyed, restarted, the IP address will not change. However, once the machine is destroyed, the IP address is freed up for other customers to use and cannot be reclaimed. Similarly, the IP address assigned to a machine by default cannot be moved to a different machine, which can only be achieved with Elastic IP addresses.
Exoscale has a built-in network firewall. These work by assigning virtual machines to a security group, and the firewall rules are applied to each security group.
This option lets you select which security group(s) a machine should belong to.
As mentioned in the introduction, the virtual machines on Exoscale are running on a physical machine. Physical devices, of course, can have hardware failures. In some cases, these failures can be detected by an early warning system, and the Exoscale staff can move the virtual machines off the affected physical host. In other cases, the failure occurs suddenly, and the virtual machines crash with the host machine. In the worst-case scenario, the data in the virtual machine may be lost.
Anti-affinity groups let you define a group of machines that should never live on the same host machine. This is done to ensure that parts of a redundant system do not fail at the same time.
Anti-affinity groups should be used when redundancy is desired between multiple machines in the same zone. For optimal redundancy, the system should be designed in such a way that the data and services are distributed to various zones in addition to ensuring local redundancy.
Once the operating system is installed, it is usually desirable to automatically install software on the operating system. The user data field lets you upload a program written in Bash, PowerShell, etc., to process this automatic installation.
All virtual machines on Exoscale are connected to the Internet, with a firewall attached to them. That means that if the firewall allows it, the instances can directly communicate with other servers on the Internet without the need for a proxy server or NAT gateway. (A NAT/Network Address Translation gateway is needed when instances do not get a public IP address to access the Internet. However, this is not the case on Exoscale as all compute-instances get public IP addresses by default.)
Every machine on Exoscale is automatically assigned a public IPv4 address. Additionally, you can request an IPv6 address to be assigned. Both the IPv4 and the IPv6 addresses are tied to the machine for the lifetime of the machine. Even if the machine is stopped (but not destroyed), the IP address stays with that machine. When the machine is started the next time, the IP address will remain the same.
However, the IP address assigned by default to the machine cannot be transferred to a different machine and is lost when the machine is destroyed.
If a permanent IP address is desired that can be moved between machines and stays on the account when the machine is destroyed, an Elastic IP must be used. Elastic IPs can be attached to a virtual machine and be removed from a virtual machine. This allows you to create a permanent “service” IP address you can use.
Note that elastic IP addresses can be attached to more than one machine, making them ideal for a failover scenario.
Each machine on Exoscale must belong to one or more security groups. Security groups regulate the firewall behavior of each machine.
Each security group can contain any number of rules for both inbound and outbound traffic. These rules can either specify a different security group to allow traffic from specific IP addresses or networks. The former is useful when creating multiple security groups within the same account, while the latter helps enable connectivity to and from external services.
In addition to the public networks attached to each machine by default, it is also possible to create private networks between machines. Note that the private networks only provide connectivity within one zone, not across multiple zones.
When a private network is attached to a machine, it does not automatically get an IP address on the private network. Instead, IP addresses on private networks have to be assigned manually. Similarly, security groups and, therefore, firewalls are also not applied to private networks.
Private networks are an excellent way to create a secure networking environment between machines on Exoscale. With some work private networks can also be used to create VPN gateways or application/virus scanning firewalls in front of other machines.
Sometimes it is desirable to extend private networks and connect them to an office network or the customer’s physical server network (on-premises) hosted elsewhere. It may also be advisable to connect private networks across multiple zones. That is where Private Connect comes in. Private Connect lets a customer connect directly to the private network on Exoscale. However, this is quite expensive, so it is not for everyone.
To enable Private Connect, the customer must first establish connectivity to the Exoscale data center via a VPN, MPLS, or other means. Then Private Connect is enabled, and the customer network is connected to the private network on Exoscale.
Private Connect, VPN, and MPLS are explained in greater detail in the Cloud Architecture Handbook.
Exoscale Compute pricing is made up of three components: compute, storage, and bandwidth.
Compute instances are only charged when the machine is running. When a machine is stopped but not destroyed, then there are no charges. The website states the prices in hourly increments, but the amount is prorated to the second, so if you run a machine for exactly half an hour, only half of the hourly price is charged.
Storage is charged while a machine exists, no matter if it is running or not. The website states the prices in hourly increments for one GB of storage, but the amount is prorated to the second, so if you run a machine for exactly half an hour, only half of the hourly price is charged.
The exact pricing applies for snapshots.
Each machine gets 1.42 GB per hour (listed as 1 TB (equivalent) per month for convenience). Bandwidth is calculated for all instances in an account together, so if you have three machines, your account, in total, gets 3 TB (equivalent) of data transfer per month or 4.2 GB per hour, no matter which device incurred the data transfer.
“Bandwidth is billed per hour!” It is important to note that the Exoscale website states the bandwidth consumption as a monthly price for customer convenience. The billing cycle for bandwidth, however, is hourly.
The number of running machines in an organization is taken for each hour, and the bandwidth consumed is compared. So if you have three machines and consume over 4.2 GB of data per hour, charges are applied.
So, if the three machines transfer 5 GB of data to the Internet in one hour, charges are applied for 0.8 GB of data since 4.2 GB of data is included in the price.
Also, note that ONLY bandwidth FROM Exoscale TO the Internet is charged. Everything else, including data transfer from the Internet to Exoscale, between regions, and between different accounts, private networks, or Exoscale Private Connect, is free.
Some large customers may want to rent their physical hardware from Exoscale to run their virtual machines. This has a couple of benefits for the customer:
- The customer does not share the network bandwidth between its virtual machines with others and can leverage the total amount.
- Compliance with specific regulatory requirements.
Prices can be found on the Exoscale Pricing Page.
Redundancy & Disaster Recovery
Exoscale does not automatically create backups of virtual machines, nor does it migrate the machines to a different zone in case of an outage or restart the virtual machines if they fail. Therefore it falls on the user to build a redundancy and disaster recovery solution on top of Exoscale.
Exoscale Object Storage provides a reliable way to store large amounts of data and is, therefore, it is an ideal platform for storing backups. Note, however, that Exoscale does not automatically back up instances to the object storage, which the customer must do. Also note, that neither Exoscale Compute nor Exoscale Simple Object Storage automatically encrypts data, so if you want to encrypt your backups for long-term storage, you will have to implement that in your backup solution.
Additionally, Exoscale Compute offers the ability to create snapshots, which are momentary copies of an instance stored on a different storage system. These can be used to restore the state of a virtual machine to the point in time the snapshot was taken. However, snapshots cannot, at this time, be restored into a new virtual machine.
Exoscale does not automatically scale or failover machines; it also falls to the user to implement a redundancy solution. This is often desirable, as implementing such a solution on top of the virtual machine layer is much easier and more performant than under it.
Standard solutions to provide redundancy include running a load balancer, multiple copies of service, and synchronizing the data between them. It is also strongly recommended and distributed to implement automated machine installations. For this purpose, the machines use anti-affinity groups and into multiple geographical zones.
Machines on Exoscale can be resized to any size, but the machines need to be stopped to do that. If the system is not designed to handle that, it may cause an outage.
Generally, it is best to design a system to start more machines, rather than to change the size of a machine, as it makes the system flexible. Automation is required to facilitate that.
It has now become standard practice not to install software by hand anymore (next-next-finish style). The reason for that is that it is desirable to make all servers reproducible. Automation tools like Ansible, Terraform, etc., make it possible to create a “recipe” of sorts to install servers.
Automation around installation enables customers to replicate the production environment and create a similar test environment that is guaranteed to be the same as the production environment.
Exoscale supports automated installation and maintains a set of integrations for these tools. Details on which tools are supported can be found on the Exoscale Integrations Page.
Infrastructure as Code
Exoscale supports a wide range of automation tools that integrate well with it. Exoscale supports, among others, Puppet, Terraform, Ansible, SaltStack, Chef, PalletOps, or command-line clients.
Automation creates the required number of servers on Exoscale and sends the installation instructions for the servers. This is commonly called Infrastructure as Code, meaning that the whole infrastructure is documented as part of the code to create it.
This is also important because automation tests software updates before applying them to the production system. As software updates are an essential part of any infrastructure security concept, the update process must be made as smooth and painless as possible.
Certifications & Security
Exoscale has a large number of certifications, including ISO 27000 and PCI-DSS (Credit Card Processing). For details on the available certificates, see the Exoscale Compliance Page.