7 stages of web application development

Original author: John Engates
  • Transfer
This is an edited translation from Comrade's presentation slides . John Engates
format: slide number, summary and (my rare kamenty)
  1. Web Development Stages by
    John Engates
  2. Regulations:
    • What do we expect from web applications
    • How does it happen
    • Good examples
    • Questions and answers

  3. What do we expect from sites

    • Scalability
    • High return
    • Efficiency
    • Ease of Management
    • Low cost (service included)
    • An abundance of ryushechek Rich functionality
    • And what will he do to us loot, a lot of dough!

    This is the seven-digit mantra of the client-director who is thinking about ordering a corporate website
  4. High availability. Definition:
    High Availability HA is an approach to design and implementation that guarantees a certain degree of confidence in their (design and development) continuity. So that!
    How it looks on examples:
    • your site is always up and running
    • users are happy
    • you do not lose money due to technical downtime
    • (and this does not increase maintenance costs beyond what is necessary)
    It was the mantra of the tehdir of the project
  5. What is actually called scalability
    Scalability (extensibility) is the expected property of the system, which shows its ability to increase revenue in a pleasant way, or easily increase functionality as necessary
    (Uncle turned down cool. I really got tired of the translation. In short, scalability is the ability systems to expand and grow Well, increase profitability, yes)
    The option from pika is here

    What scalability is not expressed:
    • purely capacity increase (2MHz -> 3MHz)
    • something like operating systems (Solaris vs Linux)
    • software technology feature (Java - Python - Rails)
    • platform features (Intel - AMD)
    • code optimization (10 lines versus 1000, this guy claims, doesn't solve anything )
    • the choice of storage technology (SAN vs NAS) as I guessed, these are different storage infrastructures. see kamenty below

  6. in big red letters

    EXTENDABILITY AND PERFORMANCE - NOT ONE AND ALSO

  7. pictures with examples
    beautiful cars, road interchanges and urinals
  8. images
  9. images
  10. images
  11. images
  12. images
  13. The first truth:

    Nothing can multiply if it is not designed.
    (Option: Nothing can be scaled unless designed to be scalable.)

  14. The second truth:

    If something was designed as a constructor, it can grow without problems.
    Option from pika : Even if the system is designed for scaling, it will still hurt.

  15. Very interesting picture “scale of pain” (puns with the previous paragraphs scaling - scale, it was difficult to adequately translate)
  16. Typical development scenarios

    Stage 1. Start
    • Simple architecture
      - firewall and balancer
      - a couple of web servers are written like that, didn’t lie
      - database server
      - internal storage

    • Small complexity and problem, fast development, rich features of various kinds and everything is fast
    • No redundancy (Wh and labor), low cost of work - a great start-up!

  17. Stage two, all the same, but a little bit more
    • Successful business is the key to a good relationship with the law
    • Add some firewalls and balancers
    • Add a little more web servers for performance
    • We install the DB schema and optimize it using DBA (consultant)
    • Add Bases
    • We will transfer storage to SAN or DAS
    • Still simple, suitable for promising applications

  18. Stage Three - First Symptoms
    • Publicity
    • Squid or Vanish installed in reverse proxy mode, or a very good balancer - for caching static content
    • Add as many web servers as you want (content management already delivers a lot of bunting)
    • The only database will not be shared ever (separate read-write operations are meant - the entire recording is done on a single master server with several secondary servers for reading)
    • It may be necessary to rewrite the thread in the application

  19. The picture “Extensibility for database servers”
  20. Stage Four - Pain intensifies
    • Memcache caching
    • Replication does not work for everything (the only basis for writing - many bases for writing - result: replication works for a long time)
    • There comes an awareness of the need for database separation (of course, if your database supports this mechanism)
    • Awareness of distributed storage for content comes
    • A serious transformation of the application and database architecture is necessary (and developers may not have such a skill)

  21. Stage Five - Really a pain in the ass!
    • Mr. Panic comes and remains with you to live.
      Couldn't we have done all this before? (List of this:
      - Complete rethinking of the application \ business model
      - And why didn’t we plan the extensibility of the system at the time of making decisions on the architecture?)
    • The impossibility of divisibility as an application feature - what else can we use? (Options
      - Separation based on a geographical principle, by last name, by userID, etc
      - Creating user clusters (user clustering)
    • Application behavior must be identical on each user cluster
    • Using hash structure or DB master server to determine which user to connect to which cluster

  22. Stage Six - Parish, Mal-Mal Relieved
    • Extensible Application and Base Architecture
    • Satisfactory performance
    • You can add new functionality again
    • Optimizing something in code
    • We continue to grow, but now it’s completely controllable

  23. Stage Seven - Exodus into the Unknown
    • Where else are bottlenecks waiting for us?
      - Power supply, accommodation area
      - Channels and stuff - how big is your hoster?
      - Problems of security 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 the data
      - problems of data replication and geographic balancing

  24. Good advice
    • Do not reinvent the wheel, copy from someone else
    • Just think
      - All things done are nowhere simpler - not so simple. - A. Einstein
    • Think horizontally ... not vertically ... in any case (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 a time (this is called iteration)
  25. Some more good advice
    • Do not waste time optimizing your optimization (“Premature optimization is premature” ©#phpclub@undernet.org)
      - Take your [correctly designed] architecture, often tailor solutions [for it], and rarely optimize (or never)
    • Test expansion options with suitable stress tests
      - Make it a familiar practice before you think about their need
    • Use caching before you feel the need
    • A lot of memory and a 64-bit platform will help you (Use the Force, Luck! :)
    • Test new features before choosing between performance and scalability becomes a problem
      - Nice to have vs. have to have. And you will be happy :)

  26. Service Changes and Availability
    • Do not underestimate the need for the correct formulation of the process and documentation
    • Manage Releases!
      - Development - testing - release
      - Availability of methods for carrying out these actions
    • Use version control systems
      - I see, yes: RCS, CVS, Subversion
    • Keep track of releases (in short, issue tracking is good advice to use a tracking system. Specialized bug tracking systems provide assistance in the development, and not trac type trash - it has other tasks. If you use a control system, 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 - Implementing
      - Critical for High Availability Infrastructure (HA)
Further there is advertising and thanks.
end the

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 it! :) if there are buyers. I did not learn anything particularly new. I hope someone will find it useful

Also popular now: