a

In Search of the Perfect Abstraction for My Web App

for Irene join me in welcoming Irina

government we're going to take a minute

here set up long long ago in a galaxy

far far away a lonely software engineer

named Irina came up with a social

networking website idea that she thought

was really cute and sweet and cool

compliments as a service and she called

her imaginary social networking website

kudos she imagined millions and millions

of users like into her amazing website

who wouldn't want to give compliments

that everybody can see online or receive

compliments that everyone can see online

collide compliments and compliments as

birthday gifts yes millions and millions

of users

but dr. reality kudos the website was

yet to be created Irina a back on Java

engineer at the time was already working

at a company serving hundreds of

millions of online users to her a

back-end java engineer that's what kudos

really looked like

her very own java web server so scary

she knew what it takes to create and

support a busy website on written in

Java one of the most popular languages

of our time a Java server is a mana web

and by the end of this presentation

presentation you will know what I mean

something unpredicted happens and the

whole thing collapses you have to be

very careful dealing with exceptions in

your code or before you know it it's the

server goes down and use clients and

money but let's not jump too far ahead

of ourselves luckily the place arena

worked at had instability business model

assault client base and a steady cash

flow they could afford losing thousands

of dollars during server downtime they

could also afford hiring very expensive

experienced developers to deal with all

the challenges that Java presents in a

context of a busy web server so I you

know was trying to start a start-up

while working at a start-up and she

fails to serious limitations as old as

money time she needed time to create the

kudos web server and she needed money to

run that's a she needed money to run

that she needed money to for the

hardware to run the software on so um

let's talk about money first I know time

equals to money just like e equals MC

squared who here try turning mass into

energy

well you know it's not easy similarly

turning your own time into money is not

trivial as equal as they might be to

start a company you actually need money

before you can turn time into money and

you you will need so for a for a web

server you need CPU and memory to

process and serve the web requests and

you need a database to sew to save the

user data and the more efficiently your

web server operates and uses these

resources the cheaper it will be for you

of course modern-day startups have a

have an amazing option available to them

they can run their software in the cloud

but anyone tried registering for Amazon

Web Services freed here you have to take

out your own credit card out of your own

pocket and it's nothing like your

infinite corporate credit think about it

for a second and then another great

benefit of efficient and scalable

software is performance actually we're

every time a discussion performance

comes up its nemesis the discussion on

premature empty optimization occurs but

in the context to a web server I don't

even think it's a worthy discussion

anyone here enjoys waiting for a web

page to load how many shoes I almost

bought online because the checkout page

took forever

well if you don't if this is not

convincing enough just if you want real

statistics and just google this and now

let's talk about time not space time and

not CPU time Irina's personal time the

time she needed to develop the Kudus

software and not just the very efficient

and scalable backhand but also would

look in front end and just to get the

angel investors and her program and

friends interest interested she needed

to develop some kind of web server

prototype so what's a work and she knew

that the scooters business will be hard

but seriously everything is hard even

making lasagna is hard but one goes to a

store and buys this and this and making

lasagna becomes a reality even for a

stay at work mom

modern-day cooks have lots and lots of

great abstractions sold to them at the

grocery store buying this may buy time

in knowledge and experience in a jar

today I don't think software

abstractions talking about framework

some high-level languages and even

design patterns are as far ahead as

cooking abstractions they exist but that

software jar is so much more likely to

explode into your face besides software

abstractions sometimes are so hard to

learn and figure out how to use with

your particular situation so sometimes I

think it would have been just easier to

write the whole thing and in C cooking

equivalent off from scratch a lot of

developers get frustrated with

frameworks and third-party libraries

it's been and with new higher level

arguably better languages that in the

end and then they get themselves so in

so much trouble with them but in the end

they think that they'll never use one

again nonetheless striving for

abstractions is in the nature of all

intelligent progress we cannot we cannot

constantly reinvent the same old stuff

we have to move on that's why a new

software abstractions get created all

the time some of them are very powerful

useful and reliable and some are easy to

learn some address very specific problem

space some are born in such favorable

conditions that when there are no better

alternatives out there that they gained

popularity unproportional completely

unprofessional was there was their value

and do to sort of a snowball effect

substract abstractions take us two steps

forward some take us one step back so we

can say that software abstractions

undergo some kind of evolutionary

process unfortunately survival is not

determined by the software professionals

alone very often recruiters and

high-level managers and people of power

but without the knowledge of software

take a big part in getting the snowball

rolling and helping mediocre or

downright use for useless abstractions

gaining popularity and software

engineers just go along with it I wish

they didn't but um to be on a positive

side here that I am really curious what

abstractions we are will be like 10 20

years from now maybe we'll have them so

powerful that little kids will be able

to come build complex software

architectures was there was a cute

visual app on their iphone 26s or

whatever the unimaginable holographic

display gadget not be playing was so

dear fellow software engineers out there

if p1 great future for our industry

let's be picky and choosy and take

control let's look at the arenas example

she had to be picky and choosy she had

no other choice but her example is a

good example known to us so she did not

put her own web server she did not

consider job the language she knew so

well and the language that fed her and

her family for so many years and why not

so okay she needed this highly scalable

a scalable paralyzed web server what

about Java concurrency package well

unfortunately joakim currency package

does not protect the developer from the

perils of concurrent programming if

anything it makes a concurrent

programming look deceptively easy and

more appealing but not any less

dangerous if you happen not to be very

familiar with what concurrency

programming is I strongly encourage you

to go ahead and try it for yourself you

c c++ go ahead try using a java

concurrency package play was it long

enough and you will understand this is

something you

don't want to be alone in the in the

wild human brain is not designed to

operate concurrently that's why

experienced programmers want to avoid

concurrency programming altogether we

don't want fancy tools to roll our own

concurrency we just want to avoid all at

all costs so there are few programming

languages out there that actually take

the concurrency programming of the

developers play all together we look at

them in just a moment but before we do

let's take a look at some very important

considerations for our web server

mutability and shared state are the

biggest enemies of proper concurrency

just trust me on that for now but google

it later I actually wish that our google

developers googled it before developing

goal a program written in a language

that allows mutable variables will

inevitably end up in a was a deep down

broken concurrency model and that will

cost you and no matter how hard you try

to enforce immutability in your own

concurrent program mutable variables

will pop up somewhere whether it's going

to be a third-party library or your own

piece of code you wrote on a Friday

night but let's say by some miracle you

actually managed to maintain and to

write and maintain a one hundred percent

immutable program using mutable language

you know that is actually very very hard

and in case you haven't gotten the gist

of this presentation yet this is exactly

what we are trying to avoid in hard work

and not the next very important thing we

want for our web server is fault

tolerance we want our server to be up

and running in even an unpredicted

circumstances despite bugs and

unexpected requests and such and such we

don't want it to be

down at all because when the server is

down we are losing clients and money so

in my humble opinion the biggest our

enemies of photons are monolithic

structures of any kind and we are going

to talk about a very specific one java

virtual machine java virtual machine has

the monolithic a heap shared between all

the threats because of that killing a

bad track actively running in the on the

JVM is impossible it is not allowed we

are risking to corrupt the heap and the

bad thread is serious potential of

taking your entire server down along

with all the good threads processing all

the good requests so we'll be losing

clients and money another sigh a bad

side effect of this monolithic heap is a

monolithic garbage collector obviously

it takes money with the garbage

collector to clean up the monolithic

heap and was that monolithic garbage

collector we are going to end up with

long arm garbage collection pauses again

losing clients and money while not being

able to serve requests and a lot of you

problem here will argue that the garbage

collector can be fine tuned yes you can

fine tune the hell out of it and it will

not be it will not be closing on garbage

collection poses but that's again very

hard work very experienced in expensive

engineering so if you want really full

torrent system we wanted to look

something like this tiny isolated

processes with tiny with its own

isolated hips one process goes crazy it

gets killed the rest of the systems run

the rest of the system runs happily

alone and in my humble opinion again

no garbage collector it's a runtime

burden that could be taken care of it

called compile time that's just my

opinion so now let's talk about some fun

things concurrency abstractions so we

look at two most popular models I think

their most popular actor model designed

by Karl huge 1973 and communicating

sequential processes model designed by

20 in 1978 so one little remark to

compare the two of them with either one

of these two concurrency models

processes don't use locks and mutexes to

access shared information instead

information is passed between processes

it's known as the concept of message

passing actor model is very similar to

how we humans operate for instance if I

want to communicate to my husband on his

way to his on his way to a grocery store

if I want to communicate to him the

grocery shopping list that's in my head

I don't let him do I don't land him on a

part of my brain that has the grocery

shopping list while he's at the store I

simply communicate the list to him and

with any luck it ends up in his brain so

communicating sequential processes are

sound slightly different they actually

the mass of the information is passed

through channels and it's not intended

for a specific recipient in my humble

opinion a little more monolithic that

the actor model I personally like the

actor model way more and it's in my mind

is much more fault tolerant so now let's

take a look at some concurrency

concurrency obstruction implementations

so communicating sequential processes we

have go developed by google we have a

closure for a sink package and now we

even have Java CSP just learn about it

while preparing for this presentation so

X term

we have acha written and scala and then

we have airline so let's considering

fault tolerance and immutability let's

take a look at those languages and see

which one's of them fit our needs so go

go is a mutable language so go is no go

closure it's a language running on the

JVM we talked enough about the JVM today

so note the closure i think package java

CSP needless to say JVM language acha

scala i like actor model but it's an

it's running on the JVM Erlang back in

2011 adina became aware of a rare

treasure that had actor model

implemented and concurrency beautifully

abstracted away from the developer it's

variables are 100 immutable in nature

and hands one hundred percent safe for

concurrency it offers complete process

isolation with each process holding in

its own heap enhance ability to kill a

bad process programmatically was it came

another great abstraction OTP opened

telecom platform offering common

behaviors like server and finite state

machine out of the box the treasure was

battle proof in many production

environment demonstrating 990 uptime and

in some cases years of uptime for Irene

it was a very good news because it meant

her cousin kudos back-end could be

created without investing into expensive

developer resources that can be CPU

efficient and can be run with minimal

human support because Erlang is built in

supervisors and they can have the pot

and they have the power to kill and

restart misbehaving processes in a fully

programmable way for irina who I have to

say was a very lazy person and she liked

to sleep at night she liked to sleep at

night it was purely priceless powerhouse

of really useful abstractions created by

50 or so brilliant

eriksson employees over the course of

five years perfectly suitable for a busy

web server and just like the stars in

the sky are absolutely free and unlike

the stars in the sky readily available

for download and air wing is a

functional language in case some of your

software engineers out there haven't

noticed our world is slowly but surely

is gravitating towards functional

languages since the times of Democritus

the scientists and philosophers have

been discovering smaller and smaller

basic particles that the vast diversity

of our world is made of yet they keep

looking for power to possibly discover

the one and only modern quantum

physicists are striving to describe all

fundamental forces and the relationship

between them elementary particles in

terms of a single theoretical framework

known as unified field theory best of

luck to you quantum physicists software

engineers software scientists scientists

however already discovered their unified

field theory functions are our

fundamental forces and here is a

brilliant proof I found it on Twitter

that's where I get most of my

information let's compare some object

oriented patterns and principles to

their functional counterparts so let's

go ahead single responsibility principle

it's functional counterpart functions

open closed principle functions

interface segregation principle

functions factory pattern me as

functions dependency inversion principle

functions also strategy pattern all my

functions again a little historical

perspective functional languages were

too slow back in the days when hardware

will had only a fraction of modern

hardware power so imperative languages

at that time naturally took over despite

their all-around inferiority as far as

use the politicals they are faster and

they took over imperative language

proliferation it has purely historical

reasons that are no longer hold true

that no sorry that no longer hold true

so if anyone doubts that the future um

is functional just look at Java 8 this

this very popular object-oriented this

very popular object-oriented dude is now

wearing a functional hat I guess it

knows that's the only way that's the

only way to survive so airline was

airline in mind kudos ideas started

looking much more approachable something

like this probably however for someone

who never created a website from scratch

before it would have to begin with more

like this and that seemed a little

trickier so Irina realized she needed a

powerful web framework she needed a lot

of common web functionality out of the

box whois would be quite possible in her

situation if she had both a powerful

language and a powerful web framework

maybe something like this she definitely

had resources to build something like

this so she started looking for a feel

for a good web framework to go ahead

with the cool

to observer so this is a couple of here

here a couple of things she analyzed

ruby-on-rails she heard about Ruby on

Rails and how folks could get a website

up and running in a matter of a couple

of weeks one ruby developer I didn't

spoke to love truly because it was it's

very powerful extendable thanks to its

built-in metaprogramming abilities

maintainable an all-around very pleasant

language but she's also heard that ruby

is slow and all the pleasantries in core

around time cost and basically when

basically when a website gets very busy

very busy and popular all these little

bits are slowly being rewritten in C or

Java incur case it would be Erlang and

to her this whole things aren't

ridiculous so it's like a punishment for

success rewriting kudos just around the

time when it became very popular very

exciting prospect thanks but no thanks

so she went on to look in looking at PHP

another very popular language in web

development it has a lot of web

functionality built in and compared to

Ruby on Rails PHP is not slow however it

could be a maintenance nightmare

that's the most likely most likely

reason why a PHP developer switch to

ruby on rails and are loving it so

maintenance nightmare thanks but no

thanks if you don't a plan for your web

server to succeed you don't care about

it being maintainable however I really

expected kudos to succeed why else would

she bother was it to begin with anyway

this kind of decision making was

happening long long ago in the year of

2011 it was a very imperfect world back

down and guess what happen to kudos you

gotta try it kudos didn't happen trying

to choose between a perfect language and

the web framework combo was like

sleeping with a short blanket when you

cover your head your feet get cold and

when you cover your feet sigh that's

actually a quote by 27 team on CSS I

I found it on Twitter well anyway it is

now 2015 we live in a much better world

deserve and him didn't just come up with

this awesome quote he also created

elixir programming language built on top

of airline vm another language EP it has

beautiful hybrid Ruby are laying like

syntax and US appeals to a number of

Ruby as well as our Lang developers and

has naturally all the benefits of

airline including complete

interoperability was any airline code

and libraries and now it's time for the

cherry on top Chris McCord build a fully

featured web flame framework in elixir

it does not sacrifice the speed like

ruby on rails or maintainability like

PHP ultimately standing on the shoulders

of giants like Erlang the M the Erlang

vm and air language EP it offers amazing

scalability and fault tolerance for our

web server the name of the framework is

Phoenix you got it now we got at all

call it the best of both worlds or call

it a perfectly sized blanket this time

around chorus has a chance this

concludes my presentation thank you very

much for listening and

now it's time for any questions you have

no questions a couple in the back

hello I don't have a question I just

have a compliment great presentation

thank you so I was curious if you've

actually built the site and how did it

work out no I just thought I actually

was gonna build the site before this

presentation so I can brag about it but

I turned out at two months was not

enough for me solid I am actually

thinking about it and I also not I'm

still not sure how exciting of idea is

this and as I actually suspect that the

reason why I didn't build is not because

they weren't tools around just because

I'm I'm not much you were like a visual

website kind of person I'm more of a

backend engineer so but i might since

the tools are out there it was a

fairytale two parties hey arena um over

here oh hey I just wondering you know so

eka does implement the sort of actor

interface the UM and scala allows you to

define things as being immutable or her

mind I'm missing something I'm trying to

figure out what it was about your about

the JVM that is inherently rahner or

inherently not what you want um so you

said that um Scala is immutable but the

whole point for Scala was actually as

Colin um was that it's actually in touch

interoperable with Java so basically

while Scala itself is immutable so if

you write a program in pure Scotland

without thought without letting any java

code in it will be immutable but the JVM

it has this huge heap and basically it

cannot kill a threat on the JVM so

you'll have this

actors implemented in the art with aqua

and scour but you can't kill those if

something goes wrong it cannot kill them

and that's the you can't kill processes

it can kill rats in the on the JVM

that's that's the ultimate limitation of

the JVM so any yes and you can

contaminate your program was the mutable

code because it allows Java very easily

in so if you use any Java libraries

you're open to the dangers okay thank

you any other questions for irina

discussion has they only gone through

this I've gone through this many times

just like this this standard process of

you need to go and find the thing that

the right everything before you go build

it I can completely relate to that I

mean who know has anyone had experience

with elixir here or you're lying vm it's

very different it's an interesting

language any other questions somebody's

yawning that's not a question stretching

I'm sorry not okay well thank you very

much arena