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.
Storage type "Object", usually allows to serve static content, so we could use it to serve this content, in this way we decrease the load on our servers and gain performance, directing this traffic to a high-performance and resilience storage.
Amazing!!, now we have our data in a safe place (distributed storage) and also with great performance, but what about the database?.
Database are probably the worst type of service to deploy in H.A. and Load Balancing. Why?. Well when we speak about about databases, usually think on relatanional databases, so it's important keep safe the data and the integrity of the relationships between data.
Keep safe the integrity of the data is not easy when the number of actors (nodes) grow, especially if we want these nodes to be active / active with read and write capabilities. Each vendor deals with these problems in a different way and the limitations of one or another product depend on its characteristics.
In general we can found the following setups:
- Active/Pasive => The easier setup, and also we can deply each node in one AZ/AD
- Active/Active (the second node is ReadOnly) => In this setup the pasive node goes active, but in Read Only, so this node can execute read querys but not modify or delete data,
- Active/Active=> In this setup all nodes are able to read and write data and of course they must keep data integrity
Obviously the most difficult setup to achieve is the Active/Active and the easier the Active/Pasive setup.
From this point our only limit is our imagination :-)
Active/Pasive with pasive in different AD/AZ
Active/Active (remember that the secondary Active node support reads and maybe writes.
and finally the setup with best fault tolerance but also, the hardest and difficult to achieve.
It is important that you take in mind those limitations specific to the BBDD technology you use and also the provider you choose, for example:
- If you choose a Active / Pasive setup, do you needsynchronous replication?
- If you need synchronous replication, you must take in mind the latencies of your provider
- Is the Database technology you want to use certified in your provider
In nexts posts we deep dive into more features that must deliver our application to be a really Cloud Ready appliction.
Keep in touch and see you in the next post.