Defaulting to the Cloud

Earlier this month I did a session for Reclaim Edtech’s Open Media Ecosystem series on the open source web radio software Azuracast. I also posted about Azuracast’s web hooks that sent notifications to both Twitter and Mastodon when a live broadcast is happening. It’s been an open source media software kinda month for us at Reclaim, so the bava abides.

On the way to documenting changes made to listen.ds106rad.io, I ending up thinking more broadly about how my approach to hosting personal sites has undergone a major shift. I no longer default to cPanel, rather I am pretty much cloud-first all the way!

Screenshot of ds106radio listen page

The listen.ds106rad.io site now hosted on a micro-Apache server on Reclaim Cloud

Until two weeks ago the domain listen.ds106rad.io was pointing to a catch-all cPanel account, and I setup a subdomain for listen.ds106rad.io which hosted the HTML file with the embedded player and an image or two. As I continue to push as many applications from cPanel into Reclaim Cloud as possible,* I wanted to see how easy it would be to spin up an Apache server environment hosting the webpage. It’s probably overkill, but at 1 cloudlet (128MB RAM and 400MHz CPU) it’s also not too crazy.†

Screenshot of Reclaim Cloud interface with with the listen2ds106radio apache server

The listen2ds106radio apache server in Reclaim Cloud

The process was as easy as installing an Apache container, adding the HTML file and images to /var/www/webroot/ROOT opening up port 80 and 443 in the environment firewall and finally getting an SSL certificate (no load balancer necessary). And it worked cleanly, I want to see if I can start playing with virtualhost configuration to figure out how Apache servers manage mapping domains, but this is pretty awesome. It is the early stages of a server to host all my archived HTML sites over the years (there are many now), and if I am trying to go cPanel-less this year so figuring this out will be crucial.

Once I move a site/app into Reclaim Cloud I often find it easier to run DNS through Cloudflare rather than cPanel. I do this not only because I love the Cloudflare interface, but also because it provides everything from proxied SSL certificates to DDoS protection to load balancing to object storage to a global CDN and that’s just a few of the features.‡ In fact, the migration to the Cloud over the last two years has helped me understand that  Cloudflare could stand-in for large swathes of what cPanel does currently.

Screenshot of Cloudflare's DNS interface

Cloudflare’s DNS interface is so beautiful!

In fact, take the case of ds106radio. The main application Azuracast is hosted in a Docker container on Reclaim Cloud; the DNS runs through Cloudflare; the transactional email through Mailgun, and we’re currently setting up S3 storage for hosting backups and  recordings of live broadcasts. The more I play in Reclaim Cloud, the more I begin to understand how the future of Reclaim Hosting could look. While long overdue for my slow brain, it’s still exciting to start finally seeing the outlines of the future.

Reclaim Cloud Add-ons

Reclaim Cloud Add-ons can be thought of as packages of functionality from cPanel on an app-by-app basis

The various pieces, i.e.server (Reclaim Cloud), DNS (Cloudflare), email (Mailgun), and storage (S3), are currently distributed across various services given each does their own bit best—what’s more rather than the kitchen sink approach of cPanel, you can have addons for specific features that you can choose to activate (and pay for) on any givenenvironment as needed. So also should have the ability to manage email, DNS, or storage settings as Addons for any given server environment in Reclaim Cloud, and then go one step further and integrate them to make it possible to select which tool you will use for DNS management, storage, transactional email, etc. (this could also be cPanel, but no longer assumed and defaulted to).

So, for example, you want to install Azuracast on Reclaim Cloud, and then manage the DNS through a Cloudflare addon. After that you can setup email through a Mailgun addon, and then choose whatever S3 provider you use to integrate storage—that’s another addon. All of these pieces are managed using Addons, and keeping them linked to a specific environment helps you remember what service you used for which server/application.

I think a hosting company at this moment—not unlike an edtech—needs to be thinking through how to integrate the best of breed cloud tools into a simple, elegant interface using APIs that will essentially stitch together a next-generation hosting interface. And for the next-gen apps this goes beyond just a one-click installer for the application, it also has to make sure DNS, email, and storage all work. And this is where the one-click Ghost installer Taylor Jadin built really helped me see it all in one place tied to the Reclaim Cloud environment. It is a blueprint for making these traditionally difficult-to-install next-gen Cloud apps far more accessible, and the addons at the environment level is where you can naturally integrate all the other pieces traditionally offloaded to cPanel, DNS, Email, version updates, and storage quotas to name just a few.

Screenshot of addons in Reclaim Cloud

Addons for a Ghost 1-click isntaller in Reclaim Cloud that helps you manage Mailgun, DOmain configuration, and an easy container update.

We have talked about this at length with the idea of Domains 2.0 and trying to abstract out the hosting process to try and understand what people need rather than defaulting to registering a domain and then immediately driving folks into cPanel. What if the interface  was more contextual (tied together by APIs from other services) that can communicate with your DNS records, have bucket keys for storing files, and see what mail records exist for a given domain. I understand that what I am saying here and what Taylor has done for Ghost is not the same thing, but for me it represents a path forward to explore what Domains 2.0 might look like if Reclaim Cloud were the default, not cPanel.

I think the other piece worth discussing at length, and I will save it for my next post, is how this shift to the cloud effects hosting costs. It has been my experience that this approach can get expensive quickly, but the other side of that is that process becomes that much better and what’s possible that much greater that it seems worth it, at least for me given my day job.

Image of a white board with the early blueproint for DOmains API

White board with the early blueprint for a container-driven Domains API

All of which reminds me of when Tim and I met Kin and Audrey at Emory University in 2014 or so. We were chatting at the hotel, and Kin recounted his early server admin days when he discovered AWS (and soon after understood the power of the API) and the hook was that it is scalable infrastructure that you would only pay for what you use. But as he noted, it was so flexible and so much was possible in terms of replication, increased uptime, and generally tinkering with how the next generation of server infrastructure works that it ended up costing more, but everyone was happy because there was no downtime, while more and more infrastructure could be automated and managed remotely. In 2014 I was just trying to wrap my head around something Kin had been working on for years, and as always he was graceful and generous with everything he knew. In fact, later that year Tim and I asked Kin to help us map out the long road towards a container-driven hosting service managed using APIs, and I think that vision is aging well, and with Reclaim Cloud as robust as ever I know one thing I’ll be thinking a lot about in 2023: defaulting to the Cloud!

_______________________________________

* It’s been two years since I moved the bava.blog and the main ds106.us sites to Reclaim Cloud, and the experience has been great in terms of performance and management.

† Especially once I figure out how to automate virtual hosts so I can map domains and host numerous flat HTML sites from this one server, or basically reproduce the tilde space approach for my archived sites.

‡In many ways Cloudflare represents various pieces of the hosting panel for the next-generation of web applications, and it would be smart to figure out how to integrate, rather than try and reproduce, their features through Reclaim Cloud. An integration between Virtuozzo and Cloudflare for Reclaim Cloud driven by a series of API calls that would allow folks to use it seamlessly with Reclaim Cloud would be a worthy goal. I have much more to say about Cloudflare in the coming posts and beyond, but suffice it to say in this long footnote that there will be a day as soon as next year where all my web properties will be hosted in Reclaim Cloud with the DNS managed in Cloudflare and the email running through Mailgun.

This entry was posted in docker, ds106radio, reclaim, Reclaim Cloud and tagged , , , , , , . Bookmark the permalink.

2 Responses to Defaulting to the Cloud

  1. Alan Levine says:

    I’d like to make 2023 a year I pick up on his trail and start some clouding with y’all. But need to pick a start point.

Leave a Reply to Jim Groom Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.