This article outlines the base elements that an application developer eventually has to consider while designing, creating and deploying contemporary software made for public or private distribution which processes data in some way and provides some form of user interface experience.

Contemporary venacular loosely lumps anything which provides some sort of user interface to a computer program into the term app which is short for application. Ultimately, for the all but the most particular of souls (such as myself), every piece of software is an 'app' now.

If you are writing tools, frameworks, APIs, or any other sofware which falls outside of the context as described, then only a subset of these layers may apply to your software. For our purposes, we are explicity concerned with the design and implementation of a modern web and/or mobile application deployed for 24/7 multi-user service.

• Application Stack
  The technologies, components, APIs, packages and layers of your application, from project root inward exclusive of static assets and inclusive of all actionable code which shall, at some point, be compiled or interpreted. Some parts of your application stack will also be part of your server stack.
• Assets
  Files (typically) that are not executed or compiled and passed to the client without processing. File types such as CSS, fonts and images are almost always considered static assets, but an asset (or static asset if you prefer) has no restriction on file type. Any dynamically (as in on-the-fly or generated-per-request) constructed element cease to be considered an asset for our purposes. A file which is generated by a pre-processor, for instance, becomes an asset while the file processed by the pre-processor shall be considered actionable code. Technically a static sub-set of your application stack or data sets.
• Data Sets
  All data is data, so to speak. Your program is, in fact, data. But in this context the reference is to actual data collected and processed by your program in some way and most likely stored somewhere. This may be a large distributed database, a collection of spreadsheets, a collection of files (like your database ultimately is), or a collection of bytes in some form of memory buffer (like your database, or file system, could be). The point is, any container which holds data-at-rest shall be considered a data set (or store, collection, table, etc), which therefore may be considered to have state.
• Infrastructure
  Ultimately your program (application stack), assets and data all must live in some physical location(s). Even if it only exists in your mind. Whatever physical resources your program requires for one complete deployment is what shall be considered your application's infrastructure, regardless of the geo-physical boundaries it occupies.
• Program Flow
  If all your program does is nothing, it is probably very boring. Program flow defines how a program sends bits of data from one piece, component or service to another. Whether that other is within the program itself or external to it is of little consequence. Any movement of data, signal emitted, or side-effect incurred shall be considered part of program flow. An application's state may be said to be a snapshot of the program's flow frozen in time.
• Server Stack
  This is the system of software and technology that resides between your infrastructure and your application, enabling your software to be executed (or interpreted). It also generally provides the mechanisms which enable the storage and retrieval of your data, process and resource management. Logging, monitoring and management tools are always available at this layer, although at times an interface may be provided by the provider of one's infrastructure and one's infrastructure may be logged, monitored and managed from somewhere within one's server stack.

The icing on the cake, of course, is pure sugar. Cake is still good without it, but a truly well-crafted cake has just the perfect amount.

Automation will always be found in highly scaled applications, although applications of any size may utilize it. There are many ways to integrate magic into your application, from automated code building and deployment, to infrastructure that scales on demand.

Many people want to jump right in and start developing their application infrastructure in a scalable way using automation. It sounds like a great idea, but in the real world, it can just make everything harder. You, your application and its layers should all grow together harmoniously. Don't force it.

• Facebook
• Gmail
• Slack Chat
• Wordpress

• Direct-request (files served directly from within the application's file structure)
• Content delivery network (files hosted by external provided)
• Dynamically generated & cached (caching may be provided locally, by remote CDN and/or using browser cache)

• File system (CSV, tree based)
• Non-Relational databases (Couch, Dynamo, Mongo)
• Object stores (Memcached, Redis, ElastiCache)
• Relational databases (MSSQL, MySQL, Oracle)

• Traditional shared hosting (cPanel/WHM)
• Traditional VPS/DVS (like above, but with root)
• Platform-as-a-Service (Heroku, Modulus, Digital Ocean)
• Direct Cloud (AWS, Microsoft Azure, Google Cloud, IBM Softlayer, Rackspace Cloud)

• MVC
• MVVC
• Flux
• J-Flow (my favorite)
• Message passing
• Reactive

• AWS Lambda, AWS Dynamo, AWS API Gateway (serverless)
• Linux, Apache, MySQL, PHP
• Linux, Nginx, MySQL, PHP
• Microsoft Stack (Server, MSSQL, dotNet)

• Ansible
• AWS CloudFormation
• Chef
• Docker
• Runbook

• Android SDK
• Angular
• Django
• Google Web Toolkit
• ECMAScript
• Less
• PHP
• React
• Ruby
• Smarty
• Swift
• Twitter Bootstrap

• Actionable Code Any code in any language that will eventually be compiled or interpreted by a compiler, pre-processor or post-processor.
• API Short for application programming interface, APIs are simply functions (aka methods) exposed by some source. This source could be a global variable in your program, an imported interface from an open-source module, or provided by some external resource using HTTP GET/POST requests (often known as REST or API gateways).
• Data-at-Rest A term used to express a certain set of values frozen in time. If your program updates a counter every nano-second, then every one billionth of a second your data is at rest. Typically though, we are referring to data stored in a database or memory store that does not change until some aspect of your program intentionally does so.
• Memory Store A database that is only stored in RAM, as opposed to traditional databases which actually live on the file system.
• Project Root The outter-most directory of your application, typically containing a file named README and containing only files related to the application (ie; not your downloads & documents, etc).
• Stack A collection of loosely related technologies and resources all used in cooperation to form something larger as a whole.

• J-Flow
  Program flow for coder sanity
• The Real Application Checklist
  Targets that define the difference between MVP and P