From Screen To Docker: A Look at Two Hosting Options
Tags: docker, cloud, hosting, cloudskills
Published: 2024-03-18 17:19:21



## Introduction

As you progress in your journey as a software engineer, you'll inevitably ponder how best to showcase your projects - perhaps you've [developed a Telegram bot](https://dev.to/tjtanjin/how-to-build-a-telegram-bot-a-beginners-step-by-step-guide-1kd1) or a Discord bot. At this stage, you might not find much satisfaction if your projects are solely confined to running on your computer. Wouldn't it be great if your work could be **accessible** from **anywhere**, **at any time**, for others to experience?

## A Brief Reflection

In my early days, I wasn't aware of _Docker_, so _Screen_ was always my go-to option. I first stumbled upon _Screen_ while attempting to train a simple model on my machine, and its simplicity appealed to me. As a novice, its ease of use allowed me to easily develop and run programs that I could share with others. However, as my number of applications grew, and when I made the decision to change my hosting provider, I found myself facing the arduous task of reconfiguring and setting up each application **from scratch**.

It was a time-consuming and painful process, so when I came upon _Docker_, I knew I had been missing out. Don't get me wrong, it's not that _Screen_ is bad - matter of fact, I still host some of my applications via _Screen_. Yet, the advantages of _Docker_ were apparent, and driven by the desire for enhanced deployment efficiency and streamlined management of projects, I began a journey towards _Docker_ adoption.

## A Tale of Two Scenarios

Let's envision two scenarios that vividly contrast the experiences of utilizing _Screen_ and _Docker_. In the first scenario, likened to a lavish buffet, _Screen_ presents an array of options with its **straightforward setup and immediate accessibility**. However, unforeseen disruptions akin to a toppling chocolate tower can swiftly derail plans, leaving users stranded amidst chaos.

Conversely, _Docker_ embodies a neatly packed lunchbox, containing a curated selection of applications within containers. Even if a chocolate tower were to topple, items in your lunchbox remain safe. _Docker's_ **encapsulation** ensures seamless continuity, enabling users to resume tasks with ease. This juxtaposition vividly portrays the evolution from the simplicity of _Screen_ to the robustness and adaptability of _Docker_ in managing hosting needs.

## Understanding Docker and Screen

Continuing from our exploration of contrasting scenarios, let's delve into _Docker_ and _Screen_ in more detail. _Docker_ serves as a platform for developing, packaging, and deploying applications in lightweight, isolated containers. These containers encapsulate not only the application code, but also its dependencies, ensuring consistency across different environments and simplifying configuration management. Consequently, _Docker_ not only offers **portability** but also helps **streamline deployment** processes.

On the other hand, _Screen_ offers a **convenient** way to manage terminal sessions, especially for scenarios involving long-running processes or management of multiple sessions. With _Screen_, users can detach from a session, allowing processes to continue running in the background even after the terminal connection is closed. This functionality proves invaluable for server processes or remote tasks that necessitate **continuous operation** without an active terminal connection.

## Choosing the Right Tool

While both _Docker_ and _Screen_ are capable of running applications, the decision between the two boils down to **project requirements** and **personal preferences**. _Docker_ boasts several strengths that make it ideal for various scenarios:
- Building and deploying applications in isolated environments.
- Ensuring consistency and reproducibility across different environments.
- Scaling applications and managing resources efficiently.
- Simplifying dependency management and deployment workflows.

Meanwhile, _Screen_ shines in specific scenarios, such as:
- Prototyping quickly for testing and sharing.
- Running on resource-constrained systems.

In addition to the above considerations, it is also worth noting that **investing time** in learning _Docker_ may be necessary for those unfamiliar with it. While _Screen's_ **simplicity** may appeal to hobbyists and beginners, ambitious projects aiming for **scalability and consistency** may find _Docker_ more suitable.

As I shared earlier in my journey, I initially favored _Screen_ for its ease of use, particularly as a novice hosting projects. However, as I embarked on more projects, I began to see more value in having streamlined deployment processes. Currently, I host projects like [Simple Media Converter](https://github.com/tjtanjin/simple-media-converter), [Simple Transcriptions](https://github.com/tjtanjin/simple-transcriptions) and [TeleQR](https://github.com/tjtanjin/tele-qr) in _Docker_, while a couple of prototypes, such as my Discord bot, remain on _Screen_.

## Conclusion

In conclusion, whether you're savoring a lavish buffet or enjoying a well-packed lunch, remember to **evaluate your circumstances** and select the hosting solution that aligns best with your **needs**. Ultimately, your decision between _Docker_ and _Screen_ should be guided by the **nature of your projects**, your **technical capabilities**, and your **long-term hosting objectives**. In an upcoming article, I will do a sharing on how to deploy a Telegram bot with _Docker_, where I'll delve into the practical steps of this process. If you're keen, do **keep a lookout**!

Finally, if you've found this comparison helpful in navigating your decision-making process, feel free to share your thoughts, ideas, or feedback in the comments or [reach out](https://discord.com/invite/X8VSdZvBQY) to me directly. I am more than happy to engage in a conversation. Thank you for taking the time to read my short sharing, and I wish you success in your hosting journey!