Revolutionising Africa's Tech Landscape with Kossi Selom Banybah | Mastering SaaS and Microservices

Hello, Kossi. Welcome to the show. Thanks for joining us. How are you feeling?

Hello, Mike. I'm feeling good. Thank you for inviting me.

Absolutely. I mean, we have such good topics on the table, Kossi. SaaS platforms, microservices, Let's jump in. Before we do though, let our listeners know, who is Kossi?

Sure. So, um, my name is Kossi. The full name is Kossi Selom Baniba. Um, I'm the Chief Technology Officer at Gibea. And, uh, yeah, so a little bit of a story about me. Um, I started with, um, electrical engineering, so a little bit about systems and stuff, then moving to software development because, you know, I was feeling like I had more quick feedback with programming, like I could see the result right away, and I like that. So I wanted to try a lot of things, but in general, I'm really interested in technology, science, physics, anything rocket science. I know. Yeah.

Okay. So how long you been in the, in the tech industry as a software, as a CTO or as a, you know, software developer and just, you know, what was your journey? So you started as a hands-on and then now you with the CTO, uh, in the CTO role, right?

Yeah. So I started like, uh, yeah, so that's a software developer, you know. Um, I'll say I've been in the industry for like 14 to 15 years now. Um, so yeah, I started as a developer, um, coded for some time and I've touched almost, um, any kind of application from mobile application, desktop application, um, web application, IoT even. I've touched almost everything. Um, so that has helped me like move into a leadership position because of my knowledge on almost all the aspects of the development. I've done DevOps, I've done almost everything. So it helps me understand like whatever issues my team is going through to help them, uh, you know, solve those issues.

Okay.

Um, so I'll say from software developer, I'm moving to a senior developer role. Um, then I'm moving to head of engineering or vice president of engineering role, then to CTO role.

That is a very common journey for people starting as a hands-on, accumulating huge amounts of knowledge, and effectively making that transition to a, to a leadership role. Can you tell us a little bit about Gabea? Because I read the article, you guys partnered up with Microsoft to bring a young talent, uh, online, you know, upskill them, find the positions. That's a, that's a very noble mission. Can you just give us a little bit about, you know, how that is happening, where Gebeya is right now, and how you guys contributing?

Okay, nice. So Gebeya is a, is a leading Pan-African tech leadership company, uh, which specializes— I mean, we specialize in, uh a SaaS-enabled talent cloud platform. So basically, um, our SaaS platform allows you as an entrepreneur or as a company to have your own talent cloud where you can search for people or upskill your people, right? So you can look at it like, uh, your own LinkedIn version. Yeah, now, um, Our partnership with Microsoft involves having 300,000 people on the Jatayin Cloud. So we actually launched today and yeah, we are pretty excited and waiting for people to join.

I can imagine. I can imagine. So, so if I understand this correctly, I am a company, and if I use Gebeya, I can build my Talent Cloud from a candidate's— you guys source, or do I need to source it myself?

So we have what we call the managed service. So if you want us to, to help you with that, we can do it. You know, the pricing model is different, but you can also do it yourself. I mean, if you can.

Okay. So it's, it's like a talent selection SaaS platform. Am I right with that assumption?

I mean, it's a little bit more than that. Like I said, like you have, of course, the, the, how do you call it, the part where you have people coming in registering, you can vet them, make sure they are what they say they are. And then the selection part or the matching part, which allows you to actually search for people according to specific parameters. You have that part, but also you have the community part. That one is not yet— we're not yet done developing that part. We have the upskilling part. So for the upskilling part, we have currently a partnership with O'Reilly, which allows anybody that is in, let's say, the Microsoft Talent Cloud that we have launched to have access to the O'Reilly platform at a cheaper price.

Okay, so, so which means if I'm a candidate and I'm part of the platform, I get the knowledge, and once I develop the knowledge, I can get the certification, which is driven by Microsoft, and then I get effectively a selection for potential roles, which again, it's, um, I imagine that's driven by Microsoft. Maybe that's my question, because it's like, where does the Microsoft come in?

Exactly, exactly. So, so in Africa, like, uh, and even in the world. Microsoft has a lot of partnership with companies, right? And they need, uh, people to actually come in and let's say implement solutions and stuff like that, right? So in Africa especially, there is a huge need of such people, right? So in here we are helping, um, you know, have one platform where these companies, these partners can come in and find the right people their projects.

Okay, so I mean, in general, you guys creating this SaaS platform, you know, to, to, to run Gebeya as a project, and we have that SaaS topic on the table, so let's just dig into that, right? So, you know, my main opening question, Kostya, would be how did you guys went about thinking, you know, how the platform will get created from an infrastructural perspective? Why did you choose to have this as a software as a service?

Okay, nice. So maybe I, I should start from, uh, from the beginning in the sense that, you know, when we started, uh, first we realized there was, um, a skill gap, right? So when Gebeya started, we trained a lot of people for them to have these necessary skills to thrive in the marketplace, right? And after that, you know, We started placing, you know, um, talent with companies all over the world and in Africa. And, um, at some point we realized like it's becoming a lot, let's make a platform that will allow us to manage this, uh, you know, much more efficiently. So we created a platform and, uh, it was going well. Then, you know, we got contacted by other entrepreneurs, companies. They're like, we would like to have the same thing, kind of, you know. And we had this partnership with Mastercard Foundation whereby we wanted to have 100 Gbeya, right? So if we want to have 100 Gbeya, the same success as Gbeya, Having the software being deployed every time in a new infrastructure for each, you know, is not efficient. This is where the move to the SaaS model is coming from. So we have SaaSified, let's say, the marketplace to make it multi-tenant, to make it multi-tenant. So, so with the project with Mastercard Foundation, which is called Meserat. I can give you the link later for you to have a look at it. The plan is to have 100, you know, Gebeya-like marketplace that will allow entrepreneurs in Ethiopia to have their own platform and also gig workers that will find jobs, right? So we want to help people find jobs and have more opportunity because it's not just about the job, but also about the opportunity that we are bringing to them. Whether it's the opportunity to upskill themselves and become better people in terms of skills, soft skills, hard skills, whatever. And, uh, you know, so basically that is what is going on. So we have, um, some few that have already gone live. And they are using the SaaS to make their business happen.

Okay, let me take us back to the SaaSify, as you have said it, which I, by the way, I love the term. So you guys had the platform and you, for every client, you needed to effectively launch the same platform and make it almost like a copy-paste, and you decided to, you know, to rethink this and create a SaaS platform. Can you share The biggest challenges with that migration you guys experienced while going towards the SaaS?

Biggest challenge, biggest challenge. So I will say the multi-tenancy is the challenge here. It's not the same way of thinking, right? So let me find an easy way to explain this to you. Let's say we take real estate as an example, right? So you build a house, you sell it to someone, right? Then you build again a house, you sell it to someone. Okay, that is fine. But you could have a whole building with, let's say, 100 apartments, right? And have tenants come and rent the apartments. Basically, this is a model, right? So we find that's much more efficient. You know, you have a lot of things in one small place, so you have the same infrastructure being shared by a lot, a lot of tenants, which is much more efficient than always having, you know, dedicated infrastructure for everyone. So that is, I will say, the biggest challenge because the way you code is different And every time there is a call, you need to identify which tenant it is so that you can get back the data that is specific to that tenant because you cannot mix data, you know, tenant data. So Tenant A cannot see the data of Tenant B. It's not possible. You shouldn't do that. So that is where you have to make sure that you put everything in place so that data is well managed.

Okay, I fully get it. Multitenant— having a single code base and having a multitenant is— it is definitely a challenge. And then how do you segregate the data itself? Let's say I'm a Client A and I have some regulation, you know, requirements, so I want my data to be, you know, in, in Africa data centers. And I'm a Client B who wants to have their data in Europe data centers, again because I have some type of, you know, GDPR regulations or whatnot. Do you guys have that challenge where you need to sort of, you know, have everybody almost in the same database but at the same time, you know, the data needs to be physically in different locations?

Okay, so I would say so far we don't have that challenge yet, but the way we have architected, um, architected the, the platform allows us to, to do that. Because what we have done is that the data itself is segregated. So, um, Client A, like you're saying, has his own data. Client B has his own data. So we don't mix Of course.

Okay, so that's how we solve it. All right, so if we go a little bit, uh, you know, uh, technical, the cozy, um, what you guys use, uh, you know, uh, as a, as a cloud provider? Well, I would assume it's Microsoft Azure because you guys have partnership with them. Then, you know, what's your backend framework? You know, what's your frontend framework? Just if you give us a flavor of, you know, the whole SaaS as in from technical perspective.

Sure, sure. So what do I start with? Let's say the cloud provider. So our cloud provider, I would say, is mainly Microsoft Azure, but again, we do use other services. We do use AWS, we do use Google Cloud. So, but it depends on very specific services that we think these cloud providers have maybe much easier to manage than maybe Azure, or depending on the way we have implemented the platform, you know, we started maybe with something, so it was really difficult for us to move away from that. So for instance, we use Firebase, Firebase, which is really known, you know, in the ecosystem for, you know, its integration and all of that. So it's much more easier for us to continue with Firebase. So we did not switch to the corresponding service in Azure when it comes to that, but mainly like most of our stuff in Azure. All right, so that is for the infrastructure. Now in terms of, uh, backend, backend, we do use C#, Node.js, and Python. Python, so Python mainly for data quality stuff and AI, machine learning. We use C# and Node.js for backend services. We use Dapr. Dapr is a Microsoft open source project that allows you to easily, you know, communicate between services, do caching, and many, many features allows us to streamline the development process and be more productive. So we're using that. Dapr is D-A-P-R. So we use that. And for the frontend, um, we use mainly Angular, um, but we used to code some few things in React, but mainly I would say the majority is in Angular. So we're using, uh, micro frontends. And we're using microservices.

That's a very nice setup, Ghost. And you know what, answer all your questions. It's a great answer. It's a great answer. And it's a very nice setup. And you know, we'll dig into how you guys went, uh, you know, around microservices, which is, uh, you know, I have a couple of questions around that. So, um, I got one, one, you know, coming back to, to the SaaS, um, What we're currently seeing in the market, you know, there's a lot of low-code or no-code solutions which are coming into play, and, you know, they're almost challenging the old notion of, you know, code yourself everything and create the SaaS platform. Do you guys see in any way where you can sort of leverage that? And, you know, when you hire engineers, you know, do you look for these skills? You know, maybe your platform offers these kind of skills, or you think that's just not applicable to you guys? And in general, you know, what's your take on this low-code, no-code movement we're seeing?

Okay. Okay. So, um, to begin with, I will say that I'm not religious about technology. So we always sit down and, uh, kind of like, what it's, and try to find the best solution. So whatever issue or problem you want to solve, If we find out that the low-code solution is the best solution, we use it. If we don't think it is the best solution for the problem, we will not use it. It's as easy as, as simple as that. So we're not, you know, we're not like, oh, it's this technology and we'll die by this technology or whatever. No, we really, we are startups, so we always try to adapt, you know, and be flexible as much as possible. Um, yeah, so that's like, we always try to assess first.

That's a very, very healthy view, just being technology agnostic and, and really asking that question of why, which tech, you know, which technology works, or what is the quickest way of getting what we actually need. Okay, I see that. So let me jump to another one. Um, In my experience, when you have different clients, different sizes of clients as well, and when you're catering a big broad market and you have one offering, which is your SaaS platform, you eventually end up doing customizations for various clients because, you know, the, your offering effectively is either not enough or they want to change something. Do you guys experience customization requests? And if you do, How does that affect, you know, your code base, you know, the risks around that and how you actually go about that?

Yeah. Okay. Okay. So yes, we do get requests for customization, whether it's process-based or UI-based, like we want to have a nice design. Here is how we see our design, things like that. So Whenever we have this kind of request, right, we try to see if this is something that can benefit more clients, right? If it's something that can benefit more clients, we put it into the SaaS platform as a configuration. So you as a tenant, you can enable that configuration or disable it. Right now, if the, if the customization is so special that it's just for that specific client or tenant, so we make sure that in the code we have, we identify, once we identify the tenant, then we enable that specific piece of code for them. So let's say for the design, for instance, we have different templates that we put in place, right? So we can have a specific template for, let's say, Microsoft. And then when you go to the ms.gbea.com, which is the Microsoft Talent Cloud, then you'll get a special design for that platform. Okay.

I like that. So effectively, if the feature is applicable to a handful of clients, you, you make it into a configuration flag. Otherwise, you know, it's a bespoke approach. So eventually you're going to end up with a lot of configuration flags, right? You're going to be as big as, you know, Jira or any other tools, and then you almost will need to open your own how to use Gabea, right?

Definitely, definitely. I mean, that is a good problem to have.

Yeah, that's a, that's a success-driven problem. That's a very nice problem to have. Let me ask this. I want to be now in the client's shoes. So I'm coming to Gebea and I want to buy into, you know, your SaaS platform. How do I measure the return of investment of using Gebea versus going ahead and trying to hire myself, you know, trying to upskill people myself and, you know, and all of the things?

Wow. Okay. Okay. So, I mean, this SaaS platform is worth millions of dollars. So if you have millions of dollars and you want to build yourself, I mean, no problem. But the goal of the SaaS is to make things more efficient, cost efficient for you, right? So, um, you won't really pay for infrastructure or anything like that. You're just paying for the service that we are offering new. So I mean, it's, it's way more cheaper than you developing the solution again, and you know, the maintenance and everything for the long term. I mean, it's not that easy to manage. So if, if you want more, I'll say, to have more probability of succeeding, uh, and focusing on your business instead of building the platform and at the same time doing the business, I'll see how SaaS is the best solution for you.

So I got this one, which I've been part of these debates. So there's a lot of CTOs, you know, who challenge the notion of SaaS platforms and especially the pricing model of being, you know, subscription. So effectively you never stop paying versus the old school licensing where you pay once but the sum is much bigger. Do you have any opinion in, you know, from your perspective, I, you know, do you like SaaS pricing modules compared to the old school, I'll pay you once and I never need to pay again?

Yeah, again, for me it's, it's mostly a matter of cost, um, how do you call it, calculation, if I can say. Like, evaluate your cost and, and see, um, let's say over 5 years what you pay, right, for using the SaaS service and, uh, what you pay if you want to develop it yourself. And it will be much easier for you to even decide, right? So I mean, both models are right depending on what you want to do. Like I said again, it depends on what you want to do, what problem you are trying to solve, right? Um, If you, if you have to build the software we are building again, after it's hard, it's not easy. So I mean, if you are willing to, let's say, spend 1 year, uh, for instance, to have the MVP and, you know, start testing, and I mean, it's a lot of time. Why don't you just start right away in between a few weeks of just, you know, testing and configuring, and then you're good. Like, even in one day you can start using your, your platform. The rest is just about configuration, testing different configurations.

What about vendor lock? That's, that's another argument which, which happens quite often. It's like you buy into your SaaS, you know, maybe you start using SaaS integration, so integrate with your platform, and effectively you lock in into that SaaS platform, and then it's quite easy— you know, not easy, it's quite hard then to leave. From your perspective as a CTO, did you ever been in situations where, you know, you went with the SaaS for a year or so and then you sort of like, okay, you know, they're increasing the price, I would, you know, I would like to walk somewhere else, but because I have that vendor lock, it becomes difficult?

Yes, I would say it happens, it happens. Especially when the price increase, that can be a big issue because you did your calculation on the pricing, the old pricing, right? So if it changes and it increase, increases, then yeah, definitely that can trigger some other stuff. Um, so on my side, what we try to do is to be as cloud agnostic as possible, right? So for instance, I mean, I don't think it will happen, but let's say some aliens comes in and they destroy all Microsoft Azure infrastructure, whatever, we can easily move the whole platform to AWS or Google Cloud.

So you can do lift and shift?

We try to really plan for this.

So you can do lift and shift quite easily. Is that based on the fact that you provision your infrastructure via code, like, you know, potentially using Terraform or similar solutions?

Yes, we do.

Okay, that's a good business resilience approach to build infrastructure like that. Often startups, they just do things by hand or manually, and, you know, they get that cloud lock-in, and then it's quite actually quite difficult to jump the cloud, you know, cloud providers.

I understand that. Yeah.

Okay, so let's go talk a little bit about microservices, Kostya. And you mentioned you guys have micro frontends, which— that was a big thing, uh, I don't know, 3 or so years back when it's, you know, started to become a thing. How do you— just give us examples how you actually utilize this in, in real terms with Gebea platform.

Okay, so to begin with, I will say that, um, whatever pattern you're using, like, we try to, to be as balanced as possible. Like, we don't try to use it too much. If you use it too much, then it becomes an issue, right? So, um, for instance, before the SaaS our marketplace platform that we used to have, like, we try to make sure that we do not have a lot of microservices, right? Because we are not Netflix, we don't have a lot of DevOps, a lot of developers to be able to handle, I don't know, hundreds of microservices or thousands of microservices. So we try to make sure we have a small pool of microservices, like maybe 10 to 15 maximum. We try to lower it down as much as possible. So you are in between, let's say, in the middle, in between monolithic approach and the microservice approach, right? It's not really monolithic, it's not really full-blown microservice. We have very small services and stuff like that. So we try to use domains and see how we can group as much as possible things into services so we don't have too many services, right? So we are trying to also follow that kind of approach with the SaaS, even though with the SaaS we have a lot more microservices. But still, we try to make sure we don't, um, I'll say, play too much with services, right? We try to make sure if we have to create a service, it must be really needed. If it's not really needed, then we try to see What service can handle this thing without creating an issue? Then we add to that service.

Okay.

Which allows us to have a relatively low number of services. Now in terms of micro frontends, what it allows us to do is to, let's say, switch in between, let's say for instance, React or Angular for, you know, or use components like we can put components components and then use these components in between different applications without, you know, having to recode it. So in terms of reusability, that helps a lot. Yeah.

Okay, so, so mainly you're driving a different framework switches with the front ends. Does your front-end services align to your backend services?

I'm not sure I understand the question. Okay, uh, what we are using for the micro frontend is called Single SPA, which is a framework that allows you to actually manage your micro frontend, and it supports all the JavaScript frameworks out there. So if tomorrow we decide to switch to, let's say, Svelte or Qwik or other frameworks. Yeah, we can do so quite easily.

So just to elaborate on my question, Kostya, so let's say, you know, we have a service which we call the search, right? So that means that all the backend logic of that service and all the frontend logic is, is aligned. So that means, you know, it's a full service, and if I deploy it, you know, you get the frontend and you get the backend. That's what I meant with the question. Asking if the frontend aligns to the backend.

No, no, no, they are not combined. No, no, no.

Okay.

So the backend is on its own because again, this is a SaaS, you know, let's say it's more like component-based. So we can tomorrow have other services outside the SaaS that can consume specific APIs from the SaaS, right? So one of our plan, for instance, is by the end of the year to open up the platform so that other entrepreneurs that, you know, have the capability to do so can code against the platform with their own frontend and stuff like that. So we'll show them, I mean, we'll give them access to the API and then they can build themselves their frontend.

Okay, what's your, what's your take personally as a CTO, Kelsey? What's your take on monolithic applications and, and microservice applications and applications in between? So do you feel like monoliths don't have a place, you know, and, and should be forgotten, uh, or do you feel the microservices are maybe overhyped and, and, you know, they shouldn't be used onboarded very easily. It's just like, what's your opinion on that debate?

For me, all of these different ways of seeing this is just different ways of doing the same thing. And also depending on the project and the size of the project, you would, you know, decide what is best. So I lean a little bit towards microservice. But again, I will use monoliths every day if that is what solves the problem. I'll use serverless if that's what solves the problem. I'll use microservice if that's what solves the problem. So for instance, I can— for monoliths, like, you can have modular monoliths. Like, even though it's, it's one application, inside the application you have different modules, right? So that tomorrow, if you, if you need to move into microservice, you just separate, you know, these modules into their own services.

That's a, that's a, that's a very good sort of like transition thinking or preparing for that transition. Am I right to assume that Gebeya, when you guys started building, was a monolith, and, and then you started to to sort of cut it out and make it into its own services?

I will say no. We started straight from microservice, but like I said, it's really in the middle because we had, let's say, big services, not that big, but not also small. So Uh, we did not start with a monolith. We start right away with microservice, but in a safer, safer way. Because if you don't— if you jump right into microservice without having the right knowledge, you make work much more difficult for yourself, right? So with my experience and what I know about monolith, microservice and stuff, at that time we decided it was best to start with microservice but make it very small number of service so that is easily manageable for our small team, right? So this is exactly what we've done. And inside every, uh, I think we were calling it mini services just for fun. We're calling mini services, not microservice. So inside every mini service you have small modules, at least every code is really well, you know, designed so that it is easy to extract that when we need to. So we use CQRS to make sure that everything is very, you know, very straightforward. Yeah.

Okay. So you jumped in the journey of micro or mini or macro services or just services in general, right? It wasn't and as you mentioned, like hundreds of them, it was a, it was a handful which had their own responsibilities. So did you guys apply some type of like a domain-driven design of how you actually think about the services? Like, is there a logic, or is it more like demand-driven where you sort of eventually see that there's a service being born by, by just simply, you know, thinking about the roadmap or, or thinking about which makes sense, how you want to segregate your code. Maybe you want to align your code to your particular team's skills or whatnot. It's like, in general, is there a logic behind how you create services?

Yes, we are a big, big fan of domain-driven design, so we try as much as possible to, to use that.

How do you— how the session looks like? Let's say you know, you're coming in a room with development team and like, what questions do you guys ask to establish like, you know, the boundaries? And it's just like, give us a flavor of like how the newest service was born.

Yeah, so, so to be frank, it's not that easy because not everyone understands domain-driven design. Even myself, I still learn every day as as I can. There are always some few things that small use cases that you wonder like, how do this work for this special use case and stuff like that? But we always try to find like, okay, what does this, or what is this trying to do, right? And, uh, where can we put it? Let me try to make it simple. You know, this is trying to do, let's say, payments, right? So what does it right? How do we handle this and stuff? So okay, maybe you should have this service that handles everything about payment and stuff like that, right? And you have use cases where you can have the same, let's say, entity in, in different services, but it's represented different because of the specific need of this service. So you have these different things you need to look into.

Okay.

But again, it's always a learning experience. We all learn.

Do you find yourself in a situation where the boundaries are getting crossed? Like, you know, let's say you have a payment service and, you know, it grows by the size and, you know, you add like refunds and, you know, maybe some of the people profile goes into the payment service, and then you have another service which is like a profile service, right? And then maybe capturing information around the payment, such as credit card, you know, should it be in the profile service, should it be in the payment service? And then you suddenly go like, I feel like I want to cross the boundaries of these, you know, services. How do you, how do you think about that, and how do you sort of solve challenges like that?

Yeah, so most of the time these challenges comes in when, let's say, there is a huge pressure, let's say, to deliver on a specific deadline or something like that. Because again, we are a startup, so sometimes you have these deadlines that you cannot miss. If you miss it, it's very difficult to recover, right? So sometimes you need to like understand that, okay, you cannot have everything perfect, you know. So you try to, to make it as acceptable as possible so that it's not too bad, it's not perfect, but it can be improved as you move on. You make sure you document that so that tomorrow somebody else that takes that code understands why you did it that way because maybe at that time you did not have the choice, we have to do it quickly and stuff like that. But you explain, you know, why it was done that way so that it can be easily improved and moved into something else if necessary. So again, there is nothing perfect, you know, it's an everyday fight or, you know, every month fight because sometimes, yeah, we plan ahead, we understand the risks and stuff, and we try to decide like, okay, let's go like that and let's reduce the risk as much as possible.

I like that, Kosi, because reality is, especially for startups, uh, you will need to move fast and you will accumulate technical depth. Could be decisions technical depth, you know, could be code technical depth, infrastructure. But as long as you have a process to actually being aware where this is, you know, being accumulated and have a strategy of addressing that, you know, maybe giving some time for the team in a week to do this. It's, it's just what happens. Like, it's, it's very difficult to not accumulate any depth when you're going and, you know, growing rapidly and scaling rapidly. So I got one which I personally have, um, around microservices or even microservices, you know, maybe We don't have hundreds of them, maybe we have, you know, tens of them. But for me, I have this frustration with this setup is that anytime you get an issue and it's, it's one of these issues, you know, where you can find the answer very quickly, like it requires a proper troubleshooting process, like it's so difficult to find an issue. Like, is it in this service? Is it in that service? You know, all the logs and you're just digging and it's just so annoying, right? So that's my frustration with this infrastructure. Do you have anything of your own frustrations when it comes to microservices?

Well, uh, I would say that is the typical one, uh, but the way you solve this is to have more visibility, uh, through monitoring, distributed tracing, so that you can track from the beginning to the end, where it's going through, right? Uh, you have the logs like you said. Um, yeah, you have different tools that you can put together to have better visibility on what is going on and solve it. So sometimes the first thing is when you have an issue, like because you have microservices, when you have an issue, most of the time you can know where the issue is coming from. At least that is the easiest part. Like, okay, you have an idea, people are not able to log in. Okay, maybe this is this service, right? This service is the one taking care of that part. So you already know where to go. That is the beginning. Then you can look at the tracing, the logs and stuff, and see, okay, I have this issue. We also have, um, um, what do you call it, tools that record the errors. So you can also go there and see, okay, what are the errors that I'm having? Maybe there is the error is there. So you have these different tools that you can put together to solve the issues very quickly.

So yeah, I buy into that. And at the same time, it's like you get these like one service calling another service, then that service calling another service, then, you know, they both write to different databases, because if you have an actual microservice, you'll have, you know, independent databases. And then it's just, it becomes such a like puzzle, and I feel the pain of developers, you know, going like, oh my God, this is a needle in a haystack. It's just, you know, hard to find it. Do you have like any names to give regarding the, you know, tools you guys use? Is it like, you know, Azure baked-in tools around microservices, or maybe use I don't know, Grafana, Kibana, anything which you think helps you greatly in these troubles.

Yeah, sure. So like I said, we try to be as agnostic as possible. So for monitoring, we do use Grafana Prometheus and stuff, Kibana. We use Sentry I don't know if you know about Sentry.

I know Sentry, yep.

And some performance checks also. Um, what else can I give you? I mean, that, that's basically, uh, we do for distributed tracing, uh, we tried what, Zipkin and other stuff, I think Jaeger. Um, yeah.

Okay.

This, this is the point we even use, uh, I mean, on the old platform, we even use Linkerd for the mesh. You know, it controls the whole communication and stuff. So it depends. There are many tools that can help you.

Yeah, I mean, these are all great tools. So I'll give you another one which came to my domain and comes often. It's like, you know, you end up in these situations where it's hard to debug stuff. And then you go like, I need all the logs. Like, you know, next time when it happens, I'll know everything, right? So, so the teams go in and they like, you know, let's just log all the JSON bodies. And, and suddenly you have this other problem, which is you're paying a lot for the storage of the logs because, you know, if, if the platform is quite busy, you're writing all of these JSON bodies in full, and then you're looking at the thousands of just ignoring the logs. Like, do you guys have issue like that? And again, you know, any sort of suggestions?

Yeah, again, that is another typical issue that you have. And, um, well, um, if you try to use, let's say, um, a cloud-based, um, how do you call it, tool that will For instance, I think at some point we were using Azure to gather these logs and process them and everything. At some point we realized that this is too expensive. So we went back to Kibana and the rest, you know, it was too expensive. I think we're paying, I don't know, $10,000 a month or something like that. It was like, ah, this is too big. Let's use open source and stuff like that. To reduce the cost. And also, like, for instance, for specific projects that we did for clients, for instance, other clients, right, they wanted to have their own platform, for instance. So in that case, let's say they have their own data center, they have their own server and everything. So when you are logging, you know, all these errors or information into their server, You need to put some alerts in place so that if, let's say, the storage reaches, I don't know, 60%, you should already be notified that, you know, it's growing at that level so that you can increase the capacity and things like that. So yeah, you definitely have to manage it. It's something that you cannot avoid, especially if you have a platform that deals with special information or like Transaction payment and stuff like that. You need to track everything.

Yep, that's, that's what the trade-off comes in place, and it is, um, you need to track, you know, it will come with the cost. And you're absolutely right, because with the open source project, you know, you can still track it, you can still get some, some, you know, better way of querying the logs. It's not as pretty as a dedicated solution which, you know, has a huge cost attached to it, but It's still better than just having a Rolex, right? So, um, let me just, uh, dig into your experience and ask this question. What advice would you give to people, you know, starting the journey into microservices? Or if you would go back when you guys started to architect and build Gebeya, what would you tell yourself?

That is a good one. Um, I will say always start small, always start small. Don't try to go big at once, like try small tests, try to, to write the simplest code possible, you know, because when you start having technical depth, if you don't understand your own code, you are dead.

You.

So try to make this as simple as possible from the beginning, and then you can improve the, you know, the situation as you move on, right? If let's say in the beginning you have maybe, I don't know, hundreds of users using your platform, you can have some simple code working for 100 users. But of course, when you reach thousands or ten thousands of users, the same code may not work anymore. Now you start working out what's going on, ability, performance, and that stuff, right? Then you can improve and stuff like that. So start small, it will cost less. And then as you, you grow, you get more money, you can get more developers. So it's much easier to scale and improve performance.

I love that, Kossi. Start small. Don't try to solve all the problems at once. And, you know, once Like, one, you're not gonna be able anyways, and two, you're probably gonna walk in the rooms where it's just overwhelming, right? That's a very good shout. Thanks for this, Kosi. So in the spirit of very similar question and in the spirit of the show, in your view, Kosi, what is one most important thing for any tech growth venture? So while you're thinking, I'll give you a context, right?

Only one.

Only one. Yeah, that's exactly. So you are just starting, you know, you're entrepreneur, maybe you know how to code, maybe you don't, but you know you want to create a tech venture. Is it mobile app? Is it SaaS platform? Something else? In your view, what is the main thing people should be thinking about?

That's a hard one. Because you normally have a set of things that you need to put together to have the right stuff. But I will say, yeah, I'll say start with selecting the right technology that will solve the problem you are having. If you miss that, coming back will be very very difficult. Yeah.

So effectively, your tech stack— make sure you're choosing the right one.

Yes.

I love that. I love that. And I can give example where I always say to tech startups when they kick off, the hiring cost and the, you know, talent cost is actually baked into your tech stack. So if you're kicking off with microservices, you're kicking off with React, you're kicking off with something like Python in the backend, what effectively you're selecting is a very expensive tech stack. So you're gonna have, like, you, you will be throwing a lot more money to get the people into your startup and you actually run the startup versus, you know, choose something cheaper, you know, choose PHP for the backend you know, maybe AWS hands-on knowledge, no Terraforms, no, you know, coded infrastructure. Start with the cheaper tech stack. I mean, you will be able at least have a, you know, bigger runway. Eventually, of course, that might actually come back and bite your ass because, you know, you're not going to be able to scale. That's a very good shout, Kosi. Think about tech stack before you kick off. All right, we We got that one. So I got this last one, which is just thinking about the future. In your view, will the SaaS offering or SaaS, you know, market change somehow? Do you think we're still gonna have SaaS being the most popular offering online, like software as a service? Do you think that will somehow innovate and evolve in something else with, you know, AI now coming into play and, and whatnot?

Okay, okay. Um, I wish I could travel to the future and come back to answer you. Uh, but so far from my analysis, um, SaaS is here to stay, according to me. And you can see this, right? Like every, every big company is trying to move to SaaS because it's much easier, um, to, to manage. Like you have one thing that you can manage much easily, um. So on the SaaS provider side, right, you can actually calculate your revenue, right, according to the people that have subscribed. So it's much easy to know about your future, like, okay, in one year if I have 1,000 users that subscribe this, you can calculate, okay, I can have this and that. So it's much easier to operate when you know your value, your monetary value. So I think it's a model that makes it easy to really manage your business in a way you can forecast you know, financial focus and other stuff. So apart from that, it is much more, uh, how do you call it, accessible for anyone all over the world. So the world is your market. So again, what can be much better than that, right? Anybody anywhere can actually pay for your stuff and use your service. Uh, if you were using the old model, then you need to like package, I mean CD or DVD, whatever, and you need to send it over there. And if they try to install, it doesn't work, you need to do tech support, blah blah blah. It's much more difficult. So I think SaaS is here to stay. That doesn't mean that you need to put SaaS everywhere. I will say no to that. Uh, I don't like extremes, you know, always try to have a balance, uh, you know. Way of viewing things, like the yin and the yang, you know.

I love that. There's philosophy behind decision, of course, isn't it? Don't, don't lean to extremes, just, just make sure there's a, there's a balance. All right, so, um, what about micro, microtransactions? Like, I'm seeing this as an evolution of SaaS, you know. You had SaaS, you're paying monthly. Now it's like, okay, come use my my platform, you know, pay a little bit. So it's a low entry cost, but then once you're inside, you want this feature, here's a little bit more payment. You want this feature, here's a little bit more payment. And then, you know, we are in this microtransaction world with many big services. Do you like that? Do you don't like that? What's your take?

I will say I like it in the sense that, um, You could have a huge platform, right? But I may not need everything in there. So why should I pay, let's say, $10,000 per month to use that while I can start with $100 per month? You see? So for me, it's more efficient. So I like that.

Hmm. So we, we do care about, um, effectively giving to the market the low entry cost. And then, you know, if they want, they can just select more, right? Of course, the monthly payment goes, but it gives that dynamic pricing in a way, right? Okay. So anybody in your network, Kosi, would you personally know who would be good for the show?

Yes, of course. I have my amazing CEO. I think he is one of the best CEOs. In Africa and the world. So I'll probably put you in contact with him so you can discuss. He's called Ahmadu Laffey. Um, we have our engineering head of engineering who is now the chief engineering officer. I'm very happy for that. And he's called Mansour. I'll give you you know, all the people that you can talk to. We have our Chief Platform Officer, so he can talk to you in terms of product management, you know, agile methodology, all of that.

That, I mean, that's many people. Cause thanks for that.

Apart from that, that is in Gebeya, right? That is in Gebeya. Yeah, but outside Gebeya, um, yeah, I know a lot of people in the tech. Yeah, um, so we can— I can give you like a list of people, no problem.

That's okay. I mean, I was with this question, the fact that I was looking, you know, often people have like a mentor they learn from, you know, which they sort of go like, yeah, you know, that, that, that person. That's effectively, you know, uh, where that question is coming from. So And any final words from your perspective, Kosi? And if anybody you want to give a shout, maybe the project, maybe a person, maybe some final words, you know, for our listeners where you feel, you know, is a good message to send.

Nice, nice, nice. So one thing I will say is, um, you know, in whatever you do, um, in life, make sure, like I said, you don't lean too much into something. Always try to be as balanced as possible because that will help you on the long term. Because sometimes when you lean too much, it becomes difficult to change direction. So when you try to be as balanced as possible in everything that you do, you know, you can see the whole— try to see like the whole perspective, right? Don't just see things from your point of view and that's it, right? Try to always see what other people are also seeing, get their perspective, and try to work with that. Because, you know, the world is big, you know, and it's just through your eyes you cannot see everything. Other people have other abilities that can help you understand the world better. So for me, it's It's like work in collaboration with more people, you know, learn to network, network, network. Now in terms of technology, I will say that what we are building at Gibea is big, and if you can try it out, please, you know, try it out and let's see because we want as many people to use it as much as possible, because what we are trying to do is really game-changing, especially for Africa and the world. Like, imagine if, let's say, you are, um, even if you are a government, right, you could use this platform to have a proper idea of the skills of your people, right? So if let's say you have a special project, you know exactly who to go to, to, to work on that project, you know. And sometimes you see it takes a lot of time for, for government to like find the right people for projects and stuff. So I think a lot of problems will be solved in this world if you can have the right person in the right position to do a job.

Thank you, Kosti. That's a good shout. Anyone checking Ebea, you know, we'll have the links in the show notes. Thank you, Kosti, for coming to the show. I had the pleasure talking with you. Hopefully too.

Thank you for inviting me. It was great.

Cheers, Kosti.