I ran a managed hosting company for five years for a single application, which was essentially a SaaS business. At its peak, I operated more than 3,500 containers. Before that, I spent two years at a Windows MSP, progressing from first-line support to sysadmin. After burning out at a difficult workplace, I returned to my family business, earned my AWS Solutions Architect certification in 2018, and tried unsuccessfully to move into cloud roles.
I eventually missed IT enough to start building again. I learned Docker and Compose, then created a platform that automatically handled reverse proxies, health checks, and restarting failed containers. I considered Kubernetes but decided it was not practical for an application that was not stateless. Making it stateless later would have required a major rewrite and would have hurt the business financially.
For infrastructure as code, I used CloudFormation because I preferred it at the time. I also learned Python and Django and built the onboarding system and APIs that automatically provisioned new customers.
The frustrating part is that I gained this experience by running real production infrastructure, yet it feels undervalued because I did not use technologies such as EKS or Terraform. I have since learned a lot of Kubernetes and EKS quickly, but the job market seems to expect very specific experience, especially from people who worked for themselves.
My business eventually lost ground as larger cloud providers began offering similar services, and I also felt stuck doing operations without the learning opportunities available in a larger engineering organization. I am worried that my only option is going back to first-line support, despite having spent years designing, automating, and operating production systems.
How would you position this background when applying for DevOps, platform engineering, or cloud roles?
4 Answers
At some point, the practical answer is to apply broadly across junior, mid-level, and infrastructure-focused roles while tailoring the résumé to each one. Do not describe yourself as someone who merely experimented with containers; describe the scale, uptime responsibilities, automation, failure handling, and systems you personally designed and maintained.
Prepare a few detailed interview stories: a production failure and how you handled it, a difficult scaling or customer-provisioning problem, an automation project, and a case where you deliberately rejected a technology because it was not appropriate. Those examples demonstrate engineering judgment, which cannot be proven by a certification or a list of tools alone.
Your experience absolutely counts, but you need to present it in terms of outcomes rather than the tools you did not use. You ran production systems at meaningful scale, automated customer provisioning, built monitoring and recovery processes, and made architecture decisions based on the actual business constraints. That is much stronger than simply listing Kubernetes and Terraform on a résumé.
Smaller companies may especially value someone who has already owned an entire platform alone. Be honest about the technologies you used, explain why you chose them, and show that you now understand where Kubernetes, EKS, or Terraform would fit. The key is finding employers who value fundamentals and practical judgment instead of treating a tool checklist as the whole job.
You may also be a fit for solutions engineering, technical account management, or cloud consulting. Running a hosting company means you dealt with customers, reliability, trade-offs, support, and the consequences of technical decisions. Those skills can be more valuable than having shallow familiarity with another popular tool.
That said, if heavily social roles are not comfortable for you, focus on companies where communication is mostly written and the work is hands-on. Smaller infrastructure teams and internal platform groups may offer a better match than highly customer-facing positions.
That is part of my difficulty. I am not naturally comfortable in roles built around constant social interaction, which is one reason I originally created a SaaS business where most communication could happen through support systems and email.
I would target DevOps, cloud operations, platform engineering, and infrastructure automation roles rather than assuming you need to start over in first-line support. Your background covers the important fundamentals: containers, deployment automation, reliability, APIs, infrastructure as code, customer onboarding, and operating systems in production.
Terraform is common, but it is not the only valid approach. Experience with CloudFormation and the ability to learn another provisioning tool are both relevant. Likewise, choosing not to use Kubernetes for a stateful application was a business and architecture decision, not evidence that you lacked ability. Build a small public project or lab using Terraform and EKS to close the terminology gap, then use your real business experience as the main story.
That is what I am trying to emphasize, but the market seems to have very little patience for gaps in specific tools. I have even had experienced people review my résumé and still struggled to get traction.