Video size:

0:09 Miko Pawlikowski

Hello and welcome to Conf42Cast Episode 6: A whole stack of Pulsars. My name is Miko Pawlikowski and today with me is Leonid Belkind, the co-founder and CTO of StackPulse. Leo, it's great having you here for a second time too.

0:25 Leonid Belkind

Thank you. It's always a pleasure Miko. Really excited to be here with you guys.

0:29 Miko Pawlikowski

We're starting with this new tradition right now to begin with through an awkward question, so here's yours. If you could have any animal at all as a pet and in the world, you know, what pet would you choose? And why octopus?

0:44 Leonid Belkind

No, I wouldn't necessarily choose octopus to be my pet animal. As a matter of fact, I'm a big animal fan and I'm not sure if keeping octopus captive is a good thing. You know, for me, I'm I'm a cat person. My first cat that is unfortunately no longer with us, if I had to choose anything from a perfect world, I would like to have her back with me right now.

1:06 Miko Pawlikowski

I was asking about octopus because I watched on Netflix "My octopus teacher" the other day, and they're absolutely crazy opening containers and having a federated brain and everything.

1:18 Leonid Belkind

Very intelligent beings indeed. That's exactly why we chose one as our logo, because nobody knows exactly how smart these things are.

1:26 Miko Pawlikowski

Yeah, they're kind of like an alien on Earth. Speaking of StackPulse, what's your favorite and least favorite thing of being a co-founder and CTO?

1:35 Leonid Belkind

I think my favorite thing about being a co-founder and CTO is the amount of creativity you can put in and the freedom you get to work with the people you really enjoy meeting every morning. This is something that I would probably not trade for anything anywhere ever. My least favorite thing... Well, you know, I have to say that I pretty much like being that so least favorite thing...

2:01 Miko Pawlikowski

It's on the record.

2:02 Leonid Belkind

Exactly. It's not a showstopper in any case. It would probably come as a surprise. But we work pretty hard that startups. And being a founder means that you're never ever officially off work, right? You can be relaxing with your family. But at that very moment, you're still a startup founder. That's the price, it is not low. Still paying it for the second time in my career. But it is something to consider for those who are thinking about taking this career direction.

2:33 Miko Pawlikowski

And also you might mention the second time in your career, how bad can it be if you're doing it for the second time, right?

2:39 Leonid Belkind

Well, you know, maybe I'm enjoying the hardships of a founder life. What do you know? I mean, some people love to suffer, not necessarily speaking from a first person experience, but could be. Don't discard that as an option

2:52 Miko Pawlikowski

Let's talk a little bit more about the suffering of yours. Why did you start StackPulse? Did you have one moment when you realize, okay, this is a great idea for a company I was just go do it. Was it a more gradual process? What happened?

3:05 Leonid Belkind

Though the process was gradual. This was not one of these ideas that suddenly sort of like lights up like an electricity bulb in your mind. I think this process started, well, maybe 10-15 years ago, well that sure is close to plenty. When I first started delivering enterprise grade software products, right? I'm an enterprise cyber security guy, who worked for many, many years for one of the world's largest vendors, check whta's up with technologies led a big organization there, while we were investing a lot in building was at the time, top notch security products, I saw that delivering on premises products to customers, and them deploying those products in their environments, them having to face the operational challenges dealing with it, and so on, always sort of like, leaves you in a place where you do really the best you can. But then you still operate a product in an environment to which you don't have any visibility. And it always surprises you. And the supportability of these solutions is really difficult. Now, happily, I was not the only one to realize that. And as we started seeing, I think maybe 15 years ago, the industry of software engineering began making its shift to software services, right. For b2b Enterprise. It probably started with the players such as Salesforce, right? That have proven that CRM doesn't have to be something you run on premises, but could be consumed as a service. Definitely Microsoft contributed a lot with Office 365, and so on and so forth, right, bringing the industry to the point where today, more and more enterprises are actually looking to consume as much of their business stack as services. Now, that was great, and indeed, has introduced a lot of improvements on my original hardship and sorrow during those days, which was supporting my products and making sure my customers were actually happened, right, supporting a service that you operate, you can do a much better job. But and here's a very significant bucks, suddenly, when you deliver a service, you become responsible for much, much more than just the business logic that you implement it and provide it to somebody, right? Suddenly you become responsible, in many cases, even legally liable for having that service a operates properly available with the desired user experience all the time, be it gave also new meaning to security operations, because in the past, every organization would own security operations for its own critical data assets, its own critical computational assets. Suddenly, when you're a service organization, you are providing service, you are hosting data being data subprocessor, for many other enterprises, both the security and your security operations, maturity, as well as reliability and operational maturity of the overall service. It's more than just your data, it's that of your customers, it's a much, much bigger responsibility. And this is what we started seeing and understanding in our previous company luminate security, we were a pioneer in zero trust network access, and what is today called secure access services, edge s a s II delivering our service to first fortune, sort of like global 2010, even to a growing number of Fortune 500 companies. So suddenly, the importance of that gets multiplied by the factor of how successful you are in your business, right? Because the more customers you provide service to the more data and the more people companies are relying on you operating your environment securely and efficiently, right. And that's actually what led us to an idea of building Stackpulse automation and orchestration platform, focusing on security and operations teams. Why? Because unfortunately, while the industry has seen tremendous progress in automated testing, continuous integration, then Continuous Delivery infrastructure as code etc, operations, both security and cloud Ops, etc, still remain much less engineered, and much more based on people who know what they're doing, which is real love. We all love people who know what they're doing. But that doesn't scale I don't want to rely on you know, my bank being always there when I need to withdraw some money or transfer some payment, just because they have a security operations, people that could focus on any problem really quickly, or they have operations team that could pull up their service and make sure it works. I really want it to be engineered better. Does that make sense? It does.

11:08 Miko Pawlikowski

Yeah. So so far, we're providing easy enough to use tools to automate all of that manual stack so that it can be done by the person who has the knowledge, not someone else who has to implement it further.

11:22 Leonid Belkind

Wait, there is more. It's not only about tools that are accessible enough and are easy enough. This is actually a tool that should fit the state of mind of that same person. Let me give you an example from a very different department so that we can all relate to it. The thesis is that you can be doing some kind of process multiple times a day. But when I asked you, stop there for a moment, could you please translate this process into, like, steps components flow diagram, you will still have a challenge to do that. Imagine it's like telling your child to go and order their room. They're like, what, wait a second, what does it mean to order my room? So I enter the room. Wait, there is an algorithm, right? I need to pick up each and every object that is currently either on the floor, on the bed on the table on the chair. And then I need to probably classify them by groups. These are books, these are toys, these are clothes. Then I need to think, what is the proper location for each and every group, right? Clothes go into that shelf, books go onto this shelf. Then what is the space on the shelf dedicated for that group? So you see where I'm going with this, right? As a grown up person, you could easily walk into a room and say, "Okay, I need to arrange this room, it's a mess". But if I asked you, let's now automate it. You would find it not easy. It will require a couple of iterations. And when I say a couple, I don't mean necessarily two. For you to actually think about it as a process. So the tool doesn't need to be only accessible for the technical merit. Like ,let's say you're not familiar with any programming languages, let's make it accessible for you. That's, that's great, that is needed. But that's not sufficient. What is sufficient, is that the way you move from a manual process that you repeat, in many cases, implicitly, without paying attention to order of operations, into your ability to actually yes, end up with logical flow that can be executed without you being present. It's an iterative process. And the tool needs to fully support that to allow you express it. This, by the way, is one of the underlying reasons why if you were told me about your processes, and your grades of the process, and I'm a pretty decent programmer, we might still be in trouble. Not because one of us doesn't know what they're doing, but because of this fundamental thing. And that's what it's all about.

13:36 Miko Pawlikowski

Solid. It makes sense. I guess the kind of flipside of that is that, you know, your offering, kind of goes very deep into a soft tissue of the teams and the organization, right? It's not just like, "Oh, hey! Here's this programming language, and we go check it out. And we like it, we take it". It takes a little bit more, I guess, to change the processes. And it takes a lot of goodwill. What's the kind of like, you know, first steps that a team takes if they want to adopt this kind of thing?

14:05 Leonid Belkind

So when offering such a product, there is a very gentle balance between a being opinionated, this process needs to be done like that, right? When you are, I don't know, restarting a server or checking if a port scan alert, that has been identified by your security solution, is false positive or not. Being opinionated and saying this is the industry's best blueprint to do it is something that many organizations would like, at least, to get from a vendor. And then, of course, they would customize it. So that is on one hand of a scale. On another hand of the scale is the fact that people are not robots. Therefore, every person building an automated version of the process they are undergoing would expect to be able to express their own creativity. So, this entry level into organizations is walking on a very thin line between coming and saying, "Hey, the value I bring you is not just the fact that you get this tool, but you actually get it with out of the box predefined blueprints that get you from 0 to 100 miles per hour, much faster than if you wanted to do this thing on your own, which you could do". On the other hand, it cannot be rigid. It's going to be a huge turnoff for adoption if it is rigid, and people take it as a "Yeah, but in my case, it's slightly different". So this is usually the way to enter an organization. You try to bring in value. It's not just a tool that you could build your own house with. Already comes with, I don't know, maybe the garage, maybe the first floor pre-built for you. So that you gain incentive very quickly, the time to initial value should be extremely quick. But then, unlike many tools, the trick is how do you sort of like go beyond that initial values. We've seen a lot of products that promise you the world, and then you buy it because you needed it for a single use case. And because the product isn't really that convenient to use, you just stick with just that single use case that you use it for. And that's that. And all the huge promises, unfortunately, remain unfulfilled. That is the challenge: quick value with opinionated things. And then this very, very elaborate ability to become customizable to express your own uniqueness, your own creativity. And if that one works, that's what actually bays the road to wider adoption in the organization.

16:27 Miko Pawlikowski

I like how you kind of described it as this thin line. I was, in my head, comparing this to basically, for example, linters, right? You have an opinionated piece of how you should be doing things that, in the grand scheme of things, might not have that much influence because they're opinionated by definition, you know, for spaces versus tabs and stuff like that, right? But there is never a linter that everybody's happy with all the time. So it's always a compromise. And people typically don't really like being told how to do things that they have an opinion about, if you know they don't see the value. So I think what you said about bringing the quick value for them to see immediately is kind of the only way forward really.

17:12 Leonid Belkind

That's a great example, you know, what you got me thinking about how we use linters. And we use a lot of linters internally in StackPulse. And indeed, when I think about the process of us bringing them on boards, I think we got the first push by just, you know, let's say day 0, we had absolutely nothing. And then day 1, we got things that started bringing in some sort of typical traditional conventions, right? About the curly brackets, about the daps. Very standard things. But then the infrastructure that we use for linters is like a meta at linter, in which you can inject various plugins, and then you have a very flexible configuration for different modules. So, for instance, we can now, if I want to add an additional linter to all of the hundreds of our modules of code, we just put it in a central configuration and all the next build starts executing that thing if they are fitting the filter. So today, I think that we are maybe 50/50 when it comes to a ready made linters, be things that are unique to our environments that were important to us. And we implemented it within the same framework. So I think it's a very, very correct analogy where being opinionated gives you a value of being flexible and allowing to express uniqueness is what keeps you going for the longer term.

18:28 Miko Pawlikowski

Definitely. One thing that I noticed when I went onto your website is that you guys talk a lot about reliability. But it appears to be a slightly different definition of reliability than you expect from, like, a server reliability. Basically uptime and stuff like that. How do you define reliability? What does it mean to you in the context of, you know, the processes that we talked about and automating out human error and stuff like that? How do you define it when you say "reliability"?

18:59 Leonid Belkind

I think it's a great question. And maybe we could actually extend it, because it's not only reliability, but in a moment, you will see that we apply exactly the same thing to security and maybe observability. Here is how we define it. From my perspective, what my customer cares about is what I should care about. When I'm providing a digital service, my customer, let's take the reliability example, doesn't really care about the CPU level on my servers. This is my operational issue. If I so desire, I could have a farm of servers, each and every one of them at 90% CPU, etc. Or I could have a much bigger farm where servers are half slacking around with 40% CPU load. That's not my customer's problem. My customer's problem is that when they use my service, they get whatever interface, whether API web interface mobile app, doesn't matter what they're doing, responsive to their requests as they expected. This is where the framework of service level objectives that later on gets sort of like, developed into Service Level Indicators. This is where this thing kicks in. And this is why the reliability of a single point in my architecture, physical server, physical hard drive, virtual network, etc, is not necessarily directly affecting that service level objective that my customer expects me to fulfill. Very similarly, we may look at security issues, right? My customers, when I'm delivering them a service, they provide me certain types of data. So I'm the subprocessor of parts of their data, maybe data of their users resides inside my boundary. And again, what my customers care about is about data privacy. These are the service level objectives that they set data privacy, how I operate around it, etc, etc. Whereas they may take lesser interest in which exactly controls with which exact configuration I use in order to provide them those service level objectives using data privacy. So it's all about what your consumer cares.

21:14 Miko Pawlikowski

Right. So basically, moving from the operational, okay, indicators that we're so used to, to actually defining the reliability that makes sense to your client, right? This is what it's about?

21:26 Leonid Belkind

Absolutely. Let me give you an example. So it comes from one of the companies I worked with very closely, will not name them, but it's a very popular consumer mobile service. And they had one of their main database services on a downtime for 20 something minutes a couple of months ago. And while, you know, it would say, "Oh my God, 20 minutes in the middle of a day per a centralized database server, this must have a horrific effects on their users". And the answer is no, because their architecture included caching of the data, lazy updates, and sort of like, eventually aligned architecture. And that particular outage did not have any effect on their service level objectives. Therefore, there needs to be a very clear separation between the technical, sort of like, indicators and indeed, probably the database administrators should do something about it, versus what the business and the customers care about.

22:22 Miko Pawlikowski

Speaking of outages, though, you know, I love a good anecdote. Can you recall an interesting or funny outage that you went through? Doesn't necessarily have to be with StackPulse. But one that you like, you know, recalling and telling other people about.

22:38 Leonid Belkind

Not as much of an outage, I usually get back to one of my first career positions as a software engineer. This was back in the 1990s. We were developing, sort of like, a user-facing application. And due to its dynamics, the only way for field engineers to troubleshoot it would be via, sort of like, messages, like message boxes that are shown to end users, but message boxes with like very elaborate errors that are being shown to operators. So we did it. The product was in I think its first generally available release. And it worked pretty nicely. But the error handling system was a bit too rigid. So it complained a lot about things, despite the fact that it kind of kept on working. But it "Oh, that file is malformed. Okay, I can still handle it. Oh, I expected here a smaller input. Okay, I can still work". But but you would be getting these error messages quite a lot, just because we were still tuning the product. And then at a certain point, some business critical event forced us to really shorten the timeline to the generally available release. So at a certain point the project manager said "Guys, we will, like, have to cut the release right now". Like, remind you, it was 1995 probably, maybe 96. So in the engineering team, we just said, "Oh my God, this thing is so verbose in these error messages. Nobody's going to like it. Let's just disable them all, like with a single flip of a switch". So we did that. And the response we got about this version, like customers were really telling us "Guys, this product is the most resilient thing we've ever seen. I mean, you can feed it completely bogus data, and it still tries to process it without like airing without complaining. I mean, sure, nothing good comes out of it. But it like really, really tries to do a job". So we were like, "Sure. That's that's the way we planned it, right? It's all pre-planned, pre-optimized. It is really a fighter, a fighter pro". So yeah, that was not entirely an outage, but definitely not something you would do after thinking about it twice. Then again, the customer is always right. And it ended up having a blast with it. So what do you know?

24:48 Miko Pawlikowski

I love how compassionate your clients were. They really appreciated the effort that was made.

24:54 Leonid Belkind

A lot. I'm telling you like we started getting emails saying that we use previous versions of your products and they were a bit snobby, I mean, you feed them something that's a bit wrong. They will start complaining, they will start blogging. And this thing just goes on and on and on and really drives no matter what you feed into it.

25:12 Miko Pawlikowski

Okay, Leo, how does a person get started with StackPulse? Is there, like, a free tier how do you do step one?

25:20 Leonid Belkind

So first of all, yes, there is a free tier. Stackpulse is a service, so we designed it in a way that the initial step would be as simple as only possible. Fully hosted service free tier, anybody could subscribe. Comes with a growing amount of out of the box templates so that you can relate to one of the challenges that we are already solving. Just take the existing template, applied to your environment, and see the outcome. We are increasingly investing only in samples, but actually in how-to movie guides, etc. At the end of the day, our goal is, like I said, we'd like to reach as many people as we can, who wants to automate processes. But unfortunately, currently cannot do this. And we would like to make this ridiculously easy for them to adopt and start automating their first process. We are fully enterprise grade certified service, HIPAA compliance, sock to compliance, ISO compliant, etc. It is really, really easy to get started in any personal or enterprise environment. And if it's not easy enough, please tell us and we will make it easier. We are fanatic about making the adoption of this thing as easy as possible. You know, it's like walking into a store, seeing something that you like and thinking to yourself, "Yeah, that would be more expensive to leave it here than to just buy it and go home". That's the goal.

26:41 Miko Pawlikowski

So Leo, you did name a few drop a few days. So I would like you to share a little bit of a golden nuggets of wisdom with our audience. So two questions. First is: what would be a single highest ROI thing that you did for your tech career? It can be a mindset, it can be a skill, it can be a programming language, something technical. If you were to pick just one and recommend that to our viewers?

27:11 Leonid Belkind

One day, when I was a r&d team lead, I got approached by one of our resellers. Back in the day, I worked at a company with an indirect sales. And they suggested that I go out to a field, and I become a keynotes person at the conference that hosts the users of my product. To tell you the truth, I was scared to death, right? Because I'm an engineer, I'm talking to engineers, and spending half of my day in front of a keyboard and a screen. And suddenly I need to talk to living people, people that may be not that happy with my product, etc. It wasn't an easy leap. But it was the most rewarding thing I ever did in my career. Changed my life, changed the way I look at things and so on. For every engineer out there, take every opportunity, seek opportunities if you don't have them, to work directly with the users of whatever you're building. It is going to change your life. I have absolutely no doubt about it. Full refund guaranteed, if some people are not satisfied.

28:07 Miko Pawlikowski

Okay, and the question number two: a lot of our audience still has decisions to make with regards to their career. If you were to talk to, let's say, a student, or even a kid who looks at your LinkedIn and they say, "Okay, this is very impressive. I would like to be like this guy, when I grow up". What would be your advice to them?

28:27 Leonid Belkind

First of all, my advice would never be trying to be like someone. I sincerely believe that the key to becoming really exceptional at what you do is in finding one thing that you are so passionate about that you simply cannot live without. And it's only when you find this thing, and you start doing it. And because you're so passionate about it, you start doing it a lot, and you start learning about it. That is the only way to get there. You cannot aim at a certain curriculum and just try to repeat it. You know, some people will have that natural connection to what they're doing, and eventually will end up being better than people who are just aiming at that curriculum. So it has to be that thing, that thing that you are personally passionate about. And if you're not, really doesn't matter how well-paid it is, how well regarded it is etc. If you're not passionate about something you would never, in my humble opinion of course, going to be great at it. And that's my advice, right? Never shoot for the curriculum. Shoot for something that you can absolutely live dream about every day.

29:37 Miko Pawlikowski

And that's definitely well-said. Thank you so much, Leo. That's been a real pleasure. If you want to find StackPulse, stackpulse.com is where you go. Otherwise, very good presentation by Or and Eldad at Conf42. How we use open source tools to create Puerta, a gating service for Flagger. And hopefully we'll see you again.

29:58 Leonid Belkind

Same here, we'll be looking for more opportunities to connect. Have a wonderful day.