Improve Durable Objects into by saying what it does.

There is a lot of debate about how best to present DOs so that people "get it".

Engineers (like me) usually want to know what a product *does*. This is contrary to the common wisdom that product pages should say what problems a product *solves*. Figuring out how to use a tool to solve a problem is an engineer's job, so as long as they know what it does, they can figure out what it solves. Conversely, if you only tell them what it solves, they then cannot visualize *how* it solves the problem, which is their job, so they get frustrated.

To that end, we should very briefly explain what a Durable Object *does* right on the landing page.

Author: kentonv

src/content/docs/durable-objects/index.mdx

@@ -23,6 +23,15 @@ Durable Objects provide a powerful compute API for coordinating multiple clients
 
 Use Durable Objects to build collaborative editing tools, interactive chat, multiplayer games and applications that need coordination among multiple clients, without requiring you to build serialization and coordination primitives on your own.
 
+### What is a Durable Object?
+
+A Durable Object is a special kind of [Worker](/workers/). Like Workers, it is automatically provisioned, it starts up quickly when needed, and shuts down when idle, and you can have millions of them around the world. However, unlike regular Workers:
+
+* Each object has a **globally-unique name**, allowing you to send requests to a specific object from anywhere in the world. Thus, a Durable Object can be used to coordinate between multiple clients who need to work together.
+* Each object has some **durable storage** attached. Since this storage lives together with the object, it is strongly consistent yet fast to access.
+
+Thus, Durable Objects enable **stateful** serverless applications.
+
 <LinkButton href="/durable-objects/get-started/walkthrough/">Get started</LinkButton>
 
 :::note[SQLite in Durable Objects Beta]