I ran a managed hosting company for five years, supporting a single application and operating more than 3,500 containers at its peak. Before that, I spent two years at a Windows-focused managed service provider, progressing from first-line support to systems administrator. After burning out at a difficult workplace, I returned to my family's business, earned an AWS Solutions Architect certification in 2018, and tried unsuccessfully to move into cloud roles.
I eventually started my own company because I missed working in IT. I learned Docker and Compose, then built an automation platform that handled reverse proxying, health checks, failed-container restarts, and customer provisioning. I also used CloudFormation for infrastructure as code, learned Python and Django, and built onboarding tools and APIs to automate the creation of customer environments.
I researched Kubernetes at the time but decided it was not a sensible fit because the application was not stateless. Converting it would have taken significant time and reduced profits, so I chose not to use Kubernetes or EKS. I also avoided Terraform because I preferred CloudFormation, although I now recognize how widely Terraform has become adopted.
The frustrating part is that I gained years of hands-on production experience, but employers seem to value specific tools and job titles more than the underlying work. I have since learned a lot about Kubernetes and EKS and have been able to pick them up quickly, but the job market feels unforgiving toward someone whose experience came from running their own business.
The company eventually lost ground as larger cloud providers began offering similar services, and I realized that running operations constantly was limiting my technical growth. I am also not naturally comfortable in highly social roles, which is one reason I originally preferred building a SaaS business and communicating mainly through support channels.
How would you present this background when applying for DevOps, cloud, or infrastructure roles? Would you target junior, mid-level, or other positions, and what would you do to avoid being pushed all the way back to first-line support?
4 Answers
There is no benefit in waiting until you match every requirement before applying. Job descriptions often describe an ideal candidate, not the minimum viable one. Apply broadly, tailor your résumé around measurable results, and prepare a clear explanation of the business ending and what you learned from it.
You may need to accept a role with a slightly lower title or narrower scope than your founder experience suggests, but that is different from starting over. Once you are inside a company and can demonstrate your production experience, it should be easier to move toward the cloud or platform work you want.
I would aim for DevOps, platform engineering, cloud infrastructure, or site reliability roles at smaller and mid-sized companies. Your background is a strong fit for environments where one person needs to understand development, operations, automation, and customer impact.
Build a small public portfolio that demonstrates the gaps employers may worry about: a Kubernetes deployment, an EKS environment, and an infrastructure project using Terraform or Pulumi. It does not need to recreate your business. A concise README explaining the architecture, trade-offs, monitoring, failure handling, and deployment process may be more useful than another certification.
In interviews, be ready to explain why you made each historical decision. Saying that Kubernetes was unnecessary for a stateful workload and that converting it would have harmed the business can actually show better engineering judgment than blindly adopting fashionable technology.
Do not undersell the business ownership side either. You handled customers, supported a live service, made architecture decisions, managed costs, and dealt with the consequences of outages. That is valuable even if you do not want a sales-heavy role.
You can target technical support engineering, infrastructure support, cloud operations, implementation engineering, and junior-to-mid-level DevOps positions as well as standard platform roles. Those can provide a bridge into a larger engineering organization without forcing you back to basic first-line work.
That absolutely counts as real experience. You were responsible for production systems, reliability, automation, customer onboarding, and the consequences of things breaking. The important part is translating it into language employers understand instead of leading with the fact that you did not use EKS or Terraform.
Describe the scale and outcomes: more than 3,500 containers, automated provisioning, health checks, recovery processes, infrastructure as code, and customer-facing uptime responsibilities. Then explain that you selected the architecture based on the application and business constraints. Not using Kubernetes was a design decision, not proof that you could not use it.
Smaller companies may be especially interested in someone who has operated an entire platform alone. Larger companies might hire you for a narrower infrastructure or platform role. Apply across a range of levels, but do not present yourself as a beginner just because your toolchain differs from the job description.
That makes sense. My concern is that even after experienced engineers helped rewrite my CV, employers still seem to screen for an exact list of tools rather than the underlying experience.
I could see infrastructure support or cloud operations being a reasonable bridge. I would prefer something technical and hands-on rather than a role centered on constant meetings or selling.