How Do Web Apps Like Medium Work? (Part 3)
And what can they teach us about the world?
The global cloud computing market was valued at USD 483.98 billion in 2022 and is expected to expand at a compound annual growth rate (CAGR) of 14.1% from 2023 to 2030.¹
What is the sound of one cloud computing? Whatever it is, it’s loud!
There are many public clouds. Growth is explosive.
Cloud computing this. Cloud computing that. What the hell is cloud computing?
Most large web applications live in the cloud. As we explain the operation of web apps, we’ll refer to the cloud frequently, and you’ll learn about clouds.
This series
This series is written for people who don’t know much about software, but are curious how it works.
Part 1 explained how people organize to build web applications.
Part 2 focused on the process of writing web application software.
In Part 3, we’ll look at how web applications operate in production.
BONUS: As we learn about web applications, we’ll learn some interesting things that generalize to the world around us.
About “the cloud”
The concept of cloud computing is simple. Prior to the cloud, computing resources lived in a data center. That’s a centralized location for web servers and related devices owned and operated by an enterprise.
Consider the Facebook application. Back in 2006, it still lived in a data center, where the company managed 10 million users.
According to VP of Technology Jeff Rothschild, “We cleaned out all of the Walgreens in the area to blast cool air at the equipment and prevent the Web site from going down.”
Soon after, Facebook moved much of its computing to the cloud. A cloud is a set of data centers owned and operated by a third party. Like Amazon, which built the first cloud at scale. Facebook runs much of its software on cloud servers, but the cloud provider runs the data center. A cloud provider doesn't need to run out and buy fans. It knows how to run a data center at scale.
What are the implications of public clouds?
- A cloud provider owns and services all of the hardware, as well as the operating system software.
- The client — like Facebook — owns loading and operating its applications on the hardware.
- Clients share the pool of computing devices. This has enormous ramifications. Since resources are shared, and usage peaks average out over across clients over time, each client can scale up or scale down its use of computing power as needed. The cloud provider don’t need to maintain enough computing power to service all of the client’s maximum needs, since these will average out. The client gets to use resources more efficiently by adding to and subtracting from a common pool as needed.
- The cloud provider provides value-added services which clients can use without reinventing the wheel. Let’s say a cloud client has users who authenticate upon connection. The cloud client could use the Cognito service provided by AWS for user authentication. Thousands of cloud clients will use each of these value-added services, which can be shared across common infrastructure. The cloud provider can offer these services more cheaply than it would cost each client to maintain their own infrastructure.
How does software architecture influence operations?
Software architecture is like building architecture. It’s a blueprint.
Two common web app architecture paradigms are monolithic and microservices.³
- A monolithic application is built as a single unit. The main components are 1) a client-side user interface aka the front end, and 2) the back end which serves up the front end software you see in your browser, handles requests for information from the front end, handles business logic, and talks to the 3) databases. What you end up with after all the software building magic happens is a single indivisible chunk of software loaded into cloud devices. To make even a single change to the system, you have to build and deploy the whole enchilada.
- A microservice application consists of a set of loosely coupled services that interact with one another. For example, a social media application might have a user authentication service, a marketplace service, and an administration service.⁴ They’re independent software units that cooperate with each other to enable people to use web apps.
A microservice is a beautiful thing. It can be rebuilt and reloaded independently of the rest of the codebase. Microservices are way more flexible than monolith in development and production. The downside? Without effective communication between teams, changes to Service X can screw up Service Y. It’s a small price to pay for flexibility.
The way application software is packaged, loaded, and managed in production depends on the architecture. This article will assume a microservices architecture, since that’s where the industry is going.
Takeaway 1: In a simple system, there may be no reason to break things into parts. Take a baseball bat. It’s a single piece of wood. It doesn’t need assembly. It’s simple. It works. Not so in software. While there are some disadvantages to a multiservice architecture, on the whole it’s a clear win because dividing the software into parts allows for much greater flexibility. This is true for the entire process of the web app, from development through deployment and monitoring.
Consider shoes. What wears out first? The insoles and heel soles. Typically, you have to toss a shoe when these wear out. That’s a waste. Why not make these parts modular? Some manufactures do offer replaceable insoles and heel soles. It likely costs more to make these modular, but it’s far more efficient over an extended period. We don’t buy shoes like this because we don’t care about shoe efficiency.
We’re not done coding yet!
Part 2 of this series dove deeply into the world of software development. But there’s a whole category of developers we didn’t discuss — DevOps engineers.
DevOps stands for Development Operations. DevOps engineers bring the discipline of coding and the efficiency of automation to operating the web application as opposed to developing it.
Some companies use Developers to fill the DevOps role.
Prior to DevOps team, web applications were often run by Operations teams that did their work manually. For a time — thankfully a short time — I worked at a company that ran Operation this way. It wasn’t pretty. Operations staffers worked hard but they were overwhelmed by the enormity of the task. I don’t think they grasped there was a better way, though we developers tried to convince them.
In Part 2, we talked about tools developers. DevOps are tools developers. But they don’t build tools to help programmers write code. They build tools to efficiently run web applications in production.
Running a robust web application at scale is an enormously tricky venture. Consider the recent fiasco in Twitter Spaces when Ron DeSantis announced his candidacy. Whatever caused that meltdown was entirely avoidable. Anticipating problem scenarios, automating their detection, and automating responses is the DevOps mission.
Cloud providers offer manual tools for managing cloud deployments. Here’s what one such AWS tool looks like.
Lots of information, but you’re not going to run a service Ebay by looking at a screen like that.
Cloud Redundancy
A key cloud feature is redundancy. Most public clouds provide several levels of redundancy. Let’s look at three of the ways AWS is redundant (there are too many to list all of them).
- AWS has data centers in 23 regions globally. A web app can be hosted in multiple regions.
- Each region has multiple availability zones (AZs). An AZ is a discrete data center within a region that has no dependency on other AZs.
- Typically, a web app would be deployed across many computer instances. When a computer fails, a replacement is automatically brought online.
How does software get deployed?
After Product Development declares software “ready,” it gets loaded into the cloud by proprietary or cloud-provided tools. A cloud consists of millions of computers in regions across the world. These are not the sort of computers people use, with a monitor and mouse. They’re highly dense and efficient computers that are typically accessed via software tools. DevOps personnel use tools to upgrade software versions on these computers, often called instances.
Remember the software architectures described above? They have a huge impact on deployment. A microservice architecture enables flexible deployment. The DevOps team can upgrade any service independent of all of the other services. With a monolithic architecture, you have to upgrade all of the software in one shot. That introduces significant risk.
Databases do have associated code and can be updated, but that’s much less common than updating the back end software. Remember — the back end contains the front end software and serves it to your computer when you connect.
Monitoring the web app in production
It’s impossible to get into detail about monitoring without getting very technical. When you deploy a complex system like a web app, there are dozens, if not hundreds, of metrics you need to review constantly to ensure the web app performs effectively.
Consider just one service. If that service is critical to the web app and gets over-subscribed, it could render the entire web app unusable. You need to continually monitor key metrics that relate to the service, to ensure they remain within expected boundaries. Multiply this by all of the web app services, and it’s an enormous job.
In a competent web app, this is all automated. Typically, when key metric boundaries are violated, this will automatically trigger a page to a developer.
Knowledge
Because complex web apps at scale are so complex, there is a critical mass of accumulated knowledge required to keep the web app running. If that knowledge exits the company in a non-linear fashion, the web app’s low failure rate is jeopardized.
Consider this report about Twitter by CNN⁵.
The situation only seems to be getting worse as Musk continues cutting staff. On Monday, Twitter suffered its third service disruption in less than a month and, according to Internet watchdog NetBlocks, its sixth major outage in 2023, compared to nine tracked throughout all of 2022.
This was reported on March 12th. That puts Twitter on pace to suffer roughly 25 service disruptions in 2023, a 400+% increase over 2022.
One thing you can say about Ron DeSantis, regardless of your political bias. He knows zero about web apps. If he had any clue, he would not have entrusted the launch of his presidential campaign to an incompetent leader like Elon Musk. Musk knows how to build an electric vehicles. He has no clue how to run a web app at scale.
Takeaway 2: Musk’s approach to cutting costs at Twitter has a 100% chance of degrading the service. Maybe he cares about that, and maybe he doesn't. Complex systems require a critical mass of knowledge to operate effectivety. There is no way around this. You wouldn't fire 75% of the employees at a nuclear power plant and expect to avoid disaster. Twitter is no different. Twitter’s degraded service is entirely predictable to anyone who understands web apps.
Conclusion
In this three-part series, we looked at the following:
- How people organize to build web applications.
- The process of writing web application software.
- How web applications operate in production.
There is only so much you can cover in 6,000 words. There are all kinds of things I didn’t mention to limit the sheer word count. If you have any questions, please comment!
¹ Grand View Research ² GMO Cloud ³ MuleSoft ⁴ Typically, services are much more granular than in this example. ⁵ CNN.
