Sony Huynh
“SRE can be considered as an implementation of DevOps, but the concept will be a bit different. We maintain and develop the infrastructure to involve every team to work base on a mutual mechanism. It’s about setting up the working culture, internal tools, and environments so developers can operate the job themselves. For example, if the work happens in Flutter, we’ll take care of the CI/CD, pipeline, or infrastructure preparation.
I’ve had more than 4 years working in software engineering, though I did come from another major - Computer engineering, embedded system. I spent the first two years in Telecom system at Ericsson, followed by almost one year as a DevOps engineer for a startup. Until I moved to Teko, where I helped set up the foundation for mutual tech stacks and operation processes. We currently bridge the gap between development and operations using GitOps - which supports a complete history of how our environment is changing over time. We manage almost everything under GitOps concept, from cloudflare, data migration, ACL, Gateway configuration, Kubernetes cluster and the workload in between.
From what I believe, if we collect a level of knowledge and experience, role switching isn’t a big deal. People can still spend 3-5 years in a role, yet they never really understand its nature. You must genuinely work at every level it takes; otherwise, it’s impossible to resolve the issue regarding infrastructure and scaling. This marks the linear line between DevOps/ SRE to other developers. It’s not always about running code.
The process of releasing a product or moving it from development to production environment faces many difficulties. Your app can run perfectly on a local test and can still crash at the moment it reaches the production environment. The second obstacle is scaling. Scaling in an application describes its ability to handle a volume of traffic simultaneously, not how many features or code you’re implying in an app. It requires a solid base in infrastructure and software design, which can be “scaled” through time and still perform at its best.
When it comes to startup, it’s another direction. Startups will expect to launch their product in a short amount of time to pitch their idea for investment. To get that done, startups must ensure a fixed set of features to make sure their app runs flawlessly and meets the problem-solution fit. From the founder’s perspective, development timing is the key. But for us developers, it’s the risk of technical debt and the chance of rebuilding everything from scratch. But rebuilding a system in startups is inevitable; still, I think the solution for that underlying issue is still unanswered.
For me, adapting the team culture is the first action to be done before it comes to the company since most of the time is spent on teamwork & communication. But don’t get me wrong, we still need to stay up-to-date on what other teams are planning on. It keeps everyone synced and make sure we run toward the same goal, and easier when the situation calls for resource reallocation. So yes, culture fit in a small team is essential, but only when that team spirit goes along with the company’s vision in the long run.”
