A Comparison: Octopus Deploy vs Otter

Although Octopus Deploy and Otter are different types of products, they can both be used to automate ASP.NET Sites and Windows Services. A side-by-side comparison would be a bit like Air Jordan vs Tesla: they’re different tools that can help you get to the same place, albeit in different manner. Moreover, there’s nothing wrong with having and using both.

Already familiar with Octopus Deploy? The terminology comparison may help you get a quicker understanding of Otter.

Deployment Automation vs Infrastructure as Code

Deployment Automation tools perform a one-way, one-time “push” of a set of packages to a group of servers. As part of this process, various scripts may executed to configure the package, such as IIS, Windows Service Manager, etc.

Infrastructure as Code tools continuously ensure that a group of servers is configured in a specific manner; this includes a specific version of a package, as well as configuration for hosts such as IIS, Windows Service Host, etc.

Although neither category of tool is designed for Application Release Automation, many organizations simply don’t have the need for orchestrating complex, multi-team release processes, and can simply use base application package deployment instead.

However, as both Development and Operations teams and solutions become more integrated, Infrastructure as Code is quickly becoming a preferred vehicle for application package deployment because it offers:

• Drift (Change) Detection – Infrastructure as Code tools will automatically detect (and optionally remediate) any unplanned changes to an application or configuration; with Deployment Automation, you rely that nothing has changed since the last one-off deployment
• Built-in Scalability – with Infrastructure as Code, you can simply set-up a new server, assign the appropriate role to it, and the tool will ensure it has all the necessary configuration and applications; a Deployment Automation would require a special one-off deployment
• Literally “code” – although you can certainly store the scripts by a Deployment Automation tool in source control, the configuration of which steps and scripts to run (as well as the variables, etc) are not versioned, and are only editable in the web UI; with Infrastructure as Code, the configuration is literally code (and with Otter, it can be easily edited in the UI as well)
• Unified Configuration – an Infrastructure as Code approach allows both Development and Operations teams to see how servers are configured, and how that may impact applications and performance; with Deployment Automation, server configuration is often embedded within the application deployment scripts

Basic Deployment Steps vs Execution Engine

Octopus Deploy runs one or more “steps” when deploying a package. The primary step is the Deploy NuGet Package Step, which copies the package contents to a target directory, and depending on which”features” are selected, performs rudimentary configuration for IIS website, Windows Service, etc. Custom PowerShell Scripts are executed before and/or after the step runs to fill in any gaps.

Otter, on the other hand, uses an advanced execution engine that’s capable of running thousands of different operations and scripts on thousands of different servers. The execution engine has a lot of features to enable this flexibility and scalability, and the features to be easy to learn, especially if you’re already familiar with general scripting or programming concepts.

Configuration plans direct the execution engine, and provide an easy-to-understand, visual representation of configuration and orchestration, while also being the “code” behind your Infrastructure as Code.

PowerShell Integration

PowerShell is the standard for automating configuration on Windows servers.

Octopus Deploy offers a few options for executing a user- or community-written PowerShell script: before, after deployment, or on error. You can also create a custom “step” using PowerShell.

Otter, on the other hand, was designed to seamlessly integrate with PowerShell, and offers not only basic PowerShell execution (similar to Octopus, through the PSCall Operation), but other tight integration points:

Inline PowerShell Execution

Within Otter’s “Infrastructure as Code” plans, you can use PSExec and swim strings to directly incorporate and execute PowerShell:

psexec >>
  # delete all but the latest 3 logs in the log directory
  Get-ChildItem "E:\Site\Logs\$ApplicationName" |
     Sort-Object $.CreatedDate -descending |
     Select-Object -skip 3 |
     Remove-Item
>>;
	

Otter will seamlessly replace variables within your PowerShell script, so in the example above $ApplicationName might be defined as a configuration variable.

Evaluating PowerShell Literals

With Otter’s PSEval, you can quickly evaluate PowerShell expressions as variable values. For example, say that you wanted to convert the value stored in one variable ($minutes) to milliseconds. You could PSEval the simple expression $minutes * 60 * 1000:

set $milliseconds = $PSEval($minutes * 60 * 1000);

$PSEval actually runs the expression on the server currently in context, so use it inside of an If/Else Block to perform different operations depending on the results of the expression on that server.

Animals: Octopuses vs Otters

Octopuses (or octopi if you if you prefer) and otters are both incredible species, known not only for their mischievousness and playfulness, but their cunningness and unexpected brawn. Though many would argue that otters win hands-down in the adorableness department, octopuses can be just as cute.

Otter for Orchestration

Using Infrastructure as Code for all automation tasks isn’t appropriate, and that’s why Otter offers orchestration plans as well.

Orchestration plans are quite a bit simpler: they just use the same, advanced execution engine to execute operations and scripts on servers. Unlike configuration plans, orchestration plans don’t run continuously. Instead, you scheduled them to run (either in the future, or on a recurring basis) using an orchestration job.

This simplicity also makes them hard to describe in detail, because they can be used to do just about anything:

• Installing patches or other changes to 1000’s of servers
• Spinning up and configuring multiple virtual servers
• Execute existing scripts in a controlled and visible manner
• Provisioning bare-metal hardware
• Deploying ProGet packages

Terminology Map