7 stages of web application development

This is an edited translation from the slides of Comrade’s presentation. John engates
format: slide number, summary and (my rare kamenty)

1. Stages of the formation of web resources
   by John Engates
2. Regulations:
   
   • What we expect from web applications
   • As it happens
   • Good examples.
   • Questions and answers
     
     
3. What we expect from sites
   
   
   • Scalability
   • High return
     
   • Efficiency
   • Ease of Management
   • Low cost (maintenance, including)
   • Abundance of ryushechek Rich functionality
   • And that he will make us loot, a lot of dough!
   
   This is the seven-digit mantra of the client-director, who thinks about ordering a corporate website.
4. High availability. Definition:
   High Availability HA is a design and implementation approach that guarantees a certain degree of confidence in their (design and development) continuity. So that!
   How it looks on examples:
   
   • your website is always up and available
   • users are happy
   • You do not lose money because of technical downtime
   • (and this does not increase maintenance costs beyond what is needed)
   This was the project mantra
5. What is actually called scalability
   Scalability (extensibility) is an expected feature of the system, which shows its ability to increase revenue in a pleasant form, or it is easy to build up functionality as needed
   (Uncle bent cool. I'm really tired of the transfer. In short, scalability is the ability of the system to expand and grow. Well, and increase the yield, yes)
   Option from pika here
   
   What is not expressed scalability:
   
   • purely capacity expansion (2MHz -> 3MHz)
   • something like operating systems (Solaris vs Linux)
   • feature of software technologies (Java - Python - Rails)
   • Platform Features (Intel - AMD)
   • code optimization (10 lines against 1000, this guy says, does not solve anything )
   • the choice of storage technology (SAN vs NAS), as I guessed, is a different storage infrastructure. see kamenty below
   
   
6. in red letters
   ')
   EXPANDABILITY AND PERFORMANCE - NOT ONE AND ALSO
   
   
7. pictures with examples
   beautiful cars, road junctions and urinals
8. Pictures
9. Pictures
10. Pictures
11. Pictures
12. Pictures
13. Truth is the first:
    
    Nothing can multiply if not designed.
    (Option: Nothing can be scaled if not designed to be scalable.)
    
    
14. The second truth:
    
    If something was designed as a constructor, it can be extended without problems.
    Option from pika : Even if the system is designed for scaling, it will still hurt.
    
    
15. Very interesting picture “scale of pain” (wordplay with previous points of scaling - scale, found it difficult to adequately translate)
16. Typical development scenarios
    
    Stage 1. Start
    
    • Simple architecture
      - firewall and balancer
      - a couple of web servers are written that way;
      - database server
      - internal storage
      
      
    • Small complexity and problematic, fast development, rich features of all kinds and everything is fast
    • No redundancy (vtch and in the workforce), low cost of work - a great startup!
      
      
17. Stage two, all the same, but a little bit more
    
    • Successful business is a good relationship with the law.
    • Add some firewalls and balancers
    • Add a little more web servers for performance
    • Set up the database schema and optimize it with the help of DBA (consultant)
    • Add databases
    • Translate storage to SAN or DAS
    • Still simple, suitable for promising applications.
    
    
18. Stage Three - First Symptoms
    
    • Publicity
    • Squid or Vanish is installed in reverse proxy mode, or a very good balancer - for caching static content
    • Add some more web servers (content management is already delivering a huge smut)
    • A single database will not be divided ever (separate read-write operations are meant - the entire record is kept on a single master server with several secondary servers for reading)
    • It may be necessary to rewrite the black thread in the application.
    
    
19. Picture "Extensibility with reference to database servers"
20. Stage Four - Pains worse
    
    • Memcache caching
    • Replication does not work for everything (the only base for writing is a lot of databases for writing - the result: replication takes a long time)
    • There comes an awareness of the need for database separation (of course, if your database supports this mechanism)
    • Awareness of distributed repositories for content comes
    • It requires a serious transformation of the application architecture and database (and developed may not have such a skill)
    
    
21. Stage Five - Really a smut!
    
    • Mr. Panic comes and it remains for you to live.
      Couldn't we do all this before? (A list of this:
      - Complete rethinking of the application \ business model
      - And why we have not planned the extensibility of the system at the time of making decisions on architecture? )
    • Impossibility of divisibility as an application feature - what else can we use? (Options
      - Division based on geographical principle, by last name, by userID, etc
      - Creating user clusters (custom clustering)
    • Application behavior must be identical on each user cluster.
      
    • Using the hash structure or database master server to determine which user to which cluster to connect
      
      
22. Stage Six - Parish, small-small feel better
    
    • Extensible application and database architecture
    • Satisfactory performance
    • You can add new functionality again.
    • Optimize something in code
    • We continue to grow, but now it is quite manageable
    
    
23. Stage Seven - Exodus into the unknown
    
    • Where are we still waiting for bottlenecks?
      - Provision of food, placement area
      - Channels and stuff - how big is your hoster?
      - Problems of protection systems and load balancers
      - Data Warehouses
      - People and problems
      - Technological limitations of database extensibility - still want to store data in a key-value scheme?
    • What about "all the eggs in one basket"?
      - one data center
      - one copy of data
      - problems of data replication and balancing on a geographical basis
    
    
24. Good advice
    
    • Do not reinvent the wheel, copy someone else
    • Just think
      - All things made easier nowhere - not so simple. - A. Einstein
      
    • Think horizontally ... not vertically ... in any cases (maybe this is an idiom?) How expensive? - instead - How fast?
    • Use suitable software and equipment.
    • Solve problems easily and simply
      - put plans into action
      - Separate different services
      - Do not make many changes at once (this is called iteration)
25. Some more good advice
    
    • Do not waste time optimizing optimization (“Premature optimization is premature” ©#phpclub@undernet.org)
      - Take your [well-designed] architecture, often adjust the solutions [for it], and rarely optimize (or never)
    • Verify extensibility with suitable load tests.
      - Make it a familiar practice before you start thinking about their need.
    • Use caching before you feel the need
    • A lot of memory and 64-bit platform will help you (Use the Force, Luck! :)
    • Check out new features before the choice between performance and scalability becomes a problem.
      - Nice to have vs. have to have. And you will be happy :)
      
      
26. Changes and service availability
    
    • Do not underestimate the need for proper formulation of the process and documentation
    • Manage your releases!
      - Development - testing - release
      - The presence of methods for carrying out these actions
    • Use version control systems.
      - Clear, yes: RCS, CVS, Subversion
    • Keep track of issues (in short, issue tracking is a good advice to use the tracking system. IMHO development assistance is provided by specialized bugtracking systems rather than trac such as trac - it has other tasks. If you use the control system, then it should be a combine in which it is transparently tracked timelines, something like eGroupWare (this tip complements the previous one)
      
    • Use coding standards
    • Manage change
      - Planning - Testing - Implementation
      - This is critical for High Availability Infrastructure (HA)

Then there is advertising and thanks.
end

first translation here
translated, because the topic is interesting; It turned out more than 1000 words, more than 7500 characters. I can make an article and sell! :) if there are buyers. I did not learn anything particularly new. I hope someone will be useful