One weekend. One website. One rebuild.
⚠️ This article was written in and contains out of date information.
I have a confession to make. Up until this weekend, my website was hosted on Squarespace.
This may seem counter-intuitive, for a software developer to use a service like Squarespace, but it made a lot of sense at the time. I needed a website fast while I was working full-time and didn't have the time or energy to build a site from scratch.
I've mentioned in the past how I'm not opposed to using third-party services where it makes sense, and this was certainly one of those occasions.
Squarespace is, however, not without its faults: accessibility is poor and there aren't many ways to improve it; the drag and drop designer is a pain when you want consistency and repetition; and my CV on the Squarespace site never looked quite right on mobile. So, combined with the fact that I'm an Umbraco developer without an Umbraco website, it was time for a change.
Investing evenings and weekends in building something I do for my day job has never really appealed to me, so I thought I might try out Umbraco Cloud. I like the idea of patch upgrades happening automatically and other upgrades possible without cloning locally. This means that going forwards I have less admin to do to keep my site up and up-to-date. Using Umbraco Cloud also meant that I'd have more recent practice using Cloud, so I was at least learning something from my endeavour (I haven't used Cloud since it was in preview and called UaaS!)
Signing up for the trial was fairly easy and promised 14 days to get my site in order before launching and paying for it. I had a repo up in no time.
Although Cloud allows fully-online development (more on that later), I'm stuck in my ways. So decided to try out developing the Umbraco site locally. Developing locally enables compiled libraries for custom helpers and extension methods and installing packages via Nuget (sorry, Umbraco Packages!) which is all good practice as far as I'm concerned.
Cloud is built around Git. Any changes you make are committed to Git and this automatically triggers a deployment to the Cloud site. In theory, this means working locally is as simple as cloning the URL Cloud provides and hitting run. But it's not quite that simple because Cloud runs ASP.NET Websites rather than their Web Application counterpart, meaning there is no Visual Studio Solution that's source controlled. Umbraco, therefore, provide UaaS.cmd to help simplify this process.
Foolishly, I initially only skim-read the documentation here before diving in. But after following the official guidance, this process was actually quite simple.
Then, after configuring my two (that's how it works!) git repos (and also setting up a mirror for the Umbraco Cloud repo because, although not necessary, I couldn't help feeling it was better practice somehow), I hit the run button...
Well, that didn't work. It's at this point I'd usually document the steps I went through to get it working properly but, in all honesty, I had no idea what I did to get it happy again. It was a bit of trial and error and likely specific to my setup, so we shan't dwell on this! The important thing is that it's working now!
Let's take a moment to discuss the setup when developing locally.
UaaS.cmd sets up two Git repositories, one at the root (that you need to source control yourself) and one in *.Web (where * is the name of your project).
*.Web contains your Umbraco site as an ASP.NET Website (not Web Application - there is no .csproj file).
The root directory contains the solution file as well as a folder and csproj file called *.Core which, according to the docs, is where controllers, models, data access and extension methods should ideally live.
Using ModelsBuilder is a bit of a pain. To get Intellisense working, the docs recommend using ModelsBuilder mode AppData (classes are generated upon request) or AppDataLive (classes are generated automatically when models change) and then overriding the path to place them in the App_Code folder, where they'll get compiled on the fly. This is quite clever. Visual Studio can pick these up automatically as ASP.NET Websites include files automatically (some of the time... it involves a lot of hitting the "Refresh" menu option) and they're compiled dynamically meaning you can change models on Umbraco Cloud (not developing locally) and they'll update dynamically.
However, this means that the *.Core project has no access to any ModelsBuilder models, which makes writing some of my common extension methods difficult. Normally I'd create a SiteSettings() extension method on IPublishedContent to get the settings node but, without access to models, I resorted to a generic method GetSite<Settings>() where Settings is the model for my Settings node.
public static T GetSite<T>(this IPublishedContent page) where T : class, IPublishedContent
{
return page.Root().FirstChild<T>();
}
There are other options here but they all have their own downsides. You can the *.Core project altogether and put all your code in the ~/App_Code folder, but this means you miss out on any compilation ahead of time. You can also set your models to be generated within the *.Core project, but then you won't be able to utilise the ability to develop on the live site (more on that later). A third option may be (I've not yet tested it) to use the Dll or LiveDll ModelsMode (in the full version of ModelsBuilder) and reference the generated DLL in your *.Core project. This allows for development on the live site, but means you'll have to either manually generate models (Dll) or have site restarts every time you change a document type (LiveDll).
As indicated above, a website is mildly annoying to have as opposed to a web application. I've always seen applications as more superior, but the only reason I think this would be is because an application can generate DLLs, while websites can only have C# in the App_Code folder, where it's only compiled on application startup (think of it as the opposite of precompiled views).
And now, lets get onto the Git setup. This is a little weird. If you want to use Visual Studio to build your Umbraco site, the docs suggest you'll need two git repositories (although if you're feeling brave I'm sure you could use one and then use subtree or submodules and mirror to the Cloud repo... but that's a story for another day!): one for the *.Web folder, and one for everything else. The *.Web repo is hosted by Cloud (and is where it deploys from), while you'll need to create your own repo for the rest. Although I'm sure it's unnecessary, I also decided to mirror the Cloud repo because it feels like the right thing to do!
It's not really an issue, just a mild niggle. I'm sure someone more confident with Git than I could find a nicer way to handle this setup, but this one will do for now.
I've heard bad things about it but so far, for me, Umbraco Deploy has just worked. When Umbraco releases Deploy for non-cloud projects, I'm sure I'll have to do a full comparison between Deploy and uSync.Publisher, but for now I'm happy to use Deploy for Cloud and uSync for everything else.
I've always found the Settings area of Umbraco a bit odd, personally I'd rather do all my development within my IDE not partially in the browser. Working in a CI/CD world, I'd also have to disable the Settings section in any environment except locally.
But in Cloud, the Settings section makes so much sense for the simple reason that any changes you make on your Cloud environments and committed to the Git repo automatically. This makes my inner "cowboy coder" very happy. If I need to hotfix a live site, I can! If I want to tweak code from my phone, halfway up a mountain, I can! If I'm too lazy to open up Visual Studio to make a minor change to my personal site, I can!
Cloud is where Umbraco seems most at home, largely because of this.
I assume due to how Umbraco Latch works, domains will need to be configured to point to the Cloud site before an SSL certificate is generated. Unfortunately for existing sites, this means there will be a short moment of downtime while your domain points to a site with an invalid HTTPS certificate. However, in my case, basic authentication was not automatically disabled when I purchased my Cloud license (and by the time I realised it was too late!)
I decided to leave the setup overnight in the hope the problem would resolve itself with time, which it, unfortunately, did not. Support was, however, very helpful and resolved the issue quickly after I notified them of the issue.
Azure Web Apps allow domains to be preconfigured (with DNS text records) prior to mapping the domain, which may mean as Umbraco Cloud moves to Web Apps and uses Cloudflare in place of the existing Latch process for HTTPS, we may see an improvement here.
I don't think it's unfair to say that Umbraco Cloud has a bit of a reputation when it comes to stability... and not a good one. And so far, I'm not helping that reputation, having already detailed an issue I had with my site not coming out of trial mode.
I did also experience a short amount of downtime on Saturday night.
But that's it so far. And support has been great at fixing the issues I have had.
I also had an issue with a bug in Umbraco Forms, which the support team fixed without having to delve into the database myself.
So who is this for? It's a question that's asked again and again. And I wasn't sure until I tried it properly myself.
I think the answer is, Umbraco Cloud is great for me. My use case is that I have a small low-traffic site which I don't want to have to invest huge swathes of time keeping patched and up to date, but I do want to quickly develop and launch new features.
It's not ideal for complex custom setups, or sites requiring "four-nines" of uptime. It might also outprice individuals or small charities. But for those in the middle, it seems to suit quite well. I won't be recommending Cloud to every client, but I think I now know who the target market is, and will recommend to those clients going forwards.
It will be interesting to see how the new planned infrastructure for Cloud will affect this target demographic and whether we'll see a more stable platform going forwards.
As for the relatively high cost vs self-hosting, I think this comes down to the quality and speed of the support team. If you consider the month price as a time-saver, it's easily worth it in my opinion.