Building a path to DevOps through simulation

Perhaps the most important “skill” of all is having the strength to avoid banging your head into the keyboard after two hours of staring at the same wall of compiler errors.

As someone who has experience with programming, it can be frustrating. A lot of the frustration stems from hidden problems, ranging from small things like improper syntax to massive headaches like the elusive heisenbug or vaguely-defined segmentation faults. As programs grow in size, these issues become more difficult to decipher, and developers waste an inordinate amount of time troubleshooting and debugging code. For software companies, there is the added step of having to ensure their code works in multiple environments, with different processors from different companies running different compilers. This can be an expensive, wasteful, and, as always, frustrating process.

Another major source of frustration is miscommunication. Issues are often difficult to describe, and it becomes very hard to figure out how to even ask for help. Miscommunications between developmental and operational teams, for example, result in a lot of wasted time on both sides. Simple issues take twice as long to solve, because neither team knows exactly what the other is saying. This has led to a greater emphasis on DevOps. In part, DevOps is the operations staff using the same techniques as the development staff, something that seems obvious that is usually forgone for the sake of faster production. This way, teams on both sides are able to communicate more easily and understand one another better.

At Wind River, we grapple with many of the same issues. Our engineers have to ensure that each of our software platforms, whether it’s our flagship VxWorks real-time operating system (RTOS) or our open-source Wind River Linux, works on a variety of systems without being vulnerable to hacks or unable to navigate tricky scenarios. Testing them on physical hardware would be incredibly time-consuming, as setting up the hardware itself takes a considerable time investment, let alone the arduous task of encountering and solving issues.

Instead, they use Simics.

Simics is a simulation platform that virtually replicates a physical hardware system, allowing developers to run their code on hardware that is not actually present. They can build a library of tests and manipulate the hardware to force it to hit failure paths, then run backwards and forwards in time to isolate the problem. Then, rather than having to show it to other engineers or, even worse, having to try to explain the problem, they can simply send a link to point in the simulation where the code fails, and another developer can examine the problem independently. Simics is a very powerful tool that has significantly improved our development process. Ed Illidge, Vice President of Engineering at Wind River, says that Simics “has allowed us to fix bugs in one-tenth the amount of time” and has “increased automation by 12,000%” by freeing up developer’s time and hastening the development process overall.

We recently put together a short video to share our experience with Simics and how it has enabled us to benefit from DevOps practices. As a company that services a wide variety of customers in multiple industries, having a simulation platform has been critical to our success. To find out more about how Simics has enabled DevOps at Wind River take a look at this video: Wind River Simics – The Path To DevOps.

Blog courtesy of Wind River.