DOCSLIB.ORG

Making Reliable Distributed Systems in the Presence of Sodware Errors Final Version (With Corrections) — Last Update 20 November 2003

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Making Reliable Distributed Systems in the Presence of Sodware Errors Final Version (With Corrections) — Last Update 20 November 2003 Making reliable distributed systems in the presence of sodware errors Final version (with corrections) — last update 20 November 2003 Joe Armstrong A Dissertation submitted to the Royal Institute of Technology in partial fulfilment of the requirements for the degree of Doctor of Technology The Royal Institute of Technology Stockholm, Sweden December 2003 Department of Microelectronics and Information Technology ii TRITA–IMIT–LECS AVH 03:09 ISSN 1651–4076 ISRN KTH/IMIT/LECS/AVH-03/09–SE and SICS Dissertation Series 34 ISSN 1101–1335 ISRN SICS–D–34–SE c Joe Armstrong, 2003 Printed by Universitetsservice US-AB 2003 iii To Helen, Thomas and Claire iv Abstract he work described in this thesis is the result of a research program T started in 1981 to find better ways of programming Telecom applica- tions. These applications are large programs which despite careful testing will probably contain many errors when the program is put into service. We assume that such programs do contain errors, and investigate methods for building reliable systems despite such errors. The research has resulted in the development of a new programming language (called Erlang), together with a design methodology, and set of libraries for building robust systems (called OTP). At the time of writing the technology described here is used in a number of major Ericsson, and Nortel products. A number of small companies have also been formed which exploit the technology. The central problem addressed by this thesis is the problem of con- structing reliable systems from programs which may themselves contain errors. Constructing such systems imposes a number of requirements on any programming language that is to be used for the construction. I discuss these language requirements, and show how they are satisfied by Erlang. Problems can be solved in a programming language, or in the stan- dard libraries which accompany the language. I argue how certain of the requirements necessary to build a fault-tolerant system are solved in the language, and others are solved in the standard libraries. Together these form a basis for building fault-tolerant sodware systems. No theory is complete without proof that the ideas work in practice. To demonstrate that these ideas work in practice I present a number of case studies of large commercially successful products which use this technol- ogy. At the time of writing the largest of these projects is a major Ericsson v vi ABSTRACT product, having over a million lines of Erlang code. This product (the AXD301) is thought to be one of the most reliable products ever made by Ericsson. Finally, I ask if the goal of finding better ways to program Telecom applications was fulfilled—I also point to areas where I think the system could be improved. Contents Abstract v 1 Introduction 1 1.1 Background . 2 Ericsson background ..................... 2 Chronology .......................... 2 1.2 Thesis outline . 7 Chapter by chapter summary ................ 7 2 The Architectural Model 11 2.1 Definition of an architecture . 12 2.2 Problem domain . 13 2.3 Philosophy . 16 2.4 Concurrency oriented programming . 19 2.4.1 Programming by observing the real world . 21 2.4.2 Characteristics of a COPL . 22 2.4.3 Process isolation . 22 2.4.4 Names of processes . 24 2.4.5 Message passing . 25 2.4.6 Protocols . 26 2.4.7 COP and programmer teams . 26 2.5 System requirements . 27 2.6 Language requirements . 28 2.7 Library requirements . 29 2.8 Application libraries . 30 2.9 Construction guidelines . 31 2.10 Related work . 32 vii viii ABSTRACT 3 Erlang 39 3.1 Overview . 39 3.2 Example . 41 3.3 Sequential Erlang . 44 3.3.1 Data structures . 44 3.3.2 Variables . 46 3.3.3 Terms and patterns . 47 3.3.4 Guards . 48 3.3.5 Extended pattern matching . 49 3.3.6 Functions . 50 3.3.7 Function bodies . 52 3.3.8 Tail recursion . 52 3.3.9 Special forms . 54 3.3.10 case . 54 3.3.11 if . 55 3.3.12 Higher order functions . 55 3.3.13 List comprehensions . 57 3.3.14 Binaries . 58 3.3.15 The bit syntax . 60 3.3.16 Records . 63 3.3.17 epp . 64 3.3.18 Macros . 64 3.3.19 Include files . 66 3.4 Concurrent programming . 66 3.4.1 register . 67 3.5 Error handling . 68 3.5.1 Exceptions . 69 3.5.2 catch . 70 3.5.3 exit . 71 3.5.4 throw . 72 3.5.5 Corrected and uncorrected errors . 72 3.5.6 Process links and monitors . 73 3.6 Distributed programming . 76 3.7 Ports . 77 3.8 Dynamic code change . 78 ix 3.9 A type notation . 80 3.10 Discussion . 82 4 Programming Techniques 85 4.1 Abstracting out concurrency . 86 4.1.1 A fault-tolerant client-server . 92 4.2 Maintaining the Erlang view of the world . 101 4.3 Error handling philosophy . 104 4.3.1 Let some other process fix the error . 104 4.3.2 Workers and supervisors . 106 4.4 Let it crash . 107 4.5 Intentional programming . 109 4.6 Discussion . 111 5 Programming Fault-tolerant Systems 115 5.1 Programming fault-tolerance . 116 5.2 Supervision hierarchies . 118 5.2.1 Diagrammatic representation . 120 5.2.2 Linear supervision . 121 5.2.3 And/or supervision hierarchies . 122 5.3 What is an error? . 123 5.3.1 Well-behaved functions . 126 6 Building an Application 129 6.1 Behaviours . 129 6.1.1 How behaviours are written . 131 6.2 Generic server principles . 132 6.2.1 The generic server API . 132 6.2.2 Generic server example . 135 6.3 Event manager principles . 137 6.3.1 The event manager API . 139 6.3.2 Event manager example . 141 6.4 Finite state machine principles . 141 6.4.1 Finite state machine API . 143 6.4.2 Finite state machine example . 144 x ABSTRACT 6.5 Supervisor principles . 146 6.5.1 Supervisor API . 146 6.5.2 Supervisor example . 147 6.6 Application principles . 153 6.6.1 Applications API . 153 6.6.2 Application example . 154 6.7 Systems and releases . 156 6.8 Discussion . 157 7 OTP 161 7.1 Libraries . 163 8 Case Studies 167 8.1 Methodology . 168 8.2 AXD301 . 170 8.3 Quantitative properties of the sodware . 171 8.3.1 System Structure . 174 8.3.2 Evidence for fault recovery . 177 8.3.3 Trouble report HD90439 . 177 8.3.4 Trouble report HD29758 . 180 8.3.5 Deficiencies in OTP structure . 181 8.4 Smaller products . 185 8.4.1 Bluetail Mail Robustifier . 185 8.4.2 Alteon SSL accelerator . 188 8.4.3 Quantitative properties of the code . 189 8.5 Discussion . 190 9 APIs and Protocols 193 9.1 Protocols . 195 9.2 APIs or protocols? . 197 9.3 Communicating components . 198 9.4 Discussion . 199 10 Conclusions 201 10.1 What has been achieved so far? . 201 xi 10.2 Ideas for future work . 202 10.2.1 Conceptual integrity . 202 10.2.2 Files and bang bang . 203 10.2.3 Distribution and bang bang . 204 10.2.4 Spawning and bang bang . 205 10.2.5 Naming of processes . 205 10.2.6 Programming with bang bang . 206 10.3 Exposing the interface - discussion . 207 10.4 Programming communicating components . 208 A Acknowledgments 211 B Programming Rules and Conventions 215 C UBF 247 D Colophon 275 References 277 xii ABSTRACT 1 Introduction ow can we program systems which behave in a reasonable manner in the presence of sodware errors? This is the central question H that I hope to answer in this thesis. Large systems will probably always be delivered containing a number of errors in the sodware, nevertheless such systems are expected to behave in a reasonable manner. To make a reliable system from faulty components places certain re- quirements on the system. The requirements can be satisfied, either in the programming language which is used to solve the problem, or in the standard libraries which are called by the application programs to solve the problem. In this thesis I identify the essential characteristics which I believe are necessary to build fault-tolerant sodware systems. I also show how these characteristics are satisfied in our system. Some of the essential characteristics are satisfied in our programming language (Erlang), others are satisfied in library modules written in Erlang. Together the language and libraries form a basis for building reliable sod- ware systems which function in an adequate manner even in the presence of programming errors. Having said what my thesis is about, I should also say what it is not about. The thesis does not cover in detail many of the algorithms used as building blocks for construction fault-tolerant systems—it is not the al- gorithms themselves which are the concern of this thesis, but rather the programming language in which such algorithms are expressed. I am also 1 2 CHAPTER 1. INTRODUCTION not concerned with hardware aspects of building fault-tolerant systems, nor with the sodware engineering aspects of fault-tolerance. The concern is with the language, libraries and operating system re- quirements for sodware fault-tolerance. Erlang belongs to the family of pure message passing.
Load more

Recommended publications
  • Introducing Elixir Getting Started in Functional Programming [St. Laurent & Eisenberg 2014-09-25].Pdf
    Introducing Elixir Introducing Elixir Introducing Elixir is an excellent language if you want to learn about functional programming, and with this hands-on introduction, you’ll discover just how powerful and fun Elixir can be. This language combines the robust functional programming of Erlang with a syntax similar to Ruby, and includes powerful features for metaprogramming. This book shows you how to write simple Elixir programs by teaching one skill at a time. Once you pick up pattern matching, process-oriented programming, and other concepts, you’ll understand why Elixir makes it easier to build concurrent and resilient programs that scale up and down with ease. ■ Get comfortable with IEx, Elixir’s command-line interface ■ Discover atoms, pattern matching, and guards: the foundations of your program structure ■ Delve into the heart of Elixir with recursion, strings, lists, and higher-order functions ■ Create processes, send messages among them, and apply pattern matching to incoming messages ■ Store and manipulate structured data with Erlang Term Storage and the Mnesia database ■ Build resilient applications with Erlang’s Open Telecom Platform Introducing ■ Define macros with Elixir’s metaprogramming tools St. Laurent & Eisenberg Laurent St. Simon St. Laurent is a Strategic Content Director at O’Reilly Media, Inc., focusing primarily on web-related topics. He is co-chair of O’Reilly’s Fluent and OSCON conferences. Simon has written or co-written books, including Introducing Erlang, Learning Rails 3, and XML Pocket Reference, Third Edition (all O’Reilly). J. David Eisenberg is a programmer and instructor in San Jose, California, with a talent for teaching and explaining.
    [Show full text]
  • Mnesia Database Management System (MNESIA)
    Mnesia Database Management System (MNESIA) version 4.4 Typeset in LATEX from SGML source using the DocBuilder-0.9.8.5 Document System. Contents 1 Mnesia User’s Guide 1 1.1 Introduction.......................................... 1 1.1.1AboutMnesia..................................... 1 1.1.2TheMnesiaDataBaseManagementSystem(DBMS)............... 2 1.2 GettingStartedwithMnesia................................. 4 1.2.1StartingMnesiaforthefirsttime.......................... 4 1.2.2AnIntroductoryExample.............................. 5 1.3 BuildingAMnesiaDatabase................................. 14 1.3.1DefiningaSchema.................................. 15 1.3.2TheDataModel................................... 16 1.3.3StartingMnesia.................................... 16 1.3.4CreatingNewTables................................. 19 1.4 TransactionsandOtherAccessContexts.......................... 21 1.4.1TransactionProperties................................ 22 1.4.2Locking........................................ 23 1.4.3DirtyOperations................................... 27 1.4.4RecordNamesversusTableNames......................... 28 1.4.5ActivityConceptandVariousAccessContexts................... 30 1.4.6Nestedtransactions.................................. 32 1.4.7PatternMatching................................... 33 1.4.8Iteration........................................ 35 1.5 MiscellaneousMnesiaFeatures................................ 36 1.5.1Indexing........................................ 37 1.5.2DistributionandFaultTolerance.........................
    [Show full text]
  • Implementing Erlang/OTP on Intel Galileo
    DEGREE PROJECT, IN INFORMATION TECHNOLOGY, FIRST LEVEL STOCKHOLM, SWEDEN 2015-06-22 Implementing Erlang/OTP on Intel Galileo Paul Coada, Erkut Kaya KTH ROYAL INSTITUTE OF TECHNOLOGY INFORMATION AND COMMUNICATION TECHNOLOGY Abstract The Intel Galileo, inspired by the well-known Arduino board, is a development board with many possibilities because of its strength. The Galileo is has an Intel processor capable of running GNU/Linux and can be connected to the internet, which opens up the possibility to be controlled remotely. The programming language that comes with the Intel Galileo is the same as for the Arduino development boards, and is therefore very limited and does not utilize the Galileo’s entire strength. Our aim with this project is to integrate a more suitable programming language; a language that can make better use of the relatively powerful processor to control the components of the board. The programming language of choice is Erlang, and the reason is obvious. Erlang can be described as a process-oriented programming language based on the functional programming paradigm and its power in concurrency. The result of the project was the successful integration of a complete version of GNU/Linux on the board and the cross-compilation of Erlang/OTP onto the board. Having Erlang running on the system opens up many possibilities for future work, amongst all: creating Erlang programs for the Intel Galileo, integrating an effective API, and measuring the pros and cons of using Erlang on an Intel Galileo. Keywords Embedded, Arduino, multiprogramming, concurrency, Internet of Things, cross-compilation, API Sammanfattning Intel Galileo är ett utvecklingskort som bygger på Arduinos succé.
    [Show full text]
  • Top Functional Programming Languages Based on Sentiment Analysis 2021 11
    POWERED BY: TOP FUNCTIONAL PROGRAMMING LANGUAGES BASED ON SENTIMENT ANALYSIS 2021 Functional Programming helps companies build software that is scalable, and less prone to bugs, which means that software is more reliable and future-proof. It gives developers the opportunity to write code that is clean, elegant, and powerful. Functional Programming is used in demanding industries like eCommerce or streaming services in companies such as Zalando, Netflix, or Airbnb. Developers that work with Functional Programming languages are among the highest paid in the business. I personally fell in love with Functional Programming in Scala, and that’s why Scalac was born. I wanted to encourage both companies, and developers to expect more from their applications, and Scala was the perfect answer, especially for Big Data, Blockchain, and FinTech solutions. I’m glad that my marketing and tech team picked this topic, to prepare the report that is focused on sentiment - because that is what really drives people. All of us want to build effective applications that will help businesses succeed - but still... We want to have some fun along the way, and I believe that the Functional Programming paradigm gives developers exactly that - fun, and a chance to clearly express themselves solving complex challenges in an elegant code. LUKASZ KUCZERA, CEO AT SCALAC 01 Table of contents Introduction 03 What Is Functional Programming? 04 Big Data and the WHY behind the idea of functional programming. 04 Functional Programming Languages Ranking 05 Methodology 06 Brand24
    [Show full text]
  • Erlang – a Platform for Developing Distributed Software Systems
    Erlang – a platform for developing distributed software systems Lars-Ake˚ Fredlund 1 / 55 Problems of distributed systems ■ Distributed programming is hard ■ Challenges for concurrency: ◆ process coordination and communication 2 / 55 Problems of distributed systems ■ Distributed programming is hard ■ Challenges for concurrency: ◆ process coordination and communication ■ And challenges for distributed software: ◆ heterogeneous systems ◆ security, reliability (lack of control) ◆ performance 2 / 55 Distributed Programming Today Todays contrasts: ■ Vision – easy programming of distributed systems ■ The nightmare/reality – Web services, XML, Apache, SOAP, WSDL, . ■ Why are Web services a nightmare? Too many standards, too many tools, too many layers, too complex! ■ Erlang is an Industrially proven solution for developing and maintaining demanding distributed applications ■ Good qualities of Erlang as a distributed systems platform: Complexity encapsulated in a programming language, good performance, efficient data formats, debuggable, not complex 3 / 55 Erlang as a component platform: a summary ■ Processes are the components 4 / 55 Erlang as a component platform: a summary ■ Processes are the components ■ Components (processes) communicate by binary asynchronous message passing 4 / 55 Erlang as a component platform: a summary ■ Processes are the components ■ Components (processes) communicate by binary asynchronous message passing ■ Component communication does not depend on whether components are located in the same node, or physically remote
    [Show full text]
  • The Implementation and Use of a Generic Dataflow Behaviour in Erlang
    The Implementation and Use of a Generic Dataflow Behaviour in Erlang Christopher Meiklejohn Peter Van Roy Basho Technologies, Inc. Universite´ catholique de Louvain Bellevue, WA, United States Louvain-la-Neuve, Belgium [email protected] [email protected] Abstract concurrent programming: developers author code that adheres to a 2 We propose a new “generic” abstraction for Erlang/OTP that aids in specific “behaviour” and these abstractions then provide a com- the implementation of dataflow programming languages and mod- mon way to supervise, manage, and reason about processing con- els on the Erlang VM. This abstraction simplifies the implemen- current messages to a single actor. tation of “processing elements” in dataflow languages by provid- We propose a new Erlang/OTP “generic” abstraction for dataflow ing a simple callback interface in the style of the gen server and programming on the Erlang VM called gen flow. This abstraction gen fsm abstractions. We motivate the use of this new abstraction allows for the arbitrary composition of stateful actors into larger by examining the implementation of a distributed dataflow pro- dataflow computations. This abstraction is sufficiently generic to gramming variant called Lasp. aid in the implementation of an arbitrary dataflow language in Erlang/OTP: we motivate the use of gen flow through the im- Categories and Subject Descriptors D.1.3 [Programming Tech- plementation of a deterministic distributed dataflow variant called niques]: Concurrent Programming; E.1 [Data Structures]: Dis- Lasp. [14, 15] tributed data structures This paper contains the following contributions: Keywords Dataflow Programming, Erlang, Concurrent Program- • gen flow abstraction: We propose gen flow, a new abstrac- ming tion in the style of the “generic” abstractions provided by Er- lang/OTP for building dataflow “processing elements.” 1.
    [Show full text]
  • Francesco Cesarini, Simon Thompson — «Erlang Programming
    Erlang Programming Francesco Cesarini and Simon Thompson Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Erlang Programming by Francesco Cesarini and Simon Thompson Copyright © 2009 Francesco Cesarini and Simon Thompson. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mike Loukides Indexer: Lucie Haskins Production Editor: Sumita Mukherji Cover Designer: Karen Montgomery Copyeditor: Audrey Doyle Interior Designer: David Futato Proofreader: Sumita Mukherji Illustrator: Robert Romano Printing History: June 2009: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Erlang Programming, the image of a brush-tailed rat kangaroo, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein. TM This book uses RepKover™, a durable and flexible lay-flat binding. ISBN: 978-0-596-51818-9 [M] 1244557300 Table of Contents Foreword .
    [Show full text]
  • Elixir Language
    Elixir Language #elixir Table of Contents About 1 Chapter 1: Getting started with Elixir Language 2 Remarks 2 Versions 2 Examples 2 Hello World 2 Hello World from IEx 3 Chapter 2: Basic .gitignore for elixir program 5 Chapter 3: Basic .gitignore for elixir program 6 Remarks 6 Examples 6 A basic .gitignore for Elixir 6 Example 6 Standalone elixir application 6 Phoenix application 7 Auto-generated .gitignore 7 Chapter 4: basic use of guard clauses 8 Examples 8 basic uses of guard clauses 8 Chapter 5: BEAM 10 Examples 10 Introduction 10 Chapter 6: Behaviours 11 Examples 11 Introduction 11 Chapter 7: Better debugging with IO.inspect and labels 12 Introduction 12 Remarks 12 Examples 12 Without labels 12 With labels 13 Chapter 8: Built-in types 14 Examples 14 Numbers 14 Atoms 15 Binaries and Bitstrings 15 Chapter 9: Conditionals 17 Remarks 17 Examples 17 case 17 if and unless 17 cond 18 with clause 18 Chapter 10: Constants 20 Remarks 20 Examples 20 Module-scoped constants 20 Constants as functions 20 Constants via macros 21 Chapter 11: Data Structures 23 Syntax 23 Remarks 23 Examples 23 Lists 23 Tuples 23 Chapter 12: Debugging Tips 24 Examples 24 Debugging with IEX.pry/0 24 Debugging with IO.inspect/1 24 Debug in pipe 25 Pry in pipe 25 Chapter 13: Doctests 27 Examples 27 Introduction 27 Generating HTML documentation based on doctest 27 Multiline doctests 27 Chapter 14: Ecto 29 Examples 29 Adding a Ecto.Repo in an elixir program 29 "and" clause in a Repo.get_by/3 29 Querying with dynamic fields 30 Add custom data types to migration and to schema
    [Show full text]
  • The Implementation and Use of a Generic Dataflow Behaviour in Erlang
    The Implementation and Use of a Generic Dataflow Behaviour in Erlang Christopher Meiklejohn Peter Van Roy Basho Technologies, Inc. Universite´ catholique de Louvain Bellevue, WA, United States Louvain-la-Neuve, Belgium [email protected] [email protected] Abstract concurrent programming: developers author code that adheres to a 2 We propose a new “generic” abstraction for Erlang/OTP that aids in specific “behaviour” and these abstractions then provide a com- the implementation of dataflow programming languages and mod- mon way to supervise, manage, and reason about processing con- els on the Erlang VM. This abstraction simplifies the implemen- current messages to a single actor. tation of “processing elements” in dataflow languages by provid- We propose a new Erlang/OTP “generic” abstraction for dataflow ing a simple callback interface in the style of the gen server and programming on the Erlang VM called gen flow. This abstraction gen fsm abstractions. We motivate the use of this new abstraction allows for the arbitrary composition of stateful actors into larger by examining the implementation of a distributed dataflow pro- dataflow computations. This abstraction is sufficiently generic to gramming variant called Lasp. aid in the implementation of an arbitrary dataflow language in Erlang/OTP: we motivate the use of gen flow through the im- Categories and Subject Descriptors D.1.3 [Programming Tech- plementation of a deterministic distributed dataflow variant called niques]: Concurrent Programming; E.1 [Data Structures]: Dis- Lasp. [14, 15] tributed data structures This paper contains the following contributions: Keywords Dataflow Programming, Erlang, Concurrent Program- • gen flow abstraction: We propose gen flow, a new abstrac- ming tion in the style of the “generic” abstractions provided by Er- lang/OTP for building dataflow “processing elements.” 1.
    [Show full text]
  • Getting Started with Erlang
    Getting Started with Erlang version 5.2 Typeset in LATEX from SGML source using the DOCBUILDER 3.2.2 Document System. Contents 1 Getting Started with Erlang 1 1.1 GettingStartedwithErlang................................. 1 1.1.1Introduction...................................... 1 1.1.2WorkingwithErlang................................. 2 1.1.3TheErlangShell................................... 5 1.1.4 Compiling . 13 1.1.5DebuggingwithPman................................ 16 1.1.6DistributedErlang.................................. 18 1.1.7Configuration..................................... 22 List of Figures 23 List of Tables 25 Bibliography 27 Getting Started with Erlang iii iv Getting Started with Erlang Chapter 1 Getting Started with Erlang 1.1 Getting Started with Erlang 1.1.1 Introduction This chapter describes the most common tasks users perform in Erlang/OTP and is intended for readers who are running Erlang/OTP for the first time. It also contains references to more detailed information. This manual assumes that you have another source of information about how the language Erlang works. The first chapter of the book Concurrent Programming in ERLANG,[Concurrent Programming in ERLANG [1]], is available online in PDF1 format. This manual will describe how to ¯ compile and run Erlang programs ¯ work with the Erlang shell, this is the most central part of the development environment ¯ use the basic tools, Debugger and Pman This manual will also describe differences in development environment on the Unix and Windows platforms. Manual conventions The following conventions are used to describe commands, which are entered from the keyboard in the Erlang shell, or on the Emacs command line: window-based ¯ to enter the command C-c: Press the Control key and the letter c simultaneously. C-c is equivalent to ^c.
    [Show full text]
  • Go Big - Scaling Erlang
    Informatix Solutions GO BIG - SCALING ERLANG Richard Croucher Page 1 © - Informatix Solutions, 2014 Version 1.0 Informatix Background and Biases – Richard Croucher Solutions • Platform architect • Chief Architect at Sun Microsystems where I helped create the dotcom deployment standard and designed and deployed a 1024 server cluster • Principle DevOPs Architect at Microsoft for all its Internet properties . Adding 4000 servers a month. Established the dynamic computing working group to create design patterns for Cloud computing • Primary focus over the last decade has been High Frequency Trading systems for Banks - pushing technology to extremes • Involved with several Cloud startups • Code in multiple languages • Transitioned through Assembler, Pascal, C, C++, Java , C# and Erlang • Love new technology and finding novel ways to use existing technologies • Degrees in Physics, Electronics and Materials Science • Elected Fellow of the British Computer Society and Fellow of STAC Research • See www.informatix-sol.com Page 2 © - Informatix Solutions, 2014 Version 1.0 Informatix My Erlang journey Solutions Wow! Erlang is great Page 3 © - Informatix Solutions, 2014 Version 1.0 Informatix My Erlang journey Solutions OTP has all I need Wow! Erlang is great Page 4 © - Informatix Solutions, 2014 Version 1.0 Informatix My Erlang journey Solutions c("tcp-test"). tcp-test.erl:4: bad module declaration Immutable variables take some getting used to OTP has Where’s ‘while’ all I OTP is so hard need Limited atoms Slow maths chatty Wow! OOM Erlang is great Page 5 © - Informatix Solutions, 2014 Version 1.0 Informatix My Erlang journey Solutions c("tcp-test"). tcp-test.erl:4: bad module declaration Immutable variables take some getting used to OTP has Where’s ‘while’ all I OTP is so hard need Limited atoms Slow maths chatty Wow! OOM Erlang is great Page 6 © - Informatix Solutions, 2014 Version 1.0 Informatix My Erlang journey Solutions c("tcp-test").
    [Show full text]
  • Elixir in Action
    SECOND EDITION Saša Juric´ Sample Chapter MANNING Elixir in Action by Saša Jurić Chapter 1 Copyright 2019 Manning Publications brief contents 1 ■ First steps 1 2 ■ Building blocks 16 3 ■ Control flow 63 4 ■ Data abstractions 102 5 ■ Concurrency primitives 129 6 ■ Generic server processes 159 7 ■ Building a concurrent system 179 8 ■ Fault-tolerance basics 201 9 ■ Isolating error effects 224 10 ■ Beyond GenServer 251 11 ■ Working with components 277 12 ■ Building a distributed system 305 13 ■ Running the system 334 v First steps This chapter covers 1 ¡ Overview of Erlang ¡ Benefits of Elixir This is the beginning of your journey into the world of Elixir and Erlang, two effi- cient and useful technologies that can significantly simplify the development of large, scalable systems. Chances are, you’re reading this book to learn about Elixir. But because Elixir is built on top of Erlang and depends heavily on it, you should first learn a bit about what Erlang is and the benefits it offers. So let’s take a brief, high-level look at Erlang. 1.1 About Erlang Erlang is a development platform for building scalable and reliable systems that constantly provide service with little or no downtime. This is a bold statement, but it’s exactly what Erlang was made for. Conceived in the mid-1980s by Ericsson, a Swedish telecom giant, Erlang was driven by the needs of the company’s own tele- com systems, where properties like reliability, responsiveness, scalability, and con- stant availability were imperative. A telephone network should always operate 1 2 CHAPTER 1 First steps regardless of the number of simultaneous calls, unexpected bugs, or hardware and software upgrades taking place.
    [Show full text]