How's it going? Welcome to 'This is My Architecture'.
Today I am with Pablo from Cabify.
Pablo, I would like to know if you can tell us what your company does.
My company is in charge of taking things and people from point A to point B.
Excellent, and what do you use this architecture for?
This architecture, it is responsible for
assembling the platform for mobile applications
used by both riders and drivers.
Excellent, and then here,
talking about details,
how does this architecture operate?
Ok, our architecture begins on phones, with an app,
at the end of the day.
These apps, the first thing they are going to do
is to go and try
to solve the domain with Route 53.
Did you have a particular benefit
with Route 53, or has it been useful for some kind of functionality?
Yes, it has served us because we,
not long ago, we had a migration
across the entire platform, from one cloud provider to another,
to AWS, specifically,
and there we use it through geolocation by IP.
And since our service is in many countries,
we migrated country by country,
copying our architecture on the new cloud provider.
Okay, and they were able to do it in a quick and easy way?
We had planned to do it over a period of two weeks,
but we did it in two days.
-Well, that sounds great, isn't it? -Yes.
And once they do the resolution within Route 53,
what is the next step?
The next step is the client applications
to go towards load balancers,
and load balancers are distributed inwardly
to other load balancers,
they are running on a NOMA platform
and also from an EKS.
Depending on the tier of service.
And why do these two have
different clusters that are within the same layer?
We have two different clusters
because what we are in is a migration process
from our old NOMA cluster
towards a managed EKS cluster.
The main reason we were using NOMA was because
it is about 4 years old, that's when we did
the containerization of the platform, we started to run everything in containers,
and it suited us very well to be able to make a scheduler, which is very simple,
really, and it allowed us to focus precisely on this migration from
services in virtual machines
towards containers, specifically.
The point is that as time went by, we have discovered that
every time we were adding more and more functionalities,
which are the ones that come standard in trays.
It stopped making sense.
Okay, and a third element within the same layer, which is SPOT.
Yes, one of the main
problems that we have had to solve is the availability of services.
Our service is a real-time service.
You have a person, he takes out his mobile, he wants a trip, he wants to do it now.
So the service has to be available all the time.
The way to make this available is precisely with the containers.
We have quite a few services, approximately 700 services, some more,
-maybe, by now, I don't know. -That's are quite a few.
There are quite a few.
And each one has a specific responsibility.
The reason we have Spot is because it allows us
to generate a situation in which
there are machines that are going to disappear, that might cause our service
to drop its capacity at a certain point.
And services have to be able to survive
these events.
Thus, Spots are instances that can disappear at any time.
-They are very practical. -And do they have any additional benefits?
-Yes, they cost half the price. -Well, that sounds very good too.
I see a layer of persistence below.
I see both RDS and S3. Could you tell us how it works?
Yes, of course. Not all our services
have persistence, but those that do, what they do is write first
to an SRT database, which is RDS, which is a MySQL after all.
And in this case they have a single instance for all microservices?
Or do they have it in a distributed way?
No, each service owns its data.
Which means that only the service
that is writing data, is the only one that can access data, for this database.
And the rest of the services that want to access the data have to do so through an API.
This is something we have literally copied from Amazon.
So, by doing it this way, each database can scale
independently. We have databases that have
many writes, we have databases that have
some writes and many reads.
And we have databases that have to have high availability
and they have more than one instance running.
But each service is completely independent.
And what role does S3 play?
The role it plays is that, as I told you, our service runs in real time, so,
the life cycle of a trip is approximately 15 minutes,
which is when it is hot.
Once the trip is finished, the next thing to do with that trip is to charge for it.
That is something that is going to happen within the next week.
And that's what we consider to be warm data. The moment the data gets cold,
and it is no longer necessary, what we do is put them in
long-term storage
on an S3.
Each service, as I said before, owns its own data,
with which each service has to offer this functionality.
That is the fact of maintaining the temperature of the data.
And we manage this through buckets, at the end of the day.
-Excellent, thank you very much, Pablo. -You're welcome.
And thank you very much for watching 'This is My Architecture'.