Shades of Applications and its Archetypes
This particular blog we will discuss about what is different types of application, how to make sure data durability, availability, backup and will share overview about different type of architecture.
Shades of Application
There are three different type of Application in the environment and each has certain special requirement for availability and Latency. We can deep dive on each of these. Related to these blogs will focus only on Business critical Applications.
1. Business critical Applications
2. LOB(Line of Business) Applications
3. Internal Applications
Business Critical Applications
These are core critical applications for business, Example (bank apps, Social Network apps, search engines etc). If Application is down then it is consider as business is down. Highest Availability and low latency is required for this type of application. This application may be user facing or not (Internal Api calls service). Each business will decide these Applications will fall under Business critical Application bucket or not.
LOB (Line of Business) Applications
These applications which supports running business, These applications will not serve as customer user-facing traffic and mostly they act as Instrumental for feeding data to that applications or business. They are desired to finish the work on-time. Just like jobs which is required to complete on particular time. CI/CD (Continues integration and Continues Deployment) pipelines, data analytics and processing service will fall under this category. Considering this High Availability is required for these type of applications. But few short outages are Ok to be considered and it should not have impact to the business.
Internal Applications
These applications are just used for internal consumptions or usage. Better example is Attendance, time sheet, Recruiting portals etc. Best effort availability is required. Impact on the business will be lower on these types of applications. Employees are always required these application to be available, Since there day to day task are required to complete.
Data Durability, Availability, and Backup
Data is something always to be available and for an Application it is must and required to process the internal flow logic. Here we can see how data is stored and managed. There are three main points to be considering when we are storing and managing data. Of course we will talk about RPO and RTO for data availability.
1. Data durability
2. Data Availability
3. Data Backup
Data Durability
Data which is stored for a long time or term SRE have to ensure there should be no corruption or lost. To overcome this critical risk, Storage system uses replicas either data has to sync or backed up. Have to perform error correcting checks and scrubbing of the data to prevent data decay.
Data availability
This will talk more about data should be readily available for accessing. High Data availability which means placing data more than one failure domain, it can be synced more than one zone to another, one region to another. Considering data durable on other side, ensuring the service provides access to the data, and making sure the data is appropriately resource-provisioned to serve requests. There are different type of replications, asynchronous (eventually consistent) or synchronous (strongly consistent), along with data failover capabilities are important building blocks for achieving data availability.
Data backup
Data backup is most impact to avoid major outages and protecting Applications or Human errors/mistakes. Point-in snap shots are suggested here. All applications should use backup services to protect against accidental loss or corruption of data due to application-level issues.
RTO and RPO
It is important to place to objective for DR for each application. For example Recovery Point Objective (RPO) and Recovery Time Objective (RTO) and to choose deployment models and infrastructure that can achieve the desired RPO and RTO.
RPO looks for how old a copy (backup or replica) of the data is compared to the current state in prod environment. This copy of the data would become the active state of production in case the current state fails, and any data changes more recent than the recovery point would be lost. If an application has more than one source of data and then independent recovery points of each one need to be reconciled.
RTP looks how long it takes to restore an application during recovery to bring it back online and available in prod environment, which includes access to the data needed for running the application. Core critical Applications required both RPO and RTO to be as close to zero as possible.
Different types of architecture
There are six different types of Deployment archetypes. Each one them we can discuss about it.
1. Zonal
2. Regional
3. Multi-regional
4. Global
5. Hybrid
6. Multi-cloud
Zonal
All the components of application run in a single zone. A Zone will provide a set of cluster with infrastructure or resource needed to run a service (Compute, storage, networking etc) within that zone. If entire Zone goes down and Application which is deployed on that zone will be unavailable and it will create an outage. To overcome this failure either SRE have to deploy the services on standup zone. If outage happens SRE required routing the traffic to standby zone.
Regional
All the components of application run in a single cloud region (it can be US or UK or India or Singapore). Single region contains two or three zones. Which defines availability zone (AZ1/AZ2/AZ3). Each zone looked as a separate fault domain. HA (High Availability) will be achieved based on copying apps or replicating apps to all three zones and this is within the region. Apps are typically designed to run with a data store that shares data and makes it accessible within that region. Application traffic requests are load-balanced across multiple zones and this is at same region. To improve reliability or availability some critical applications would have deployed on standby region. Example: US is primary and UK is standup. By default all the traffic will hit to US region and if any issue with US region traffic would be routed to UK region. So the applications can easily failover to standby region.
Multi-region
These applications stack runs and bind together across multiple regions to achieve higher availability (HA) and low latency at user end through geographic distribution. In this deployment data is typically replicated and shared across regions. This is commonly used for applications that want to achieve high availability, such as user-facing applications.
Global
Global and multi-region are quite similar, Application stack is spread and replicated across all cloud regions around the globe and data is available worldwide via global databases and storage. Applications consisting of a large number of services and microservices benefit from this deployment. This is the five-nines deployment model used by retail, social media and other businesses requiring always-on availability, while running large services at globally. Example: Google, Amazon, Facebook, Twitter, WhatsApp.
Hybrid
Application stacks or application may have combination of running on on-primises and public cloud. Better example Front end layer runs on Public cloud and data storage might be running on On-premises environment might be on VM or Physical machines. On-premises will evolve to continue to connect service running on cloud environment. To achieve this proper network ACL or security group required to open from Cloud environment and On-premises environment servers are ready to accept the connection. Proper Port and IP segment is required to open and not all range of IP is required to do so. Hybrid application availability and resilience is often achieved by creating deployment archetypes that leverage failover between on-premise and Cloud and Coordinating the execution of parts of the application that run in the Cloud versus run on-premises.
Multi-cloud
Applications can gain highest availability by using two or more public Cloud platforms at the same time, to protect against one Cloud’s unavailability. Example: Deploying your stack on AWS and Google Cloud. In each cloud one of the deployment architecture listed above is used, and then combined across clouds to create a multi-cloud deployment. This deployment architecture is in its infancy, but applications that require the highest availability are prime targets for multi-cloud deployments as this model evolves.
