7 Interesting Parallels Between the Invention of Tiny Satellites and Cloud Computing

CubeSats are revolutionizing space exploration because they are small, modular, and inexpensive to build and launch. On an episode of embedded.fm, Professor Jordi Puig-Suari gives a fascinating interview on the invention of the CubeSat. 195: A BUNCH OF SPUTNIKS.

What struck me in the interview is how the process of how the CubeSat was invented parallels how the cloud developed. They followed a very similar path driven by many of the same forces and ideas.

Just what is a CubeSat? It's a "type of miniaturized satellite for space research that is made up of multiples of 10×10×10 cm cubic units. CubeSats have a mass of no more than 1.33 kilograms per unit, and often use commercial off-the-shelf (COTS) components for their electronics and structure."

Parallel #1:  University as Startup Incubator


The CubeStat project wasn't on anyone's technology roadmap, nobody knew they needed it, it just happened. A bunch of really bright students at California Polytechnic State University and Stanford, in a highly constrained environment, didn't have enough resources to do anything interesting, so they couldn't build spacecraft conventionally. So they came up with a very different approach to building a satellite than was found in industry. Not knowing what you're doing is an advantage in highly innovative environments.


While Google wasn't first to market with a public cloud, they do seem to be the first to think publicly of the datacenter as a cloud, as a single integrate whole. The Datacenter as a Computer.

It's eerie how the timeline's for Google and CubeSat line up. The CubeSat reference design was published in 1999. Google was founded in 1998, though project BackRub, the research on the web's link structure, started in 1996 at Stanford. The Birth of Google. It took a lot longer for Professor Puig-Suari to go the startup route. He (and others) founded Tyvak in 2011 to take advantage of their research and experience putting payloads in space.

Parallel #2: Use Off the Shelf Components


They looked for the highest performance components they could find. These were commercial off the shelf components that when launched into space actually worked. The mainline space industry couldn't take these sort of risks. Industry eventually started paying attention because the higher performing, lower cost components, even with the higher risk, changed the value proposition completely.


Jeff Atwood visited the Computer History Museum in Silicon Valley and wrote an article of his experience seeing Google's original servers from 1999. Building a Computer the Google Way. Jeff puts it nicely:

If Google's first production server resembles a hastily cobbled together amalgam of off-the-shelf computer parts circa 1999, well, that's because it is. Just like Google's original servers at Stanford. If you think this rack is scary, you should see what it replaced. Instead of buying whatever pre-built rack-mount servers Dell, Compaq, and IBM were selling at the time, Google opted to hand-build their server infrastructure themselves. The sagging motherboards and hard drives are literally propped in place on handmade plywood platforms. The power switches are crudely mounted in front, the network cables draped along each side. The poorly routed power connectors snake their way back to generic PC power supplies in the rear.

Parallel #3: Eliminate Redundancies


The students took more risks than industry by eliminating redundancies. One battery. One radio. They were willing to take a risk that things could go wrong...in space. That takes chutzpah.


Notice the Google servers discussed above do not contain RAID storage, ECC memory, redundant power supplies, redundant NICs, redundant fans, redundant microprocessors, or redundant much of anything. While redundancy was the sine qua non of traditional server design, and it seems satellite design, redundancy happens at a different level in a low cost, off the shelf component world.

Xkcd, as usual, nails it. 1737: Datacenter Scale.

Parallel #4: Make it up With Numbers


Instead of making one large, expensive, satellite, the CubeSat researchers realized they could launch 50 CubeSats for the cost of one traditional satellite. So the idea is to launch a lot of them. What level of redundancy do satellites have?

What can you do with a beowulf cluster of CubeSats? JPL imagines quite a bit: With CubeSats, there's strength in numbers. Entire constellations of CubeSats, flying in formation and working together, could make powerful observations analyzing everything from the nature of Europa's icy shell to the extremely low-frequency energy of far-away galactic nuclei and black holes . For more complex missions, swarms of CubeSats could be anchored by a single "hub" -- a powerful central spacecraft that can handle complex computational tasks and data transmission back to Earth. Keeping each CubeSat simple and focused will allow for more inexpensive deployment, greater reliability, and the incremental ability to add new CubeSats or replace malfunctioning units.


Cloud computing is based on this same insight. Redundancy based on numbers is everywhere in the cloud. There are lots of machines to handle machine failure. There are lots of disks to handle disk failure. Data is copied to multiple locations in case one location fails. This is . Google On Latency Tolerant Systems: Making A Predictable Whole Out Of Unpredictable Parts. The Google File System.

Parallel #5: Modularization

CubeSats' have a standard size, which means launch vehicles could also standardize. Before, launch vehicles were specialized for each payload. Now it doesn't matter where a satellite comes from, it can be launched with a standard configuration, which dramatically brings down launch costs and increases the number of launches that can occur. This is a key step in the modularization of the satellite launching, the same force that drives all mass commercialization in the tech industry.

Horace Dediu defines modularization as: The primary accelerant is a process called “modularization” which allows each subsequent industry to leverage all the previous industries by incorporating their advances as modules in its own. The availability of electric power allowed home appliances and entertainment to emerge. More recently, the availability of internet allowed both personal and mobile computing to prosper and the availability of a computing infrastructure is allowing the rise of digital services

You can't create an ecosystem building one-offs. You need standards, APIs, the ability for nearly anyone to pick up a technology and make something new and innovative. Today, even kids in high school can create their own CubeSat mission. SpaceX will this to the next level.

Now the same ideas are being applied to bigger and bigger spacecraft and it's now a vibrant industry. Learning happens more quickly because they get to fly more. All well known characteristics of the cloud, cloud adoption, and software in general.

Parallel #6: Platformification

The CubeSat is standardized such that it can specialized to carry out different missions by adding a small amount of customized hardware and software. By not reinventing wheel, satellite launches can be more reliable, happen faster, and are easier, cheaper, and less risky to develop. Tyvak supplies several different type of satellite platforms.

Of course the whole idea of cloud computing is to be a platform play for various kinds of services.

Parallel #7: Future Growth Driven by Open Source

The role of open source in software is well known.

What was surprising to me is role of open source in CubeSat. KubOS is an open source, integrated platform built to run on any satellite subsystem. LibreCube is a community-driven initiative to provide open source solutions for space and earth exploration. UPSat is the first open source satellite. Take a look on GitHub. On UpSat, Launching Open Hardware Satellites says "All of the critical subsystems of the satellite being designed from scratch using open software and open hardware." SatNOGS is an open source ground station and network, optimized for modularity, built from readily available and affordable tools and resources.

So it's open source everywhere, all the way down.