Webinar recap - 4G Capital’s Cloud transformation journey

Transcript of webinar

Alex: Oh, excellent. So we shall begin. So welcome everyone. Good morning, afternoon, evening from wherever in the world you are. Very glad you are joining us today for this Cerbos webinar about the future proofing fintech in the age of microservices and the cloud. So just by way to kick off, we'll go through a bit of an intro go on to speak about kind of the future of fintech.

Touching particularly on like why authorization is kind of the number one security risk facing this, the, the industry today. And then we're very lucky to have Edgar joining us from 4G there. He's going to take us through kind of their journey and their transformation. Around bringing their stack up to meet their new requirements around authorization.

So a way of introductions quickly. I'm Alex Olivier. I'm one of the co founders and the chief product officer here at Cerbos. My background is software engineer going into the world of product latterly, but always very much focusing on data and infrastructure side of things. And as I said, I'm very grateful to have Edgar joining us now.

Edgar Rivera, who is the CTO of 4G Capital. Edgar, how are you doing today? 

Edgar: I'm fine. Thank you so much for inviting me, Alex. Thanks for letting me be here. I'm very excited. You know, it's a great opportunity to tell us a story and, you know, tell about what 4G I'm a CTO. I've been working as an engineer as well for more than 24 years done a lot of in the financial industry, banking, payments and other sectors and being here CTO since nearly August last year in 4G Capital.

And we are an amazing fintech in Africa. We operate mostly in Kenya and Uganda, and we do micro lending. We provide working capital to entrepreneurs, people with small businesses, people in the markets. And we're impacting a lot of businesses in Africa and Uganda. 

Alex: Yeah. Thank you again for so much for joining us.

And we are very lucky to count Egger and the whole of 4G Capital as one of our our partners here. And you guys have been a really kind of interesting journey over the last year or so as you've taken the helm around taking your infrastructure and really transforming it to a modern set up and really leveraging some of the great kind of tools and services that are now out there which you've been very generous.

You're going to kind of take us through. So actually, some of your before transitional and future architecture diagrams which hopefully will be kind of very, very interesting for those that have joined on the stream to hear about that. So just kind of kick it off you know, really leveraging your experience that go around FinTech and both from that sort of engineering background, which is really where my heart is.

I still write bad code to this day. Thankfully, it doesn't go into production. But now kind of looking more at sort of architectures and software stacks. Every day we get to speak to users of both servers, but also kind of the wider ecosystem around their different architectures and different platforms.

And. We have a big kind of tranche of users in the FinTech space. So hence, we really want to put this session together and really leverage kind of your experience. So kind of historically, what, what, what we see talk to these users is there's been this kind of nascent uptake of cloud or kind of traditionally, maybe a bit scared of using cloud and kind of the, the banking sector, you know, as you, as a, a very modern FinTech, you know, how, how are you going about sort of embracing these kind of new technologies and really how does that kind of change what your priorities are over recent years?

Edgar: Well, I think it's clear that now bank and fintech lives in the cloud. We see more and more digital natives born in the cloud. And then the traditional, you know I would say bank dinosaurs moving entirely into cloud and starting to operate in the cloud. And I think that the reason of that is because how quickly and how fast is the ecosystem.

You see the constant changing priorities, you know, where we got to deliver all the time value to the customers. I did a reflection few, you know, a few years ago, when I looked at one of these fintech applications in the app store and I saw how many times they deliver or they release the mobile application.

And over a period of six months. And then I saw the same. On a traditional bank, and it was like five against 35 releases, and this is the reason why as well. Things needs to be moving to the cloud. So fast delivery, you know, fast time value to customers and obviously scalability and all of those things that we already know that are happening on the cloud.

Alex: Yeah, do you think what was driving that is kind of a demand from customers or is that kind of a competition kind of in the fintech space kind of what you're seeing? Or, you know, is this just kind of a whole new paradigm in terms of how building applications? 

Edgar: I Think was posed by the fintech, you know, like, okay, so when we started to born digital natives, like bands that don't have branches.

Banks that don't have offices that completely changed the game. We see very successful banks in Europe, in America, as well in Asia completely native, digital native, and they have millions of customers now. So, and that's, that's one of the reasons they got to compete with the, with the digital natives.

Now users, They're already used to the same user experience that, you know, big brands or big tech brands give you, you know, I'm talking about like the Googles, the Netflix, you know, people is used to that user experience. And so you, you got to compete providing the same user experience and, and the fast, the fast value to the customer.

Alex: And so what was that really meant in terms of your priorities coming into FinTech? You've worked in payments and numerous businesses before, but particularly coming into 4G. So what, what was kind of top of your mind in terms of things you really wanted to get in place so you could actually start delivering that, that end user value and that sort of customer, the customer demand?

Edgar: So for me that was clear that if we wanted to, you know, compete in, in the African market and lead that market, we gotta provide a best user experience and, and build with solutions faster. So, you know, when I arrived I knew there were some things, some gaps that we, we gotta improve things that we gotta make better in, in, in 4G capital and the direct consequence is how can we update our tech or how can we change our tech to adapt to these new ways of working? What can we do to make sure that we're something secure, scalable, you know, but also something that really provides that value to the customers. And that's simple. Yeah. You got to adapt to that.

Alex: Yeah. And sort of how did that influence your your architecture and we're gonna be talking about this transformation going on sort of what was The key kind of key things for you around sort of set up sort of architecture decisions, the security you mentioned, you know, making sure your compliance and regulatory needs are met. So what, how do you sort of approach that? 

Edgar: So the first thing for us was, okay we, we got to build something that we're able to change quickly, you know, to test quickly. And we didn't have that capability before. We, we were not able to change policies permissions that easy, you know? And the other thing is that we gotta be able to, as well, be compliant, because compliance is such a very important thing in fintech, in banks that are regulated.

Yeah, we're regulated by the Central Bank of Kenya. So you gotta build something that is auditable, that is secure, that, you know something that also product people and, and, you know, business people and able to, to, to modify, change based on the changing requirements too. And then for us. When we say, okay, we don't have these capabilities.

Yeah, we're going to need to make changes in our architecture to, you know, to facilitate these to the product and to impact our customers and still being able to be compliant. 

Alex: Yeah. So yeah, we, we kind of bumped each other a few months ago at a Google event in London and we were both looking at sort of this sort of API gateway.

What does that mean in terms of how you architect systems and composable architectures? We're gonna talk about Cloud Run, for example, in a bit, and really kind of this Microsoft driven or API based strategies really kind of unlocks a lot and kind of brings you away from these big monolithic, monolithic systems.

Edgar: Yeah. The other thing is when we met in, in, in Google Cloud, I remember AI, AI, AI was all around. Okay. But the problem is okay, but how do you do AI if you're not yet ready to do AI? So, and then you got to start with a proper API strategy, you know, an API management strategy that touches all your, you know, your points.

Okay. And I knew that we have to first build that capability in order to innovate first, innovate after. And then, but okay, if you have some API layer, how do you ensure that that API layer is secure, you know, and that API layer it's preventing is preventing, you know, fraud or is preventing mistakes, you know, or unauthorized access to certain features or center I mean, we got to make sure that only the people that is Approve that is not that is responsible or our flags to approve alone are the ones that are can only approve alone, you know, and that that needs to be changed quickly if the requirements change to.

Alex: Yeah Absolutely in this kind of authorization topic is what we're going to kind of frame the rest of the discussion upon but just to make sure we're kind of all on the same page as a bit of a kind of a Background so firstly Cerbos for those of you that joined us from from kind of the fintech world that may not have heard of Cerbos before but we're an open source project and a commercial product that enable you to implement fine grain permissions for your application layer So we have a big, user base and kind of fintech We're really like I was saying with those those who can make a loan decision who's allowed to view an application Who's allowed to you know, sign off a particular particular agreement?

These are all kind of permission checks and authorization checks that every kind of system needs And authorization is is a topic that it says You Very much close to close to our heart, but really if you look at the broader industry this is not a new concept. But there are some new solutions to it.

So if we go back away to 2021, I remember those dark days of the the COVID times as it were the open the OWASP, the Open Worldwide Application Security Project released their semi biennial, semi biennial report around kind of the top Security risk in web apps and back then in 2021 the number one issue that was identified through the testing they do was around broken access control And that was really kind of broken down into three buckets.

It was the Violation of least privileged access or basically denied by default. So there basically was a way to get into systems where you shouldn't have Permitting to view or edit another account which you know in fintech if you're looking at someone's finances or a loan agreement or someone's bank Account, you know, this is obviously things that need to be correct.

And then being able to access apis We're talking about api strategy You know, making sure you have the right access controls for each method, for each call, for each HTTP, HTTP verb ultimately it was kind of the number one piece and was also highlighted as number nine on the list was also around the security logging and monitoring for failures ultimately.

So that audit log story, so being able to actually have a clean and consistent audit log for permissions and. Just last year, they released kind of a minor update to this report and basically the exact same things being stated. So authorization is one of those key components. When you do move to these more API based strategies and architectures, it's one of the first things you sort of have to decouple out of your sort of monolith application or decouple yourselves from, from a, a banking backend, as we're going to go on about into something that you can own and control and really is the gatekeeper to kind of every access and every part of your system.

And it's something that sort of has to be right, particularly in kind of regulated industries, FinTech being one of those, but we work with a lot of healthcare and sure tech, these kinds of businesses where there's that strong regulatory requirement also. So talk about that. Let's go into really the juice of this presentation, which is really from Edgar about kind of this transformation journey you're going on and you've been very generous sharing some of your architecture diagrams and such, which you're going to touch upon.

Let's kind of begin really what were your priorities around getting your system set up with the right level of authorization? 

Edgar: Sure, for us was very important to have capability to to Full control or access full control or full governance around access control And that is special, you know, because the problem is that You know, traditional fintech authorization models they often rely on, on just one role, you know, or, or something like, okay, you're a, you, you are manager, you're a branch manager, and that's it, but there is this lack of flexibility when you need to do more complex financial operations or business logic.

And the other problem is that. That most of the time is in the backend or in your backend. So the business logic is completely coupled to your, to your systems. So that's, that's one of the best, biggest problems, you know, the second was, Hey, look, this is a very fast pacing and changing environment. You got to adapt to new compliance and business rules.

So we see, you know, regulations like, you know, GDPR CCPA or PSD two, and plus the internal business rules because obviously product people comes with new requirements. We, we get always new, new requirements, new changes. Yeah. So then if you hard code the business logic inside your backend systems, then it's very painful and slowly process to evolve them.

And then finally. It's all about how can you enhance the security and the auditability of your, of your APIs of your features. So if you have a centralized, okay, so the issue here is that in fintech, you got to track and enforce who can access the data and when. And, and then if you don't do this correctly, that can potentially open unauthorized access.

So we, we, we got these priorities for our business, which is we got to do this, right? Okay. If you wanna scale, if you want to go to the countries, if you want to grow, if business, these things needs to, you need to nail these things. Yeah. Otherwise, you're gonna get trouble later in the future. 

Alex: Yeah, are there any kind of like particular scenarios or, or kind of use cases that sort of come to mind when not having the sort of centralized authorization can lead to security risks or things that you're trying to design around?

Edgar: Yeah, exactly. So for example for, for us, If, I mean, we, we try to do these things. Yeah. But then we were falling on the traps, you know, of hard coding this business logic in the code. Yeah. We fall in the trap of, you know, adding something else to create an audit capability, you know, building a new component to add an audit capability.

And, and also every time we were collecting these requirements from the product, how you transform that or, or test that That all of those scenarios are correct. 

Alex: And sort of like how often were you getting these change requests and how long were they taking you to actually get rolled out? 

Edgar: So buying great access control is a constant thing because you know, first of all, we got users and employees coming and going and back, going and back.

That's something that you should be able to manage very easily. Second we, we see again, the regulator coming with new requirements. Oh, by the way, you're not, no, you're not supposed to show the ID or the phone number, you know, you should report these or that. So we get constantly, you know, changes as well.

And then, but again, the, the other one is, is for product people, because products are, you know, live things. They evolve, they grow quickly. And. We change direction because we want to do this initiative and then another initiative. And we, it's a constant changing, you know, and that's why you gotta, you gotta have that flexibility.

Otherwise, it's very hard to, to deliver quickly and to, to innovate. 

Alex: Yeah, we hear this a lot like this. There's this constant sort of drumbeat of requirements coming from different parts of the business or regulators, particularly in that fintech space. And, you know, you're, you're regulated by the bank of Kenya at the moment, but I know you're scaling kind of out Africa and You know, change the complexity of the kind of requirements you can have to meet.

So yeah, you're right. You're right to see this coming. 

Edgar: And if you operate in different countries, different types of products, and now we have products that are also dealing with partners or third party you know companies, and, and then there are different things for, for these actors. Yeah. The rules are not the same.

Alex: Yeah, so really kind of that flexibility. So it's kind of take us through sort of your architecture, you've you know, She has a couple diagrams here. So You know, you had this existing model that kind of didn't scale, kind of take us through what that looked like and we can put the diagram as well. 

Edgar: Sure. So basically we, we started with simple Google identity and, and, you know, simple role based access. And then at that point we have an API gateway in AWS and we build Lambda as an authorization service. That was basically acting as the man in the middle between the service layer, all of the other microservices and land us.

And we also put some other uh, roles at the core banking layer. So, in this case, basically, all of the authorization was quite center or in the authorization service, and it was becoming a bottleneck. Because all of the, everything was passing through and also we were getting, you know, that, you know, that lack of flexibility, you know, when introducing complex business logic, because you have to implement that on the service layer based on the roles from Mambo and Google identity.

So then every change or everything that will, was impacting that area requires a new deployment and new changes, new testing and new regression testing. So it's becoming very painful to make changes around that authorization side. 

Alex: Yeah, just to kind of clarify here. So Mambu in this case is this guy.

Platform sort of off the shelf, as it were that you, you kind of that run, run the kind of the banking business and then we're building service layers and top for interaction with different third parties or in customers and such. And that's where you needed that more fine grain controls. 

Edgar: Yeah. So our banking, our service layer, or we built several microservices uh, with Java and, and we were at that point develop deploying as well as land us.

And then we were exposing APIs and API gateway for the mobile or web application, the different web or mobile web applications that we had. So Mambo, it's our core banking solution. That's where we, you know where you can process or create loans and add as a CRM as well. And he has some embedding security and role capabilities.

But again, it's, it's something that sometimes affect the service layer. Yeah. So you always have to as well, load things from Mambo, you know, in order to make some changes or decisions. 

Alex: And so you really need to get that, like, like next group granularity. So what may be one role in man, but you actually wanted to expose in a more fine grained way to, to your end.

Edgar: Yeah. Especially when you have combinations of, of of business logic. So, okay. So if you, you are, let's say branch manager, you are a loan officer. And, you know, so when this, these and that, and that, then you can do this, there is always complexity on the business logic and. You need to have that flexibility to adapt that business logic, because maybe the, the permissions or the business logic might be different for certain products we had different financial products.

Yeah. And then we, and we seen. Changes in requirements when we were trying to launch new products. Yeah. So we're going to do a new type of loan with this, you know different partners or whatever. And we were saying, oh, but wait a minute, but this is different because now it's not through a loan officer or a branch manager.

This is actually okay. What? I mean, now we got to change this layer and do something else. Yeah. So there was no, a lot of flexibility. 

Alex: Yeah, and this is kind of when we started speaking So you were kind of working on this more, future state architecture that say we will come to but you wanted to really Get set up with with a more fine grained permission model today to kind of support These use cases you had Around maybe and that's when we started working together around kind of Getting set up getting you on boarded with serverless to manage and define those more fine grain permissions and so you're kind of in this sort of transition phase now You're going through this really kind of interesting cloud migration You know, you haven't i'm sure you've had some sleepless nights recently to get that done But i'm sure you're a lot on track.

And so you kind of went to this transitional phrase where I well, talk us through, you wanted to kind of take out this, this one author authorization service authentication sort of layer and, and start moving to a more fine grade approach. 

Edgar: Well, you can't do this on your own. You need to have a great team behind you and supporting you, obviously, doing all of these transformations and migrations wouldn't be possible with, you know, my team, you know, the developers, the backend developers.

The front end, the mobile developers, the product team, the IT ops, data people, there's a lot of people involved behind. So I'm just here representing them. Okay. Of course. But in, in that transition architecture, uh, we, because we were sometimes, you know, it happens that everything happens at the same time.

Yeah. So you say, okay, one of the challenges that we found was the scalability, what our previous platform just that. Bottleneck authorizations layer, authorization lambda was killing us. Yeah. And, and we, we, we knew that we got to have a different, that would be more scalable on the cost control.

And so I made a decision to migrate from AWS to GCP. And that often includes database migrations is a big project behind we have a great partner supporting us on that. So it's okay. So, because we are in that future architecture, we got to do a transition architecture. So, in this 1st stage. We, we keep the API gateway and the service layer.

And this is where we introduced the service PDP and the service hub, which is a gray SaaS platform that you guys built that connects with your policies in GitHub. It was very easily for us building the policies in GitHub. You can actually test the, the different scenarios and your policies directly on the service hub as well.

And then. We build, we deploy a component, another lander on AWS that was acting as our authorization or policies layer. Okay. And we keep using some of the Google identity and, and Mambo roles, but now with more flexibility by, by making the policies outside the Java code. 

Alex: Yeah, so so just kind of replay that before you had kind of requests coming in They everything went through this centralized authentication authorization sort of master service and then they hit your service layer and then you move to the transition model where you got on board with Cerbos So you you took what before was all that hard coded application java Code took that out into service policies as service policies such as yam yaml files which are very clear and obvious for defining your different resource types.

So for example, you have a loan, there's an action of approve a loan. And these particular conditions must be met. And, and your, your service layer is essentially passing to Cerbos and the input about who the user is and the particular resource, particular loan they're trying to access. And then Cerbos is then evaluating that the, the policy is based upon that.

And these policies are being evaluated inside this Lambda we can see here called Cerbos PDP. So rather than requests going through like a central authorization service, then to the service layer, you're now in a model where the service layer is checking the decision point. 

Edgar: Exactly. And then they, they, this also integrates.

Feedback from product team. So basically we, we got a couple of workshops with the product team so they can understand you know, what is a policy, you know, how can we build permissions and requirements for that? Because we, we gotta get, you know, product team input. And the nice thing about the policies is that they are human readable, so it's quite easy to see what they do, and also very easy to update them.

There is a CICD feature, when you update a new policy, it automatically can push. The latest version to to PDP or the next time the, the, the PDP starts, you can download the latest version. So it's quite secure in terms of getting the, the last version. 

Alex: Yeah, and just one thing to call it here is because you are using lambda So serverless architecture is going to scale up and down with your application It means at any point in time you're going to have more than one improbable instance of Cerbos ultimately running inside of your stack So really keeping them in sync with what the latest policies are was a kind of a key requirement You came to us with and that's ultimately what Cerbos hub is doing here It's that managed ci cd pipeline and then it's making sure that all the Instances of running inside of both the Amazon infrastructure here, but also the future statement.

We're going to see in a second. So you actually had both Amazon and Google cloud environments running to the same service hub instance. So that way all your policies were centralized and distributed to both environments without you having to do any extra CI work or extra infrastructure work and services kind of that for you.

Edgar: Yeah and also I want to point to that. He also took very few resources from us to do this. We have one engineer that actually nailed these and he went through all of the documentation, you know, and it was quite easy for him to create the policies, implement the changes on the back end. So it was quite straightforward you know, process for us.

Alex: Now let's go to the future. 

Edgar: So in the future to stay, we're going to get rid of AWS. I'm really sorry Amazon, but uh, we're moving completely to GCP. We're gonna have, you know RPG as API gateway. And one of the features that I'm really excited about is. Cloud run as a serverless technology and cloud run multi containers.

So we were able to migrate our AWS landers to, you know, to containers in cloud run, but cloud run has a capability to run two containers or two processes on the same container. I would say probably two processes in the same container. And that was exciting. I remember we were you know, drawing the solution on the, on the, in the cloud.

In, in a, in a stand. And this is fantastic because here, there is no latency. You know, the container has the PDP next to, so, and it can access their policies in record time. So no, no single point of failure. Yeah, because the containers scale up or down and they, the PDP, the service, PDP scales up and down as well.

And you keep having the same surplus app. Pulling the policies from GitHub, nothing changed on that, which is fantastic. And we obviously keep using, you know, some of the things we have in Google identity and some of the, you know, improvements we're doing at the core banking platform as well. 

Alex: Yeah, so kind of the request flow we're looking at here, you have your end clients, they're hitting your Google Cloud environment, they're going through Apigee as kind of the API gateway, you're reaching requests to one of numerous, I'm sure, Cloud Run services that you're running, and now each instance of the Cloud Run service Has the application.

So your Java application service is running inside of it as well as co located inside of that, that, that pod. If you were to use the communities terminology also has the instance of servers running. So it really gives a well, hopefully it's giving you that kind of that flexibility for as, when you're building new services, you don't have to worry about scaling the authorization piece as well because it's co located to your app.

And as your app scales out and you're, as API strategy. 

Edgar: And it's a very  lightweight component. So it's a very lightweight component. You know, it doesn't take that much RAM or, or, or, or a CPU. Because I compare other solutions and the issue that I have is that you have to go through a central you know, SAS solution.

So then it creates another point of failure. Yeah, and increase the latency, having the, the, the policies on the same container and having capability to download the latest versions, you know, it's, it's crucial. I think this, I was very excited about these and when Google releases multi container capability on cloud run, because it opens up a lot of possibilities and they, when I met you and we talk about these, I was like, wow, this would be amazing.

So. And yeah, that's, this is where we're heading right now. This is our future state. 

Alex: Yeah, it's got very exciting and fortuitous that google cloud run a team really much more to contain exit It was always like this thing that was hanging around a beta and then they released it next so that was that was great to see and great to see you kind of leveraging it as well It's really nice.

Edgar: And if you think about this is something already supported in Kubernetes, if you know, so it was actually following the sidecar, you know, pattern that was already popular in Kubernetes, but we didn't have that capability in serverless applications and serverless containers with Cloud Run.

So great, exciting and powerful feature. 

Alex: Yeah, yeah. And then that couple with like the stateless approach to serverless, like you're saying, is very lightweight because it is not hitting some external database or hitting some external API as your service layer needs to scale. Serverless sales are with it.

It has the policies loaded into it and there's no other infrastructure requirements or API calls or cloud access required, hence you get those super snappy response times with a particular architecture. And you're still kind of working then, your service is then talking back to you, to your core banking platform.

Yeah. So just to kind of wrap this up. So kind of the, the key improvements that you were sort of discussing that this talk that you saw, and there was a mixture of like time and cost savings, which is always, you know, good for the bottom line, but also what that meant for your security posture and kind of how you build applications.

How have you kind of seen that? 

Edgar: So, okay. So once I, it's, we were about to scale our existing platform to all branches in Kenya and When we look at the performance of the land authorization service land when we look at the cost of that existing, we look at a, we're having, let's say, 10 millions of requests per month.

Okay, as an example, and we look at the cause, then we project that into, okay, now let's increment this. 10 times, you know, because we're going to increment 10 times more users by expanding to all branches. We were scared. We were saying, Oh my God, this is going to cause us a lot of money. So by us, by re changing the, the authorization service and moving into that, allow us to save a lot of money in authorization, now the engineers have now the possibility to change policies in minutes, which is really And no, there no longer need to deploy a microservice or write new, you know, new tests because they can test as well.

The policies directly from the from the hub and from the service hub. And then if product comes with a new requirements, like, Oh, by the way, now branch managers are allowed to approve if dah, dah, dah, dah, you know, so we are able to implement these changes much faster or even for different products.

So at the end of the day. In terms of advantages, yeah, or benefits for us was, uh, being able to grant to, you know, to the different roles or, you know like these granular access, you know to the different APIs. And, and also to define even attribute based authorization policies, because you can also access to the, to, to the different attributes they seem to be attributes that comes as well on the Heather, or even on the payloads and having that capability.

So allow us to control resources and actions in a more granular way. And what in a, in a better context based on the relationships of these APIs. That was it. You know, the fine grain access control issue was sold second. It's by decoupling, you know, completely the authorization logic from the application code.

So now we're able to modify policies. And much easier, more, much faster, and we can propagate those changes in services without, you know, requiring redeployments. And this is very important for the changing compliance and business rules. Because if we, if we, for some reason, we got a new requirement from the regulator.

Okay, so now we can implement those changes at the authorization layer easily. Okay. And and then finally, all of all of the enhanced security and auditability now the service maintains, like, a central lock where, you know, we can see all of the authorization decisions. So we got a clear, clear audit for compliance and security investigations.

And also by having. Policies this reduce the risk of accidental grants or of access to and due to misconfigurations and that that is also very, very important for for a fintech that is regulated. 

Alex: Yeah. And that's kind of the common theme. We sort of hear that audit log is really the thing that, you know, regulated businesses need much earlier, you know, other businesses potentially can wait a bit, but it's just a hard requirement from day one to kind of get that right.

And, you know, the cost saving piece as well. I think you gave us a number of like how much you're saving per year uh, the infrastructure 

Edgar: just on the, just on the authorization service, more than 200 K. Right. And in authorization service, because that component, if we were to scale out that company, it will cost a lot of money, you know, like 20 K per month.

So it was a huge, huge saving not going into that direction. 

Alex: Yeah, that's always good to hear. And you always want to say the spend sensibly on your cloud infrastructure so great again just to wrap it up firstly Thank you very much for all your insight and willingness to share kind of some of the innards of how you kind of build your architecture I would just to end on sort of to all those aspiring fintechs that are listening in or follow you on linkedin and Twitch and such, you know, what was your advice be to them for kind of building a modern stack today?

Like where, where would you tell them to begin? 

Edgar: Yeah. So I look, I'll, I'll say, you know, implementing authentication was, you know, a big thing some years ago, but now it's easy and there is providers, you know, there is easily. Solutions to provide authentication, but I think when you build authorization from the, from the ground, you know, you, you include these principles from the very beginning of your architecture of your applications, then you're going to guarantee a good scalability.

And as well, you're covering and avoiding risks, you know, by exposing things where you shouldn't. So I think it's important to analyze, okay, what's the cause of doing this now, but what is the cause of doing it later? Or change it later. Yeah, or the effort as well. And, and when I, when you look at this, and how easily was for us to implement Cerbos, you know, it took one spring to actually implement these.

And we were able to the commission that service. So what was a clear, clear winning for us. Now, obviously, we got to. The foundation set, then from there, you're able to add more policies and keep adding the SDK supports Java. So it was very easy as well to, you know, to include that in the, in the code.

But now, you know, you're, you're bulletproof. Yeah. Yeah, I did. We did our work. Now we know we can scale and we can include more complex policies and we can know that we're going to grow in the right direction and with the right security as well. So I'll say. Do not overthink it, you know, do it from day one, because later it's going to be more painful.

Alex: Excellent, very, very sage advice. So finally, thank you again very, very much, Edgar. Where can people reach you? Where can people follow you? Where can people get your insights? 

Edgar: Sure, well, well, we are As I say, we are in 4G capital. com. We are really an amazing fintech that is transforming lives in Africa and is supporting people.

We work in capital. I'm really inspired by the work that we're doing because it's not about getting people into debt. Now it's about empowering entrepreneurs, people with a small business and with working capital. And that is a transformational effect. We, we have, we have a stories of customers being with us years and doing repeated loans.

And they know that they, they can count on us to grow their businesses. We have stories of people opening, you know, restaurants and new restaurants because they were able to, to use the capital to grow. So as well on LinkedIn I'm always, you know, I LinkedIn tried to be active, you know, but I'm, you know, I'm always open to have discussions around tech and see how can we do better, better fintechs, you know, and better applications.

Alex: Excellent. And yeah, I can accidentally vouch if you see a appearing on agenda at a tech event in a U because I know you like you're traveling, you know, you like speaking highly recommend go go and see him. You're a very engaging speaker and always do something very interesting to say. Thank you. 

Edgar: Thank you.

Alex: So just to wrap up a service as well. And if you want to find out more about service and service hub, you can go to service. dev and find out there. And we also run a free architecture reviews and workshops. You'll get myself. Or one of the other team on a call and we can actually go through your your detail requirements Like we did with the 4g team as well and kind of get you up and running and with Cerbos but we are at the end of the day an open source project So best place to find us if you want to jump straight into the code is on github.com/Cerbos.

Edgar: Any questions, Alex?

Alex: Now's your chance, please if you have any questions dump them send them into that chat box below. I don't think we've got any pending at the moment I think we tackled them sort of as we went but please follow 'em in there and we'll, we'll follow up with you individually as well.

If you have any other questions you want to ping us after the fact. So I will leave it there. Thank you very much everyone. I hope you enjoy the rest of your day slash evening. Thank you so much everyone, 

Edgar: And thank you, Alex. 

Alex: Yeah, thank you very much speak soon and check out cerbos.dev for more. Take care. 

Edgar: Take care guys.