Root at 16:16, 22 October 2025

2025-10-22T16:16:11Z

← Older revision		Revision as of 17:16, 22 October 2025
Line 64:		Line 64:

	To meet these objectives it is necessary invest a lot of time and money, so we have to decide how much we want to invest in high availability depending on the criticity of each part of our service.		To meet these objectives it is necessary invest a lot of time and money, so we have to decide how much we want to invest in high availability depending on the criticity of each part of our service.
	~~<!-- From bodyContent 1542966.mraw -->~~

	[[Category:IT scalability]]		[[Category:IT scalability]]

Maintenance script: Added category IT scalability

2025-10-19T17:51:22Z

Added category IT scalability

← Older revision		Revision as of 18:51, 19 October 2025
Line 66:		Line 66:
	<!-- From bodyContent 1542966.mraw -->		<!-- From bodyContent 1542966.mraw -->

			[[Category:IT scalability]]

Maintenance script: Maintenance script moved page UserDocumentation:Knowledge Central/KC IT/IT scalability/Scale infrastructure to Scale infrastructure: Cleaned title and categorized

2025-10-19T17:51:21Z

Maintenance script moved page UserDocumentation:Knowledge Central/KC IT/IT scalability/Scale infrastructure to Scale infrastructure: Cleaned title and categorized

← Older revision	Revision as of 18:51, 19 October 2025
(No difference)

imported>Unknown user at 09:35, 19 April 2025

2025-04-19T09:35:09Z

← Older revision		Revision as of 10:35, 19 April 2025
Line 1:		Line 1:
			Servers infrastructure will define the possible future limitations we could have.

			We must take into account architecture aspects as structure, relations, restrictions and interactions

			Main resources that affect our applications are:

			* '''processing''': servers where application is stored and processed
			* '''information''': all data that is registered by the application (database)
			* '''APIs''': allow to separate functionalities of our applications (microservices)
			* '''events''': ease the asynchronous execution of the different parts of our application (event driven)
			* '''content delivery''': ease the user experience through CDNs an cache systems

			We don't need over scaled infrastructure, it will result in unnecessary costs. We have to take into account that if we have a server with a processing capacity, two servers with half of the capacity will provide an efficiency of 130% compared to one server.

			<span id="build-from-scratch"></span>
			= Build from scratch =

			* '''administration''': define the users that will manage the infrastructure
			* '''security rules''': establish basic roles with their control permissions
			* '''budget''': define alerts and spending limits
			* '''environments''': define them (local, test, live)
			* '''deploy''': allow the installation of the application in different environments

			<span id="on-premise-cloud-iaas-paas-saas-or-serverless"></span>
			= On Premise, Cloud (IaaS, PaaS, SaaS) or Serverless =

			When deciding where are we going to host our application (or if we purchase a Software as a Service), we must take into account this features:

			* '''availability''': which percentage of the time service is available
			* '''scalability''': we have resources available if our application demands it
			* '''management''': how complex is running infrastructure
			* '''cost''': how expensive is running infrastructure
			* '''data localization''': legal permissions of data stored
			* '''location''': be close to the client for a better user experience
			* '''security''': both physical as logical
			* '''power''': not haven't power outages

			If you have one implemented, we must appreciate the implications that have making that change.

			<span id="high-availability"></span>
			= High availability =

			When project grows, usually service availability and quality is not taken into account. To maximize it we need:

			<span id="allow-high-concurrency"></span>
			== allow high concurrency ==

			It appears when we have traffic peaks in our service. In order not to have an overscalated infrastructure, we use balancing and number of server available escalation. To handle this we can use services as AWS Load Balancing or Kubernetes. Tools such Jmeter or Locust allow us make stress tests.

			<span id="be-tolerant-to-failure"></span>
			== be tolerant to failure ==

			It is necessary to have a highly resilient system (reliability of minimum services on failures) to confront possible errors in our service, both at the infrastructure as application level.

			<span id="have-a-disaster-recovery-plan"></span>
			== have a disaster recovery plan ==

			It is divided in two main concepts:

			* '''RTO''': Recovery Time Objective. Maximum time that it takes us to recover the system.
			* '''RPO''': Recovery Point Objective. Maximum time period of data we assume we can loose.

			== investing ==

			To meet these objectives it is necessary invest a lot of time and money, so we have to decide how much we want to invest in high availability depending on the criticity of each part of our service.
	<!-- From bodyContent 1542966.mraw -->		<!-- From bodyContent 1542966.mraw -->

imported>Unknown user at 09:35, 19 April 2025

2025-04-19T09:35:09Z

← Older revision	Revision as of 10:35, 19 April 2025
(No difference)

imported>Unknown user at 09:35, 19 April 2025

2025-04-19T09:35:09Z

New page

Scale infrastructure - Revision history

Root at 16:16, 22 October 2025

Maintenance script: Added category IT scalability

Maintenance script: Maintenance script moved page UserDocumentation:Knowledge Central/KC IT/IT scalability/Scale infrastructure to Scale infrastructure: Cleaned title and categorized

imported>Unknown user at 09:35, 19 April 2025

imported>Unknown user at 09:35, 19 April 2025

imported>Unknown user at 09:35, 19 April 2025