Burak Yenier likes the part of technology that disappears when it works. A payment goes through. A compute cluster spins up. An engineer opens a familiar tool, runs a difficult model and gets back to designing. The machinery underneath may involve data centers, licenses, security rules, containers, queues and clouds. The user should not have to become the person who holds all of that together.
That instinct connects two chapters of Yenier’s career that otherwise look unrelated. Before he co-founded Simr, the engineering-simulation company formerly called UberCloud, he managed data-center and digital-payment operations at CashEdge, a financial software business later acquired by Fiserv. Availability in that setting was not a nice dashboard number. Banks and their customers expected the system to be there. Yenier worked on large-scale, high-availability infrastructure and on operations built for growth.
Then he carried the same operator’s eye into high-performance computing. Product engineers had powerful simulation software and increasingly accessible cloud resources, but the route between the two was crowded with manual work. The cluster had to be configured. The application had to be packaged. Licenses had to behave. Data had to move safely. Someone had to understand both the engineer’s desktop and the infrastructure waiting elsewhere.
“I love working with engineers. Hard problems bring out the best thinking.”Burak Yenier, in a public post about an engineering event
The experiment before the company
In 2012, cloud computing was already a serious business, but it was not yet an ordinary answer for demanding technical workloads. Engineers were cautious for specific reasons: security, privacy, software licensing, large data transfers, unpredictable cost, unfamiliar infrastructure and the fear of losing control. Yenier and high-performance-computing veteran Wolfgang Gentzsch began talking about that resistance. Instead of arguing with it, they designed a field test.
The UberCloud Experiment invited engineers, cloud-resource providers, software companies and HPC specialists to try real workloads together. Ten trained mentors helped teams through the process. Within eight months, the program had run its first 100 experiments and produced 50 case studies. The cases were not marketing abstractions. They involved the awkward particulars of technical computing: complex solvers, large models, specialist software and infrastructure that could fail in more than one place.
This was customer discovery with the sharp edges left on. Every failed onboarding exposed a constraint that a polished demo might conceal. Every successful run revealed a pattern that could be repeated. The point was not simply to prove that cloud HPC worked. It was to learn what had to change before an engineer could use it without becoming a cloud specialist.
Turning objections into product
The company that grew from the experiment was founded in 2013. Its early name, UberCloud, fit the moment: it helped engineers reach high-performance computing in the cloud. But the durable insight was operational. Access to compute was only one link in a chain. A practical service also had to preserve the engineer’s software environment, connect with enterprise systems and make the workflow portable.
Containers became part of the answer. UberCloud packaged complex engineering applications and their surrounding environments so they could move onto suitable infrastructure with less rebuilding. The company later reported that its onboarding time fell from an average of about three months to a few days. That compression is Yenier’s preferred kind of product result. It returns time to the person doing the domain work.
Yenier also kept publishing. He wrote about faster electromagnetic simulations, and in 2019 he co-authored an examination of Kubernetes, containers, HPC and AI with Daniel Gruber and Gentzsch. The recurring concern was portability: engineers should be able to use suitable compute without having their daily experience remade around each infrastructure choice.
His industrial-engineering education makes an apt backdrop. The work sits between software architecture and process design. Yenier later earned an MBA, and his public profile lists Stanford continuing-education certificates in the Internet of Things and in blockchain and cryptocurrency. Yet his public voice is less interested in collecting technologies than in making them operational. The question is usually not whether a tool exists. It is whether a team can use it repeatedly, securely and at scale.
A new name for the actual job
By 2024, “cloud” no longer described the full problem. UberCloud became Simr, a shorter name centered on simulation itself. The company introduced SimOps, or Simulation Operations Automation, as a set of practices for automating the workflows and data movement around simulation. The analogy is DevOps, but the conditions are different. Physical-product development brings solver software, expensive licenses, large files, specialized compute and engineering judgment that cannot be reduced to a software deployment pipeline.
The rebrand arrived with a $20 million Series A led by Uncorrelated Ventures, with BMW i Ventures and Earlybird Venture Capital participating. BMW i Ventures described Yenier as experienced in large-scale, high-availability systems and cloud computing, with management work spanning development and operations. The endorsement neatly connected the older financial-infrastructure chapter to the newer engineering one.
UberCloud described where demanding workloads could run. Simr describes whose work the company organizes. The strategic center moved from infrastructure access to the full simulation operation.
Simr’s architecture keeps the software in a customer’s own cloud account, an important choice for companies protective of engineering data. It also lets customers retain direct relationships with their simulation-software and cloud providers. Those boundaries are not incidental. They reflect a founder who learned in payments that control, compliance and reliability have to be designed into the operating model.
The folder full of evidence
The current version of Yenier’s argument has moved beyond running simulations. It asks what happens to their output. Engineering teams accumulate years of results in proprietary formats, nested folders, slides and email. A file may contain the raw evidence of a run, but not the assumption behind it, the solver version, the boundary conditions or the expert’s conclusion. That arrangement was inconvenient when people were the only consumers. It becomes a structural obstacle when AI systems need to compare thousands of runs.
“A simulation file holds the raw evidence. It does not hold the conclusion.”Burak Yenier, writing about simulation data and engineering judgment
This distinction is the personal idea at the center of his recent work. An AI model can extract values, but engineering knowledge includes why a team believed one result and discarded another. Yenier argues that the conclusion needs to travel with the evidence. Data should be structured, versioned and queryable; context and provenance should remain attached. The engineer stays in the loop because the engineer decides what the result means.
He illustrates the problem with the plain comedy of a filename: proj_astra/cad_v3/50mph/re-run1.sim. Everyone who has inherited a shared drive understands it. The name appears informative until someone asks which rerun was accepted, what changed, who approved it, or how to assemble all comparable cases. A folder tree is a storage habit masquerading as a knowledge system.
The proposed replacement is not an AI flourish. It is data plumbing: convert specialist outputs into accessible formats, capture useful metadata, preserve versions, offer programmatic access and keep expert decisions beside the data. Yenier calls this the quiet enabler beneath physics AI. The agent may run the simulation or analyze a result. Trust still depends on traceable inputs and human judgment.
An operator’s ambition
Yenier’s career does not read like a chase from trend to trend. The subject has remained stubbornly consistent: how to make complicated systems dependable for the people whose actual work happens above them. At CashEdge, that meant payments and data-center operations. In the UberCloud years, it meant getting simulation software onto remote compute. At Simr, it means automating the entire operation and making its data usable without stripping away context.
There is also a specific way he seems to build. Begin with a community and a real workload. Invite the parties who own different pieces of the problem. Publish the case study. Measure where the process breaks. Turn repeated work into software. Give the practice a name only after the pattern is visible. SimOps emerged page by page, the company says, from what engineers and administrators told the team.
The aspiration now is larger than faster compute. It is a simulation record that can compound: each run accessible, each decision traceable, each piece of expert context available to the next engineer and, when appropriate, to an AI system. Yenier’s recent line captures the balance: “Engineering judgment matters more in an AI workflow, not less.” The system should carry more of the operation precisely so the engineer can carry more of the meaning.