DEV Community: Sebastian Dingler

Understanding Virtual Platforms: Exploring the Levels of Virtualisation

Sebastian Dingler — Wed, 27 Aug 2025 15:49:05 +0000

Over the last decade, the idea of virtualisation has quietly become one of the most influential forces in technology. Whether we notice it or not, it shapes how we develop cars, test software, run data centers, and even stream movies on our phones. At the heart of this movement lies the concept of virtual platforms—digital representations of physical systems that allow engineers and developers to experiment, test, and validate without relying on expensive hardware.

But not all virtualisation is the same. There are different layers and levels of abstraction, each with its own strengths, trade-offs, and use cases. To understand where virtual platforms fit in, let’s break down the main levels of virtualisation.

1. Hardware Virtualisation

This is often the first layer people think of. Hardware virtualisation creates a software-based representation of a physical machine. Instead of running directly on the hardware, applications run on a virtual machine (VM), which behaves as if it were the real device.

A good example is server virtualisation. Data centers use hypervisors like VMware, Hyper-V, or KVM to run multiple operating systems on one physical server. Each VM believes it has its own CPU, memory, and storage, while in reality it shares resources.

The benefit? Higher efficiency, lower cost, and flexibility. But it comes with overhead—emulating hardware consumes extra computing power.

2. Operating System Virtualisation

One step above hardware is OS-level virtualisation. Instead of creating full machines, this level slices a single operating system into isolated environments, often called containers.

Think of Docker or Kubernetes. Here, you don’t emulate hardware; you package applications and their dependencies into lightweight units. Containers start in seconds, use fewer resources, and can be easily moved across environments.

Compared to hardware virtualisation, OS-level virtualisation trades completeness for speed. You can’t run two different operating systems in the same container host, but for cloud-native applications this model is hard to beat.

3. Application Virtualisation

Sometimes, it’s not the machine or the OS that needs to be virtualised—it’s the application itself. Application virtualisation allows programs to run in environments where they normally wouldn’t, often without being installed in the usual way.

For example, enterprise IT teams use application virtualisation to run older business apps on modern operating systems. The app believes it’s interacting with a local OS, while in fact, it’s working inside a controlled, redirected environment.

This level is about compatibility and portability. It reduces conflicts, eases deployment, and extends the lifespan of legacy software.

4. Virtual Platforms for Development and Testing

Now, let’s zoom in on the engineering world. A virtual platform is a digital twin of a system—be it a car’s control unit, a smartphone processor, or even an entire aircraft subsystem. Unlike general hardware or OS virtualisation, here the focus is on simulating hardware behavior with enough accuracy to run unmodified software on top.

For automotive companies, this is transformative. Engineers can test control algorithms on a virtual ECU before the first prototype vehicle is even built. In aerospace, safety-critical systems can be validated in silico, long before a physical test flight.

The main advantage lies in speed and accessibility. Virtual platforms allow multiple teams worldwide to access the same “machine” simultaneously, iterate quickly, and catch issues early—without being bottlenecked by scarce hardware.

5. Mixed and Hybrid Virtualisation

In practice, the world is rarely black and white. Many organisations use a hybrid approach, mixing different levels of virtualisation to balance cost, speed, and realism.

For example:

Developers may use virtual platforms to design software.
Integration teams may run OS-level containers for large-scale testing.
Hardware teams may still rely on physical prototypes for final validation.

This layered approach allows each stage of development to get the right tool for the job, instead of forcing a one-size-fits-all model.

Why Virtualisation Matters More Than Ever

The industry is facing shorter development cycles, stricter safety requirements, and skyrocketing complexity. Physical prototypes are expensive, limited in availability, and slow to iterate on. Virtualisation is not just a technical choice—it’s a strategic enabler.

By leveraging different levels of virtualisation, organisations can:

Reduce costs by cutting dependency on physical prototypes.
Accelerate development by enabling early and parallel testing.
Improve quality by catching design flaws earlier in the process.
Scale collaboration across global teams.

Final Thoughts

Virtualisation is no longer just about running a few virtual machines on a server. It’s a spectrum—from low-level hardware emulation to high-level application isolation—and virtual platforms sit at the center of this transformation.

The deeper we go into digital engineering, the clearer it becomes: mastering the different levels of virtualisation isn’t just an IT skill. It’s a core capability for building the complex systems of tomorrow.

EARS: The Easy Approach to Requirements Syntax

Sebastian Dingler — Fri, 03 Jan 2025 20:00:07 +0000

Alistair Mavin and a team from Rolls-Royce PLC first introduced the Easy Approach to Requirements Syntax (EARS) at the Requirements Engineering (RE 09) conference in 2009. Since then, the EARS requirement syntax has become a go-to framework for simplifying how we write and organize software requirements.

In this article, we will explore what EARS requirement syntax is, why it’s important, and how it can significantly improve the clarity and quality of your software requirements. We’ll also address common challenges in requirements writing and show how EARS provides a systematic way to overcome them.

What Is a Requirement?

Before diving into EARS requirement syntax, it’s crucial to understand what a requirement is. In software development, a requirement refers to a statement that describes:

Functional requirements (FRs)
- The actions or functions a system must perform.
Non-functional requirements (NFRs)
- Known limitations or resource constraints.
- Desired performance or quality levels.

Example Functional Requirements

A website must allow users to create an account and log in securely.
A mobile app must enable users to purchase products using their credit card.

Example Non-Functional Requirements

The website must handle high traffic volumes without downtime.
The mobile app must be compatible with Android and iOS.

Common Challenges in Writing Requirements

Even though requirements are the foundation of successful software projects, many teams face challenges such as:

Lack of formal training on effective requirement writing.
Use of natural language without constraints, leading to ambiguity.
Requirements not being clear, concise, or coherent.
Missing triggers or important context.
Incomplete logic within requirements.
Copy-and-paste duplication leading to an increase in defective requirements.

Introducing EARS: Easy Approach to Requirements Syntax

The EARS requirement syntax was developed to simplify and standardize how requirements are written. Rather than wrestling with overly complex sentences or missing details, EARS provides a straightforward template that ensures each requirement is well-defined, easy to read, and consistently structured.

Five EARS Patterns

EARS differentiates requirements into five primary patterns:

Ubiquitous (Always Occurring)

Defines fundamental properties of the system.

Example: “The software shall be written in Python.”
Event-Driven

Triggered only when a specific event occurs.

Example: “When the payment is received, then the app shall send a notification.”
Unwanted Behaviors

Manages undesired occurrences such as errors, failures, or faults.

Example: “If the password is entered incorrectly, then the app shall display an error message.”
State-Driven

Activated while the system is in a particular state.

Example: “When in Do Not Disturb mode, then the software shall silence incoming calls.”
Optional Features

Applies only if a certain optional feature is present.

Example: “Where the DisplayPort is present, then the software shall allow users to select the maximum supported refresh rate.”

In some cases, requirements can also be complex, combining multiple triggers and conditions. For instance:

Complex Requirement Example

“When the reverse gear button is pressed once, if the software detects that the gear is not engaged, then the software shall display a notification.”

Applying EARS Requirement Syntax to Ambiguous Requirements

One of the key benefits of EARS requirement syntax is its ability to transform vague, ambiguous requirements into clear, actionable statements. Consider this original requirement:

Original Requirement:

“The system shall break network connection.”

Rewritten Using EARS Requirement Syntax

“When the disconnect button is pressed, then the software shall break the network connection.”

By specifying the condition (“When the disconnect button is pressed”) and the desired action (“the software shall break the network connection”), we remove ambiguity and provide a clear trigger-action relationship.

Conclusion

The EARS requirement syntax offers a powerful yet easy-to-implement framework for writing clear, consistent software requirements. By adopting EARS, development teams can avoid common pitfalls—such as ambiguity, missing triggers, and incomplete logic—and ensure that their requirements are both understandable and verifiable.

Whether you’re working on a small application or a large-scale enterprise system, implementing the EARS requirement syntax can help streamline your requirements engineering process. This leads to better communication among team members, clearer project objectives, and ultimately, a more successful software solution.

Embrace EARS, and take the complexity out of writing requirements—so you can focus on building software that meets its goals and delights its users.

If you need assistant with requirements for your next requirements review you can try AI assisted requirements tools.

Requirements review

Sebastian Dingler — Thu, 02 Jan 2025 08:28:23 +0000

A Gentle Introduction to Covariance Intersection

Sebastian Dingler — Wed, 11 Dec 2024 22:27:33 +0000

Imagine you’re keeping track of something—perhaps the position of a moving car—using two different methods at once. Maybe you have a camera measuring its location and also a GPS sensor. Both give you estimates of where the car is, but each measurement comes with a certain “uncertainty.” You might know how reliable each individual source is, but it’s often tricky to figure out how these different pieces of information relate to each other. For instance, did the camera and the GPS make similar kinds of mistakes at the same time? Are their errors connected in some way? When you try to combine their results into one improved estimate, ignoring these hidden connections can cause big problems.

This is where something called covariance intersection steps in. It’s a method for blending information from multiple sources—even if you have no idea how their errors interact—without producing an overly optimistic or misleading final estimate.

Why Is This Important?

In many real-world scenarios, we fuse data from multiple sensors or calculations to keep track of something: a robot’s position in a warehouse, a drone’s path in the sky, or even the state of financial indicators. Commonly used tools, like the Kalman filter, work beautifully when you know how each pair of data sources is related. If the Kalman filter “thinks” two sources are independent when they’re not, it can become too confident and start making big errors. This can lead to serious issues, like a robot losing track of where it is.

Covariance intersection was developed to prevent this from happening. Think of it like a safety net. It ensures that when you merge two estimates, you always end up with a combined confidence level that makes sense, never pushing the new estimate to be unrealistically certain.

The Core Idea Behind Covariance Intersection

At its heart, covariance intersection takes the uncertainties from two sources of information and finds a middle ground that cannot be wrong, even if you guessed incorrectly about their correlation (which is a fancy word for how their errors are connected). Instead of assuming they’re fully independent or heavily dependent, covariance intersection picks a sweet spot between the two extremes.

Mathematically, it involves a special weighting factor that you can tune to produce a conservative and meaningful combined uncertainty. In simpler terms, it combines the strengths of both pieces of information without allowing their unknown relationship to “cheat” the system and make your final guess look better than it really is.

A Practical Example

Let’s say you have two weather forecasts predicting tomorrow’s temperature. One forecast might be from a local weather station, while another might be from a smartphone app. Both predictions include some margin of error. You don’t know if these two predictions tend to be off in the same way or not—they might be making similar mistakes or completely different ones.

If you just took a regular weighted average without thinking about their possible connection, you might end up too sure about your final prediction. With covariance intersection, you blend these forecasts and their uncertainties in such a way that you never overestimate how accurate your final guess is. You get a safe, reliable combined estimate that avoids the pitfalls of ignoring unknown relationships between errors.

Why It Matters in Sensor Fusion and Beyond

In fields like robotics, drones, and self-driving cars, understanding and controlling uncertainty is crucial. Poorly combined sensor data can cause the navigation system to drift away from reality. Covariance intersection helps maintain a level-headed, trustworthy perspective. It guarantees that even when you don’t know if your different data sources are making errors in sync, you won’t end up with estimates that are unrealistically sure of themselves.

This approach has proven its worth in large-scale applications, such as simultaneous localization and mapping (SLAM), where a robot or vehicle tries to figure out its own position while also building a map of its surroundings. Researchers have found that using covariance intersection can keep the system stable and reliable, even when dealing with huge amounts of data and uncertain relationships between various measurements.

In Summary

Covariance intersection is a technique that ensures you don’t become overconfident when blending uncertain estimates from different sources. By carefully balancing uncertainties without assuming how they’re related, it helps keep your combined estimate honest, stable, and ready to face the complexities of the real world.

Microservices: Understanding the Trade-Offs and Finding the Right Balance

Sebastian Dingler — Mon, 09 Dec 2024 22:13:37 +0000

Note to the Reader: If you’re short on time, feel free to jump ahead to the conclusion where you’ll find a concise summary of the biggest pain points.

I’ve witnessed firsthand the promise and pitfalls of the microservice architecture pattern. Especially, small teams and start-ups take the path of microservice and just over-engineer. Microservices are often heralded as the key to greater flexibility, improved scalability, and more autonomous development teams. In theory, microservices can simplify development, reduce the need for extensive coordination, and facilitate rapid decision-making. Yet, in practice, they can also introduce significant complexity, skyrocketing costs, and daunting operational overhead. In my experience the latter point gets often underestimated.

Why Microservices in the First Place?

The allure of microservices lies in their promise of modularity. By breaking a large application into small, independently deployable components, teams can develop, test, and deploy their features more rapidly. Autonomy improves, meeting overhead decreases, and, in theory, scaling and fault isolation become easier. Instead of scaling an entire monolithic application, you can scale only what’s needed.

The Data Challenge

Underneath their simplicity in concept, microservices often lead to complex data challenges. In a monolith, a single database and an ORM (Object-Relational Mapper) make queries and joins straightforward. With microservices, each service ideally has its own database, fragmenting the data model. Queries that once required a single SQL join now involve multiple API calls, manual stitching of data, and custom code to emulate once-simple relationships.

Performance and the Call Graph Problem

One major overlooked factor is performance. Calls within a monolith are incredibly fast, while service-to-service communication involves network hops, increasing latency. The more services you add, the greater the cumulative delay. Teams often try to fix these issues with caching, load balancing, and more intricate network topologies—adding further complexity and cost.

Consistency and Transactions

With a single database, robust transactional guarantees come easily. Distributed data across many services breaks traditional transaction models, making data consistency a significant challenge. Patterns like Sagas, event sourcing, and CQRS attempt to restore order, but they introduce their own complexities and often result in “eventual consistency” rather than the immediate consistency developers and users may expect.

Operational Overhead and Tooling

A monolith might require just a single server and database. In contrast, microservices demand orchestration frameworks, centralized logging, monitoring, tracing, service discovery, and more. Costs can mount quickly, and what once seemed like a more flexible approach can devolve into a complex and expensive undertaking.

Technology Sprawl and Governance

Microservices’ autonomy can lead to a fragmented technology landscape. Different teams choose different libraries, frameworks, and architectural patterns even if you limit to one single programming language. Without strong governance and standardization, your codebase becomes inconsistent, and maintenance gets harder.

Where’s the Sweet Spot?

Microservices can work greatly if you’re at the scale of Amazon, Netflix, or similarly large, complex systems. For many projects, the effort might not pay off. A well-structured monolith—or a minimal number of services—can be just as effective and far easier to maintain.

Conclusion: The Biggest Pain Points

Before committing to microservices, consider these critical challenges:

Complex Data Management: Fragmented databases make joins, transactions, and consistency far harder.
Performance Overheads: Multiple network hops increase latency, often requiring caches and more infrastructure.
Operational Complexity: Dozens of services mean intricate deployments, service discovery, logging, monitoring, and tracing solutions.
Rising Costs: Cloud resources, tooling, and maintenance expenses can balloon compared to a single, well-structured monolith.
Inconsistent Technology Stack: Without governance, services can diverge technologically, complicating maintenance and onboarding.

Microservices are a powerful architectural style, but they’re not a silver bullet for the most projects. Think carefully about your use case, scale, and organizational maturity before embracing them and challenge your dev team. Sometimes, simpler solutions deliver more value with fewer headaches.