One of the things i really like from being a Cloud Evangelist is th epossibility to talk with people working on different roles within the IT inside an organization. For example, doubts, questions and concerns are very different depending who are talking to:
- Application developer (in its different degrees of “seniority” and regardless of the technology in which it develops)
- System administrators and in general personnel linked to the operation of the systems
- Managers, middle managers and in general what we could call final consumers of technology, without being in many cases participants of its development
Obviously with such a disparate group, the interests, motivations and considerations of each one will also be different, and will come to light for example when developing or adapting an application for the Cloud.
Leaving aside considerations regarding usability (we will assume that we will be able to develop a usable and working application) and even technology (we will abstract from decisions related to technology such as the choice of the programming language), what should we take into account? when it comes to having a CloudReady application?
Note: the illustrations have been based on the Oracle Cloud, although they could be extrapolated to any provider that offered the same functionalities.
Cloud Basic Principles:
The cloud makes sense when we realize that we can have access to a complete set of technology, paying only for the features we use and freeing us from the cost associated with the infrastructure necessary to enjoy those services, for example:
- We will have multiple regions distributed around the world (ideal for disaster recovery or to serve customers 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 losing ourselves with property costs)
- Scalability (we can grow to the “infinity” if we need it )
- Friendly use (the Cloud operator has already developed numerous features that can make life easier, serverless, PaaS, etc.)
- and a long etc.
So, what should we take in mind to develop a CloudReady application?
Cloud Ready Application Basic Principles:
The “perfect” Cloud Ready Application will able us to get maximum performance from our technology stack.
Scalability and the Stateless Challenge:
Well, as you all know the scalability can be vertical (increasing the resources associated with a server) or horizontal (increasing the number of resources associated with a work pool), from the point of view of vertical scaling we must take in mind that the technology that we use, doesn’t establish limits too low that for example condition the maximum number of vCPUs or memory assigned to the machines.
What about horizontal scaling? The quick response is that it is very easy to do in the cloud, we replicate virtual machines and place a balancer in front of them, that also detects whether a server has fallen or not. That’s it, easy, right?
but … what happens with the sessions, Is it important wich server serves us, one or another? If the answer is no, it means that our application is not stateless.
If our application isn’t stateless, the quick solution is using some type of sticky session, forcing each connection to go all the time to the same server. The problem working with sticky connections i that we can create situations like the one showed in the next picture:
the smart and Cloud Ready solution would be to make our application stateless (or at least, the state of the session didn’t reside in the connection itself), in this way any server could respond to any request. (The colors indicate requests from the same user, to illustrate that any server can answer them)
much better now, right?
Fault Tolerance, the data persistence Challenge:
Although the use of Load Balancers already provides some tolerance to failure, the reality is that this type of devices are designed to be placed in front of web servers and application, but there are many other types of service that could not benefit (at least in the first instance of this functionality).
Achieving the persistence of data at the file level can be as simple as using features such as the ObjectStorage or similar, which will natively replicate the data between different availability zones, thus guaranteeing their survival.
great we have our data safe in distributed and high performance storage, but what happens for example with databases?
Well, databases are probably the most complex case of applications that a priori can’t benefit from the use of “classic” Load Balancers. The approach in this case is to design / deploy an Active / Passive architecture (to have fault tolerance) or Active / Active (to have in addition to the fault tolerance load balancing.
The easiest option to implement is an Active / Passive, in the graphs I will illustrate it with an Oracle DB, but it can be extrapolated to any other DB that supports similar functionalities.
if we wanted an Active / Active in the case of Oracle we would be talking about a RAC, which we could even complement with a Dataguard:
It is important that you take into consideration those limitations inherent to the BBDD technology you use and the provider you choose, for example:
- If you want an Active / Passive model, do you need to guarantee synchronous replication?
- If you need synchronous replication, does your provider guarantee the minimum latencies necessary to avoid problems?
- Is your cloud provider certified for the functionality you want to use ?, in the case of Oracle (today 08/05/2018) for example if you want to use an Active Dataguard or a RAC are only supported in the Oracle cloud (OCI)
in future posts we will look a little more into the characteristics that our application must meet to be Cloud Ready.
I hope you have found it interesting and useful and we read in future posts