Tweet
Tweet

Slide 1

Slide 1 text

eNigeria 2018 Masterclass Session Shuaib Afegbua |> @afegbuas LET IT CRASH: TECHNIQUES FOR BUILDING DISRUPTIVE SOFTWARE For a Concurrent World

Slide 2

Slide 2 text

SHUAIB AFEGBUA @afegbuas Software Craftsman Long love affair with Java. Also writes Elixir, Scala and others

Slide 3

Slide 3 text

My past, present and possible future ● Computer Science major (FUTMINNA and ABU) ● Worked at Mott Macdonald/Cambridge Education for a long time and some other places ● Got tired, quit and stayed at home. @afegbuas

Slide 4

Slide 4 text

My past, present and possible future ● Got bored and started #buildingTheFuture (what the hell is that?) at ECTORIUM ● I love building things - comvers, spaces.ng, powershop.ng and some others I can’t list here ● Amateur writer ● I have an addiction bleeding edge technology ● Got another addiction - READING @afegbuas

Slide 5

Slide 5 text

Some stuff I built or still building with friends

Slide 6

Slide 6 text

WWW.POWERSHOP.NG

Slide 7

Slide 7 text

WWW.SPACES.NG

Slide 8

Slide 8 text

Sometimes I write https://medium.com/@afegbua

Slide 9

Slide 9 text

WECODE Community http://bit.ly/graphql-saturday

Slide 10

Slide 10 text

In the beginning was? @afegbuas

Slide 11

Slide 11 text

IDEA You have this great idea that will change the world

Slide 12

Slide 12 text

Prototyping You start small, make wireframes and to test your ideas

Slide 13

Slide 13 text

An MVP Something you can ship out to user. A Minimum Valuable, Viable, Validating, Product.

Slide 14

Slide 14 text

Launch & Feedback You test the market and get feedback from users, sometimes cruel responses

Slide 15

Slide 15 text

Iterate

Slide 16

Slide 16 text

Traction Your idea, product, etc. gains popularity or acceptance.

Slide 17

Slide 17 text

Scale {:ok, “my app is highly available”} OR {:error, “I don die”}

Slide 18

Slide 18 text

What the heck is this talk about? @afegbuas

Slide 19

Slide 19 text

How and why should you care about scaling? @afegbuas

Slide 20

Slide 20 text

Let’s understand some terms I will throw around @afegbuas

Slide 21

Slide 21 text

Program @afegbuas Software operating system OS process Concurrency Parallelism Go JVM Scheduler OTP Erlang Actor model

Slide 22

Slide 22 text

Why should you I build for this? @afegbuas

Slide 23

Slide 23 text

Networked age @afegbuas

Slide 24

Slide 24 text

1980s and early 90s Mostly desktops @afegbuas

Slide 25

Slide 25 text

1989 Tim Berners Lee @afegbuas

Slide 26

Slide 26 text

2005 1 BILLION USERS @afegbuas

Slide 27

Slide 27 text

2017 3.4 BILLION USERS @afegbuas

Slide 28

Slide 28 text

@afegbuas 60 billion Whatsapp messages Over 2.5 quintillion bytes of data daily (2.5 x 1018 or 2 trillion million) => 10 million blu-ray disc 24/7 connected systems Social networks Web servers Multi players game

Slide 29

Slide 29 text

What becomes imperative? “The system must be responsive, regardless of the number of connected clients. The impact of unexpected errors must be as minimal as possible, instead of affecting the entire system. It’s acceptable if an occasional request fails due to a bug, but it’s a major problem when the entire system becomes completely unavailable. Ideally, the system should never crash or be taken down, not even during a software upgrade. It should always be up and running, providing the service to its clients.” ... SAS ̌ A JURIC ́

Slide 30

Slide 30 text

What ? @afegbuas

Slide 31

Slide 31 text

What is a highly available system A software that is always online without downtime and provides service to their clients even when faced with unexpected circumstances. Hence it has to be fault tolerant, scalable, responsive and distributed. @afegbuas

Slide 32

Slide 32 text

Fault tolerance ● A system has to keep working when something unforeseen happens. ● Minimise, isolate, and recover from the runtime errors effects to keep the system up @afegbuas

Slide 33

Slide 33 text

Scalability ● Handle increase in load ● Additional hardware without change in code @afegbuas

Slide 34

Slide 34 text

Distributed ● Run on multiple computers and handle failed ● Horizontal scaling @afegbuas

Slide 35

Slide 35 text

Responsiveness ● System reasonably fast and responsive ● No prolonged request handling, even if the load increases or unexpected errors happen ● Lengthy tasks shouldn’t block the rest of the system or have a significant effect on performance. @afegbuas

Slide 36

Slide 36 text

Live updating ● Pushing update code shouldn’t require without restarting any servers @afegbuas

Slide 37

Slide 37 text

Real-life Use Cases

Slide 38

Slide 38 text

WhatsApp ● 55 Billion messages per day ● 35 engineers at 450M user, 50 at 900M users ● 1 Billion active daily users ● 1.3 billion active monthly users ● 1 billion videos per day ● 4.5 Billion photos per day ● 60 supported languages

Slide 39

Slide 39 text

BleacherReport ● World 2nd largest sports website, gets 1.5 billion page views per month and 250,000 users at its peak ● Initially on Ruby on Rails, but later, they experienced issues with scaling. ● They moved from 150 to 5 AWS servers. ● From 50 engineers to 15

Slide 40

Slide 40 text

Pinterest ● 250 million monthly active users as of October 2018 ● Rewrote their api: 50 percent response time is around 500 microseconds with a 90 percent response time of 800 microseconds., microseconds! ● 90% reduction in lines of code 10,000 to 1000

Slide 41

Slide 41 text

Moz ● An analytic company that helps clients to be more visible in search engines ● They adopted Elixir to create a database-free solution for analytics That became faster than the database solution

Slide 42

Slide 42 text

BET 365 ● They handle over 6 million HTTP requests and more than 500,000 database transactions per second! ● They deliver live online experiences in 17 languages to over 11 million customers worldwide.

Slide 43

Slide 43 text

CDFIPB Recruitment ● You all know tales from online recruitment in Nigeria ● 41K concurrent users at peak period. An average of 1K users on low period ● We had two commodity servers hosted on linode

Slide 44

Slide 44 text

Aeternity ● A blockchain company ● Need to scale their distributed system and peer-to-peer network by providing fault tolerant systems capable of scaling to billions of potential users.

Slide 45

Slide 45 text

Others

Slide 46

Slide 46 text

{:ok, “that’s enough”} @afegbuas

Slide 47

Slide 47 text

How to handle a billion users? @afegbuas

Slide 48

Slide 48 text

The Erlang/OTP BEAM as a case study @afegbuas

Slide 49

Slide 49 text

Concurrency Many things happening at a time Parallelism Two or more things happening simultaneously @afegbuas

Slide 50

Slide 50 text

Concurrency models @afegbuas

Slide 51

Slide 51 text

Shared memory concurrency ● Components communicate by altering content of memory locations. ● Mainly handled by the OS ● Uses locks to to communicate between threads ● C#, Java, C, C++, .

Slide 52

Slide 52 text

Message based concurrency ● Communicate by sharing messages between processes (Actors) ● A process is an independent and usually different from OS process ● Erlang, Elixir, LFE, Akka (Scala and Java), Dart, occam.

Slide 53

Slide 53 text

How and why do this in Erlang/OTP ? @afegbuas

Slide 54

Slide 54 text

Erlang Erlang is platform for building highly available systems. It consisting of four distinct parts: ● the language, ● the virtual machine, ● the framework ● the tools.

Slide 55

Slide 55 text

How Erlang? A little bit of story of the tortoise fell from heaven and cracked it shell Conceived by Ericsson team led by Joe Armstrong, in the 80s to solve their telecom needs Sas Juric: “A telephone network should always operate regardless of the number of simultaneous calls, unexpected bugs, or hardware and software upgrades taking place.” @afegbuas

Slide 56

Slide 56 text

Design goal To provide 99.9999999% availability = 1 second downtime every 32 years Erlang is sometimes called a concurrency-oriented language.. ● Compiled ● Immutable state ● Functional paradigm ● Abstracted Processes ● Message based concurrency ● Supervision tools ● Distributed @afegbuas

Slide 57

Slide 57 text

Erlang Concurrency Model @afegbuas

Slide 58

Slide 58 text

Process ● The process is the basic unit of concurrency ● Lightweight and cheap - about 1kb/2kb initial memory footprint. Can grow and shrink as required ● No shared state/memory thus never need to compete for locks for access to shared data. ● They communicate by sending messages. The receiver gets a read only copy of the sender’s message (transparent distribution)

Slide 59

Slide 59 text

ERLANG VM (BEAM) A single operating system process SCHEDULER THREAD CPU Image credits: https://pragmaticstudio.com/

Slide 60

Slide 60 text

Multi Core computer Image credits: https://pragmaticstudio.com/

Slide 61

Slide 61 text

So how does the BEAM handles this? @afegbuas

Slide 62

Slide 62 text

Fault Tolerance ● Erlang processes are completely isolated from each other ● They crash alone ● Supervisors are present to detects and manage failures

Slide 63

Slide 63 text

Distribution ● Erlang processes are completely isolated from each other ● They crash alone ● They communicate by sending messages. The receiver gets a read only copy of the sender’s message (transparent distribution)

Slide 64

Slide 64 text

Scalability ● No shared state/memory thus never need to compete for locks for access to shared data. ● No locks, mutexes, or semaphores ● Erlang processes are completely isolated from each other ● The virtual machine can efficiently parallelize the execution of processes as much as possible ● Erlang programs take advantage of all available cores to execute programs

Slide 65

Slide 65 text

Distribution ● Same mode of communication regardless of the machine where the process is running be it single or remote machine; local and remote ● Handles failures across machines

Slide 66

Slide 66 text

Responsiveness ● Excellent scheduler preemption ● I/0 operations are delegated to separate threads internally ● Excellent garbage collection

Slide 67

Slide 67 text

Erlang code can be difficult and verbose So you can write nicer erlang: Elixir @afegbuas

Slide 68

Slide 68 text

So WTF is Elixir ? @afegbuas

Slide 69

Slide 69 text

Elixir Elixir is a dynamic, functional language designed for building scalable and maintainable applications and runs on the Erlang virtual machine (BEAM). @afegbuas

Slide 70

Slide 70 text

Elixir ? All the goods of Erlang plus ● Concise - Erlang is verbose ● Metaprogramming with Macros. ● Polymorphism using Protocols ● Better tools - mix and hex ● Friendlier syntax ● Seamless interoperability @afegbuas

Slide 71

Slide 71 text

Abstracting process Agents and Task ● Start a process ● A recursive function in an infinite loop passing the state for each function call ● A way to handle message ● How to respond to these messages @afegbuas

Slide 72

Slide 72 text

OTP framework and behaviours @afegbuas

Slide 73

Slide 73 text

OTP behaviours GenServer ● Generic Server behaviour is an abstraction of client/server functionality GenEvent ● A behaviour module that Provides event-handling support Supervisor ● Provides error handling and recovery in concurrent systems Application ● Generic implementation of components and libraries @afegbuas

Slide 74

Slide 74 text

So what next? ● Build fast and build well ● Think design, test fast and iterate. ● Adopt the right tools. ● Create appealing user experience ● Create a knowledge base company ● Avoid over bloated engineering team. Recruit for your need

Slide 75

Slide 75 text

1. https://moz.com/devblog/moz-analytics-db-free/ 2. https://www.netguru.co/blog/10-companies-use-elixir 3. https://www.manning.com/books/elixir-in-action 4. https://www.erlang-solutions.com/resources/case-studies.html#aol-marketplace-rea l-time-bidding-and-platform-powered-by-erlang-9-doc 5. https://www.zdnet.com/article/whatsapp-now-one-billion-people-send-55-billion- messages-per-day/ 6.

Slide 76

Slide 76 text

Thank you @afegbuas