arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full dots-horizontal facebook-box facebook loader magnify menu-down RSS star Twitter twitter GitHub white-balance-sunny window-close
Should have written it in Java
2 min read

Should have written it in Java

This is an old post and doesn't necessarily reflect my current thinking on a topic, and some links or images may not work. The text is preserved here for posterity.

The Windows and .NET platforms are a great stack for building and deploying applications when you have control of them. But as an ISV building software that needs to run on other people's systems, right now I feel like they are causing me a lot of pain. To give some recent examples:

  1. A customer was unable to use the IIS-hosted Octopus web portal because of problems serving the JavaScript/CSS files. The reason turned out to be because they had removed all the default MIME types and expected us to document every MIME type they should enable.
  2. Two customers are experiencing problems with the X509 certificates that we use, due to the way Windows deals with the certificates and the permissions around them. We've even build a custom diagnostics tool to try and discover the problems, but it seems to be something specific to the machines.
  3. A customer reported a bug because our software wouldn't run on Windows Server Core. This was because a Windows hotfix was needed to allow portable class libraries to work.
  4. Because .NET 4.5 overwrites parts of .NET 4.0, our software has to work on .NET 4.0 (for customers who can't install 4.5) and 4.5 (for customers that have installed it). But we often get bug reports because a customer has just installed .NET 4.5, and having not restarted yet, Octopus crashes because some code path is trying to now call .NET 4.5 code but is reading .NET 4.0 binaries.

Recently I've been toying with Erlang on Xen, which I think is a fascinating idea: being able to compile an application into a virtual machine image that can be run directly on a hypervisor, with a fit-for-purpose operating system and tiny footprint. If we took this approach, we could ensure that our application was running entirely on a stack that we control and can support properly.

Unfortunately I can see a few stumbling blocks if we were to try and ship a Hyper-V image containing a Windows server with our software installed and configured as the only way to use the software:

  • Customers would probably want to join it to a domain, and a lot of the problems would come back once group policies are applied
  • Customers would probably want to enable automatic updates, so it wouldn't remain "pure" for long
  • Customers in small shops might be unable to dedicate an entire running VM just for Octopus, and would also want to be able to run a build server alongside

Still, it's a wonderful dream. Perhaps this is a sign that Octopus needs to be ported to Java, where I can bundle the runtime and not depend on IIS, HTTP.sys or the abomination that is the Windows certificate store.

Paul Stovell's Blog

Hello, I'm Paul Stovell

I'm a Brisbane-based software developer, and founder of Octopus Deploy, a DevOps automation software company. This is my personal blog where I write about my journey with Octopus and software development.

I write new blog posts about once a month. Subscribe and I'll send you an email when I publish something new.