An Ephemeral Life: The Story of a Software Artifact

I started my career in the software industry during the era of large Sun Microsystems SPARC server racks. Those servers were expensive, durable, and (some would say in private) the status symbol of startups. It was the era of eternal gods with no mortals in the sight.

When Google first revealed that it’s building a server farm with a pool of inexpensive machines (by server standards) running Linux on them, the whole industry was taken by surprise. Google had a unique problem to deal with: They had limited money unlike competitors like Yahoo but had tons of talent and ingenuity. Here’s the perspective of Naga Kataru, one of the early engineers at Google and inventor of Google Alerts:

“ In early 2000, Google was losing money and wanted to find a way to save money and also increase rack density. At that time commercial vendors provided 20 servers per rack and Google’s goal was to double this capacity. Google sourced hardware from whenever they can to build servers, loaded them with the free Linux operating system and the server farm was ready” — Naga Sridhar Kataru

This was the start of the era of mortals. These servers were provisioned assuming they would not last forever. Google created its own filesystem to handle it which later came to be known as Google FileSystem. Google FileSytem paper along with MapReduce paper heralded the era of Hadoop and Big Data.

On the hardware side, Sun Microsystems (at least to my eyes) was an eternal god. At the same time, Sun was innovating faster than ever on the software side. Java was the second most spoken language in Silicon Valley and it was impossible to get a job if you were not well versed in it. The reason I brought it up here is that as I learned about Enterprise Java Beans, I learned about the mortality and life-cycle of software artifacts.

Over the years, I learned about the life-cycle stages of various objects and artifacts like:

• Agile development: {requirements, plan, design, developer, release}
• Container: { created, running/paused, stopped, deleted}
• Java Thread: {new, active, blocked/waiting/ timed waiting, terminated }
• Java Servlet: { init(), service(), doGet()/doPost(), destroy() }
• JUnit: { class setup, test setup, execution, test cleanup, class cleanup }

Graceful Exits

One of the most important aspects of life-cycle of ephemeral objects is that at the end of life, they need to return all borrowed resources and gracefully shutdown. The most talked-about borrowed resources are persistent database connections but it’s not limited to that.

Ephemeral Virtual Machines to Ephemeral Environments

The era of server farms was followed by the era of virtual machines. Virtual machines were the next step in improving server density. VMs were followed by containerization which brought virtualization at the application level. Truly speaking, it was not containers but Kubernetes pod which was the next level of abstraction.

“ Ideally if an application is running in a host, or virtual machine or in a pod, it should not know where its running. What that means is that key services an application need to run like networking, persistent storage, access to compute cycle should be available in a similar way.”

The ephemeral trait is so profound & powerful that it can be applied to virtual infrastructure artifacts like pre-production environments and that’s what we are exactly doing at Roost.io environments as a service platform. More details to come in the future blogs about the application of this trait for environment engineering by my fellow meteorologist Sudhir Jangir.

This post was created with Typeshare