42.zip(42.374 bytes zipped)
The file contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped,
which again contains 16 zipped files, which contain 1 file, with the size of 4.3GB.
So, if you extract all files, you will most likely run out of space :-)
16 x 4294967295 = 68.719.476.720 (68GB)
16 x 68719476720 = 1.099.511.627.520 (1TB)
16 x 1099511627520 = 17.592.186.040.320 (17TB)
16 x 17592186040320 = 281.474.976.645.120 (281TB)
16 x 281474976645120 = 4.503.599.626.321.920 (4,5PB)
Tuesday, January 6, 2015
Friday, January 2, 2015
Notes from Lucas Carlson talk
6 Bad practices:
1. Synchronicity
3_tier systems are like sync information factory lines
If one area chokes, rest chokes
2. Dependency on Filesystems
State data (sessions, uploaded files, etc) stored on hard drives is very hard to scale
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
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
5. Moving to the Cloud without a Plan
Cloud migration is often thought of as simple 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
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 otherwise robust system
All your eggs in one basket
6 Good practices:
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
2. Distributed Object Storage
Memcached, Redis, MongoDB, CouchDB, etc
Use instead of filesystems in legacy web applications (sessions, file uploads, etc)
Consider replacing oc caching the largest and fastest growing relational database tables with object storage
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
4. Architecting fo Failure
Think about anti-fragile 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 redundancy.
5. Use cloud migration as an Opportunity to modernize architecture
Dont half-do it
Not all applications will do well in cloud environment
Automation is vital in cloud environments where infrastructure isn't reliable
6. Redundancy everywhere
Audit every area of your application for redundancy
2x or 3x redundancy is not enough
Google's rule of thumb is for 5x redundancy
Be like the Hydra, kill one head and grow tow in its spot
Netflix: Chaos Monkey - try to randomly break servers through out the system and day to see how your application would react.
Dont expect it to work
3 Conclusions
1. Legacy web applications are fragile
2. Think about anti-fragility (not scalability) up front
3. Micro-services are anti-fragile future:
Lightweight distributed
Share-nothing systems built with APIs
Conclusion
1. Automation is dominating the future landscape of web app architecture
2. Micro-services are the future
- Lightweight distributed
- Share-nothing systems built with APIs
3. Docker and Linux Containers are the new way to package and distribute your applications
1. Synchronicity
3_tier systems are like sync information factory lines
If one area chokes, rest chokes
2. Dependency on Filesystems
State data (sessions, uploaded files, etc) stored on hard drives is very hard to scale
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
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
5. Moving to the Cloud without a Plan
Cloud migration is often thought of as simple 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
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 otherwise robust system
All your eggs in one basket
6 Good practices:
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
2. Distributed Object Storage
Memcached, Redis, MongoDB, CouchDB, etc
Use instead of filesystems in legacy web applications (sessions, file uploads, etc)
Consider replacing oc caching the largest and fastest growing relational database tables with object storage
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
4. Architecting fo Failure
Think about anti-fragile 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 redundancy.
5. Use cloud migration as an Opportunity to modernize architecture
Dont half-do it
Not all applications will do well in cloud environment
Automation is vital in cloud environments where infrastructure isn't reliable
6. Redundancy everywhere
Audit every area of your application for redundancy
2x or 3x redundancy is not enough
Google's rule of thumb is for 5x redundancy
Be like the Hydra, kill one head and grow tow in its spot
Netflix: Chaos Monkey - try to randomly break servers through out the system and day to see how your application would react.
Dont expect it to work
3 Conclusions
1. Legacy web applications are fragile
2. Think about anti-fragility (not scalability) up front
3. Micro-services are anti-fragile future:
Lightweight distributed
Share-nothing systems built with APIs
Conclusion
1. Automation is dominating the future landscape of web app architecture
2. Micro-services are the future
- Lightweight distributed
- Share-nothing systems built with APIs
3. Docker and Linux Containers are the new way to package and distribute your applications
Subscribe to:
Posts (Atom)