Ewen Simon, Cloud Architect bei ÖBB: Learning at the Edge in Azure — Why Struggle Builds Real Cloud Skills

Overview: The message distilled from this session

Title: Ewen Simon, Cloud Architect bei ÖBB

Speaker: Ewen Simon

Company: ÖBB-Konzern

In a concise, clear session, Ewen Simon articulates what many cloud engineers intuitively sense: true learning in the cloud begins where documentation ends. He shares what draws him to Azure, why constant change is a feature rather than a bug, and how working with like-minded people on common projects fuels growth. Above all, he offers one piece of practical advice for anyone starting out: find a context that nudges you beyond your comfort zone — not “outside the box,” but right at the border.

From our DevJobs.at editorial perspective, that insight matters. “It worked, that’s the end of it” is not a learning moment. The session is a call to pursue intentional friction — to deliberately operate near the edges, where assumptions are tested and understanding is forged.

What Ewen finds compelling about Cloud and Azure

Ewen highlights three aspects that make cloud work — and Azure in particular — compelling:

• There isn’t always an example, and sometimes not even documentation.
• It’s a field that is constantly changing.
• You work with like-minded people who want to grow and collaborate on common projects.

This framing flips the usual frustrations — sparse samples, documentation gaps, perpetual change — into a source of motivation. The absence of a step-by-step recipe is precisely where engineering begins. Between incompleteness and movement lies the space where we prove designs, stabilize systems, and learn how things actually behave in production-like conditions.

Missing examples as a learning engine

The “happy path” is familiar: follow the docs, configure service A with B, deploy, done. Ewen flips that script. When examples stop, the real work starts. Questions multiply: What is the correct sequence? Which assumptions are baked into defaults? What happens when you tweak identity, networking, or storage just a bit? Wrestling with these questions produces durable understanding.

Constant change as a practice field

“Constantly changing” is not hype; it is the metronome of cloud work. New services, quotas, features, or deprecations in Azure can nudge an architecture at any time. Teams that embrace this motion intentionally revisit principles and check decisions against new realities. That discipline is an engine for continuous learning.

Like-minded peers and common projects

Ewen also points to the people. Working with like-minded peers who want to grow and contribute to shared projects turns individual curiosity into team capability. Pairing, code/design reviews, and post-mortems that surface patterns rather than blame create a learning architecture: tacit knowledge becomes explicit, decisions become reproducible.

The core advice: Find a context “at the border”

Asked how to get started, Ewen’s answer is disarmingly practical: create a context that challenges you — not outside the box, but at the edge of it.

The nuance matters: “at the border.” You don’t need artificial complexity, just intentional constraints that push you slightly beyond the well-lit path. In the cloud, this is easy to arrange — a stricter network boundary, an unusual auth flow, or an integration the docs only hint at. The point isn’t to fail; it’s to increase your chances of encountering real issues so you can learn from them.

Why the happy path teaches too little

If you deploy “an App Service and a website database” strictly by the documentation and it works on first try, that’s satisfying — but pedagogically thin. Learning needs feedback. Errors, bottlenecks, and ambiguities provide that feedback. If you never hit the walls, you won’t learn where they are.

Struggle as teacher — “luckily”

It’s telling that Ewen says “luckily.” We learn not despite difficulties but because of them. That’s a posture. Treat failures as data and problem-solving as the core of the craft. Then you can “fail smart”: form a hypothesis, adjust one variable, retest, and anchor the insight.

From impulse to practice: Operationalizing “edge contexts”

Ewen doesn’t prescribe a playbook, but his remarks suggest a practical way to structure learning in Azure.

1) Start with a learning hypothesis, not a feature

• State what you aim to understand (e.g., identity boundaries, network isolation, deployment strategies).
• Define how you’ll know you learned it (metrics, logs, failure modes, throughput limits).
• Tie the learning to a small, concrete artifact (a minimal app with one deliberate constraint).

2) Choose one constraint that creates healthy friction

• Limit resources or permissions on purpose.
• Pick a path the docs mention only briefly.
• Avoid the most forgiving defaults once you understand what they hide.

3) Iterate with hypotheses and short feedback loops

• Write down your expectation (“Service A should reach B over private endpoints”).
• Test failures on purpose (revoke credentials, tighten networks, nudge limits).
• Log cause-and-effect: which configuration produced which behavior?

4) Use documentation as a baseline, not the finish line

• Read docs to align terminology and basics.
• Seek the edge: where do the docs discuss exceptions, limits, and caveats?
• Confirm with experiments where the docs are vague or intentionally open.

5) Learn socially: rely on “like-minded people”

• Share hypotheses and results.
• Hold debriefs: what surprised you, what remains unclear?
• Turn insights into reusable assets (readmes, templates, patterns, checklists).

The pedagogy of cloud: Concepts over click paths

Implicit in Ewen’s remarks is a shift from procedural deployment to conceptual grasp. In Azure and any cloud, click paths don’t transfer well across services, versions, or orgs. Concepts do:

• Identity and access: who talks to whom, with what identity and scope?
• Networks and boundaries: what isolation levels do we truly need?
• State and data: where does state live, how does data flow, what happens on failure?
• Observability: what signals tell us that “it works”?
• Resilience: which degradation paths are acceptable, which must be prevented?

Master these, and you’ll be ready for the volatility Ewen names as core to cloud work.

“Common projects”: Learn in the product, not beside it

Ewen explicitly mentions “common projects.” That’s not just collaboration; it’s learning woven into product work. In our view, that’s the most sustainable form of team growth:

• Real requirements, not abstract exercises.
• Realistic risk: decisions have consequences — contained, but real.
• Shared responsibility: insights flow directly into code, pipelines, and operations.

Run enough edge experiments and then consolidate them into standards. That loop — exploration into codified practice — is how teams turn missing examples into organizational knowledge.

Why “It worked” isn’t a learning goal

Functionality is necessary, but as a learning target it’s too coarse. The interesting questions are:

• Why does it work?
• Under which conditions does it break?
• How do we observe it?
• How do we make it reproducible?
• How do we communicate the assumptions?

These questions shift the goal from “success” to “understanding.” That’s the core of “struggling, luckily.”

A pragmatic Azure learning loop (inspired by Ewen’s guidance)

Without stretching his words, here’s a lightweight loop for deliberate practice:

1. Pick a small product goal (a simple API or web endpoint).
2. Define a learning goal (e.g., private comms, zero public endpoints).
3. Choose one boundary that creates friction (restricted roles, tight networks, an alternative auth model).
4. Build the minimal product — yes, follow the docs at first to establish a baseline.
5. Turn one knob the docs don’t fully spell out.
6. Log everything: hypothesis, change, observation, outcome.
7. Share insights, elevate them into reusable building blocks (readme, template, pattern).
8. Repeat with a new constraint.

This loop is small enough to fit alongside delivery work and strong enough to build durable mental models.

Mental models for productive struggle

Ewen’s talk supports three robust mental models:

• Edge-first design: think from boundaries inward. Which assumptions could be false? Which resource becomes scarce first?
• Hypothesis and disproof: treat every config as a claim — how would you falsify it?
• Social amplifier: turn like-minded peers and common projects into a multiplier that converts personal insight into team capability.

These models travel well across clouds and hybrid setups. The constant is the mindset you bring to ambiguity and change.

Quotes worth remembering

• “There is not always an example, or not even a documentation sometimes.”
• “It’s just working in a field that’s constantly changing.”
• “With people that are like-minded, trying to grow for themselves, and also to work on common projects.”
• “The main thing that you will learn with, is by struggling, luckily.”
• “It will work … and it’s not interesting.”

They read like signposts, pointing to where learning truly happens.

Closing: Learn where the docs grow quiet

In “Ewen Simon, Cloud Architect bei ÖBB,” set within the ÖBB-Konzern, we hear a concise case for context-driven learning in the cloud. Azure is appealing precisely because examples and documentation can be thin, because the field is in constant motion, and because there are like-minded people to learn with on common projects.

The key impulse is simple to say and demanding to practice: go to the border. Not for drama, but for insight. Build small, testable contexts and allow yourself to struggle — “luckily.” That’s where the understanding forms that will carry you in real projects.

For developers and architects, the takeaway is clear: use the happy path as a starting line, not the finish line. The goal is understanding. And you rarely find it in the middle — almost always at the edge.

• 

  

  Natascha Muehl, Back End Developerin bei ÖBB

  Natascha Muehl von der ÖBB redet im Interview über ihren Start in die IT, was ihre Arbeit im Back End Development beinhaltet und gibt Tipps für Beginner.

  Watch now