Cloud Ready Applications Design I

June 23, 2020, 10:23 am blog-header-image

One of the things I like most about "evangelizing" cloud evangelization is the possibility of speak with people from different positions regarding IT within an organization. We have different doubts, questions, and concerns if we are talking to a:

  • Application developper (in his/her different degrees of "seniority" and regardless of the technology in which he/she develops)
  • Sysadmins and in general all the the people around system operations
  • CxO
  • Executives, middle managers and, in general, what we could call end consumers of technology, without in many cases being participants in its development

Obviously with such a different group, the interests, motivations and considerations of each of these groups will also be and will come to light, for example when developing or adapting an application for the Cloud.

Leaving aside considerations of usability and functionality (we will assume that we can develop a functional and usable application) and even technology (we will abstract ourselves from decisions related to technology, such as the choice of the programming language), what should we have in mind in order to have a CloudReady app?

Note: I tried to made the diagrams to be agnostic so it could be used to any provider that offered the same functionalities

Cloud basic Principles:

The cloud makes sense in the moment we realize that we can have access to a complete technological stack, paying only for those features that we use and freeing ourselves from the cost associated with having the necessary infrastructure to enjoy these services, for example:

  • We will have multiple regions distributed throughout the world (ideal for disaster recovery or to serve clients in different geographical areas)
  • Some providers operate multiple data centers in the same region (even more fault tolerance)
  • Flexibility (we can grow and decrease as we need it, paying only for what we use and without weighing down on ownership costs)
  • Scalability (we can grow almost to the "infinity" if we need)
  • Ease to use (the Cloud operator has already developed numerous functionalities that can make life easier for us, serverless, PaaS, etc.)
  • etc.

So what should we take care about when having a CloudReady application?

Principles of a Cloud Ready application

A "Perfect" Cloud Ready application is one that will allow us to obtain the most of the entire technological stack at our disposal.

Scalability the challenge of the Stateless:

Well, as you all know, scalability can be vertical (increasing the resources associated with a server) or horizontal (increasing the number of resources associated with a server pool), from the point of view of vertical scaling we must take in mind that the technology that we use don't establish too low limits that for example determine the maximum number of vCPUs or memory assigned to the machines.

What about horizontal scaling? The quick answer is that it is very easy to do in the cloud, we replicate virtual machines and setup a balancer in front that also detects whether a server has fallen or not. That's it, easy right?

But ... and what happens with the sessions, does it matter if our request goes to one server or another? If the answer is no, it means that our application is not stateless.

Again it's easy to fix, we only need to make a connection always go to the same server, what we call a sticky or persistent connection. This type of connection can cause that our load balancing isn't perfectly symmetrical, causing other types of problems.

Stateless Load Balancing

The most elegant and Cloud Ready solution would be to make our application stateless (or at least that the state of the session didn't reside in the connection itself), in this way any server could attend to any request and it would be much easier to achieve optimal balancing, also recover after failures. (The colors indicate requests from the same user, to illustrate that any server can attend them).

Much better now, right?

Fault tolerance. because problems happen!!

Sooner or later our application will fail for one reason or another and how resilient it will be to these failures will mainly depend of tha App design.

Load balancers, for example, will allow us to "remove" a node with problems and send clients to "healthy" one node, if our application is also stateless, it will not even be necessary to re-connect the session again.

Fault tolerance the challenge of data persistence:

Although the use of load balancers already provides a certain tolerance to failure, the reality is that these types of devices are designed to be placed in front of web and application servers, but there are many other types of services that could not benefit (at least in the first instance of this functionality).

Achieving the persistence of the data at the file level can be as simple as making use of functionalities such as the ObjectStorage or similar, which will natively replicate the data between different Availability Zones, thus guaranteeing its survival.

El almacenamiento tipo ObjectStorage, suele permitir servir contenido estático, por lo que incluso podríamos usarlo para servir este contenido desde fuera de nuestra aplicación, de esta manera aliviamos la carga de nuestros servidores y ganamos rendimiento, dirigiendo este tráfico a una infraestrucutura de alto rendimiento y resiliencia.

genial tenemos nuestros datos a salvo en un almacenamiento distribuido y de alto rendimiento, pero ¿Qué pasa por ejemplo con las bases de datos?

Bien, las bases de datos son probablemente el caso más complejo a la hora de conseguir alta disponibilidad y balanceo de carga, ¿por qué?. Bien, cuando hablamos de BBDD, solemos estar pensando en BBDD relaciones, donde es importante manterner la integridad del dato. Mantener la integridad del dato no es secillo cuando aumentamos el nº de actores (nodos) sobre todo si queremos que estos nodos sean un activo /activo con capacidades de lectura y escritura. Cada fabricante aborda estos problemas de una manera diferente y las limitaciones de uno u otro producto dependen de las características del mismo.

En general podemo pensar en las siguientes configuraciones tipo:

  • Activo/Pasivo => Es la configuración más secillo y podemos por ejemplo ubicar los nodos en distintas AZ/AD
  • Activo/Activo (pero este último solo en lectura) => Este despliegue se diferencia del anterior en que el nodo Pasivo, deja de serlo y puede ejecutar consultas de lectura (no escritura)
  • Activo/Activo=> Ambos nodos son capacdes de leer y escribir y por supuesto sincronizarse, garantizando la integridad del dato.

La opción más fácil de implementar es un Activo / Pasivo, este tipo de configuración suele ser la primera que soporta cualquier BBDD.

A partir de aquí tenemos n permutaciones :-)

Activo/Pasivo con el pasivo en otra AZ/AD

Activo/Activo (recordad que el nodo Activo, no necesariamente tiene que soportar toda la operativa de la BBDD, puede usarse o soportar solo para lecturas.

y finalmente la configuración con más disponibilidad a fallos, pero tambien la más compleja de conseguir

Es importante que tengáis en cuenta aquellas limitaciones propias de la tecnología de BBDD que uséis y del proveedor que elijáis, por ejemplo:

  • Si queréis un modelo Activo / Pasivo, ¿necesitáis garantizar la replicación síncrona?
  • Si necesitáis replicación síncrona, ¿garantiza vuestro proveedor las latencias mínimas necesarias para no tener problemas?
  • ¿Esta certificado vuestro proveedor de cloud para la funcionalidad que queréis usar?, en el caso de Oracle (a día de hoy 24/06/2020) por ejemplo si queréis usar un Active Dataguard o un RAC solo están soportados sobre OCI

En próximas entradas profundizaremos un poco más en las características que debe reunir nuestra aplicación para ser Cloud Ready.

Espero os haya resultado de interés y utilidad y nos leemos en los siguientes posts.

Previous Post