Slide 1

Slide 1 text

NODE JS API your like a boss Scaling http://htmlmag.com/etkinlik/the-frontiers-mini Volkan Özçelik June, 20, 2015 http://volkan.io/

Slide 2

Slide 2 text

Resources volkan.io Slides & Source Code volkan.io @linkibol

Slide 3

Slide 3 text

About Me • JavaScript Lover & Performance Freak • Current: • Technical Lead @ Cisco • Before: • Mobile Frontend Engineer @ Jive Software • VP of Technology @ grou.ps • CTO @ cember.net (acquired by Xing)
 • Chase me: • @linkibol • volkan.io • github.com/v0lkan • speakerdeck.com/volkan • linkedin.com/in/volkanozcelik

Slide 4

Slide 4 text

How do I Architect a Scalable and Consistent API with a Manageable Complexity? In a Nutshell… volkan.io @linkibol

Slide 5

Slide 5 text

Scalability & Consistency (in theory) volkan.io @linkibol

Slide 6

Slide 6 text

Scalability & Consistency (in practice)

Slide 7

Slide 7 text

Agenda • Why APIs? • Complexity • Consistency • Microservices • Know Your Platform • Know Your Tools • Limitations • V8 Limitations • OS Limitations • Monitoring • Throughput • Concurrency • Event Loop • Debugging • Automation • Logging • Configuration • Security • Perf Before Scale • Memory Leaks • IO Optimization • Hot Code Paths • Scaling Your API Environment Operations Scaling Up volkan.io @linkibol

Slide 8

Slide 8 text

Why APIS? web mobile iot saas

Slide 9

Slide 9 text

High-Level Topology $:> Clients http proxy ssl termination load balancer authentication authorization token exchange rate limiting API Gateway API Server …

Slide 10

Slide 10 text

Complexity volkan.io @linkibol

Slide 11

Slide 11 text

– Dan Ward “Through carelessness, inattention, or miscalculation, we may inadvertently overfill [the design] to the detriment of the whole. Additions once led to improvement. Beyond a certain point, that is no longer the case. Additions begin to make things worse. ” volkan.io @linkibol

Slide 12

Slide 12 text

Keep It Simple

Slide 13

Slide 13 text

Keep It Simpler

Slide 14

Slide 14 text

Find a Balance

Slide 15

Slide 15 text

Consistency volkan.io @linkibol

Slide 16

Slide 16 text

Eventual Consistency Eventual consistency is a consistency model used in distributed computing to achieve high availability that guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. see also: “Event Sourcing” 
 ( http://martinfowler.com/eaaDev/EventSourcing.html )

Slide 17

Slide 17 text

99% of the Time Eventual Consistency is Good Enough Transactional Consistency in a distributed system is hard to achieve and expensive to implement. volkan.io @linkibol

Slide 18

Slide 18 text

Be Optimistic Client app.js data store send update ACK ASAP persist ACK update state verify state actual state

Slide 19

Slide 19 text

Be Optimistic Client app.js data store send update ACK ASAP persist ACK update state verify state actual state

Slide 20

Slide 20 text

Be Optimistic Client app.js data store send update ACK ASAP persist ACK update state verify state actual state

Slide 21

Slide 21 text

Before Everything Think Functionally volkan.io @linkibol

Slide 22

Slide 22 text

Think Functionally • Delegate; Don’t Return • Avoid Side Effects • Avoid State • Easier to Scale Horizontally • Easier to Swap/Reboot Instances • Session Affinity is Not A Problem • Better Performance

Slide 23

Slide 23 text

Think Functionally • Understand Control Flow Patterns • Understand Promise Patterns (and anti-patterns) • Avoid this and avoid new as much as you can. * • You’ll thank me later. • Think in Streams • Translate, Transform, Reduce https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 *

Slide 24

Slide 24 text

Think Functionally bolognese is onion and oil fried until golden mixed with ground beef mixed with tomato simmered for 20 minutes. cheese sauce is milk and cheese added progressively to roux while frying it until the sauce thickens. Lasagna is grated cheese on cheese sauce on flat pasta on cheese sauce on bolognese on flat pasta on cheese sauce on bolognese on flat pasta on cheese sauce baked for 45 minutes. roux is flour and butter fried briefly. baked is put in an oven dish in a hot oven. fried is put in a pan on high and mixed frequently. simmered is put in a pan on low and mixed infrequently. TRANSFORMATION TRANSFORMATION REDUCTION TRANSLATION TRANSFORMATION TRANSLATION TRANSLATION 1. Cook ground beef, onion, and garlic over medium heat until well browned. 2. Stir in crushed tomatoes, tomato paste, tomato sauce, and water. 3. Season with sugar, basil, fennel seeds, Italian seasoning, stirring occasionally. 4. Bring a large pot of lightly salted water to a boil. 5. Cook noodles in boiling water for 8 to 10 minutes. 6. Drain noodles, and rinse with cold water. 7. In a mixing bowl, combine ricotta cheese with egg, remaining parsley. 8. Arrange 6 noodles lengthwise over meat sauce. 9. Spread with one half of the ricotta cheese mixture. 10. Top with a third of mozzarella cheese slices. 11. Spoon 2 cups meat sauce over mozzarella. 12. Repeat layers, and top with remaining mozzarella and Parmesan cheese. 13. Bake in preheated oven for 25 minutes. 14. Remove foil, and bake an additional 25 minutes. 15. Cool for 15 minutes before serving.

Slide 25

Slide 25 text

Think Functionally bolognese is onion and oil fried until golden mixed with ground beef mixed with tomato simmered for 20 minutes. cheese sauce is milk and cheese added progressively to roux while frying it until the sauce thickens. Lasagna is grated cheese on cheese sauce on flat pasta on cheese sauce on bolognese on flat pasta on cheese sauce on bolognese on flat pasta on cheese sauce baked for 45 minutes. roux is flour and butter fried briefly. baked is put in an oven dish in a hot oven. fried is put in a pan on high and mixed frequently. simmered is put in a pan on low and mixed infrequently. TRANSFORMATION TRANSFORMATION REDUCTION TRANSLATION TRANSFORMATION TRANSLATION TRANSLATION

Slide 26

Slide 26 text

Know Your Platform

Slide 27

Slide 27 text

Perf Advice Is Addictive volkan.io @linkibol

Slide 28

Slide 28 text

Learn JavaScript Before the Deep Dive • Understand EcmaScript 5 • scope, hoisting, closures, promises, `this`, all that jazz. • Keep an Eye on EcmaScript 6 • Consider Using EcmaScript 6 for new Projects

Slide 29

Slide 29 text

Fact Check • “JavaScript is like Java, but easier.” • “Node.JS is slow.” • “I can’t let the app restart; it will take too long.” • “Node.JS is Insecure.” (no! people are.) • “Node.JS does not support feature x.”

Slide 30

Slide 30 text

Node.JS Is Perfect For… • IO-Heavy Applications • Data-Intensive Realtime Apps • RESTful / API-Driven (Micro)services • Streams • Queued (Lazy) Writes • Processing data on-the-fly

Slide 31

Slide 31 text

Node.JS Is not For… • Serving Static Files • CPU-bound Applications • Creating a Monolithic Infrastructure volkan.io @linkibol

Slide 32

Slide 32 text

The Event Loop volkan.io @linkibol

Slide 33

Slide 33 text

Node.JS Event Model * http://nikhilm.github.io/uvbook * https://strongloop.com/strongblog/node-js-event-loop/

Slide 34

Slide 34 text

Never Block The Event Loop • First rule of Node.JS Programming: • Never Block the Event Loop
 • Second rule of Node.JS Programming: • Never Block the Freaking Event Loop!
 • Corollary: • Delegate long (>10ms) Tasks to a Worker • child_process (*) • native add-ons (**) * https://nodejs.org/api/child_process.html
 ** https://nodejs.org/api/addons.html

Slide 35

Slide 35 text

Know the Ecosystem • Do Not Ignore The Ecosystem • Follow Community News and Updates • Attend to Conferences (like this one) volkan.io @linkibol

Slide 36

Slide 36 text

Know the Ecosystem • npm (as of June 20, 2015) • 155,880 (and increasing) total packages • 70,624,534 downloads yesterday • 389,190,331 downloads in the last week • 1,609,312,413 downloads in the last month

Slide 37

Slide 37 text

Embrace Open Source and contribute back volkan.io @linkibol

Slide 38

Slide 38 text

Know Your Tools volkan.io @linkibol

Slide 39

Slide 39 text

Node.JS is not a Swiss army knife • Load Balancing ➡ haproxy ( http://www.haproxy.org/ ) • Web Server ➡ nginx ( http://nginx.org/ ) • SSL Termination ➡ stud ( https://github.com/bumptech/stud ) • GZIP Compression ➡ nginx / haproxy • Static Assets ➡ CDN / Varnish ( https://www.varnish-cache.org/ )

Slide 40

Slide 40 text

Limitations

Slide 41

Slide 41 text

v8 Limitations volkan.io @linkibol

Slide 42

Slide 42 text

v8 Limitations • ~2gb ➡ heap limit (--max-old-space-size) • will be more than enough • spawn more processes for more (child_process) • ~1gb ➡ max size of a Buffer

Slide 43

Slide 43 text

• Lazily produce or consume data in buffered chunks. • Evented and non-blocking. • Low memory footprint. • Automatically handle back-pressure. • Buffers allow you to work around the v8 heap memory limit. • Most core node.js content sources/sinks are streams already. Show Love to Streams

Slide 44

Slide 44 text

OS Limitations volkan.io @linkibol

Slide 45

Slide 45 text

Open File Limits • “Error: EMFILE, Too many open files” • ulimit -n 65535; volkan.io @linkibol

Slide 46

Slide 46 text

Open File Limits

Slide 47

Slide 47 text

Configuring the Load Balancer see https://bit.ly/nginx-rocks

Slide 48

Slide 48 text

Configuring the Load Balancer see https://bit.ly/nginx-rocks

Slide 49

Slide 49 text

Additional Tweaks http.globalAgent.maxSockets = SOME_BIG_NUMBER; (if you have many outgoing requests) volkan.io @linkibol

Slide 50

Slide 50 text

Additional Tweaks sysctl -w net.core.somaxconn=1024; (default is 128) volkan.io @linkibol

Slide 51

Slide 51 text

Even More Tweaks

Slide 52

Slide 52 text

Monitoring volkan.io @linkibol

Slide 53

Slide 53 text

You Can’t Optimize What You Don’t Measure volkan.io @linkibol

Slide 54

Slide 54 text

Things to Watch Out For • Your API Service may Become CPU-Bound • External API Calls Can Be a Bottleneck • Always Keep an Eye on the Event Loop • Implement Sanity Checks • Circuit Breaker • Have an Upper Bound for Concurrency

Slide 55

Slide 55 text

Things to Watch Out For • Is app running and functional? • Is app overloaded? • How many errors have been raised so far? • How many times do forks restored? • Are all forks alive and okay? • Is app performant (throughput, memory utilization, concurrency)?

Slide 56

Slide 56 text

Which Will (most of the time) Boil Down to… • Watching Response Times • Watching CPU Utilization + General Sys Resource Usage • Watching Number of Concurrent Connections

Slide 57

Slide 57 text

Throughput / Concurrency volkan.io @linkibol

Slide 58

Slide 58 text

Throughput vs Concurrency throughput concurrent connections

Slide 59

Slide 59 text

Throughput vs Concurrency throughput concurrent connections throughput concurrent connections

Slide 60

Slide 60 text

Throughput vs Concurrency throughput concurrency

Slide 61

Slide 61 text

Throughput vs Concurrency throughput concurrency near-linear rapid decrease degrade throughput concurrency

Slide 62

Slide 62 text

Throughput vs Concurrency throughput concurrency near-linear rapid decrease degrade throughput concurrency near-linear rapid decrease degrade throughput concurrency ideal path practical path

Slide 63

Slide 63 text

Event Loop Delay volkan.io @linkibol

Slide 64

Slide 64 text

Track the Event Loop

Slide 65

Slide 65 text

Track the Event Loop volkan.io @linkibol

Slide 66

Slide 66 text

Track the Event Loop

Slide 67

Slide 67 text

Track the Event Loop

Slide 68

Slide 68 text

Track the Event Loop

Slide 69

Slide 69 text

Circuit Breaker closed fail (under threshold) open fail (reached threshold) checking… timer (exponential backoff) fail success volkan.io @linkibol

Slide 70

Slide 70 text

Circuit Breaker • Can be used with any kind of metric. • Event-loop tracking is just a specific example. • Useful when you depend on other APIs that might fail. volkan.io @linkibol

Slide 71

Slide 71 text

Monitoring Tools volkan.io @linkibol

Slide 72

Slide 72 text

Monitoring as a Service • nodetime • https://nodetime.com/ • newrelic • http://newrelic.com/nodejs • strongloop • https://strongloop.com/node-js/performance-monitoring/

Slide 73

Slide 73 text

Memwatch • https://github.com/lloyd/node-memwatch • heap stats • heap diffing • leak detection (subscribe to “leak” events)

Slide 74

Slide 74 text

cluster-live https://github.com/tj/cluster-live

Slide 75

Slide 75 text

Flame Graphs http://www.brendangregg.com/flamegraphs.html

Slide 76

Slide 76 text

Flame Graphs • Can Be Created Post-Mortem (after a core dump) • Can Be Created at Runtime (using gcore *) • You Can Use dtrace + stackvis to generate them ** http://man7.org/linux/man-pages/man1/gcore.1.html * http://blog.nodejs.org/2012/04/25/profiling-node-js/ **

Slide 77

Slide 77 text

Error Handling volkan.io @linkibol

Slide 78

Slide 78 text

Error Handling • Use an error object; not a String (or better, use an error event) • https://github.com/davepacheco/node-verror • Error handling for Async Code Is Hard • Throwing does not make sense ( scope and stack trace is lost ) • Consider using domains ( https://nodejs.org/api/domain.html )

Slide 79

Slide 79 text

Error Handling • Throwing is for programmer errors. • Consider using an error event instead of throwing.

Slide 80

Slide 80 text

Handle Errors Gracefully • Know how exceptions and errors propagate in Node.JS. • Raise error events to throwing exceptions. • Restart on uncaught exceptions. • Utilize domains. https://www.joyent.com/developers/node/design/errors

Slide 81

Slide 81 text

Using Domains

Slide 82

Slide 82 text

Processes Die Accept it volkan.io @linkibol

Slide 83

Slide 83 text

Processes Die Accept it volkan.io @linkibol

Slide 84

Slide 84 text

Processes Die Accept it volkan.io @linkibol

Slide 85

Slide 85 text

Processes Die Accept it No system is %100 resilient. Keep things as simple as possible. Build something that’s good enough for your purpose. Solve for the problems that are actually on your plate. volkan.io @linkibol

Slide 86

Slide 86 text

Keep It Running •forever ( https://github.com/foreverjs/forever ) •pm2 ( https://github.com/Unitech/pm2 ) •upstart ( http://upstart.ubuntu.com/ ) •systemd ( https://www.wikiwand.com/en/Systemd )

Slide 87

Slide 87 text

Debugging volkan.io @linkibol

Slide 88

Slide 88 text

Debugging • Live Debugging • Post-Mortem Debugging volkan.io @linkibol

Slide 89

Slide 89 text

Live Debugging Given the Tornado, Where’s the Butterfly? volkan.io @linkibol

Slide 90

Slide 90 text

Post-Mortem Debugging volkan.io @linkibol

Slide 91

Slide 91 text

Node.JS Debugging Myths • Debugging and Profiling in Node.JS is Hard • Debugging and Profiling in Node.JS is Immature • You Cannot Debug or Profile a Live Production Node.JS App volkan.io @linkibol

Slide 92

Slide 92 text

Node.JS Debugging Tips • Attaching a debugger to prod is not practical. • Make as much state as possible observable. • You can take a core dump, and analyze it later. volkan.io @linkibol

Slide 93

Slide 93 text

Debugging Node.JS • You Can Expose Internal State via an API and/or a CLI/REPL • https://github.com/davepacheco/kang • https://nodejs.org/api/repl.html • Expose Additional Logging Info at Runtime (in systems that support it) • bunyan -p ( https://github.com/trentm/node-bunyan )

Slide 94

Slide 94 text

Debugging Node.JS • Interactive Debugging • Using node-debug • https://nodejs.org/api/debugger.html • Using Node Inspector • https://github.com/node-inspector/node-inspector • Using Cloud9 IDE • https://c9.io/

Slide 95

Slide 95 text

Debugging Node.JS • Log Libraries Specialized for Dumping Debug Info • Caterpillar ( https://github.com/bevry/caterpillar ) • Tracer ( https://github.com/baryon/tracer ) volkan.io @linkibol

Slide 96

Slide 96 text

Logging volkan.io @linkibol

Slide 97

Slide 97 text

What to Log • Authentication & Authorization • Session Management • Method Entry Points • Erros and Weird Events • Specific Events (startup, shutdown, slowdown etc.) • High-Risk Functionalities (payments, privileges, admins etc)

Slide 98

Slide 98 text

Centralized Logging • Send logs to a log aggregation server; • Using a library that supports it: • bunyan ( https://github.com/trentm/node-bunyan ); • winston ( https://github.com/winstonjs/winston ); • custom (using Streams).

Slide 99

Slide 99 text

Configuration volkan.io @linkibol

Slide 100

Slide 100 text

• No Hard-Coded IP Addresses in Config Files • Let DNS do What it Does Best • Update Configuration From a Central Service • saltstack ( http://saltstack.com/ ) • chef ( https://www.chef.io/ ) • puppet ( https://puppetlabs.com/ ) Configuration

Slide 101

Slide 101 text

Automation volkan.io @linkibol

Slide 102

Slide 102 text

Have a CI/CD Pipeline • go ( http://www.go.cd/ ) • gradle ( http://gradle.org/ ) • jenkins ( https://jenkins-ci.org/ ) volkan.io @linkibol

Slide 103

Slide 103 text

Code Quality volkan.io @linkibol

Slide 104

Slide 104 text

Code Quality • Group Common Logic Into Reusable Modules • Modules Should Do One Thing, and Do One Thing Well • Use Static File Analyzers • jshint ( https://github.com/gruntjs/grunt-contrib-jshint ) • jscs ( https://github.com/jscs-dev/grunt-jscs ) • grunt-complexity ( https://github.com/vigetlabs/grunt-complexity )

Slide 105

Slide 105 text

Perf Before Scale volkan.io @linkibol

Slide 106

Slide 106 text

Memory Leaks volkan.io @linkibol

Slide 107

Slide 107 text

Memory Leaks volkan.io @linkibol

Slide 108

Slide 108 text

Memory Leaks volkan.io @linkibol

Slide 109

Slide 109 text

Perf Before Scale • Configure Your System for High Performance • Cache at Every Layer • The fastest API response is no response at all. • Delegate Long-Running(*) Operations volkan.io @linkibol

Slide 110

Slide 110 text

Perf Before Scale • CPU-Intensive Computations? • child_process + External Libraries • Native Extensions volkan.io @linkibol

Slide 111

Slide 111 text

IO Optimization volkan.io @linkibol

Slide 112

Slide 112 text

IO Optimization • Don’t Immediately Write Small Packets • Reduce the Number of Outgoing Requests • Use Lesser Abstractions for Maximum Throughput volkan.io @linkibol

Slide 113

Slide 113 text

Know Your Bottlenecks • 99% of the time you will be IO-bound. • You’ll scale horizontally before hitting 100% CPU. • You’ll have to try really hard to have a CPU or memory bottleneck. • Node.JS serves really well as a highly concurrent networking app. • Node.JS is very sensitive to memory leaks and blocking code. volkan.io @linkibol

Slide 114

Slide 114 text

Torture Your System • Try Chaos Monkey • https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey • Randomly send `kill -9` to Processes • Randomly Knock a Server Offline • Intentionally Run Out of Disk Space • Take an entire data center down

Slide 115

Slide 115 text

Going Bare Bones volkan.io @linkibol

Slide 116

Slide 116 text

express.js vs Bare-Bones Node.JS express.js http

Slide 117

Slide 117 text

Diving Deeper

Slide 118

Slide 118 text

Going Bare Bones express (with 5 common middleware) bare bones http bare bones tcp 0 1150 2300 3450 4600 4,517 3,561 2,891 requests per second ab -c 100 -n 1000 Tested on MacBook Pro, 2.4 GHz Intel Core i5, 16 GB 1600 MHz DDR3, single core, w/o keep-alive

Slide 119

Slide 119 text

Is It Worth It? • Consider Going Bare-Bones for Maximum Throughput • Tradeoff: • harder to maintain • more complex code • error prone • lots of edge cases • harder to use additional tooling (i.e. no dtrace support)

Slide 120

Slide 120 text

v8 Optimizations volkan.io @linkibol

Slide 121

Slide 121 text

Taking Control of the Garbage Controller • Warning: You probably would not want to do that! • --expose-gc • --nouse-idle-notification volkan.io @linkibol

Slide 122

Slide 122 text

Types of Compilers in v8 • Generic Compiler • Optimizing Compiler • Can Be Two or More Orders of Magnitude Faster volkan.io @linkibol

Slide 123

Slide 123 text

Optimize Only Hot Code Paths Unless You Have Solid Evidence to Do Otherwise volkan.io @linkibol

Slide 124

Slide 124 text

Tooling node --trace_opt 
 --trace_deopt 
 --allow-natives-syntax test.js; • console.log(%HasFastProperties(obj)) • console.log(%GetOptimizationStatus(fn)) https://github.com/Nathanaela/v8-natives

Slide 125

Slide 125 text

v8 Optimization Killers • These will be bailed out (likely, forever): • Using debugger anywhere within the function • Using eval anywhere within the function • Using with anywhere within the function https://github.com/petkaantonov/bluebird/wiki/Optimization-killers

Slide 126

Slide 126 text

v8 Optimization Killers • These will be bailed out (for now): • Generators • Functions that contain a for-of statement • Functions that contain try-catch or try-finally • let assignments • const assignments • functions that contain object literals with
 __proto__, get, or set declarations.

Slide 127

Slide 127 text

Infinite Loops With Unclear Logic • while(true) { … } • for( ; ; ) { … } volkan.io @linkibol

Slide 128

Slide 128 text

Objects Object.prototype.baz = function() {}; • Do not define enumerable properties in the prototype chain. • Use Object.defineProperty to create non-enumerable properties.

Slide 129

Slide 129 text

Objects

Slide 130

Slide 130 text

for/each

Slide 131

Slide 131 text

Isolate try/catch

Slide 132

Slide 132 text

Isolate try/catch

Slide 133

Slide 133 text

Isolate try/catch

Slide 134

Slide 134 text

Isolate try/catch

Slide 135

Slide 135 text

arguments Object

Slide 136

Slide 136 text

Iteration Tips • Rule of thumb: Avoid for/in loops in hot code paths. • Always use Object.keys to iterate an object. • Rethink your architecture 
 if you need to iterate the parent prototype’s keys. volkan.io @linkibol

Slide 137

Slide 137 text

Inherited keys volkan.io @linkibol

Slide 138

Slide 138 text

Promises volkan.io @linkibol

Slide 139

Slide 139 text

Callback Hell Is Real

Slide 140

Slide 140 text

Promises Promises are not as slow as they once were. https://github.com/petkaantonov/bluebird

Slide 141

Slide 141 text

Promises • Use promises — *ahem* BlueBird — liberally. • Consider using continuation passing style 
 (i.e. callbacks) for very hot code paths. • Callbacks are always faster, and more memory-efficient. • Do not optimize prematurely; measure things first!

Slide 142

Slide 142 text

Security volkan.io @linkibol

Slide 143

Slide 143 text

Do Not Run Node.JS As Root useradd -mrU web;
 mkdir /opt/web-app;
 chown web /opt/web-app;
 cd /opt/web-app;
 su web;
 node app.js;
 firewall-cmd --permanent --zone=public --add-port=3000/tcp volkan.io @linkibol

Slide 144

Slide 144 text

Security • https://www.owasp.org/index.php/ OWASP_Node_js_Goat_Project • http://nodesecurity.io/ • https://www.owasp.org/index.php/ OWASP_Zed_Attack_Proxy_Project volkan.io @linkibol

Slide 145

Slide 145 text

Common Threats • XSS / CSRF • Input Validation Attack • DoS / ReDoS • Request Size * not different from any other web app.

Slide 146

Slide 146 text

Your API at Scale

Slide 147

Slide 147 text

Goals • Minimize Client Response Time • Maximize Resource Efficiency on the Server
 Hint: Leave 50% of the memory unused
 (for taking core dumps)

Slide 148

Slide 148 text

Microservices to the rescue volkan.io @linkibol

Slide 149

Slide 149 text

Microservices web.js auth.js routing.js persistence.js messaging.js logging.js process A web.js process A web.js process B routing.js process C persistence.js process D messaging.js process E logging.js process F Monolith Microservice multiple modules single process multiple modules multiple processes

Slide 150

Slide 150 text

Think Twice http://martinfowler.com/bliki/MicroservicePremium.html

Slide 151

Slide 151 text

Favor Microservices Over Monoliths • Prefer Composition over Inheritance • Publish Modules Instead of Inlining Functionality • Use an Internal npm

Slide 152

Slide 152 text

Scaling Your API volkan.io @linkibol

Slide 153

Slide 153 text

Scaling Your API app memory volkan.io @linkibol

Slide 154

Slide 154 text

Cluster volkan.io @linkibol

Slide 155

Slide 155 text

Cluster

Slide 156

Slide 156 text

Cluster

Slide 157

Slide 157 text

Cluster

Slide 158

Slide 158 text

Cluster

Slide 159

Slide 159 text

Cluster + Domains volkan.io @linkibol

Slide 160

Slide 160 text

Cluster + Domains

Slide 161

Slide 161 text

Cluster + Domains

Slide 162

Slide 162 text

Cluster + Domains

Slide 163

Slide 163 text

Cluster + Domains

Slide 164

Slide 164 text

Cluster + Domains

Slide 165

Slide 165 text

Cluster + Zero Downtime Rolling Deployments volkan.io @linkibol

Slide 166

Slide 166 text

Zero Downtime kill --USR2 volkan.io @linkibol

Slide 167

Slide 167 text

Zero Downtime see also: https://github.com/doxout/recluster

Slide 168

Slide 168 text

Zero Downtime see also: https://github.com/doxout/recluster

Slide 169

Slide 169 text

Zero Downtime see also: https://github.com/doxout/recluster

Slide 170

Slide 170 text

Build Redundancy Everywhere volkan.io @linkibol

Slide 171

Slide 171 text

Build Redundancy Everywhere

Slide 172

Slide 172 text

Build Redundancy Everywhere

Slide 173

Slide 173 text

Build Redundancy Everywhere

Slide 174

Slide 174 text

Build Redundancy Everywhere

Slide 175

Slide 175 text

Build Redundancy Everywhere

Slide 176

Slide 176 text

Cluster app memory app app app volkan.io @linkibol

Slide 177

Slide 177 text

IS BIGGER ALWAYS BETTER? ultra mega super box with bazillion cores regular box

Slide 178

Slide 178 text

Let’s Step Back app memory volkan.io @linkibol

Slide 179

Slide 179 text

Delegate Heavy Computation to Workers app memory worker worker worker child_process volkan.io @linkibol

Slide 180

Slide 180 text

Split Logical Components into Distinct Services API app memory compute app memory worker worker worker child_process volkan.io @linkibol

Slide 181

Slide 181 text

IPC With a Message Bus API app memory compute app memory worker worker worker child_process message bus * * rabbitmq, zeromq, resque etc. see also http://queues.io/

Slide 182

Slide 182 text

Message Bus Topologies P C Send/Listen P C1 C2 Worker Queue X C1 PubSub P C2

Slide 183

Slide 183 text

Cluster Processes API app memory compute app memory worker worker worker child_process message bus API app c l u s t e r c l u s t e r compute app worker worker worker child_process volkan.io @linkibol

Slide 184

Slide 184 text

How Do We Multiplex? API app memory compute app memory worker worker worker child_process message bus API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app memory compute app memory worker worker worker child_process message bus API app c l u s t e r c l u s t e r compute app worker worker worker child_process

Slide 185

Slide 185 text

How Do We Multiplex? API app memory compute app memory worker worker worker child_process message bus API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app memory compute app memory worker worker worker child_process message bus API app c l u s t e r c l u s t e r compute app worker worker worker child_process ?

Slide 186

Slide 186 text

Introduce a LB and a Broker API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process broker load balancer Internet message bus volkan.io @linkibol

Slide 187

Slide 187 text

Load Balancing Options • Elastic Load Balancing as a Service (amazon, rackspace…) • Hardware Load Balancer (Cisco ACE, Barracuda, etc…) • Software Load Balancer • nginx • haproxy • home grown

Slide 188

Slide 188 text

Load Balancer

Slide 189

Slide 189 text

Making the Load Balancer Highly Available • round-robin DNS • https://www.wikiwand.com/en/Round-robin_DNS • heartbeat • https://www.wikiwand.com/en/Heartbeat_(computing) • keepalived • http://keepalived.org/ * You can use these tools to make any component HA.

Slide 190

Slide 190 text

Making the Load Balancer HA load balancer load balancer load balancer keepalived DNS failover active * see also: https://www.wikiwand.com/en/Virtual_Router_Redundancy_Protocol

Slide 191

Slide 191 text

SSL Termination load balancer load balancer keepalived DNS failover active SSL Terminator SSL Terminator keepalived DNS failover active load balancer load balancer * * * https://github.com/bumptech/stud

Slide 192

Slide 192 text

Elephant in the Room How Do We Manage State? volkan.io @linkibol

Slide 193

Slide 193 text

Share State With Redis API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process broker load balancer Internet message bus redis redis volkan.io @linkibol

Slide 194

Slide 194 text

Share State With Redis API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process broker load balancer Internet message bus redis redis volkan.io @linkibol

Slide 195

Slide 195 text

Make Redis Redundant redis redis (master) redis (read replica) redis (read replica) redis (read replica) redis (master) redis (read replica) redis (read replica) redis (read replica) round-robin DNS This will also increase throughput as a side benefit. See http://redis.io/topics/replication and http://redis.io/topics/cluster-tutorial You can also use a managed “memory as a service” solution.

Slide 196

Slide 196 text

We Can Add More… API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process broker load balancer Internet message bus redis redis … …

Slide 197

Slide 197 text

we are actually using Microservices here volkan.io @linkibol

Slide 198

Slide 198 text

Microservices API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process broker load balancer Internet message bus redis redis … …

Slide 199

Slide 199 text

Microservices API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process broker load balancer Internet message bus redis redis … … API μ-Service

Slide 200

Slide 200 text

Microservices API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process API app compute app worker worker worker child_process API app c l u s t e r c l u s t e r compute app worker worker worker child_process broker load balancer Internet message bus redis redis … … API μ-Service Compute μ-Service

Slide 201

Slide 201 text

Microservices API μ-Service Compute μ-Service load balancer broker redis redis message bus Internet volkan.io @linkibol

Slide 202

Slide 202 text

What If We Exhaust All the Bandwidth? 
 That Means You’ve Become Famous Scalability Will Be the Least of Your Concerns volkan.io @linkibol

Slide 203

Slide 203 text

Scaling Into Multiple Zones API μ-Service Compute μ-Service load balancer broker redis redis message bus Internet Zone 1 volkan.io @linkibol

Slide 204

Slide 204 text

Scaling Into Multiple Zones API μ-Service Compute μ-Service load balancer broker redis redis message bus Internet Zone 1 API μ-Service Compute μ-Service load balancer broker redis redis message bus Zone 2

Slide 205

Slide 205 text

Scaling Into Multiple Zones round-robin DNS API μ-Service Compute μ-Service load balancer broker redis redis message bus API μ-Service Compute μ-Service load balancer broker redis redis message bus Internet

Slide 206

Slide 206 text

Scaling Into Multiple Zones round-robin DNS API μ-Service Compute μ-Service load balancer broker redis redis message bus API μ-Service Compute μ-Service load balancer broker redis redis message bus Internet

Slide 207

Slide 207 text

Mirroring the Data Stores round-robin DNS API μ-Service Compute μ-Service load balancer broker redis redis message bus API μ-Service Compute μ-Service load balancer broker redis redis message bus Internet mirror mirror

Slide 208

Slide 208 text

Mirroring the Data Stores round-robin DNS API μ-Service Compute μ-Service load balancer broker redis redis message bus API μ-Service Compute μ-Service load balancer broker redis redis message bus Internet mirror mirror

Slide 209

Slide 209 text

We Can Add More… round-robin DNS API μ-Service Compute μ-Service load balancer broker redis redis message bus API μ-Service Compute μ-Service load balancer broker redis redis message bus Internet mirror mirror …

Slide 210

Slide 210 text

scale 2 ∞ & 㱺

Slide 211

Slide 211 text

Thank You Questions? @linkibol