Challenges of Starting Projects with Microservices – Darko Fabijan, Semaphore

This is Textron TV. Hi everyone, welcome back to another text drunk TV interview my guest. Actually we haven't had anyone from his company in a long time.

My guest is Darko Fabian Darko is the CTO of semaphore. If you haven't heard of some before you might have used some of their stuff without even realizing it, but he'll explain it all to you. Hey Darko, welcome to Tech strong TV.

Yeah, well, thank you for having me. It's our pleasure. So as I mentioned Darko, you're the CTO at semaphore.

Why don't we start a little bit about you though? What tell us, you know a little bit about Darko and then tell us about some before. Yeah.

Yeah, so actually I started a computer harder and then went into web, you know straight after the university and not not long after that. I started the 74 with my partner Marco and it was like a bit over 10 years ago. So for last 10 years, I'm working on Sam for cites like a continuous integration continuous delivery service.

And yeah, we work with you know, a lot of companies in various domains. And yeah, what is going to be our topic today microservices we speak with our customers a lot about that. So yeah, I would love to explore that topic further.

Absolutely before we do the website for semaphore. com. com.

Just want to make sure people know that I believe it's sem a p h o r e. Yeah calm. It's number four CI right exactly.

com. Okay, we got that out of the way. We're gonna talk micro services.

So, you know, everybody's abuzz about Elon Musk in Twitter and what the heck's going on there, you know, I I read an interest or I saw an interesting tweet from musk that got highlighted in the news yesterday that said they're gonna rip out like something like 80% of all the micro services in Twitter and just use the 20% that they need for the thing to run and it'll run better as a result because the rest of it was all bloatware and so forth. Look, I'm not a fan. I'll be honest with you of them and I'm certainly not a fan of what's going on at Twitter.

But I'm saying to myself is 80% of the microservices just Bloat, where is he said has microservices. Kind of joined the thing it was supposed to start. You know, it was how bad could it be?

As we move towards microservices, right? No less than Martin Fowler and Sam Newman, you know have come out and said that well if you starting a green field, Application. Maybe it's not the best idea to start it.

You know in a microservices based architecture, I don't design it initially for microservices type architecture. That seems to run counter from what we're hearing or what we've seen the last couple years, which is look if you do in a green field kind of app why not? You don't have any Legacy to worry about right do it do it from the get-go?

What do you think and why? Well, yeah, I'm definitely going to answer a question but to give a bit of a context. So 10 years ago, when we started our you know assess product we used Ruby rails, you know, and it's a lot of startup from that from that era did.

Let's say about four years ago. We started more aggressively shopping up that monolith into you know, separate Services. We have like about 25 of them right now.

And we also have around 25 Engineers. It's a good ratio. I got yeah, and we understood our domain very very well at that point and I'm not sure if I would call those 25 micro.

I don't know what how do we set up scales? So we decide what's not the micro. What's the mini and and so on?

So that that's one one thing that I know it works for us very well. But our domain is also specific. There are a lot of you know, a synchronous long running jobs, you know attributes of the system are maybe a bit different to a typical of web application and and so on.

I mean the other experience that they have is you know speaking with a lot of customers. So my vice majority of our customers are you know startups with less than 500 engineers? And you know the most time that we spend talking to are the most, you know successful ones that have most of the challenges and those challenges are all us usually in the realm of you know, how what's the speed of their, you know feedback loop and how fast they can share.

as they scale from you know, five fifty Engineers to maybe on 200 engineers and so on they start to encounter various of those of those challenges with shipping, you know, independently and shipping, you know, without significant delays a vast majority of them jump into that ship of like micro service and they started transition. That transition takes takes years and one very important thing to Define define is what is the current biggest bottleneck have heavy exhausted all the other tools that we have in our toolkit before we make that we make that transition. Um in that realm, I think it's very important to have a scientific trigger into defining what the bottlenecks are and what are really, you know, the solutions to those problems.

And in that realm I would say it's important to be successful. In order to move to to microservices and that you know that you would need to scale your your engineering to you know, above a certain size that transition would pay off. Um not so that that's that's the round that I can comment on.

I I haven't started, you know, a company or a service application, you know Greenfield project with microservices. So it's hard to comment on that but there are many many good things that you lose when you move to microservices, you know, generally all the guarantees that the database provides are gone, you know just on boarding to a project becomes, you know. A bit of a hurdle.

So yeah. those are some of the some of you ask the question no doctor. You've got as you said about 25 what's called Services, whether they're micro mini or in my mind.

You know if they're a service a thread if you will making up, you know part of the app. It's a microservice. I I don't.

really distinguish micro to many yeah You got 25 of them running on 25 engineers. That sounds pretty damn good. I mean that's you know.

That's not a large team by any means. Seems to be running. Well, is it that you guys are special?

And the average customer can't do that. Or because you know, how much more scale do you need? It's one to one there.

Yeah, well, we understand the domain very very well. I mean over the course of first, you know, five or six years we kind of rewrote. A significant portion of our application actual couple of times, you know.

As we were, you know running and growing. Well, everything was still as a part of monolith. So we understand we understood the domain very very well.

We were reasonably successful that we knew that you know, this is going to be around for the next decade or you know or so for sure it's worth the investment and then, you know chopping those species up was not a big hurdle for us. And it didn't didn't backfire in any any significant way. However, there was a significant significant learning curve that we you know had had to go through.

So yeah in that term, I don't think that we are special in any way but I would say that we really really well knew our domain and starting Greenfield project. It's it's different, you know, you're still finding yourself, you know, where are the boundaries for your domain how they're separating things. What are the things?

That's what investing in What are the things that are going to be throw away things? So all those components are I think crucial for a successful successful transition? So I'm just playing devil's advocate here a little bit.

A new project the Greenfield project like this whether you use microservices or not. It's a bit of learning as you go right? It's always Things don't always work the way you thought you you make changes improvements iterations.

I mean, that's key. That's like classic devops, right? You got your feedback.

Loops you iterate you reiterate and iterate yet again, and it gets better whether you use microservices or not. That's the way of it. However there are distinct advantages to using microservices versus a monolithic architecture you want to change something out tweak something Etc.

And there's more those aren't the only advantages. At some level. How do you you know, I'm from security.

It's all about managing risk, right? How do you manage the risk here? How do you manage the advantages of microservices to the This advantages and then make an intelligent decision.

Well, I would start with people. And you know figure out what's a composition of a team firstly are those the people that have prior experience with working with microservices because one of the biggest disadvantages with microservices that you have a lot of network connections between them and that's just, you know, more expensive and has many attributes that you don't have to deal with when something is within the single process of like operating system. So that's the biggest thing and if your team has a team members have a lot of experience with you know, working over the network and so on.

That's a plus if your team is composed of Engineers who have some prior experience working with microservices that that's a big plus. and I would say On top of that you have to figure out what was the level of your of your engineers? Because you know if it's a it depends if it's a project within a very established and successful company or if it's a startup so, you know, we didn't startups usually get you know, initial set of Engineers that should you know, hit the product Market fit, you know correctly, and they should make it to run for a hundred customers or Maybe a couple of hundred customers that potentially either those Engineers are going to you know, develop and mature or you will have to replace them.

And then if you become really successful, then you will get that kind of Engineers that are not going to scale from one from zero to one or from around to 10 or from 10 to 10,000. So with within the startups, I would say, you know be frank with with yourself and your team. You know in figuring out what's the experience level of those Engineers because there are also operational issues with with running with running microservices, you know kubernetes and you know, a lot of things, you know mash and so on make some of those things easier but there is still a significant overhead.

So I mean as you can see I'm very much into that mindset of you know, startup and starting a company in the project, you know from scratch because that's what vast majority for customers are. If that team is composed within you know about established, you know company and there is a new green project and you have like a set of expert Engineers with a lot of experience under then their belt, then it might be might be different. But I mean I I would say that that's the biggest, you know think that you have to be in.

Oh thankfully. Taco it's been a great conversation. I want to make sure we semaphore.

That's where we spelled it before s e m a p h o r e c i calm. I interested in your you know, you're seeing a lot of customers doing a lot of CI. Right the way we build applications today.

You know, I call it like frankensteining them. You know, we take a lot of components. Stitch them together and you get a you know, an integration and deployment it's your application.

It kind of lends itself to a microservices architecture. No. I'm yes you could say so.

Yeah, I mean, you know, they're already. Threaded like that so to speak and and so I don't know. Anyway, I want to thank you for coming on textrung TV today and chatting with us.

This is a question. You know, let's see how Twitter does real eliminating their microservices but it's also something relevant to our audience out there into micro service or not. That's the question.

Good luck. It's said before come back and join us again. Thank you so much.

Alrighty, we're gonna take a break here on Tech strong and we'll be right back.