Recently I had a bit of a nightmarish experience that we might be able to transition into an opportunity. Let me share it with you.
For many years now I have been running my personal website at [archivedblog.jonobacon.com](https://archivedblog.jonobacon.com/). The site is nothing special, just my blog and some other content, and I have been running it on a dedicated host alongside some other sites (including [Stuart Langridge’s homepage](https://kryogenix.org/days/)). Stuart and I shared the server and paid nearly $1400 a year for the hosting.
Recently we discussed shutting the server down and migrating our sites to shared hosting providers; we are tired of having to take care of a server and we wanted to cut costs. Stuart and I both run WordPress for all of our sites; I used to write and maintain my own CMS many moons ago, but moved to WordPress for convenience. We both wanted to end up in a position where we didn’t have to maintain the OS and WordPress and have to deal with upgrades, backups and other related sysadmin work. As such I started the process of exploring hosted WordPress providers. This is when the pain started.
Computing can be fraught with pain and danger.
At first I thought…[wordpress.com](https://wordpress.com/). Perfect! Taking a quick look at their site I could pay for my domain to point there and I could also pay to not have ads. There were two downsides though: I could not use my current theme (which is a premium [WooThemes](https://www.woothemes.com/) theme), and I couldn’t use my own plugins. Unfortunately I need two key plugins: [phpmarkdown](https://michelf.ca/projects/php-markdown/) and [Disqus comments](https://wordpress.org/extend/plugins/disqus-comment-system/) and I may need additional plugins in the future. I would have happily compromised on the theme, but it seems that getting comments back out of Disqus and into WordPress is a pain, and converting years of mixed HTML and markdown blog posts was going to be a pain, as well as not having flexibility in the future. I looked at other WordPress providers but they all had similar problems.
Knowing I didn’t want a dedicated server due to the expense (and this would be just me paying this time, Stuart had already moved his site), I started looking into alternatives.
Now many of you will be screaming “*use the cloud, Jono!*”, but my worry here is that while my normal traffic is generally pretty consistent and predictable, every so often my site gets hammered into the ground with traffic, and I didn’t want to get stuck with a big bill. I wanted to instead just pay a monthly fee and know it wouldn’t extend beyond that in cost.
## Getting All Virtual
As such it seemed my best option was going to be a *Virtual Private Server* (VPS). These are dedicated machines that share multiple virtual machines and you pay for a set of resources. If you want more resources, you simply upgrade your plan. This gives you the flexibility of a dedicated host but cheaper and without the risk of ballooning cloud costs.
Pictured: ballooning costs.
There are basically two types of VPS: *Managed* and *Semi-Managed*. The *Managed* plans include full technical support, backups, managed OS upgrades etc. *Semi-Managed* means you are basically on your own with a root shell, but many semi-managed plans also include a control panel that you can use to manage different parts of the server.
*Managed* was a little more expensive than I wanted to pay, but the idea of *Semi-Managed* was interesting, particularly if I could use a control panel to take care of the things on the server I didn’t want to care about (such as backups). So I started looking into different providers.
This is where I hit a roadblock. Ubuntu was a non-negotiable requirement for me in choosing a server, but irrespective of whether I went managed or semi-managed it seemed like these were my options with pretty much most of the VPS providers:
1. cPanel Control Panel running on CentOS.
2. Plesk Control Panel running on Debian.
3. Ubuntu with no Control Panel.
From what I read, cPanel is considered the better panel, so I was optimally hoping for cPanel on Ubuntu, but it seemed I would need to compromise on both the panel (Plesk) and the OS (Debian). Now, don’t get me wrong, I *love* Debian, and most things in Ubuntu are the same in Debian, but not quite everything is and I would probably get caught up in those details. Also, I love the LTS support for Ubuntu.
With my Ubuntu requirement it seemed like the last option in the list above was my only real step forward, and this basically meant I was going to have to take care of the server manually. Now, I know some of you folks love doing that, but I don’t. It is not that I don’t have the knowledge to administer a server, and Ubuntu definitely makes it easier, it is just that I don’t really want to spend my time fiddling with Apache and MySQL; I just want it to work. Despite this I sucked it up, registered with a provider and a little while later I was all set up and running.
## What I Want
One of the reasons I love Ubuntu is that it makes my computing experience easier. Ubuntu on my desktop lets me work quicker and more efficiently, and Ubuntu on the server lets me install what I need quickly and efficiently.
On the server though I still need to keep up to date with how to configure, manage, and maintain these components in my service. I care more about simply deploying a service, and ideally I would have an expert in the tools I use to make the specific configuration and performance decisions, but I am not an expert. As such using Ubuntu on the server in a VPS without a Control Panel relies on me learning the skills to run my service well.
This is why I want [Juju](https://juju.ubuntu.com/) to be able to control my VPS.
Juju has been focused on providing a fantastic deployment service for the cloud. It lets you set up and configure a comprehensive deployment in just a few commands, and a core design goal with Juju charms is to infuse the knowledge of deployment experts into the charms so that Juju users benefit from this knowledge and expertise when they deploy their service.
Knowledge flowing from a deployment expert into a charm.
Unfortunately I can’t currently use Juju with my VPS; it is currently focused on the cloud. I think however that Juju could benefit VPS hosting needs in a number of ways:
* **Simplifying Deployment** – ideally I want to subscribe to a hosting plan, get my machine provisioned and then simply deploy WordPress with just a few Juju commands. This would save me having to poke around configuration files, setting up databases etc.
* **Scale Out** – for those times when my site gets hammered by traffic I want to be able to scale up my resources to cater for the traffic. I would love Juju to be able to speak to my hosting provider’s API to be able to provision either more memory, CPUs or additional machines to cater to these needs.
* **Transitioning To The Cloud** – if I could use Juju right now with my VPS it would make it simple to re-target my service to the cloud. With the sheer scale and focus of the cloud I will no doubt move to cloud hosting in the future, and Juju could simply that transition significantly.
* **Lower The Bar** – if we provided support for VPS providers this would provide a means in which many more people would be able to play with, try, and experiment with Juju. This would in itself continue to grow Juju adoption.
* **Juju GUI** – while I currently lack a panel, Juju GUI would be my panel. This would ease management of my service tremendously.
* **Great For Providers** – the margins in hosting are low due to the competitiveness of the industry, and from what I could see in my research lots of people want to use Ubuntu as their server OS, but the lack of a panel makes it a complicating issue in some cases. Offering Juju and Juju GUI would make Ubuntu an even more attractive option for hosting providers and also likely reduce support costs.
After I went though this process I reached out to the Juju team to see what would be involved in bridging this gap. I talked with *Mark Ramm* who is managing Juju, who was resonant to the idea, but was also conscious that Canonical engineers are busy working on other parts of Juju. Fortunately there has been [some work going on](https://lists.ubuntu.com/archives/juju/2012-September/001883.html) that could support this goal, and Mark suspected that it would not be a tremendous amount of work to build this support into Juju. I thought that this could be a fun project that our community could work on.
I have asked Jorge to coordinate with Mark to put together a list of what would need to be done. Jorge is going to follow up with a blog post and some next steps. Stay tuned if you are interested in contributing to this. Thanks!
**UPDATE**: See [this page](https://juju.ubuntu.com/the-juju-unprovider/) for what needs to be done and [this discussion](https://lists.ubuntu.com/archives/juju/2012-November/001985.html) to get involved (you can join the `juju` mailing list [here](https://lists.ubuntu.com/mailman/listinfo/juju)).
