Go, Docker, and Kubernetes: Why I Decided to Step Out of My Comfort Zone
After more than 15 years spent developing web applications in PHP—working on management software, web platforms, and production systems—I decided to take on a new technical challenge:
<strong>learning Go, Docker, and Kubernetes.</strong>
Not because it is "trendy."
And not because I think the technologies I use today are no longer valid.
The reason is much simpler: I believe a good developer should <strong>never</strong> stop evolving.
<h2>Why Go?</h2>
Over the last few years, I started noticing more and more backend projects and infrastructures built in Go.
What immediately struck me was the language's philosophy:
<ul>
<li>simplicity</li>
<li>performance</li>
<li>readability</li>
<li>native concurrency</li>
</ul>
After so many years spent on traditional web stacks, working with a language designed for modern services, APIs, and distributed systems has been extremely stimulating.
Go forces you to think differently.
And that, in my opinion, is one of the most exciting parts of learning.
<h3>A Completely Different Approach to Concurrency</h3>
One of the aspects that impressed me the most about Go is how it handles concurrency.
After years on traditional web stacks, facing concepts like:
<ul>
<li>goroutines</li>
<li>channels</li>
<li>select</li>
<li>context management</li>
</ul>
completely changes the way you design certain types of applications.
The ability to run concurrent tasks in a simple and readable way makes Go particularly interesting for:
<ul>
<li>microservices</li>
<li>high-performance APIs</li>
<li>CLI tools</li>
<li>distributed services</li>
</ul>
Another aspect I am highly appreciating is the standard library: minimal yet extremely powerful.
It really feels like Go continuously tries to eliminate unnecessary complexity, favoring clear and maintainable code.
<h2>Docker: The Moment Everything Changes</h2>
For years, I worked with local environments, Linux servers, staging, and manual deployments.
Then Docker comes along, and it completely changes how you look at an application.
You are no longer just thinking about the code.
You are thinking about the entire environment:
<ul>
<li>services</li>
<li>dependencies</li>
<li>containers</li>
<li>portability</li>
</ul>
The ability to have consistent environments between development and production radically changes the workflow.
And honestly? After you start using it, you instantly understand why it became a standard.
<h3>Containerizing an Application Changes Your Mindset</h3>
The interesting part of Docker is not just creating containers. It is understanding how it changes your approach to development.
Over the last few months, I started working with:
<ul>
<li>multi-stage Dockerfiles</li>
<li>docker-compose</li>
<li>inter-container networking</li>
<li>volume persistence</li>
<li>containerizing databases and backend services</li>
</ul>
and this made me realize how important it is to design truly isolated and portable applications.
One of the most useful aspects is the ability to replicate complete environments in just a few seconds:
<ul>
<li>backend</li>
<li>database</li>
<li>reverse proxy</li>
<li>secondary services</li>
</ul>
drastically reducing the classic configuration issues between development, staging, and production.
Docker is not simply a DevOps tool. It is a different way of thinking about the software lifecycle.
<h2>Kubernetes: Complex, yet Fascinating</h2>
Kubernetes is probably one of the most complex technologies I have started tackling in recent years.
And it is also the one that made me realize how much the modern development world is shifting toward:
<ul>
<li>scalability</li>
<li>automation</li>
<li>orchestration</li>
<li>resilience</li>
</ul>
At first, it feels massive.
Pods, deployments, services, ingress, clusters... everything seems overwhelming.
But then you start to see the bigger picture.
And you realize that Kubernetes is not "just DevOps": it is a new way of thinking about software in production.
<h2>The Hardest Part? Becoming a Beginner Again</h2>
After so many years of experience, the biggest challenge is not learning the syntax.
It is accepting being back in a phase where:
<ul>
<li>you don't know everything</li>
<li>you have to make mistakes</li>
<li>you have to experiment</li>
<li>you have to start asking questions again</li>
</ul>
But it is also the healthiest part of this job.
Because it reminds you that technology constantly evolves... and that stopping to learn is the fastest way to fall behind.
<h2>What I Am Really Trying to Build</h2>
I am not trying to "switch stacks" overnight.
I am trying to broaden the way I design software.
Understanding:
<ul>
<li>how modern architectures work</li>
<li>how services are deployed</li>
<li>how applications scale</li>
<li>how development and infrastructure communicate</li>
</ul>
And above all, I want to continue being a developer who is capable of adapting.
<h2>Why I Am Sharing This Journey</h2>
For two reasons.
<strong>The first:</strong> because I think it is important to show the learning process itself, not just the final result.
<strong>The second:</strong> because I would love to connect with other developers who are going through similar journeys.
Different tips, experiences, and points of view are often the best way to truly grow.
<h2>Conclusion</h2>
After many years in web development, stepping out of your comfort zone is not easy.
But it is probably one of the best things a developer can do.
And honestly? I am glad I started this journey.
