Managing Microservices-Based Applications – Eli Cohen, Helios

This is texturing TV. Hey guys. Thanks for the throw.

We're here with Eli Cohen is CEO for Helios, and they come up with a way to figure out what's going on with your highly distributed microservices based applications Eli. Welcome the show. Thanks for having me.

You guys just picked up. So, what's the plan? Where are we gonna go with this?

I'm assuming you already bought everybody a beer who's gonna be concerned. So now where do we go from here? Yeah, so, you know world and a big toast and now we're planning to double down both on engineering and on marketing and sales, you know to expand the team and most importantly the customer base.

So what exactly do you guys do? How does it work? And why didn't somebody already do this?

So it's a great question, but I think I would be I think we should start with the pain. We're trying to solve it will be a little bit easier if it's fine with you. Sure go ahead.

Yeah, definitely. You know what you need to remember today that you know, all of that and the organizations are moving to the cloud right you're already tired of that pitch. Now within the transition to the cloud what we see within our customers is the either break their monolith into microservices or service function.

Or the beginning the architecture, you know for microservices and stuff like functions and what we thought based on our experience, you know both me and the phone and my co-founder now we're Engineers back then and Engineering managers is that it getting quite complex for the developer today to developing a cloud native and distributed system mainly because you know, you have so many different Services you have so many different Technologies you are so much reliant on top of the API is on in Cloud native resources that even when you as a developer want to develop one feature, you know in I did world you would expect it to end all only one service at the time but in real life you actually have to handle a few services that are actually tied together with few different technology. So you as a developer, your day-to-day life are actually getting much more complex and you actually get much much lower and this is exactly where we start. Makes sense so far.

Yeah, I'm with you a lot of folks are intimidated by microservices, right? Yeah, definitely and you know, what what we're saying. Is that Microsoft?

Said they have a good thing. You know, it gives you the option to accelerate your development. It gives you the option to to walk in smaller teams, but eventually you get into a certain phase when you just get lower and lower and the more micro Services you have and the more Engineers you have on both actually things are getting much more complicated and this is exactly where we want to help.

Yeah, so how did you go about doing that? I mean the problem has been around for a while. So what did you guys discover that nobody else did?

Um, so I really agree with you. The problem was that we possible a few years already, but I think that's why change significantly during the last few years is an open source board called open telementally. Are you familiar with that?

Have you heard about it? Yeah, absolutely. So open Telemetry.

It's getting widely adopted now days, um, you know, and it gives us as developers capabilities that simply well and there before so what we do we tell us we don't only make the distributed racing data from open Telemetry accessible for you as a developer, but we also make it actionable for you as a developer. Meaning we're giving you the traces that we collect with the right context at the right time in order to accelerate your Dev velocity. When you develop new features when you travel with them when you try to reproduce you even when you test your application, Once your sense of how rapidly is open Telemetry being adopted by developers because it used to be a chore to instrument my application.

So is that getting easier? Yeah, so definitely I think part of the things that recently changing at least in the last two years is that open Telemetry is getting widely adopted and it's getting easier to implement it so you know it now days I think there is an agreement upon industry that this is gonna be the industry standout for collecting Telemetry data, and we think the interesting question is not how are you going to collect this data? But actually what are you going to do with it?

And how can you leverage that? Well, do you think that a lot of folks have started down a microservices based project? But because of the complexity that you're describing abandoned it and went back to their old monolithic efforts and you know, is that kind of holding the whole industry up?

So there is a real pain. Right with Michael stellington and then when they scale they suddenly realized that it's not that of it's not that honeymoon that they experience saw before so they definitely are struggling with that. So what we see is kind of like minimally mini monolithic Still within your architecture and this is exactly part of the things we're trying to help you with because the eventually, you know, Michael services that some very good advantages, but we want to help you leverage them.

Even when your organization scale. Oh much. Can you track in real time?

Because a lot of these environments are very Dynamic these days and there's a lot of changes. So can I you know, maybe create something that looks like a visual graph that shows me all these changes in real time. And what does that look like?

Yeah, definitely. So if you're interested we can also do a quick demo later on really, you know, I can share the screen but the idea is exactly what you said, you know giving you as a developer a complete a picture of how your different Services interact with each other to the level of the specific transaction. And not only that also aggregated that I give you insights on top of that for example, how your code change throughout the time.

So when you try to probably shoot an issue we can also give you for example the git commit and not only that kid commit but the last game commit that was actually walking again everything in order to help you as a developer acceleration of development philosophy. I think a lot of people understand that a microservices based application is more resilient, but I don't think they appreciate the performance issues that go along with that because over time if I have an issue the application doesn't crash it just kind of reroutes things and makes things slower and I can spend weeks and months looking for that. So do you think people get that?

So I think people if they have enough experience they get it but this is definitely one of the pain points that we identified and we see even we our current customers today. So I think this is something that is very painful, especially when you involve more capabilities, if you're for example, ask sophisticated data pipelines or if you have many databases, so I think this is one of the pain points that you get to realize when you're done when you'll go organization. Google is any actually takes a lot a lot of your development time.

So actually what we see is that developers today spend more time on exact death problem of trying to understand what is going on instead of developing, you know new feature and instead of handling their business logic. Hmm and then we wind up inviting them into a war room where we try to prove everybody's innocence, but that can also take weeks and forever. So what we save a lot of time on the back end because we won't be dragging everybody into a meeting for three hours trying to figure out what's going on.

Yeah, definitely. It's been in this situation for many times already too many actually. What's your sense then of what is the biggest challenge that people are kind of getting to right now?

It seems like developers are embracing the idea of microservices and containers. But the length of time it takes to build these apps and get them into production environment seems to be a challenge and we're not quite seeing the pace of deployment. So do you think that we are at the at some hump in the middle here that we're kind of stuck but that all these apps will soon be deployed in production environments and we're kind of building this huge base of things today that haven't quite manifested themselves just yet.

Yeah, so I totally agree with you. I think we have a challenge right now in the industry. I think people double down on microservices because you know, that's what they read and that's what they believe and this is effectively the only way to walk in smaller team in big organizations.

But then there is a certain Plato that they understand that they have to do better than that because they're execution is simply gets hurt, you know, so this is the exactly I think what we as an interesting should solve in order to better execute and to deliver better products faster. You guys are helping people collect the massive amount of data as well. So does that mean we'll soon be throwing algorithms at this data to kind of figure out what's going on?

What can we go do in the future does AI play a role? Yeah, so for now, you know for now we're doing the simple thing because what we see is that even just helping you as a developer collect this huge amount of data is very valuable for you. But definitely we keep hearing demand from customer all the time to better analyze the DACA that we collect and to give them insights on that data.

And those are the things that we already started doing because we not only help you understand the system our capabilities also start to understand your system sometimes better than you so we kind of get a grasp of what is going on within your applications sometimes even before you did do that. And the other issue that people don't talk about all that much is it takes a lot of time and effort to onboard somebody to one of these projects once it starts to get very complex. So is what you guys are doing gonna help me figure out a way to get those people on board faster because otherwise they spend, you know months trying to figure out what code goes where yeah, definitely.

So actually I have to be honest. We didn't think about it at the beginning but when we started playing our system to customer the feedback we got is that our system actually is becoming their single source of truth of what is going on live within application and they will actually starting to use us in order to help the fellow Engineers on board. Not only the new team but also to new project for suddenly, you know, when you want to understand what is going on with your system.

You don't have to go into outdated documentation. You can simply go into Helios and see how these flow behave just yesterday. All right.

So what's your best advice to organizations as they kind of look at all this stuff and they try to bring some order to the chaos. What do you see as a best practice? Um, so first of all, it's important for me to say don't be afraid and think Michael services and serverless.

Eventually. They are here to stay with all the complexity that it brings. We need to remember that.

It brings a lot of value and it does help you accelerate your development process, but you need to have the right tools. It can be the devops perspective. It can be at the deaf perspective.

You just need to provide your developers and devops necessary the right tools to make things easier on their life in order for them to be focused on their business logic and not on the peripheral. All right, guys, you heard it here first using the same tools as you always use to build something new in different may not be the best idea you're ever going to have Eli. Thanks for being on the show.

Thank you very much for having me. It's been a pleasure. All right back to you guys in the studio.