Learning paths / Deploy on ComputeSphere / How ComputeSphere is organised

Spherelets: shapes and counts

Reading · 6 min · Module 2, lesson 3 of 411 min left in this module

Module 2 · How ComputeSphere is organisedLesson 3 of 4

Goal: Choose a spherelet shape and count for a service, and explain what changing each one does.

Key idea

A spherelet is one running copy of your service, and it's what you size, scale and pay for. Two numbers describe a service: the shape of each spherelet and the count of them.

Shape: how big each copy is

A shape fixes each spherelet's CPU, in vCPU (a share of a processor; 1 vCPU is one full core's worth), and its memory.

  • Flex suits small APIs, sites and workers, and every lab in this path.
  • Standard suits typical production web apps and APIs.
  • Performance is for CPU- or memory-heavy work.

Shape is set per service, so a Flex worker can sit next to a Standard API in the same project.

An app that needs more memory than its shape has is stopped and restarted. If a service keeps restarting under load, check memory first.

Count: how many copies

The count is how many identical spherelets run the service, with traffic spread across them. More copies give you:

  • Capacity: more requests handled at once.
  • Availability: if one copy fails, the others keep serving.

Changing the count doesn't record a new version; it runs more or fewer copies of the one you have.

Bigger or more?

SymptomUsually the fix
Each request is slow, even with little trafficA bigger shape
Fine at low traffic, slow or failing at high trafficMore spherelets
Restarts when memory runs outA bigger shape, then look for a memory leak
One crash takes the whole app downA count of at least 2

Your account's capacity

Your subscription sets how many spherelets of each shape the account can run, across every service. A deploy that would go over is refused before anything starts, with a message like “not enough Flex spherelets available in your account”. Trial accounts can run up to two Flex spherelets.

Check yourself

Your API answers quickly for one user but errors when traffic spikes. What do you change first?