Three years and counting running hybrid cloud, multi-datacenter virtualisation, and container platforms that other people depend on every day. I automate what repeats, measure before and after, and write down how it works so it can be maintained without me.
In short
I came into IT through network cabling, not through a slide deck.
My vocational school specialisation was Computer and Network Engineering, and the first piece of work I was genuinely proud of was building a school-wide local network so digital exams could actually run. My way of working has not changed much since: the problem has to be genuinely solved, not made to look solved.
From there I moved to the less visible side: the servers, storage and networks that let everything else run. I learned that most of this work is about making a system maintainable by someone else — not about who types a command fastest.
Today I work on hybrid cloud infrastructure: virtualisation and storage clusters spread across more than one data center, container platforms for a product sold to clients, and automation for the work that should never have to be done manually twice.
If you want to know how my technical decisions get made, the Approach section below summarises it. For the employment and study history, the About page has it.
More about meProblems I solve
Every one of them starts from a situation, not from a list of technologies.
A system goes down without warning, and nobody knows where to start.
The first thing I check is not the service — it is whether this is genuinely new, or a symptom that has been sitting in the logs for weeks with nobody reading them. Once the cause is found I close the way in, rather than only restoring the service.
Releases are tense because there is always a manual step that can be missed.
I move the repeated manual steps into a pipeline, then make sure the result is exactly repeatable. Two numbers tell you whether it worked: how long a release takes, and how often a step has to be redone because it was forgotten.
Running costs keep climbing with no clear explanation of why.
I map what is actually used against what is being paid for, then cost it per workload. The most common finding: capacity paid for as insurance that is rarely touched — and the opposite, one small service quietly holding up the whole budget.
Areas of work
Each area below is not a separate service. The value shows up when they are treated as one interdependent system.
01Systems & infrastructure
Keeping the machines that run a service alive, secure, and unremarkable when something breaks.
The terms below are the vocabulary used in technical environments. You do not need them to judge the section above.
02Virtualisation & storage
Pooling many machines into shared resources, so that one machine failing does not take a service down with it.
The terms below are the vocabulary used in technical environments. You do not need them to judge the section above.
03Containers & automation
Making an application run and update the same way every time, without a manual step in the middle.
The terms below are the vocabulary used in technical environments. You do not need them to judge the section above.
04Networking & service delivery
Designing the paths data travels, and keeping those paths fast and correct.
The terms below are the vocabulary used in technical environments. You do not need them to judge the section above.
05Cloud & operational security
Using cloud services safely, and stopping the payment for the parts that turn out to be unused.
The terms below are the vocabulary used in technical environments. You do not need them to judge the section above.
Selected work
Every case study records the original problem, what I did myself, and what changed afterwards. Tools come last.
Infrastructure & platform
One shared platform replaced hand-built servers, so a new service line can grow without adding work to the operations team.
Infrastructure & reliability
Two physical sites now operate as one shared set of services, so losing a single component no longer turns straight into an outage for users.
Infrastructure & operations
Production workloads that ran at an external provider were moved back onto owned infrastructure, cutting the recurring cost without users noticing a change.
Approach
Four habits that decide how I make technical calls. These are not company values — they are things you can judge me on from the work itself.
01The problem first, the tool later
Most requests arrive as an already-chosen solution. I always trace back to the original problem, because the answer is often much cheaper — or turns out not to need building at all.
02A system that can be explained is easier to maintain
The cleverest solution is useless if only one person understands it. When the benefit gap is small I choose the simpler design, and write down the reasoning so the decision can be revisited.
03Measure before and after, not during the presentation
An improvement without a number is an opinion. I decide what will be measured before starting, and I still report the result when the number is not the one I hoped for.
04Translate, do not simplify
A technical explanation for a non-technical audience does not need a misleading analogy. It needs the right order: what the impact is, what the constraint is, and only then how it works.
Selected writing
Written for two readers at once: the one who builds the system, and the one who has to make decisions about it.
Selected writingNews
This is VickyApp - Portfolio And Blog Website, a brand new site by Vicky Ardiansyah Pathurrohman that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd…
Working together
I am open to conversations about system reliability, release automation, architecture decisions, or a full-time role. You do not need to prepare anything to start — just describe the situation.