Fault-Tolerance on the Cheap: Making Systems That (Probably) Won't Fall Over
Building computer systems that are reliable is hard. The functional programming community has invested a lot of time and energy into up-front-correctness guarantees: types and the like. Unfortunately, absolutely correct software is time-consuming to write and expensive. Fault-tolerant systems achieve system-total reliability by accepting that sub-components will fail and planning for that failure as a first-class concern of the system. As companies embrace the wave of "as-a-service" architectures, failure of sub-systems become a more pressing concern. Using examples from heavy industry, aeronautics and telecom systems, this talk will explore how you can design for fault-tolerance using functional programming techniques, type theory, monitoring, instrumentation and effective team dynamics.
Outline/Structure of the Talk
This talk will define the system under discussion, important software and possibly mechanical devices with some mission-critical constraints. Approaches to building such systems commonly seen will be defined and their benefits and costs analyzed. Once done, the fault-tolerant approach will be discussed in more detail, giving the audience an effective overview with regard to getting started in such system design.
The audience will be capable of designing and re-evaluating existing systems along fault-tolerant lines. They will have materials for further study, context necessary to put such study to practice. It is my intention to impart a certain kind of view toward fault-tolerance as well, one of precise urgency which can be addressed in a relaxed professional environment.
Software engineers, architects, project management, engineering management, students
schedule Submitted 7 years ago
People who liked this proposal, also liked:
Brian Lee Troutwine - Instrumentation and Monitoring for Functional ArchitecturesBrian Lee TroutwineSr. Software EngineerAdRoll
schedule 7 years agoSold Out!
Using a hands-on format, this workshop will address the design and construction of a well-understood back-of-house system found in larger organizations: a resource-consumption based billing system. We will focus on multi-group collaboration to build a service-oriented architecture with individual groups being responsible for a service vertical. Basic infrastructure tools and specific goals for each service vertical will introduce and teach functional concepts that will be immediately useful in existing production environment. Each service vertical and the total integrated system will be exercised by a tool that I will provide. Intra-component protocols will be well-specified and groups will be free to meet their goals as they see fit. No specific language will be used. Participants are encouraged to use languages they are comfortable with. The principles being taught in this workshop will require functional architectures and this will be covered explicitly. Special emphasis will be placed on designing for instrumentation and monitoring using functional principles and the goals of the workshop will support this emphasis.
Ravi Mohan - Building a General Game Playing Engine with OCaml and ErlangRavi MohanCEOAxiomChoice
schedule 7 years agoSold Out!
"General Game Playing is the design of artificial intelligence programs that play more than one game" Wikipedia 
In other words, one program has to be able to play (and win!) multiple games ( Chess, checkers, Go, Othello etc).
Summary: This experience report is about my "Forever Project" [2,3,4] to build such a system in OCaml, and the problems (theoretical and practical) and will include a demo of the program, warts and all.
Detail: GGP is an active CS research area Annual competitions are held every year where ggp programs compete against each other, playing games which they have never seen before (the rules are supplied as an input file for the system to consume five minutes before the match begins).
Over the last year, in my non-existent spare time, I've been building a GGP engine to compete in a GGP competition.
Most such engines are written in Java, C++ etc.. I'm using OCaml for the game playing agent, and Manoj is building the backend in Erlang.
As mentioned above this is our "Forever Project" We've made some decent progress.
Come, see, laugh, jeer!