Evolution of Web Application Architecture - PHPDay Italy · Evolution of Web Application Architecture PHPDay Italy Kore Nordmann / @koredn / May 14th, 2016

Evolution of Web Application ArchitecturePHPDay Italy

Kore Nordmann / @koredn / <[email protected]>May 14th, 2016

Hi, I’m Kore

Architecture

Evolution

Too many visitors

CC BY 2.0 Scott Cresswell – https://flic.kr/p/knkntv

https://flic.kr/p/knkntv

Evolution

Evolution

Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com

Lessons Learned: Load Balancing

I Works because of HTTP & PHPI HTTP is LCoDC$SSI PHP is build for shared-nothing

I Round Robin works bestI Sticky sessions will overload certain servers

Non sticky session– how?

CC BY 2.0 DJ Bustos – https://flic.kr/p/rLfXoR

https://flic.kr/p/rLfXoR

Evolution


Lessons Learned: Non-Sticky Session

I Put session on memcached / RedisI Mostly trivial because of existing extensions

Where to put thestatic data?

CC BY 2.0 Richard – https://flic.kr/p/joASfQ

https://flic.kr/p/joASfQ

Evolution


Lessons Learned: Static Files

I NFS will eventually lead to dead locksI . . . still seems the most popular solution around.

I Multiple domains can hurt performance (TCP slow start)I Using dedicated CDN providers can help

I Content locality

Database serverstoo slow…

CC BY 2.0 super awesome – https://flic.kr/p/75LH5i

https://flic.kr/p/75LH5i

Evolution


Lessons Learned: Replicate Database

I Master Slave Replication is fairly easy to set upI Obviously only scales READsI WRITEs are usually not your first problem

Database serverstoo expensive…

CC BY-SA-NC 3.0 Kore Nordmann

Evolution


Lessons Learned: Cache With Memcache

I Cache all the things in memoryI Cache entitiesI Cache collectionsI Full page cache

I Cache invalidationThere are three hard things in Computer Science:Cache invalidation and off by one errors.

I Cache dependency calculationI The paging problem

Too many writes

CC BY 2.0 Drew Coffman – https://flic.kr/p/8kvbSL

https://flic.kr/p/8kvbSL

Evolution

Sharding

I Split tables across multiplenodes

I Vertical shardingI Shard by consistent

hashingI Horizontal sharding

product

user

…


Lessons Learned: Sharding

I Shard by tableI . . . or even shard by consistent hash per entity

I No referential integrity checkingI Queries are limited to sharding solutionI Schema updates across multiple shards are fun

Setup too complex

CC BY 2.0 KellarW – https://flic.kr/p/rqJYiZ

https://flic.kr/p/rqJYiZ

Evolution


Lessons Learned: NoSQL

I Usually solves one problem really well:I ShardingI Multi-Master-ReplicationI Cross-shard queries

I Usually omits:I SQLI Referential Integrity

I . . . we lost all relevant features fromRelational Database Management Systemsanyways. . .

Keeping data consistentacross multiple nodes

CC BY 2.0 Beraldo Leal – https://flic.kr/p/56UqaR

https://flic.kr/p/56UqaR

Data Consistency Across Nodes

?

✓????

Eventual Consistency

Truth ClientUpdater /Replicator

Last Revision?

<hash>

Get Updates Since <hash>

{update, revision}[]{update, revision}[]

null

Revisions MUSTincrement

strictly monotonic

Revisions MUST NOTbe stored if anupdate fails.


Lessons Learned: Data Consistency

I Embrace Eventual ConsistencyI Compaction is hardI Data migrations are hard

Business wants toquery data

CC BY 2.0 anton petukhov – https://flic.kr/p/rCGQp6

https://flic.kr/p/rCGQp6

Evolution


Lessons Learned: Map-Reduce

I Execute queries on distributed databasesI New query language to learn

I Your developers write analysis scripts, instead of the businessanalysts writing slow SQL queries

How to orchestrate?

CC BY 2.0 Frederik Magle Music – https://flic.kr/p/bGW2Pv

https://flic.kr/p/bGW2Pv

Evolution


Lessons Learned: Queues

I Queues can ensure data is processed asynchronouslyI Data consistency must be ensured even when pushing into

queuesI Following the data flow of an action can be “tricky”

I Used to distribute data between systems

Evolution

Microservices

Apply Seperation of Concerns on service level to allowfor seperate teams & technologies per concern.

I Microservices can simplify things:I Choose optimal technology stack per team & concern

I Microservices will also complicate things:I Automated deployment is a mustI Service orchestration is still a problemI Service downtimes and latency must be handled gracefully

(Eventual Consistency)

I Big DataTM will stay a problemI Sensible services are often not micro any more. . .


Lessons Learned (subjective)

I Boring technology choices will often work bestI Just start & stay with LAMP?

I Only bring in shiny new technologies with careI There are enough reasons to eventually do that, though

The Hipster Says:

*

* Except you evaluated it as the correct solution for your case


Conclusion

I There are many developers, documentation & experience forboring technologies

I Evaluate before adding new technologies (ATAM)I Do not jump on every bandwagon – this includes

microservicesI Data Consistency accross nodes is hard &

important

https://joind.in/talk/3152e

Documents

Evolution of Web Application Architecture - PHPDay Italy · Evolution of Web Application Architecture PHPDay Italy Kore Nordmann / @koredn / May 14th, 2016