evolution of web application architecture - phpday italy · evolution of web application...
TRANSCRIPT
Evolution of Web Application ArchitecturePHPDay Italy
Kore Nordmann / @koredn / <[email protected]>May 14th, 2016
Hi, I’m Kore
Architecture
Evolution
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
Evolution
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
Lessons Learned: Non-Sticky Session
I Put session on memcached / RedisI Mostly trivial because of existing extensions
Evolution
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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
Evolution
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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
Evolution
Sharding
I Split tables across multiplenodes
I Vertical shardingI Shard by consistent
hashingI Horizontal sharding
product
user
…
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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
Evolution
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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
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.
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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
Evolution
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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
Evolution
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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. . .
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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
Copyright Qafoo GmbH; All Rights Reservedtalks.qafoo.com
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