Being a software developer just looks like a journey of learning something new everyday. Recently, I embarked on this exact progression with a project called ascii-web art. What began as a simple command-line interface (CLI) application written in Go evolved into an interactive web service, which was ultimately packaged inside a Docker container. Through this process, I gained firsthand experience in web development, containerization, and did research on the foundational principles of container orchestration with Kubernetes.
Phase 1: Building in the Terminal
The initial iteration of the project was a pure terminal application. The core logic read plain text input from the command line, parsed each character, and mapped it to corresponding ASCII banner characters stored in template files such as standard, shadow, or thinkertoy.
While building a CLI application was an excellent way to practice core programming logic, algorithms, and file parsing in Go, it had inherent limitations in terms of usability:
Execution required direct access to a command terminal and the underlying source code environment.
Formatting and visual output depended heavily on the user's local terminal dimensions and font settings.
Non-technical users could not easily interact with or benefit from the tool.
To overcome these barriers and make the program accessible to a wider audience, the next logical step was bringing the application to the web.
Phase 2: Transitioning to the Web
Transitioning the project to a web application meant wrapping the core ASCII generation logic inside an HTTP server using Go's standard library.
Instead of accepting command-line arguments, the application served a web interface containing a clean HTML form. Users could enter their desired text, choose an ASCII font style, and submit the request. The Go backend received the POST request, processed the string through the ASCII generator, and rendered the rendered banner dynamically on the web page.
While this solved the user-accessibility problem, it introduced a common software engineering challenge: environment dependency, commonly summarized as the "works on my machine" problem. Running the application required anyone pulling the project to have Go installed, correctly configure their local environment, and manage directory dependencies for templates and banner files.
Phase 3: Containerization with Docker
To make the application truly portable and self-contained, we containerized it using Docker.
At its core, Docker wraps application code along with its specific runtime, system libraries, configuration files, and dependencies into a single, standardized unit known as a Docker Image. When executed, this image runs inside an isolated environment called a Docker Container. Because the container carries its own lightweight runtime environment, it guarantees that the application runs identically regardless of the underlying host operating system—whether Linux, macOS, or Windows.
The Dockerfile Blueprint
To containerize ascii-web art, we authored a Dockerfile at the root of the project to serve as the build recipe:
Phase 4: Beyond Single Containers—Understanding Kubernetes
Working with Docker naturally opens the door to broader infrastructure questions: How do you manage, scale, and maintain hundreds of containers in a production environment across multiple server nodes?
This is where Kubernetes (K8s) comes into play. While Docker excels at packaging and running individual containers on a single host, Kubernetes is a container orchestraPhase 3: Containerization with Dockertion platform designed to automate management at scale. It handles essential operational needs including:
Autoscaling: Spinning up additional instances of a container during traffic spikes.
Self-Healing: Automatically restarting or replacing containers that crash or fail health checks.
Load Balancing: Distributing network traffic across multiple container instances to maintain uptime and performance.
In essence, Docker provides the container, and Kubernetes provides the system to manage an entire fleet of them.
Conclusion
The journey of building and containerizing ascii-web art highlighted the practical value of modern software architecture patterns. Moving from a CLI utility to a web application made the software accessible to end-users, while wrapping it in a Docker container made it instantly deployable for developers and systems administrators alike. Understanding containerization—along with the foundational concepts of orchestration tools like Kubernetes—provides a strong foundation for building portable, scalable, and resilient cloud-native applications.with Kubernetes.
Top comments (0)