



























Hi everybody - a few weeks ago, I did something that most web developers dread. I changed web hosting providers on a live site! 😇
A few weeks ago, I did something that I never thought I would do in a million years. I deleted my Media Temple account and site settings:
For some background, the KIRUPA.com site has been hosted on Media Temple since 1999. They were one of the site’s earliest supporters and have hosted the site ever since. This is despite me not making their life easy. They worked with me through numerous scaling issues, sophisticated hacking attempts, technical quirks, and more with a smile on their digital faces.
I wasn’t the only one who loved Media Temple. Many developers and companies relied on them, and their success drew the attention of GoDaddy, who bought them in 2013. After a very long time of there being no changes (huge 👍 to GoDaddy for this!), over the last few months, GoDaddy started migrating all Media Temple accounts to their equivalent GoDaddy plans. Because KIRUPA.com was running on a custom server, the migration would have been a pain.
To avoid a tricky migration and the very likely downtime, I decided to proactively move the site’s contents to a new server I provisioned on GoDaddy. This meant backing up all of the files, closing my Media Temple account, deleting all of the site settings from it, and re-creating everything on a new server. What I found interesting through this whole process is how much the role of a web host has changed.
Back in the day, our choice of web hosting provider mattered a lot. How fast were they at serving content? Did they use SSDs? How much RAM did they provide? What version of PHP do they support? Were you going to have just one server or a bunch of servers co-located in other parts of the world?
The decisions you and I needed to make were quite large with real consequences, similar to what is shown below in this xkcd comic:
A large part of the reason is that our web servers did a lot of work. A LOT OF WORK. They not only served our HTML content, but they also managed our database, were a mail server (including newsletter-scale I/O), were responsible for optimizing our content, and did a lot of other related tasks. The more powerful your server, the faster it could handle all of these tasks. At that time, unless you were a really large company, there were few feasible alternatives.
To get an idea of what web hosts emphasized as selling points, below is a screenshot of Media Temple’s site from 2010:
Those of you who lived through these times can relate. Many of you who entered the industry in the last ten years are probably puzzled by half of the things being talked about here.
The reason for this can be partly explained by the following: With the rise of serverless and microservices, we no longer depended on a single server to handle everything for us. Need a database? Use something like Firebase. Want a mail server? Use Mailgun to send a blast to thousands of people or something like Google Workspace for your (and your team’s) communication needs. Need to run some code on the server or provision a backend API? You have a bunch of options like AWS Lambda, Firebase, Cloud Run, or Azure Functions. Need a scalable backend to run virtually anything? Use DigitalOcean. Want to ensure your static content reaches everyone worldwide at lightning fast speed? Use a CDN like Cloudflare. Yes, there is an added cost in wrangling all of these services, but the rise in interoperability between all of these various services did even things out in the long-run.
For the majority of us, the do-everything-for-you monolithic web server is a relic of a bygone era. So what did I end up doing for KIRUPA.com? What did I replace the powerful Media Temple VPS server(s) that powered this site for decades with? I picked a single low-cost GoDaddy Shared Hosting server.
Over the years, I slowly shifted the many activities my Media Temple server does to the many services I called out earlier. All the server was really doing was serving static web content with the occasional PHP processing. The only strict requirement I had was that the server needed to handle Apache Server-Side Includes (SSI), a decision that highlights the age of this site when this was the best templating solution available! If there is interest, I may write about my current build process (🤦♂️) - just comment below or reply to this e-mail! 🙃
I hope you enjoyed this behind-the-scenes look at a task that I had to do a few weeks ago. You can follow along and participate in my Tweet on this topic that I posted a while ago or discuss on the forums.
Before I leave, I do want to say a huge Thank You again to Media Temple for everything. Those were good times.
Cheers,
Kirupa 😀
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。