Resources

Outgrow Existing Monitoring Tools

Video
 

Vess Bakalov, founder of SevOne, discusses the history surrounding SevOne and the benefits of using SevOne technology. Get an immersed view into why SevOne is the best choice for growing companies that need to consolidate existing monitoring tools.

Transcription:

Casey:
It's my pleasure to be your host and semi-interviewer as we are going to have a conversation with Vess Bakalov, the CTO and founder of SevOne. We have primed the prompt with a couple of questions that we want to feed him to get the conversation going, and some of that was in the invite that you guys accepted, so you won't be surprised by those, but we also want to let you guys ask some questions as well. In a second, I will share our Twitter handle and you can tweet questions right to us there and we can take a look and see if we can bring some of those in as we go along.

With that, let me just show you the Twitter address, so it s just at SevOneInc, so if you have something that you want to fire off to us. We're not trying to stump Vess, although feel free to send something that may be of interest. And we have some other good questions lined up for you has well.

I will go to the first visual, and maybe I won't ask you to answer all that one, but as I was saying, as we prep Vess, maybe go back a minute and talk about how you got into this arena, what got you into network management, and take us back through some of that history.

Vess:
Sure, thanks Casey. It's a pleasure to speak to you all. It's always refreshing to be able to have this great forum to interact with the customers, and yes, please stump the chump is fine. Go for it.

How did this whole show get started? It was around 2003 and 2004. I was serving as a network architect at JP Morgan Chase and circumstances were such that I had to step in and own a portion of our network management system. At the time, we had two of everything because of the massive consolidation that was going on in the banking industry, but two of everything doesn't mean that it did the job that well. I had a lot of systems, but they all fell short in different ways but mostly in terms of scalability. We could fix other things, we could create reports in an unflexible environment, but when it came to being able to collect data through an infrastructure that's large, nothing compared to some of the carriers that dominate our daily life.

We simply were not able to do so in a manner that facilitated the speed and the efficiency that the organization demanded of us. That obviously was a very high performance environment, and when you are waiting five minutes for a report, that five minutes is a pretty staggering impact to the bottom line. That's when the idea came around that we are going to create a system for which scale and speed would not be factors, or rather that would be the main driving factors behind our design. That's how SevOne emerged.

Very soon afterwards, we realized that the second most important thing is to have all the data available at your disposal across many different technology types. As we've grown, our customers have demanded of us to include monitoring of different infrastructure types, so from networking we grew into servers. We started applications. We have an excellent NetFlow engine, and this continues to be the case. We continue to trend and add new technology types with every single release.

Casey:
What do you think, Vess, putting yourself in the seat of our customers, you knew first hand the pain of being asked for data and not having it. Maybe I'll segway that into some trend in terms of what you are seeing now. When we see customers, or when you think about architecting us for the future, what are we looking at coming down the pike that you think is going to be maybe the next challenge. If you were in that seat again, you would either be worried about it or hopeful that you had coverage.

Vess:
That is one of the great things. We actually live in interesting times, as the saying goes. Whether it's a blessing or a curse, it has to be determined. We are certainly going through some dystonic shifts in our infrastructure akin to when Ethernet was becoming the dominant player, in terms especially of data center. If we think about what is happening in our data centers today, I would say it's a similar upheaval where there's many competing standards with good ideas. Most of you were around when token ring was competing with Ethernet and certainly can speak to the fact that token ring has done amazing things, but the ease of use was what made the Ethernet the dominant solution here today.

Today things are shaken out. We have virtualization which obviously has created amazing cost savings, amazing abilities in terms of giving us flexibility in our data center, ways to use capacity in a very efficient manner. We have software defined networks taking shape, and whether they are software based networks like some of the companies out there today, or whether they are the more traditional, hardware based solutions with dedicated hardware based solutions that simply have a centralized controller, or whether we stay with what we have always had with individual devices controlling their own destiny. This is yet to really fall out. There is obviously standards from different organizations competing for space. Actually one of the most interesting things that I think will become part of reality very short is the hybrid cloud. The fact is, few people are going to be entirely, public cloud based or are going to remain with all of their infrastructure behind their firewalls.

All of us will have to live in the reality where a part of our infrastructure is going to be in the cloud, part of it is going to be back behind the firewalls, and part of it is going to be in a hybrid cloud, basically what we used to call the DMZ five or six years ago. Now we sort of call it the private cloud. In essence it is really the same thing. All these technologies will have to interact together. Security policies, traffic-shaping policies, and really from our perspective, from performance and IT management, how do we ensure a consistent user security across all these resources are going to be very paramount.

Casey:
You mentioned a couple of trends there. SDN might be on some people's mind. Let's dig into that just a hair deeper for a second because in some ways it is similar to the goal of virtualizing the data center from two years ago, but now it is really extending the idea of being more efficient on a network and driving cost savings. I know you had some passion around founding SevOne in internal rate of return. Can you speak as to how that was part of your make up and you as a network person were thinking about internal rates of return.

Vess:
Wow, budgets, right? I think everybody in the call is familiar with that, and obviously justifiable is budget in IT. You have to justify safe. IT is rarely a primary function of an enterprise. Sometimes it is, but it's great and we have many customers, especially in telecomm space where that is certainly the case. But once we step into enterprise, more often than not IT is a supporting crow rather than the main draft of the business. In that case, really being able to save the business money is how you make the business money, being in IT. SDN comes in and gives us really the opportunity to reduce the cost of our solutions mainly by centralizing the intelligence. In most cases, what we see is, the bulk of our devices, the switches and the data centers, the distribution layer, the access layer, being actually much dumber than they currently are. A lot of the logic is being abstracted out of them and put into a centralized controller. This in itself reduces the cost of the hardware because now we have one centralized controller and we have a lot of much simpler devices controlling the traffic at the edge of the distribution later.

That doesn't mean we are losing anything. Actually the opposite. The controllers are usually much more sophisticated than what we have been able to get in the normal management switch out there based at the manufacturer. The controller now gives us a uniform interface across all these devices. This also allows the manufacturers to concentrate on providing great line rates and the kind of features in the ASIX that really makes the difference in creating nonblocking fabric in our data center force.

We have the central controller, and it gives us a lot of flexibility now because if the standards we are currently evolving come into play, we will be able to use a controller from one manufacture while at the same time implementing hardware from another and give us the best of both worlds. If we really like the switching fabric of one guy but we really don't like the way they configure things, we now have the option to switch around. This also gives us a really good place to start managing things and getting a lot more information, and what's even better, make the information more actionable. Be able to turn the table around and be able to access the data very quickly without having the human factor play so much. Configuration management becomes much, much easier and we can begin to act on the performance data we collect with much greater impact.

Casey:
We have had some folks join us since we started so I will just recap for a little bit. We are sitting with Vess Bakalovk, the founder and CTO of SevOne, and we have a handful of questions we've prepared, but I want you also to feel free to send something in to us at SevOneInc for Twitter. Alex Connors will be manning the Twitter feed and if something pops up, we'll try to work that question in before we go as well.

Let me see what's next in terms of the questions. We talked about trends. We talked about SDN, what should they be preparing for. I don't know if you have any comments on that in terms of what's coming.

Vess:
Oh certainly.

Casey:
Okay, go ahead.

Vess:
Again obviously it is something big we are talking about and virtualization, I wouldn't even say it is something you should be prepared for. It is something that I would imagine that you are already experiencing. The main thing that really comes down the pike currently, and again we are in a time of pretty serious change. A lot of the standard protocols that we have been use to using over time to manage the network, things like SNMP, are not necessarily supported in the kind of depth that we wish they were, by many of these new standards. You look at managing your VMware infrastructure, just to pick a vendor, but it could be another vendor for that matter. There isn't a whole lot available to you in SNMP. There is a lot available via APIs but now those are actually proprietary for manufacturer by vendor. This is where the challenge begins of being able to pick a system that is flexible and able to quickly extend to coverages in new API types and change its inversion because unlike the SNMP standards to pick an oldie but goodie, you're not guaranteed backward compatibility.

As we move into SDN, as we move into much more of this sort of software controlled networks, we begin to talk about APIs because it's a small expense. This stuff is being designed by developers and not by network engineers. The grip on the old standards is loosening a little bit. I am one that personally really likes the idea of having standards, but at the same time, recognizing the current realities such that we need to be able to accommodate various vendor specific APIs. That is one of the red flags I currently see in the not so distance future if you guys are not already experiencing it.

Casey:
Keeping it on the role of an admin or network person for a second. We've had some customers that are somewhat excited by the converging of more and more things coming to the network and IP based, and their experience being kind of that expert is going to grow in terms of their influence in the organization because the network truly is becoming the business for so many customers. In some ways, we'd like to think, hey, that's a great place to be, and we want to support them with good data. Do you see that as a trend?

Vess:
Absolutely. One of the things that we need to talk about is the fact that it's no longer a question of whether your office is going to be paperless. I mean, your office is paperless. If it's paperless, where did all the paper go? It went into servers. Every single function in the organization today is run on the IT infrastructure. In that sense, we are now delivering the core services that are backing the business. There is all these jokes, if we look at Saturday Night Live and our favorite comedy shows over time on office space and where is the stapler and where is the paper clips. The jokes are always that the little diminution of office life are what ends up being the biggest obstacle. There's no more paper clips in our office because it's paperless. Where are the paperclips? Well, it's probably your sharepoint. Your sharepoint is holding all your documents together in folders, and if somebody can get to them quickly and efficiently, it's just as if they just spilled all their papers over the office floor and now they are looking pretty ridiculous in front of their boss.

In essence, the services that we provide and we need to be really understood as such. We can no longer think about Jane has a laptop that gets to the share drive. We need to think about Jane has access to the HR files. And being able to guarantee that she will be able to get to any HR file in a timely fashion, whether she is in a meeting on her iPhone, whether she is at home and just got a phone call about someone not behaving quite like they should and needing an action taken against them, or whether she is sitting at her desk and interviewing the next candidate. All those files need to be at her fingertips, and we need to be thinking about that service.

We're IT guys so we immediately start thinking down to what switchboard she is plugged into, which router she is going through, but this is where your system needs to come and be able to give you the information about Jane's experience without you necessarily having to go through all those steps. If she calls and says, hey, these things are slow. I'm not getting into my files, that needs to be something that your measurement system, your management system should be able to pull up together in a report in a flash and present to you. Also something at the end of the month, you should be able to present to your superiors, and to the rest of the organization really in this case. Let's face it, as IT providers, we are now just as much appear to the management staff as the CFO in terms of providing the service such as, here is how we did financially and here is how we did IT wise. In many ways the information is on similar levels and similar importance in the government of the business.

Casey:
Interesting. Best practices, we may come back to that. Let's get to this one. When you're looking at a monitoring tool or system, what considerations should you take into account as your infrastructure grows? I'm curious if you have any thoughts. If you could be a coach to people out there right now, what would you tell them to look at?

Vess:
Absolutely. It comes down to something very important eight years ago and it's really important today. One of the most important things is being able to monitor everything, because you never know what's going to be important tomorrow. Today you think, oh, I just need to worry about these three, four, five things. I care about my core links, I care about my upstream provider. But it is tomorrow that someone actually decided to plug in a share server by the means of their desk, and you never really caught it because we don't look at access ports, and it goes down. When it goes down, it is that guy who violated that policy and put an important resource underneath the desk. The person who will end up needing to fix it is you. You will need to be able to get those resources back online because they are important to the business. Yes, the guy messed up, but the business relies on these resources, and it is now up to you to get them up and running.

Being able to get ahead, and this is just one example. Being able to get ahead of those very quickly requires that we have the data and comfortably be able to change this proactively. Then we can talk about whether NetFlow can help you do this, we can talk about other technologies, but the main thing is you should be able to monitor everything in terms of the infrastructure.

You should also be able to monitor everything in terms of the technologist available to you. If you have a firewall, or let's say you have your new net scaler device available. You should be able to collect NetFlow from that and be able to do so using all the different custom fields that that device provides, all the new additional capabilities it gives you. If you have virtualization, you should be able to monitor your virtualization provided inside the same system that you are monitoring your network. Being able to correlate the data together from the various systems and the various technologies seamlessly will give you the power to make really informed decisions and be able to give you that end-to-end service picture.

Which brings me to single pane of glass. Swivel chair management is bad. Oftentimes different vendors, for good reasons, may use different terminology to describe similar things. Having a single source of truth, a single communication platform that everyone can get behind, from the desktop admin to the server admin, the virtualization and storage admin, the networking guys, if all of them can draw their data from the same resource and agree on the validity of that data, you are now winning major efficiency points, which are very, very important. That gives you also the ability to leverage, like I mentioned, analytics across the board. As you correlate this data together, you gain insight into the data which separate data points in separate systems do not give you.

Another thing is, find a system that does not depend on scaling the individual piece of hardware in order to scale. It's a long sentence, but I can break it down for you. If you have a system that depends on a centralized database, that runs in a particular house, or let's say the entire sync is a single system solution, as your network inevitably grows, as your IT infrastructure grows, you will need to put more and more things in that system until you eventually exhaust the capability of the house that it is running on.

You can argue that you can upgrade that house, but is that truly always a possibility? Wouldn't it be easier to just plug in a parallel house, another one, and basically have a plug and play upgrade so to say. As you exhaust the current resources you have, if you are simply able to add in parallel to the existing resource another one which appears with it and it gives you still a single pane of glass functionality similarly to what you would so with, let's say, with load balancing across multiple web servers as you exhaust the capability server, you have another one that is a load balancer that is transparent to the end user. That is a very important capability.

As you begin to go through this hardware upgrade cycle where you are trying to get a single host to do more and more, you inevitably incur downtime. You inevitably occur headache. There is always the next bottleneck that you did not foresee right around the corner, much more quickly than your upgrade cycle suggested. You end up going to your boss much more often than you thought you would. Today you're out of IOPS, and you know what, let me get this NAV solution is going to get me the IOPS and it's going to be great, and as soon as you have that you run out RAM, and as soon as you get that, well then you need more CPU sockets, and God forbid, you run the scale across multiple CPU sockets and then you're in trouble, but let's say that now you need to get more of that. Just as you do this, well guess what, you need actually more throughput on your NAV. This is a cycle that is difficult to manage.

You can't really see around the next corner is what I am trying to say. This is where being able to scale in parallel, horizontally, is very, very important, and that's something I would advise anyone to look for a solution out there.

Casey:
I know you told a funny story, too, when you were building out systems that you got thrown a stack of CDs and had to try to figure out how to make servers and how to figure out a database. That kind of led you to an appliance preference and that kind of led to an architecture that I can put the visual up in a second that addresses some of the scaling and ultimately we can talk about platformization, too. Put the visual up, and then you can take us through some of what you've seen in those bottlenecks, and what's the impact of someone who is trying to troubleshoot that ultimately gets hung up by this process.

Vess:
Sure. This is interesting, but one of the systems I used when I was in my previous life required essentially a pretty massive Oracle back-end. Well, I'm a network engineer. I'm not the GBA but as many of you who are network engineers, and this call would attest, you often times would get asked to be the managers also of your network management systems. Oracle is a great system. But there is also people who are called GBAs who are proficient and spent just as many hours as we do in our certifications to achieve the masters of that system. We don't often get access to those folks in the networking department.

There I was, I had my brand new Sun Server. Okay, this was a few years ago. I had my brand new Sun Server and I had my stack of CDs and I called my vendor, my NMS vendor and asked him how should I partition my brand new massive rate that we had just purchased. Two words best with the Oracle that they require. The answer was, co-Oracle. Now obviously Oracle has no idea what the optimal rate partition for the particular application would be, so in a way they told me that basically I'm on my own. That was something that we made sure would never happen with SevOne. That is the reason why SevOne is in appliance solutions. We guarantee the performance of each appliance solution to the extent it's rating of number of elements it will cover. The user does not have to have a database or operating system expertise as they get to install it. Again, if they need another one, they just connect it, it discovers it's neighbors, and they become peers, they become a single pane of glass.

What Casey put here on the board is sort of like the standard design. Most are enterprise systems we see out there. These are enterprise systems. They are not SMA systems because as you can see, there are already multiple devices. Oftentimes what happens here is the job of polling is distributed. There are actually multiple pollers in the network. They all collect data, but they send all the date they collect to a centralized database. As all databases, as the size of this database grows in the house that manages it, it slows down. The more infrastructure you put in, essentially the more you try to get out of the system, the less is gives you because it needs to process all of these data that you have collected in that single house. Some of the bottlenecks I mentioned earlier like throughput on your host, the CPU memory, these all come into effect. You can work around some of those. How can try to scale it, but it is a very much uphill battle. There is simply no horizontal scaling.

We decided we are going to completely side step the problem. We went to a completely horizontal solution where we've created what we called the SevOne cluster. In the SevOne cluster cluster, all of our systems are aware of each other. They are both collectors and reporters, and they share resources both through collection as well as creating the report. A user can log in to any one of them, so actually creating major efficiencies, especially if you are Global enterprise because you don't have to make your users log into system that may be many thousands of miles away and it increases the latency panels, but it also allow you to distribute the reporting cloud to the system that actually has the data. Then as we become bigger and bigger, as we cover millions and millions of interfaces and CPUs and hard drives, we speed up the generation of reports in parallel with adding the capability to get new collection data points. The system doesn't really end up slowing down as it grows because we scale both the reporting and the collection capabilities.

Casey:
One or two more questions from me, and we will be near the end. Just a reminder for folks remote you wanted to send a question in you can tweet us at SevOneInc. As you look at the cluster technology and or goal going forward as a company, and we do like your feedback for those of you who are on the line, but I know you are starting to promote the concept of platformization for us. SevOne involved and had a kind of triage approach where, hey, the more data I can make available to you, the better, and now I think we are at a maturity standpoint where we want to be able to continue that process and get as much data available to our users as possible.

What does platformization mean to you and what could people tracking SevOne look for in the near future?

Vess:
What's platformization? That's a good point. Our customers talk to us a lot, and I just took a trip to California and met with several of our largest customers out there in the valley, and I spent some time speaking to some of our carrier customers here on the east coast. One of the major things that all of us keep telling us is the value of the data that is currently stored inside of SevOne is increasing every day internally to the organization. It is something that they use to make, one of them is making billion dollar decisions on a daily basis, and how their traffic is going to be routed, how capacity needs to be expanded, and what should be prioritized. We recognize that tool is an island. We do some amazing things to help people become operationally effective, to do good planning, but there are models and tasks that simply cannot be done inside SevOne.

This is where we are making a very concerted effort to open up our system, both in terms of being able to ingest data, which I will talk about in a second, but also in the terms of being able to give users a very easy way to get historical as well as real time data out of the system and into different modeling MPI tools out there. We already have a very successful project called xStats, which allows us to import third party database in a text based format. Part of the platformization effort is to provide an SDK so that the community out there can begin certifying these file types for themselves. Speaking of community, we are really working on enhancing our community sites to be able to allow people to share these certifications with each other.

As soon as you get the data in the system, you want to be able to report it in an innovative way. Being able to share report templates is very important, so different ways that people can be able to extract value out of the system through high level reports, very specific reports from different technologies will be sharable. What's even more important there is we are going to try to open our reporting engines to new visualization types that our customers will be able to bring in. As I mentioned, we are going to be adding a pretty massive amount of restful APIs such that with minimal programming, we can extract the maximum value out of the system. Your access to various pages is going to continue to improve. I always hope API would remain in place. Many of you have used it. It is a really good configuration, API, but to get us to the high throughput tasks that have been really demanded, we are going to enhance that with RESTful and even some binary level functionality.

Casey:
Good answer. And my last comment, and maybe you can agree or disagree, but is it fair to say, Vess, that if someone's on the line listening, evaluating which direction to go, or just comparing themselves to what they have, are you comfortable if they brought us, SevOne, their challenge that they could get a good response in terms of what's giving them a hard time? Why are we eager to meet that challenge?

Vess:
SevOne's team is good at solving any hard problems at are there. A testament to that is obviously our customer roster is extremely heavy in terms of those most demanding customers out three who have found the solution in SevOne. Not because we necessarily had it at day one, but because we are the kind of folks who will step above and beyond to solve those problems. Big data challenges, being able to extract value out of massive data sets is obviously something we do extremely well, but even when it comes to literally any part of the IT infrastructure, it is simply our passion, Casey. It is difficult to almost express in words, but it is what we do.

We are committed to being able to solve the hardest problems out there, but what's even more important is to be able to deliver the most value for organizations, especially when an organization already knows what the pain points are. They know that if I can only solve this, I will be 10, 15, 100-percent better at it than I was at it before. This is the kind of thing that simply lights us up and makes us ready to go.

Casey:
Perfect. You hit the word I was thinking about but obviously the passion thing comes through in terms of your energy in solving these problems.

Vess:
Just to give an example, we had a customer come to us not long ago, maybe like eight weeks ago, they are a big carrier, and they wanted to be able to track their customer's information to an MPLS cloud via NetFlow. As most of you know, the more you hit the MPLS cloud, you know the source and destination of your traffic hop by hop, but you really don't know what it is outside of the cloud. I don't really know the customer's end points on the outside of the cloud once I measured traffic inside the cloud. It's the kind of problem that most people would shrug and say, you don't. That's how it is. That's how it works.

This is the kind of thing we do and don't take no for an answer. We retrieved from the customer mapping of the external IP addresses to the MPLS stacks inside the cloud. They keep the tag consistent hub by hub for each customer, so what you are able to do is as we received the netflow, we make a look up for every flow of the tab against the IP of the customer and we add not just IP but actually the customer name straight up inside the flow. Then we pass it on to our collector and processed further. When the customer runs a report they can actually see the traffic per customer in their MPLS cloud.

Something again most people would say can't be done or isn't done, and we do this by the way, as I said, in a carrier MPLS cloud. We are talking about multi-gigabyte speed links. This is happening at rates that would cloud the mind to most of the other competing vendors. This is the kind of thing we are extremely, extremely good at.

Casey:
Good. Good line to finish on. We've run over by just a couple of minutes, but I appreciate everyone's attention and staying online. Certainly, still, if you have questions we can get back to you and answer individually. I'll put up our Twitter address one more time just so you can see it. Please send us those questions, and you can also follow Vess directly. What is your Twitter handle, Vess?

Vess:
All right, so get ready to start here, guys. It's @Veskoteque, V-E-S-K-O-T-E-Q-U-E. Feel free to hit me up anytime. Feel free to tweet @SevOneInc, which is much easier to spell. And I would definitely pick those up and answer them as well, so no worries.

Casey:
Question in under the wire, so if you need to drop we understand. But someone did just send a question in terms of a trend on agents versus agent lists and some of the probes and wanted to know your thoughts. Which way is that going to go from an industry perspective? Are you going to see more agents? Are you going to see less? What's your thoughts?

Vess:
I am a big bias on the agent list angle. I do think agentless is the way to go, as least unless you really, really, need an agent. I say this with my operational hat on my head. The fact is, deploying agents is very expensive. You need to go to every host, even if it's a centralized deployment. It's still something that needs to be managed. It costs money. It's not free most of the time. In the same time, the data that agents provide can go into depth much higher than what we have historically seen, being able to get being agentless.

It kind of falls into two camps. The question is, is it worth it to you? That is a little bit of a business decision. If it's worth it to you to go through the extra pain to get the agents installed, then SevOne is more than happy to leverage that data and display it in our interface as well. One of the good things we see is the capabilities in the end devices are growing tremendously. As we get virtualization out there, it is deployed much more heavily, and we are getting a lot of the benefits that traditionally only were when the agents were young. I see agents as being helpful today, more in application management than necessarily infrastructure management. By all means, there is a huge role to be played there. Again, there are some words of caution because if your agent thinks to can't handle that inside the application, you can kill your performance, which is what you are trying to increase in the first place. I guess it is a nuanced answer.

From a SevOne perspective, we have traditionally been very much agentless. But it may be something that, given the proper demand in the market and if there is a need, that simply can't be sorted of any other way. It may be something we move on as well.

Casey:
It almost becomes a business decision.

Vess:
It very much is.

Casey:
Can you live without the data that some agents can give that you can't get from a remote perspective? Our peers, our customers, our folks online, they have to become justifiers to say, well, we're going to go without but we can get 80-percent of the picture agentless and is that okay to the business owners.

Vess:
This is one of those great follow up questions that you guys can feel free to hit me up with is, describe your business case. I'll be more than happy to talk to you, so see if there is a way to do it agentlessly, and if there isn't, we can talk about what can be done.

Casey:
Okay, good. Well, thank you all for giving us some time on a Friday. Enjoy your great weekend and send in other questions for the future. We do these webinars. Demos with Dave will be back as a regular product demo in two weeks. I believe the topic may be on our support of Cisco UCS servers or it may be an F5 focused one. We'll promote that back out in the next couple of weeks and let you guys know. Thanks of your time today. This will be recorded if you know of anyone that needs to get it. We'll send that out as well. Enjoy the rest of your Friday.

Vess:
Thanks for you time, guys.