# What is Eugo?

Eugo is a cloud platform for high-performance computing. You write ordinary Python in a browser-based
[notebook](/glossary/notebook), and Eugo compiles, vectorizes, and distributes it across a [cluster](/glossary/cluster) of ARM and [GPU](/glossary/gpu) compute
nodes.

No servers to provision, no environments to configure, no autoscaling policy to tune.

## The shape of it

Three things, and the relationship between them:

| Thing | What it is |
| --- | --- |
| **Interactive session** | A running EugoIDE instance in your browser. Where you write code. |
| **Cluster** | A head node plus compute nodes, launched on demand. Where code runs at scale. |
| **Workspace** | The environment that owns your storage, libraries, and resource allocation. |

You open a session inside a [workspace](/glossary/workspace). From that session you launch a cluster. Your notebook code
dispatches work to the cluster and collects results back. When the work is done you shut the cluster
down, and the session stays open for the next thing.

## What you actually write

The API is deliberately small. Here is a complete distributed program:

```python
import eugo.hpc

@eugo.hpc.distribute
def process(partition):
    # Ordinary Python. Nothing here knows it is running on a cluster.
    return expensive_transform(partition)

futures = [process(p) for p in partitions]
results = eugo.hpc.get(futures)
```

Two things changed from a single-machine version: a decorator on the function, and one call to
resolve the results. The body of `process` is unmodified.

That is the design goal. Notebook code stays readable, with no `.remote()` on every call site, no
explicit cluster initialization, and no separate configuration file describing your topology.

:::note The `eugo` namespace is empty
`import eugo` on its own gives you nothing. The distributed-compute API lives under `eugo.hpc`, so
`import eugo.hpc` is the import you want.
:::

## What Eugo is not

The phrase "cloud HPC platform" covers a lot of ground, so here are the boundaries.

- **Not a managed Kubernetes.** You do not write manifests or think about pods.
- **Not a job scheduler you submit scripts to.** Work is dispatched interactively from a notebook.
- **Not a rewrite of your analysis.** Your pandas, NumPy, and scientific Python code carries over.

## Supported libraries

The scientific Python stack is preinstalled and supported: NumPy, pandas, SciPy, scikit-learn,
PyTorch, and the usual geospatial and imaging libraries.

:::warning Not supported
Eugo does not support TensorFlow, spaCy, or JAX. If your pipeline depends on one of them, plan for
that before you migrate. It is the constraint most likely to surprise you.
:::

## What comes next

The next lesson covers *why* this exists: the specific problem that makes provisioning your own
instances unattractive. If you would rather see it working first, skip ahead to
[opening your first session](./04-first-session.mdx).

---

**Video:** [What is Eugo, in 90 seconds](/videos/what-is-eugo-in-90-seconds). Same material, with a transcript.

---

Source: https://university.eugo.io/lesson/getting-started-with-eugo/what-is-eugo