Skip to content

About

I've been doing this since 2014.

Anshuman Abhishek, Platform Engineering Architect, based in Stockholm, Sweden

Anshuman Abhishek · Stockholm, Sweden

I started in Linux systems administration — LDAP in high availability, MySQL clustering, load balancers, the unglamorous infrastructure that everything else sat on. That grounding turns out to matter more than I expected. A lot of cloud-native engineering is the same problems with better tooling, and knowing the problems underneath makes the tooling make sense.

Since then I've worked across telecom, SaaS and enterprise environments, on systems where availability carried regulatory weight and maintenance windows didn't really exist. Most of my work now is Kubernetes platform architecture — the networking, the tenancy model, the delivery pipeline, the guardrails — plus the migrations that get workloads there and the cost work that keeps them affordable.

I'm based in Stockholm, Sweden and work with clients across Europe and the US. I take on architecture engagements, fixed-scope builds, and fractional platform lead work for teams that need architect-level judgement without a full-time hire.

The thing I'm actually selling isn't Kubernetes. Plenty of people know Kubernetes. It's judgement about which of forty possible answers fits a particular team's size, skills and deadline — and the willingness to tell you when the answer is “don't do this at all.”

Education

Bachelor of Engineering, Computer Science

Visvesvaraya Technological University, Karnataka, India · 2010–2014

Currently learning

AI and GPU infrastructure on Kubernetes, platform security and supply-chain hardening, and telco cloud network functions. I write about what I find as I go.

How I work

Four things I do on every engagement

  1. 01

    Discovery before design

    I start with what actually exists rather than what the documentation claims. Real dependencies, real traffic, real costs — and a written list of the questions nobody could answer. That list is usually the most valuable page.

  2. 02

    Options, then a recommendation

    Every significant decision gets two or three candidates with honest trade-offs and a recommendation with reasons, recorded as an architecture decision record. One option is a preference. Three with a recommendation is judgement.

  3. 03

    Build with the failure condition defined

    Rollback criteria on migrations, success criteria on proofs of concept, abort conditions on cutovers — written down before work starts, not improvised on the day.

  4. 04

    Hand over properly

    Reference implementations, runbooks, recorded walkthroughs. The measure of the work is whether it still runs well six months after I leave.

Tell me what's broken.

Or what you're trying to build. I'll give you an honest read on it before either of us commits to anything — and if I don't think I'm the right person for the job, I'll say so on that call.

Stockholm, Sweden (CET) · Comfortable overlap with European hours and US East Coast mornings