Inspiration
The inspiration for Dynamic Space came from my experience in the cloud hosting space. I started with hosting Minecraft servers and Discord bots using Pterodactyl, but as I began coding more, I realized that Pterodactyl wasn't the best hosting platform. I then tried Deno Deploy, but it didn't support languages like Go. This led me to the idea of creating a better solution on my own.
What it does
Dynamic Space is a serverless hosting solution that aims to eliminate the problem of "cold starts" in serverless computing. Cold starts refer to the latency between when the first request and the first response is sent in a serverless environment. This is caused by the inherent architectural design of the deployment system, where a new instance of the application has to be spun up to send a response. Dynamic Space bypasses the need to start new containers and completely removes cold starts from cloud deployment by dynamically injecting functions into containers.
How we built it
Dynamic Space was built using a "pre-warmed" container approach. Instead of creating a new container every time a function is invoked, we use a container that is running continuously. Codebases are dynamically mounted into these containers, executed, and then unmounted, freeing the container for another request later on. This system scales when the pre-existing containers are filling up, and more "pre-warmed" containers are allocated to accept requests.
Challenges we ran into
One of the challenges we faced was dealing with the communication between the application inside the containers and Dynamic Space for status and logging updates, and more importantly, a kill switch. We initially considered using a HTTP-based communication by opening a specific port which will listen to incoming and outgoing requests. However, we decided to use a standalone TCP socket server which provided a more secure and lightweight solution to our communication issue.
Accomplishments that we're proud of
We are proud of the fact that Dynamic Space has been very successful in our testing and is going to be implemented in the infrastructure of Runnr Cloud as the main deployment architecture. This feature allows for any type of stateless code to be hosted on the platform without overprovisioning costs and higher runtime efficiency. We have also noted that the redundancy of this infrastructure is quite stable and can be scaled in a moment's notice when needed.
What we learned
We learned how to manipulate and switch volumes of running Docker containers, develop and counteract isolation breakpoints, and scale this method to account for thousands of developers. We also learned how to reduce library loading latency and combat apparent isolation security issues of pre-existing similar methods.
What's next for Dynamic Space
The next step for Dynamic Space is to continue improving its performance and scalability. We will continue to test and refine our approach, focusing on reducing other points of latency such as loading libraries. We also plan to further evaluate the speed gains and the scalability of this infrastructure to millions of users and deal with performance issues.
Please read the attached paper for a further understanding of the project. Please know that this paper was written in less than a day so mind the grammar and content
Log in or sign up for Devpost to join the conversation.