Legacy web architectures are fragile and broken. It's time everyone start moving to a micro-services based and share-nothing API-driven web architectures.

1. Designing Modern
Web Applications
by
Lucas Carlson

2. Programmer
18 Years
Author
• Ruby Cookbook
• Programming for PaaS
Entrepreneur
• AppFog PaaS
• Mog Music Streaming Service
Current Role
• Chief Innovation Officer at
CenturyLink
Who Am I?

3. Structure
1
Who Am I?
2
What’s Wrong
With Legacy Web
Architectures?
3
How to Design a
Modern Web
Application
4
The 6 Worst
Web Practices and
How to Avoid Them
5
Getting the
Most From the
Cloud
6
Conclusions

4. What’s Wrong With
Legacy Web Architectures?
If it ain’t broke, don’t fix it… right?

5. Legacy Web Architectures
Web
Server
2b
5
Application
Server
AppThena
Web App
Other
Web App
Other
Web App
Other
Web App
53
Database
Server
4
Data
CSS
Images
Pages
2a
BROWSE
R

6. Legacy Web Architectures
Web
Server
2b
5
Application
Server
AppThena
Web App
Other
Web App
Other
Web App
Other
Web App
53
Database
Server
4
Data
CSS
Images
Pages
BROWSE
R

7. Browser
6
Web
Server
2b
5
Application
Server
AppThena
Web App
Other
Web App
Other
Web App
Other
Web App
53
Database
Server
4
Data
CSS
Images
Pages
Legacy Web Architectures
Limited
Redundancy
Error 500

8. Legacy Web Architectures
Web
Server
Application
Server
AppThena
Web App
Other
Web App
Other
Web App
Other
Web App
53
Database
Server
4
Data
CSS
Images
Pages
BROWSE
R

9. Legacy Web Architectures
Web
Server
Application
Server
AppThena
Web App
Other
Web App
Other
Web App
Other
Web App
53
Database
Server
4
Data
CSS
Images
Pages
BROWSE
R

10. Legacy Web Architectures
Browser
6
Web
Server
Application
Server
AppThena
Web App
Other
Web App
Other
Web App
Other
Web App
53
Database
Server
4
Data
CSS
Images
Pages
Limited
Scale
Error 500

11. Limited
Scale
Legacy Web Architectures
1
5
Browser
6
Web
Server
5
2b
5
Application
Server
AppThena
Web App
Other
Web App
Other
Web App
Other
Web App
53
Database
Server
4
Data
CSS
Images
Pages
2a
Error 500

12. Legacy Web Architectures
3-Tier
Systems
Scale…
Up to a Point
Databases are
limited
by disk size and
IO rates
Applications
are limited
by RAM and CPU
As they get
more complex,
they end up
breaking

13. Legacy Web
Architectures are

14. How to Design a
Modern Web Application

15. What’s the opposite of
fragile?
Hint: It’s not robustness

16. What’s the opposite of
fragile?
Answer : Antifragile

17. Anti-fragile
Definition

18. Examples
Break under
stress
Don’t care about
stress
Grow under
stress

19. The “Heart of Africa”

20. Characteristics
Monolithic Decentralized
Tightly coupled Loosely coupled
Heavyweight Lightweight
Complicated Simple
No redundancy Extra redundancy
AgileSluggish
Locked-in Interoperable

21. Anti-fragile
actively randomly kills
its own servers to
ensure its architectural
anti-fragility

22. Web Architectures Are Changing
To lightweight
distributed share-
nothing systems
From heavy
monolithic
backend systems

23. Legacy Web Architectures
Web
Server
Application
Server
AppThena
Web App
Other
Web App
Other
Web App
Other
Web App
53
Database
Server
4
Data
CSS
Images
Pages
BROWSE
R

24. Modern Web Architectures
App App App App
Load
Balancer
DB DB
BROWSE
R
Worker Worker
Load
Balancer
Message Bus / Distributed Service Discovery

25. Resiliency
App App App App
Load
Balancer
DB DB
BROWSE
R
Worker Worker
Load
Balancer
Message Bus / Distributed Service Discovery

26. The 6 Worst Web Practices
and How to Avoid Them

27. Bad Practice #1:
Synchronicity
 3-Tier Systems are like synchronous information factory lines
 If one area chokes, the entire system fails
 Usually leads to complex logical units

28. Bad Practice #2:
Dependency on Filesystems
 State data (sessions, uploaded
files, etc) stored on hard drives is
very hard to scale
 Requires NFS or equivalent which
are complex and chatty
 Lock you into monolithic coding
practices

29. Bad Practice #3:
Heavy Server-Side Processing
 Generating all the HTML server-
side made sense when client
hardware was slow
 No REST/JSON/Javascript
 All the information from a request
needs to be compiled before
returning any data

30. Bad Practice #4:
Expecting Services to Always Be Available
 Designing for Success is Failure
 Cloud infrastructure has higher
failure rates than dedicated
hardware
 Disaster recovery can be slow
and prone to errors

31. Bad Practice #5:
Moving to the Cloud without a Plan
 Cloud migration is often thought
of as simply a cost issue, not a
technical one
 Higher failure rates in cloud
infrastructure will break fragile
applications
 Migrations without a good plan
can cost a lot of unexpected
time and money

32. Bad Practice #6:
Lack of Redundancy
 All single points of failure are
terrible monsters (DNS, Load
Balancers, Network, etc.)
 Not only choke points, but can
take down an otherwise robust
system
 All your eggs in one basket

34. Good Practice #1:
Asynchronous Processes
 Small decoupled apps
 Communicate through a queue,
REST APIs, or a message bus
 Each one should do one thing very
well: simple and specialized

35. Good Practice #2:
Distributed Object Storage
 Memcached, Redis, MongoDB,
CouchDB, etc.
 Use instead of filesystems in legacy
web applications (sessions, file
uploads, etc.)
 Consider replacing or caching the
largest and fastest growing relational
database tables with object storage

36. Good Practice #3:
Micro-Services
 Leverage increased CPU capacity on
browsers with client-side Javascript
• AngularJS, Ember, Backbone
 Simple and specialized REST APIs
• Java: Spring, Spark, Jersey
• .NET: WCF, OpenRasta
• Ruby: Sinatra
• Python: Flask, Bottle
• PHP: Slim
 BONUS: Power your mobile apps

37. Good Practice #4:
Architecting for Failure
 Think about anti-fragility upfront
 Pro-actively stress your system
and study how it fails (not just load
testing, think of Netflix’s chaos
monkey)
 Make all failures an opportunity to
eliminate bottlenecks, increase
redundancies and prepare for the
unexpected

38. Good Practice #5:
Use Cloud Migration as an Opportunity to
Modernize Architecture
 Don’t half-do it
 Not all applications will do well in cloud
environments
 Automation is vital in cloud environments
where infrastructure isn’t reliable, traditional
IT can’t respond quickly enough

39. Good Practice #6:
Redundancy Everywhere
 Audit every area of your application
for redundancy
 2x or 3x redundancy is not enough
(the failure of one or two will over-
load and choke the remaining
systems)
 Google’s rule of thumb is for 5x
redundancy
 Be like the Hydra, kill one head and
grow two in its spot

40. Getting the Most From the Cloud

41. Portfolio of Cloud Services
EASY
HARD
 SaaS and Cloud Managed
Services
 IaaS and PaaS
 DevOps and Orchestration

42. SaaS and Cloud Managed Services
Errors
Exceptional, Airbrake
Analytics
Statsmix, NewRelic,
Blitz
Other
Zerigo, CloudFlare,
Recurly, Stripe
Mobile
Urban Airship, Pusher,
Realtime.io
Data
ClearDB, Amazon
RDS, Heroku
Postgres, MongoLab
Search
Searify, Websolr, AWS
CloudSearch
Email
Mailgun, Sendgrid,
CloudMailin
Logging
Loggly, Logentries,
Papertrail
Background
Tasks
Iron.io, CloudAMQP

43. IaaS and PaaS
 Heroku
 AppFog
 Cloud Foundry
 OpenShift
 Google App Engine
 Azure
IaaS PaaS
 AWS
 Google
 Azure
 DigitalOcean
 Rackspace
 CenturyLink Cloud

44. DevOps and Orchestration
 Apache
Mesos/Mesosphere
 Kubernetes
 CoreOS Fleet
 OpenStack Heat
 Chef
 Puppet
 SaltStack
 Ansible
 ZooKeeper
DevOps Orchestration

45. What’s Orchestration?

47. API-Driven Automation Built on Top of
DevOps Tools for Declaratively Deploying
Complex Cloud Apps
Orchestration :

48. Before Orchestration
Application
Job Scheduling
Engine
Job
Worker
Job
Worker
Job
Worker
Job
Worker
Database

49. After Orchestration
Orchestration API
Job Scheduling
Engine
App App DB
Job
Worker

50. Modern App Architecture
Orchestration API
Job Scheduling
Engine
App App DB
Job
Worker
App App
Load
Balancer
DB Worker
Load
Balancer
Message Bus / Distributed
Service Discovery

51. Conclusions

52. Conclusions
1. Legacy web architectures are
fragile
2. Think about anti-fragility (not
scalability) up-front
3. Micro-services are the anti-fragile
future:
 Lightweight distributed
 Share-nothing systems built with
APIs
1
2
3

53. Thank You!
@cardmagic
LucasCarlson.com