A program that runs perfectly well on my computer can be treated as dangerous on someone else's. Not because the code is broken or contains anything malicious, but simply because nobody can verify who made it. How does an operating system…
I used to work at a company that built on-premises software in Rust. “On-premises” means installing and running software in a self-managed server environment that the customer controls directly, rather than in a cloud provider’s environment. It was at that company that I first saw a dedicated server room inside an office. Until then, a server had been an abstract thing to me, something that existed only on my monitor as an IP address or a login. I already knew, in my head, that beneath all software, however abstract, there is a physical computer. But it was in that server room, I think, that the fact finally became real to me, seen with my own eyes. These days I’m working as an on-site freelancer, moving a service that was delivered from the cloud onto a local, on-premises setup. Things that used to take a few clicks in the cloud console now have to be put together one by one, and the physical layer I had always waved off with a “surely it’s there somewhere” is rising back into view. Beneath the Cloud, There Is a Building In 2006, Amazon launched S3 for storage and EC2 for virtual servers, and the “cloud” services we use so casually today began to spread in earnest. Hosting services that let you rent servers existed before that, but the model of provisioning servers and storage through code, when you need them, and paying only for what you use took off from this point. You no longer had to buy hardware, find a place to put it, and run a connection to it. With an account and a payment method, getting a server became far easier. The origin of the name “cloud” is also interesting. From what I’ve read, it comes from an old convention in network diagrams, where a part of the network whose inner workings didn’t need to be drawn out, such as the internet, was sketched as a cloud. The cloud was never a sign that nothing was there. It meant: you don’t need to look inside here. But just because something has been erased from the diagram doesn’t mean the physical things that make it possible have disappeared. The cloud is, in the end, renting servers that sit in someone else’s data center. Whether you’re on-premises or in the cloud, a server physically sits somewhere. What differs is whose building it is, who pays the electric bill and deals with the failed disk, and how you secure more resources and scale up when you need them. What Became Visible Again When I Moved From the Cloud to On-Premises What struck me most about this work was the difference in what you are directly responsible for. Cloud providers describe this relationship with something called the shared responsibility model: the provider manages the building, the power, and the hardware, while the operating system, applications, data, and configuration on top are split between provider and customer depending on which service you use. Moving on-premises, a large share of that responsibility comes back inside the organization. Someone has to replace the disks, take the backups, manage the network equipment, and apply the security patches. The part that hits hardest in a migration is managed services. In the cloud, it’s common to consume databases, object storage, message queues, load balancers, and authentication as services. When you move on-premises, you have to decide anew how to keep providing what those services used to do. You might replace them with open-source software you install yourself or with commercial products, or you might change the architecture to merge some functions or drop them altogether. You only see how much was sitting behind a single checkbox once the checkbox is gone. The more deeply a system leans on one provider’s proprietary services, the harder it is to move, and that is the point where the phrase “vendor lock-in” stops being abstract. Whichever way you go, you need space for the servers, electricity, cooling, and a network. The cloud isn’t a technology that removes that burden so much as a service that hands it to someone else and makes it invisible. So where does that responsibility end up in the cloud? What Does a Data Center Actually Do? The time I heard the words “data center” most loudly in the news, as I remember it, was in October 2022, when a fire at a data center in Pangyo, near Seoul, took Kakao’s services offline for a long time. It wasn’t only KakaoTalk, the messaging app that much of South Korea uses every day. Taxi hailing and payments went down at the same moment, and it made plain how many seemingly separate services had been depending on one building all along. Looking into it again, I found that the fire reportedly started in the batteries, and that afterward the question of whether the company had enough redundancy and recovery systems in place became an issue too, not just the fire itself. A data center is a building that gathers servers, meaning computers, in shelf-like frames called racks, stacked layer upon layer, and provides everything needed to keep those machines running around the clock. First, there is electricity. Layers of backup keep the servers up if the grid fails: uninterruptible power supplies (UPS) and batteries, then backup generators to take over after them. Much of the power a server consumes ends up as heat, so the cooling equipment that carries that heat away needs a great deal of power as well. Telecom lines come in along multiple routes, and there are fire suppression systems, access controls, and security guards. To keep things running reliably, power, cooling, and network connections are often made redundant, designed so that if one piece of equipment fails, another picks up its role immediately. Cloud providers operate physically separate availability zones to limit the impact of failures. An availability zone consists of one or more data centers, and if you design a service to be spread across several availability zones, you are more likely to be able to keep it running even when one facility goes down. The server room I first saw at that company was a very small version of a data center. It’s a rare experience at a startup, but plenty of places that need to keep their data inside their own buildings, such as banks, hospitals, factories, and public agencies, build and run their own server rooms, even if they are nowhere near data-center scale. At the other end, the large data centers run by cloud providers hold thousands or tens of thousands of servers, and I’ve read that the biggest campuses are planned to draw as much power as a city. The scale differs, but what’s needed is the same: machines, electricity coming in, heat going out and being cooled, and lines to connect to the outside. A cloud price list ultimately includes the cost of keeping all of this running day and night. The Smallest Server Room Is on My Desk If a data center is the biggest home a server can have, the smallest one is on my desk. Developers often talk about spinning up a server locally. To spin up a server here means to run a program that receives requests, processes them, and sends back responses (serving), and “local” means that program is running on the computer in front of me. The moment I run a server program, my computer’s CPU, memory, disk, and electricity are used just as they are. Opening localhost in a browser isn’t a trip out to somewhere on the internet. It’s my computer talking to itself, which is why that address is called the loopback address. If I shut down my laptop, the server stops with it. Unlike a data center, which is built to run around the clock, my laptop was never meant to play that role. Seen this way, a development server running locally, an on-premises server run by an organization, and a server running in the cloud all work on the same principle: a program that receives and handles requests is running on a computer somewhere. What differs is where that computer is, who manages it, and how it connects to the outside world. Moving a service from the cloud to on-premises is, in the end, bringing a program that ran on a cloud provider’s infrastructure into a server environment the organization controls. The scale and the way it’s operated differ, but running a server program on a computer is the same principle as spinning up a local server on a laptop. And yet, even having come down this far, the word “server” still remains something of a black box. Beneath the 0s and 1s Are Electricity and Light Going one level deeper into the server, the CPU holds billions of transistors, and a transistor is a tiny switch operated by electricity. People often explain 0 and 1 as electricity being connected or cut off, but what a computer actually handles are two electrical states that a circuit can tell apart, such as a high voltage and a low voltage. Memory works the same way. The main memory, DRAM, stores information as charge held in tiny capacitors. Because the charge leaks away little by little, it has to be refreshed periodically even while the power is on, and when the power is cut, the information is lost. SSDs rely on the electrical properties of charge stored in flash memory cells, and hard drives record data using the magnetic state of a magnetic material. Even information that looks formless on a screen, like a line of chat or a single photo, always exists inside a server as the state of some physical material. Then there is “wireless internet.” The term is so widespread that it’s easy to assume the internet really is wireless, but Wi-Fi only connects your device to the router. Behind the router, in a typical home with a wired connection, an Ethernet cable runs to the building’s telecom room, and from there fiber-optic cable runs through the ground. In fiber-optic cable, data is carried not by electrical signals but by changes in light, and that light is converted back into an electrical signal at the destination equipment. In the end, the road out to the rest of the world is also a matter of sending electrical and optical signals along a wire. Communication between continents is mostly carried by submarine cables laid on the seabed. You might expect satellites to link the continents, but from what I’ve read, the overwhelming majority of international data traffic passes through submarine fiber-optic cables, and there are landing stations on the Korean Peninsula where those cables come ashore. Whenever I remember that a single line of text has to travel along cables on the ocean floor to cross the sea, I think about how many physical facts the word “internet” covers up. Closing Thoughts Moving a service from the cloud to on-premises means facing, one by one, these layers that used to be out of sight. Setting up by hand what used to take a few clicks in a console shows me how much equipment and how many people it takes for even a single app to open. Whatever architecture I choose from here on, I plan to start by checking which building, which machines, and whose electricity a service is running on. These days, a single message on my screen no longer feels entirely weightless. Behind that one line are the building where the server sits, cooling units that run through the night, charge inside chips, and optical fibers beneath the sea, along with the facilities and people who make and supply the electricity. Perhaps one of the greatest things the cloud has done is let us stop thinking about all of this every time. But what has become invisible has not gone away.
When you set out to build a new blog, WordPress is the first tool people mention, and also the first one they call outdated. Still the Most Common Tool Around According to W3Techs's October 2026 survey, WordPress runs on about 40% of the websites it tracks. Among sites whose content management system (CMS) can be identified, the share rises to about 59%. For software that launched in 2003 to hold that kind of share twenty years later is remarkable in its own right. Popular tools come with the advantages of being popular, and as a developer I sometimes feel that an ecosystem this large is a feature in itself. When you hit a problem and search for it, someone has usually hit it before you and written up a fix. Nearly every hosting provider supports installing it. Plenty of people build themes and plugins, so you can pull in the functionality you need instead of building it from scratch. Those things add up and shape how usable a tool really is. Of course, popularity isn't proof of quality, and being widely used doesn't automatically make a tool good. So I'm going to narrow the scope to a single use case, blogging, and look at what WordPress offers compared with other blogging platforms and website-building frameworks. (Online stores and large media sites can wait for another day.) Born as a Blogging Tool WordPress began in 2003 as a fork of b2/cafelog, an existing blogging program, created by Matt Mullenweg and Mike Little. The fact that it was built for blogging from day one is a useful clue to how it works today. Posts and pages are separate things. Posts carry categories and tags. The newest entries stack at the top by default, every post gets its own permanent URL (a permalink), and RSS feeds and comments are built in. (Comments can be switched on or off in the settings.) A general-purpose site builder with a blog menu bolted on and a tool designed around writing from the start can share the same feature list and still feel completely different to use. As your archive grows to dozens or hundreds of posts, the value of that basic structure only becomes clearer. WordPress is used for plenty of non-blog projects now, but at its core it is still built around the post. In December 2018, WordPress 5.0 made Gutenberg, a block editor, the default. Paragraphs, headings, images, quotes, code, tables, and embeds are each a block; you can drag blocks to reorder them and save layouts you use often as patterns. Gutenberg drew plenty of complaints when it first arrived, but after several rounds of improvement, writing and laying out a post feels much more natural today. It still isn't the simplest editor for everyone. If you're used to writing in Markdown, a block editor can feel clunky. WordPress's real strength isn't the editor alone. It's that writing, placing images and tables, polishing a draft, and scheduling it for publication all happen in one environment. A blog doesn't need one pair of hands for writing and another for running the site, and I think that matters more than it sounds. Auto-save, revision history, and automatic image resizing come built in too. Depending on your server and network, not every piece of work is guaranteed to be preserved, but these features take a lot of everyday worry out of writing. Block editing and scheduled publishing aren't unique to WordPress, and plenty of other tools can do them just as well. What matters is that you don't have to build any of it yourself: it works from the moment you install it. Put simply, it's closer to installing a tool so you can write than to starting a development project so you can have a blog. You Decide Where Your Writing Lives WordPress is open-source software released under the GPL. WordPress.org is the project site where you download it, and installing and running it yourself is what people call self-hosting. The same software, run for you by Automattic, is offered under a separate name, WordPress.com. (The official Learn WordPress lesson explains the difference.) When you self-host, you choose the hosting provider, the domain, and how your data is managed, and you can access, back up, and export your posts, images, and database directly. That is what I mean by deciding where your writing lives. Platform-run services like Tistory and Naver Blog, the two big blogging platforms in Korea, have a real advantage in convenience: you don't need any development knowledge to use them. But when policies change or the service starts to wobble, the home of your writing can wobble with it. If you plan to keep a blog going for years, this is the difference that weighs the most. Services do shut down, and it has happened in Korea too. Egloos, a blogging service that launched in 2003, closed on June 16, 2023. Its users had to back up their posts and data and find a new home within a set period; as far as I can tell, they were given roughly six months of backup access after the closure. A WordPress site on your own domain can keep its existing post URLs even if you change hosting providers. If you manage your URL structure and search-engine settings carefully during the move, links from other sites keep working. (That said, search rankings aren't guaranteed. Response time, crawl settings, canonical URLs, and internal links can all change during a server move, and your search results can shift with them.) Since services like Tistory let you connect a custom domain too, the point isn't simply whether you can use your own domain. It's whether you can decide what software runs at that address and how your data is managed. If you want your posts to open at the same address ten years from now, who owns that address matters more than you might think. Of course, having direct control of your data doesn't mean you can move it to another system whenever you like. Control, meaning the ability to access, back up, and edit your data, and portability, meaning how easily you can actually move when you want to switch tools, are separate matters. If a plugin stores its data in its own database tables, or a page builder saves content in a proprietary format, you can end up locked in even within WordPress. WordPress is strong on the first; the second depends on which themes and plugins you choose. Still, the fact that the site owner has the power to back up and attempt a migration is an important difference. Naver Blog does have things WordPress can't match. Readers find you through Naver's neighbor connections and search, you don't have to think about servers or security, and you can sign up and start writing right away. But that convenience comes at the price of some autonomy over your address and your data. If you plan to run a blog for a long time, and especially if you want to build a personal brand or expertise on the writing you accumulate, I think that tradeoff deserves serious weight. Growing Only as Much as You Need The official plugin directory alone lists tens of thousands of plugins. There's Yoast SEO and Rank Math for search optimization, caching plugins for speed, and plugins for backups, security, image compression, multilingual sites, and newsletter integration. Most of the features you'd want have already been built by someone. When you switch themes, your posts and pages stay in place, so design and content are fairly independent of each other. Of course, menu positions, widgets, templates, theme-specific shortcodes, and anything built with a page builder don't carry over automatically, so the longer you've customized a site, the more a theme change costs. Since WordPress 5.9 in 2022, if you use a block theme, the Site Editor lets you change headers, footers, and page templates without writing any code. Developers can extend things with child themes and hooks while still building on the existing structure. The middle ground between tools where you build everything yourself and tools where you stay inside a fixed template is, to me, the most practical thing about WordPress. RSS feeds come built in, so readers can subscribe with a feed reader, and you can change the permalink structure to put a readable slug in your post URLs. Since WordPress 5.5, XML sitemaps are provided by core, so you don't strictly need an SEO plugin to generate one. Plugins like Yoast SEO and Rank Math come in when you want to set a meta description for each post and manage what you tell search engines in finer detail. None of this guarantees search traffic, of course. A rich set of SEO features isn't the same as a site that is well optimized by default, either: a badly built theme, an overgrown set of category and tag pages, duplicate content, and slow plugins can all hurt your visibility. Still, there are plenty of themes and tools that output HTML search engines can read easily, and that's a real advantage. Social platforms change their algorithms and reach swings up and down with them. Against that backdrop, I expect it to matter more and more to have a built-in subscription channel like RSS that doesn't depend on any platform's recommendation algorithm, and a structure you can extend with an email newsletter when you need one. Other platforms handle extensibility differently. As far as I know, Tistory lets you edit a skin's HTML and CSS, which is quite flexible, but you can't touch server-side code or the database, and Naver Blog restricts external scripts and keeps ad revenue inside Naver's own ad service. Because you choose the server environment with WordPress, you can add a newsletter signup form, members-only posts, custom post types that group different kinds of content such as serials or book reviews, structured data for search engines, and 301 redirects that point old URLs to new ones, all through plugins or code. Whether to run ads, charge for subscriptions, or leave the page clean is also up to the person running the blog. When a Blog Becomes More Than a Blog You don't need many of these features to start a blog. Most of what I've described above becomes necessary only once the blog grows, for instance when a personal blog turns into a publication or content service that several people write for. WordPress ships with five user roles (Administrator, Editor, Author, Contributor, and Subscriber), so a workflow in which a contributor writes a post and an editor reviews it before publishing works with the default permissions alone. A full editorial workflow, with review requests, stage-by-stage notifications, and an approval history, doesn't come built in, though, and needs a plugin or a separate tool. The REST API got its foundation in version 4.4, and version 4.7 brought content endpoints for posts, comments, and users into core. That makes a headless setup possible: WordPress as the back end for managing posts, with a front end built in a framework like Next.js. What Does "Old" Really Mean? There are reasons people call WordPress outdated. It has an old architecture built around PHP and a relational database. Its ecosystem is one in which countless plugins each extend functionality in their own way. The admin screen carries traces of different eras, and settings look different from one plugin to the next. Next to tools designed from the start for a modern development environment, parts of WordPress do feel clunky. "Old" describes time; "outdated" is a judgment about present usefulness. The two don't have to mean the same thing. Using PHP or a relational database is not, in itself, evidence of obsolete technology. The real question is when an old structure becomes technical debt and when it's a stable asset. Thanks to long-maintained backward compatibility, posts written years ago still open today, and you can still search up solutions that have piled up over the years. The age of old software is both technical debt and an asset. The flip side of being usable for a long time is having to keep managing old decisions. A plugin you installed years ago stops getting updates. Past customizations keep you from upgrading PHP. You want to replace a plugin, but your existing posts are tied to its format and can't easily be cleaned up. Using old software means getting backward compatibility as an asset while also accepting responsibility for maintaining it. Whether that asset is worth the present inconvenience depends, I think, on how you run your blog. Maintenance Comes With the Territory Of course, a self-hosted WordPress site comes with maintenance. If you put off updates to core, themes, and plugins, vulnerabilities open up, and plugin vulnerabilities are often cited as a major route for security breaches. You also have to deal with backups, caching, HTTPS, and hosting costs, and as you add plugins one by one, the site can get heavier or start to conflict with itself. That WordPress is free software doesn't mean running a blog is free. Count the domain and hosting fees, the subscriptions for paid themes and plugins, the time you spend on updates and backups, and the responsibility for fixing problems yourself, and the real cost ends up well above the monthly hosting bill. Choosing managed hosting or keeping only the plugins you truly need eases the burden considerably, but the time that choice takes is also part of what it costs to use WordPress, and the responsibility that comes with it falls on the site's owner. If you publish only occasionally and don't need an admin screen, building a static site with something like Hugo, Jekyll, or Astro can reduce your operating burden, since serving only static files leaves less dynamic runtime to manage on a public server. That doesn't make security concerns disappear, though. Build tool dependencies, deployment accounts, external services, and automated deployment pipelines still need protecting. So Who Is WordPress Right For? In the end, what most people want to know is less whether WordPress is a good tool than whether it suits their situation. If you want to connect with Korean readers without fiddling with settings, Naver Blog is the quickest route. If you want to publish easily without running a server, a hosted service like Tistory is comfortable. If you want to run a blog for the long haul with your own domain and content structure, self-hosted WordPress fits. If you're comfortable with development and want a fast, simple, writing-focused site, a static site generator such as Hugo or Astro is the better match. And if you plan to grow from writing into a membership site or a broader content service, WordPress or another extensible CMS is a candidate. Whichever you choose, I think the deciding factor isn't what's fashionable but how long you'll run this blog and how far you intend to grow it. WordPress remains a reasonable choice when the blog is one you'll keep running for years, under your own address, and grow as you need. The Best Tools Stay Behind the Writing The reason WordPress is still worth recommending isn't that it's old yet somehow still good. It's that what has accumulated over its long life is still useful. An old structure becomes a burden when you have to respond to new requirements or untangle past dependencies, but it becomes an asset when you keep drawing on the posts you've accumulated, the working habits you know, and a rich set of extensions. Static sites, platform blogs, and headless setups each have their place. Among them, WordPress remains an option you can start as a blog, expand when you need to, and keep running for a long time. What matters in the end is less which tool is newest and most convenient right now than which structure you entrust the coming years of accumulating posts to. For a tool meant for blogging, I think the most important quality is that it can endure that time. Sources W3Techs, WordPress usage statistics WordPress Learn, the difference between WordPress.org and WordPress.com Make WordPress Core, XML sitemaps in WordPress 5.5 WordPress.org documentation, the Site Editor (requires a block theme) WordPress Developer Resources, REST API Handbook News1, report on the Egloos shutdown (in Korean) WebSight Design, the WordPress and WP Engine dispute (2026-06-30)
A frontend developer on the factory floor discovers that React’s original question, how to keep a screen in sync with constantly changing state, fits device screens better than it fits web documents.
A longtime React developer’s notes on how React became the web’s default, what that cost in complexity, and what WordPress and PHP taught about choosing tools to fit the problem.