Scale infrastructure

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.

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

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.

High availability

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

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.

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.

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.