Non-scalable applications hit the business bottom line in two ways : First, application Scalability issues will limit the maximum number of users that can use the application at the same time. Secondly, once that limit is breached, application may become unavailable when the load increases significantly. This may lead to visitors change their mind and switch to an alternative provider. According to Scalability experts, Martin Abbott and Michael Fischer who wrote an excellent small book called, "Scalability Rules," scalability should be designed for in three phases: the design itself, the implementation, and the deployment.
Containers are the hottest trend in data center innovation today. If you don't know where Containers are used in real use cases: Everything at Google runs in a container. Containers are one of the secrets to the speed and smooth operation of the Google's search engine. For running Google Search operations, it uses containers by themselves, launching about 7,000 containers every second. It is not just their search, if we use Gmail or Google Docs — we get a container of our own for each service. OK, let us understand what is a container.
Several years, monolithic architecture has been the widely-used architecture for building the web and mobile applications. These applications were mostly characterized by individual programs handling multiple functionalities. Though monolithic applications were known for easier to operate, as the systems grow bigger, they introduced complexity for both coding and deployment stages of software development life cycle. Single point of failure, technology lock-in, and limited scalability are few other drawbacks of monolithic applications.
One of the key characteristic of Amazon Web Services (AWS) platform is its high availability. Standard availability figure is five 9’s, that is five and half minutes in a year. However, AWS outages occurred in the past clearly indicates that outages can happen and only those apps or services that are designed for failure can withstand outages with less impact to business continuity. This emphasizes “design for failure” as one of the key design attributes to be considered while architecting for AWS platform.