A common question we receive from customers thinking about moving Octopus to cloud infrastructure is:
Should I move to Octopus Server on a virtual machine or to the hosted Octopus Cloud?
In this post, we take a look at why you might choose one over the other. Cost and security are key considerations, but we’ll also consider how you’ll use Octopus.
Octopus Cloud refers to the Octopus Cloud SaaS offering from Octopus Deploy and Octopus Server refers to the self-hosted version of Octopus Deploy. In the context of this post, Octopus Server resides on a virtual machine in the cloud.
Architecture
Before I get into the details, let’s look at the architecture for the two incarnations of Octopus we’re discussing.
Server
Octopus Server runs as a Windows Service; this provides access to the Octopus REST API and Octopus Web Portal. It connects to a SQL Server database and uses file shares to store task logs, artifacts, and packages.
Cloud
Octopus Cloud uses a Linux container running on AKS with the database hosted in Azure SQL. The file shares use Azure Cloud Storage.
Management
Opting for Octopus Cloud reduces the number of administration tasks you have to carry out on your Octopus instance; however, there are some reasons you might want the greater control that Octopus Server offers.
Retention policies and storage
Octopus retention policies have a default configuration on all Octopus instances, and we recommend reviewing them to suit your requirements.
Server
When you configure Octopus Server on a VM, you select the storage that Octopus uses for the server folders. This means you can set the storage limits that suit you for these folders and configure retention policies accordingly.
Cloud
Octopus Cloud provides plenty of storage for most businesses; however, the amount of storage you can use has a limit. Where long term retention is required for regulatory compliance, you may find this a reason to select Octopus Server over Octopus Cloud.
We’ve added monitoring to the Technical section of the Octopus instance management page. To view the details, login to your Octopus Account, then, on your instance, select Manage ➜ Resource Usage . This is updated every 24 hours.
Octopus has a built-in package repository available to all instances, in addition to this, external repository feeds can be configured to serve your deployment packages. You might choose to use an external feed to aid in multi-region deployments or if your package feed storage requirements are considerable.
Maintenance window
Cloud
One of the great things about Octopus Cloud is that you don’t have to worry about how and when to perform system maintenance and upgrades. Octopus manages those for you, and you can choose a maintenance window to suit your business and region.
Outage window information is in the Technical section of the Octopus instance management page:
Server
Octopus Server allows you to be even more specific about when you perform your system maintenance and upgrades. If you implement high availability then you can have zero downtime while maintenance is carried out. Some customers choose to automate maintenance and upgrade tasks by using runbooks in another instance of Octopus. A free Octopus Cloud instance is suitable for this task.
Managing infrastructure
Server
With Octopus Server, you can use infrastructure that fits into your business’s operational architecture, and any infrastructure management processes and policies in place can be used for your Octopus instance. And because you are hosting your Octopus Server, it is your responsibility to ensure the infrastructure performs well, is maintained, and recoverable as well as scaling capabilities.
Cloud
Using Octopus Cloud allows you to take a step back from infrastructure management. It’s our responsibility to ensure that the infrastructure is robust and scales according to your usage.
Workers
There is a distinct difference between the Default Worker Pool for Octopus Server and Octopus Cloud.
Server
In Octopus Server, the Default Worker is the Octopus Server itself, whereas Octopus Cloud doesn’t allow the server to perform outside operations.
When you use Octopus Server, we recommend using Workers when possible to reduce the resource usage on the Octopus Server, and as Octopus executes under a privileged account, if you can offload work to another machine in the form of a Worker, it’s wise to do so for added security.
Cloud
Octopus Cloud leases a dynamic Worker machine from a Worker Pool specific to its region.
Backups
Cloud
Backups are included as part of the managed service with Octopus Cloud. The database, built-in package repository, and configuration are backed up. If you use an external package feed, then it is your responsibility to ensure backups are configured.
Server
When managing your infrastructure as part of an Octopus Server installation, you can design your backup and recovery plan to match your existing infrastructure plans.
Monitoring
Octopus subscriptions can be used in both Octopus Cloud and Octopus Server. You can configure notifications to notify you of changes in Octopus, for instance, a change to a specific project process, a user amendment, the addition of a deployment target. There is a long list.
The REST API has a reporting endpoint you can use to create a dashboard, available in both Octopus Cloud and Octopus Server.
With Octopus Server, you can also send logs to a central log tool by adding a log target to the nlog config file.
Database
Cloud
The Octopus Cloud database is not accessible to customers, so all interactions with Octopus must be done using the web interface or with the API. The great thing about this is that the database maintenance, security, and patching is all done by us.
Server
Octopus Server on a cloud VM gives you several options for database hosting:
- VM: Host SQL Server on a virtual machine.
- PaaS: For example, Google Cloud SQL, Azure SQL, or AWS RDS for SQL Server.
- Docker: Use SQL Server within a Docker container. This could be on a Windows or Linux virtual machine or a cloud container hosting platform.
The benefit of managing your database gives you the choice of more lenient retention policies, the ability to use a clustered database, and managing your own backups.
Security
Cloud
With Octopus Cloud, we secure the infrastructure and carry out penetration testing to ensure the security and integrity of the Octopus instances. However, you are still responsible for:
- How you connect Octopus to your infrastructure.
- How you identify your users and control their activities within Octopus.
- How you handle sensitive information within Octopus.
Server
When you use Octopus Server, it is your responsibility to harden the Octopus instance infrastructure. This level of control may be beneficial if there are industry-specific regulations to which you are required to adhere. In this case, you also taking responsibility for:
- How you harden the underlying server operating system.
- How you protect the Octopus Server files on the operating system.
- How you store files generated by Octopus Server.
- How you secure your SQL Database and protect the data generated by Octopus Server.
- How you expose your Octopus Server to your infrastructure.
- How you identify your users and control their activities within Octopus.
- How you handle sensitive information within Octopus.
When adding deployment targets and Worker machines to Octopus Cloud or Octopus Server infrastructure, their security and integrity are your responsibility.
Authentication providers
Cloud
Octopus Cloud authentication uses Octopus ID, which allows you to use the same account you use to sign in at octopus.com. Octopus ID supports username and password or can use a Google or Microsoft account.
Octopus ID allows mapping of an Octopus user to a Google or Microsoft account however, it does not allow mapping to external groups as is possible with Active Directory.
Server
Octopus Server has several authentication providers available:
- username and password
- Active Directory
- Azure Active Directory
- Google account
- Okta
Multiple providers can be configured concurrently.
IP restrictions
Cloud
An Octopus Cloud instance has a range of static IP addresses shared among customers in the same Azure region. These can found in the Technical section of the Octopus instance management page:
Server
When you use Octopus Server on a VM, you can configure the IP and DNS that suits your business’s requirements. You may choose to configure a load balancer to handle traffic to the Octopus web interface; this is especially useful if you configure HA.
Organize projects and environments
Spaces are available with both Octopus Cloud and Octopus Server. Spaces create a hard wall between projects and infrastructure, so each of your teams only access the projects and infrastructure they need.
Server
Concurrent licenses are an additional benefit of Octopus Server. You can use three instances for each license, which means you can run one Octopus Deploy service for production use and set up extra services for development or test. Or you can use two separate Octopus Deploy instances to keep production and pre-production deployments isolated.
Networking
Connecting Polling Tentacles over WebSockets to Octopus Cloud is not currently possible, but we do have plans to support Polling Tentacles connecting on port 443 soon.
Proxy support
Both Octopus Server and Octopus Cloud have support for proxies. You can specify a proxy server for Octopus to use when communicating with a Tentacle or SSH Target. You can also specify a proxy server when a Tentacle and the Octopus server make web requests to other servers.
Region
Server
Using Octopus Server on a VM lets you host your Octopus instance in your choice of geographic region.
Cloud
Octopus Cloud also offers you the option of hosting your instance in a region that suits you. We use Microsoft Azure to host Octopus Cloud, and at the time of writing, we offer the following regions:
- West US 2
- West Europe
- Australia East
The region is selected when you first create your Octopus Cloud instance.
Should we introduce a new region that suits your needs better, please get in touch so we can move your instance to that region.
Regional package feeds
If you operate in multiple regions and are concerned about network latency issues when you transfer large packages during deployments, we recommend opting for an external package feed and either replicating it across multiple regions. With DNS aliasing, you can have the Tentacle fetch packages from geographically local package repositories. Or you could have two separate but identical package repositories and use a variable for the Feed ID. Package repositories work in this way for both Octopus Server and Octopus Cloud.
High Availability
High Availability (HA) can be configured for Octopus Server to run multiple Octopus Servers that distribute the load and tasks between them.
Octopus HA is not available for Octopus Cloud, but all instances are provisioned as a Linux container running on AKS (Azure’s managed Kubernetes). Kubernetes helps us achieve resilience and scaling flexibility for Octopus Cloud.
Other considerations
Tentacles
An Octopus Tentacle machine can be configured for either the polling or listening communication modes. The type of Tentacles you select for your deployments will depend on your business requirements. You should also consider if the configuration of these machines has any impact on the infrastructure chosen for your Octopus instance.
Tentacle firewall rules
The type of Tentacle you use will depend on your firewall rules. A listening Tentacle must have an inbound firewall rule to allow access via TCP port 10933. A polling Tentacle doesn’t require any firewall rules on the Tentacle, but the Octopus Server must allow access through the firewall inbound on TCP port 10943. Listening Tentacles uses fewer resources, but if you use dynamic IPs or the Tentacle sits behind a NAT, a polling Tentacle will be required.
You will need to apply these rules to any intermediary firewalls.
Octopus in a container
An alternative to running Octopus Server on a virtual machine is to run it in a container. In fact, this is how we manage our Octopus Cloud instances. The Windows container for Octopus is fully supported, and the Linux container is, at the time of writing, part of our Early Access Program.
Conclusion
This post has hopefully provided clarity to your decision-making process about moving to cloud infrastructure. Whatever your business requirements, Octopus Deploy makes release management easy and simplifies even the most complex deployments wherever you deploy your software. Runbook automation minimizes outages and gives you control over your infrastructure and applications.
If you have any questions or would like advice on how Octopus can work for you, please drop us a line at advice@octopus.com
