Live from Las Vegas, it's theCUBE. Cover EMC World 2016, brought to you by EMC. And welcome back inside theCUBE here in the Sands Expo at EMC World 2016. I'm John Walls along with Dave Valente. It is a pleasure to welcome now to theCUBE set, Mike Bishop, who's from Pression, the chief systems architect there. And Mike, welcome to the show. We appreciate your time here. I'm delighted to be here, thank you. Tell us a little bit about Pression, if you will. You're Chicago based and I know of risk management, risk mitigation, but tell us a little bit more about your core mission and focus. Sure, well, about seven years ago, we got into business in the federal space. So we still have an existing practice down in McLean, Virginia, headquartered there. But just this last June, June 2015, we opened a new commercial headquarters in Chicago, Illinois. So that was part of productizing a number of services we've provided in the national security space for private sector use. So one of which is traveler safety. We also have a due diligence practice. They're all based out of Chicago. And then data that you're bringing in from where and then for what? Yeah, so the impetus really for what we've come to market with commercially is, was we were approached by a law firm that was very concerned about duty of care for people traveling around the world, both from a liability standpoint and also just traveler safety, helping them avoid danger. And so we looked at existing offerings of what helps keep people safe and realize that no one was using technology to really gather that information. And so the first thing we built to answer your question is a big data curation system that helps us identify where information is available that relates to the safety of individuals and companies for that matter. So right now we've got about 41,000 sources of information indexed. They range from social media to RSS feeds to news broadcasts, to forums and blogs, news articles. And so we're doing a lot of natural language processing to figure out which of those are relevant for specific locations. And then most importantly, figuring out which one of those or which of those sources relate to the individuals traveling. So we send them the alerts that relate to them most. So you're basically building a machine intelligence engine and then your end point is the individual. Yes, but there's a lot of human in the loop analysis as well. What this curation system does is across those 41,000 sources I mentioned and we had about 150 a day. Is it percolates up what's most relevant for a given area and for a given types of people and for given threats. So we've modeled various threats to business continuity and personal safety like physical, health, environmental. And so for a given location across those 40 plus thousand sources, you might say what are the threats for cyber monitoring or cybersecurity in a given country and there might be just five. And so that's what's relevant. And so that allows human analysts to focus a much more tightly on what's relevant for people in that area. And saying that humans are the last mile of fires. We are, the phrase we use is we humanize intelligence. No one was looking at traveler safety and risk management in a contemporary fashion using the technology that we've invested here that allows them to aggregate data in such volume. But the goal is really to still put it in front of a human analyst. So we have geospatial analysts, we have threat analysts that are looking at geopolitical instability, crime and it's all data driven. So we figure out where in the world there is and down to a city level, a street level. And that's what the mobile app provides is proximity alerting as you get close to these areas where there's actual danger. So that domain expertise is still critical. But you can't scale without that software infrastructure. Right, and traditionally what happens is companies will send a threat brief to a traveler before they go to someplace and it's 30 pages long and it's six months old. And so it's not really well tailored to the individual that's reading it. It's more than they can really ingest if they even have the time for it. And so what this does is put it into a very concise package and again, resonate with the individual. So down to actual demographics, the attributes of the traveler, so a female going to someplace is going to get different alerts perhaps than a male. It's not an exact analog by any means but you think about fraud detection in the last several years and how that's really moved to real time. So presumably you're getting as close to near real time as possible. We are, and in some cases it is real time. Like with an RSS feed, we're subscribing to USGS and weather alerts, those are highly structured. And so if there's a tsunami alert or an earthquake, we have a latitude, longitude, a magnitude, and we can send out an instantaneous alert to people that are in the affected region as well as to the security stakeholders that would want to know. So paint a picture of how you're doing all this stuff. What's the infrastructure and the architecture look like? Sure, so primary components, we're running SAP HANA for real time. Geospatial and linguistic analysis helps us perform sentiment analysis to figure out if people are saying good things and bad things about people we care about. But also entity extraction, fact extraction, HANA is a big part of that. Geospatially we're correlating where threats are at in proximity to travelers. And so all that traveler data is in MongoDB. And so we have a number of web applications, some of them mobile applications, some are like a dashboard, a secure dashboard that provides accountability of where people are at. But we take that positional data that's coming out of the mobile app and bounce it off threat areas that we've persisted actually in a post-GIS database. So we have geospatial threat analysts using Esri ArcGIS as well as QGIS and open source geospatial framework. And they're persisting these big polygons that say here's statistically an area of town where bad things happen. So then there's also Hadoop, an integral component of our data lake. And from a hardware perspective, we're running Icelon and Extreme I.O. So that's an example of that that I often use is when we're making snapshots of large chunks of textual data like social media and running sentiment analysis. At one point we're just kind of testing the throughput. We did about 350,000 tweets per minute for sentiment analysis.  You subscribe to their service. We are and we also use Apache NiFi. I believe we're one of the first companies to use it for real-time aggregation and curation of data where we have a number of processors that have been written that allow us to again extract what's being discussed in RSS feeds as it relates to those three threat domains that I mentioned earlier, physical health. And are you looking at Spark? Are you using Spark at all or? A little bit, yeah. And we're really just scratching the surface on some of this technology. I mean, the core components that I mentioned, we're using SAP HANA smart data access and a number of APIs that we've developed ourselves. But yeah. So HANA gives you the in-memory piece of it. In-memory color data store. So Spark will be redundant to that. But there are things that we're looking at what we can do within Hadoop and Hortonworks is an integral in helping us kind of broaden our horizons in that. And the NLP is embedded in HANA? Yeah. So that's really one of the major strengths in that, you know, in 33 different languages that can perform entity extraction based on our own object models, our own definitions or keywords. So those main threat domains I keep referencing in terms of physical threats, health threats, environmental. Those are broken down into a number of factors like physical crime, civil unrest. And so there's a number of keywords associated with each one of those. And what we do when we scrape all those sources I mentioned before, thank you, is we actually persist all the corpus of text. And so the things we'd like to begin doing with that in the future, far more advanced natural language processing algorithms, one of which our data engineers playing with right now is word vector to look at the kind of the semantic proximity when you see this, what else might you look for when you see this word or this phrase? And that's another reason to be persisting this large corpus of text was we ingested. Yeah, I was thinking, Mike, you're talking about 140,000 some sources from which you're drawing data and you have federal agencies with whom you're working. That I'm curious, are there any secure sources, confidential sources or top secret sources of some type that require a different layer of protection or consideration within your system that you have to be wary of because it is the federal government with whom you're working. Sure, excellent question. Everything we're doing for Prussian Traveler, it's the name of this particular offering that we've been describing is for the private sector and so it's all open source information. However, we are working very closely with NS2. It's a division of SAP that works specifically within the intelligence community, which is again where we came from six, seven years ago. And so there are a number of intelligence community customers that we're looking to help with these capabilities and that means tapping their sources as well. We still do have a number of federal contracts that involve classified sources, but they in no way come in contact with what we're doing on the commercial side. One of the complaints that we hear a lot of course from Hadoop practitioners is the complexity and they spend more time wrangling the data and getting it right than they are able to add value. What are EMC and I guess Hortonworks, I guess they're partnering on this, what are they doing to make that complexity simpler? Well, Hortonworks sent out an engineer that sat down with our developers and helped us stand up the clusters, figured out what we really did need based on the type of data we're acquiring, what we need to do to transform it into a form that we can access across the data lake. And I often refer to Isilon as this connective tissue that allows us to touch these different repositories regardless of where the data came from, but Hadoop lives, we're also running a VBlock so we virtualize these clusters and so that data transformation process is something that is an ongoing, not problem, it's just one of the jobs to do. Anytime you identify a new source you have to figure out how to structure it so it can be accessed by other queries. So it's interesting to hear you talk, right? Because in the early days of Hadoop, it's like, oh yeah, it's just all commodity hardware, scale out, white boxes, anybody's storage, go to fries, you'll be good to go. Hadoop obviously has entered the enterprise realm. So you're talking about VBlocks, you're talking about Isilon. So you're using a lot of modern but traditional-like infrastructure. Why? You can help the audience understand that. Sure, well, what we wanted first and foremost was flexibility, this was a Greenfield project. When we started looking at this roughly 18 months ago, there was nothing else that existed like it, so it wasn't like there was a template, but we also didn't have legacy systems that we needed to worry about integrating with. And so we wanted to go with the systems that afforded us the greatest flexibility and so virtualizing those processors was a core requirement. But we also didn't have really insight into what the kind of volume of data or what the throughput would look like and so we wanted to do what was most flexible and really in working with Hortonworks, they've been able to keep us very agile in terms of what types of data we can access and also they recently acquired on Yara and so with NIFI playing a major role, I refer to it as a data manifold and it's through NIFI processors that all of this data is conditioned and ultimately that's kind of the edge for our ETL or extract transformer load.  So you're never done, right? It's a continuous improvement cycle. When you think about continuous improvement, you said 41,000 data sources. Do you have limited resources like anybody? If you have 100 bucks to spend, do you spend it on ingesting more data or do you spend it on improving your algorithms and that piece of it? First and foremost, I would look at the optimization of the algorithms but that's where NIFI over time as we really have this thing in practice is going to allow us to tune that because one of the things that NIFI gives you is provenance. You know where it comes from but you can also look at those elevated threat areas that are drawn on a map and say, what specifically were the data points that resulted in that being drawn? Was there crime statistics? Where did it come from? Were there incidents being reported at a per capita by some NGO or some government? Where did they come from? And then you can say, well, these other sources weren't relevant to that and so it allows you to really cull your sources and so that's one way you can limit bloat and limit tracking feeds that maybe aren't paying off but you can also then use those that's the same data points to corroborate and kind of validate the veracity of information which is very important, obviously. Is there a crowd source component to this today or in the future? I mean, in the future, absolutely. So within the mobile application, beyond giving a user the ability to selectively be monitored if they want, they can have a low resolution monitor where we literally truncate the GPS coordinate before it comes back to the dashboard. So you just know generally where they're at plus or minus a few miles. But we also have alerting mechanisms where they can actually say, this is a suspicious area, I feel unsafe. I'm looking at violence in the near area whether it's like a Ferguson riot type situation and that's information we can pull back in and so that's one component of crowdsourcing but then within the mobile app we're also thinking of adding things like literally just in areas where it's data sparse. There's not a lot of information to support anything other than maybe overhead imagery analysis that we do a lot of. You could literally probe people and say, do you feel safe here? And it's just a yes, no. And that would be a crowdsourcing kind of survey mechanism that would be a feedback loop for on the ground. Mike, I probably should have asked this because it hit me early on and we went down a different road. But when you're talking about threat levels and threat areas and what have you, how is what you're doing different than what something like the State Department would do? We hear about issued warnings and what have you. I mean, what granularity of data do you have at your disposal that perhaps they don't or how do they dovetail? Well, this is where it truly is unique. We look at the individual person that's using the application and based on their own profile, where they're from, Des Moines, Iowa, mail of a given ethnicity, given nationality, that person has every threat score that they see relative to their home location. So you always have a baseline. No one else is doing that. And that I think is a very elegant manifestation of the power of big data. As you can say, all right, you have all the statistical information and you know where threats target individuals, where threats are likely to manifest against a given person or type of person or a given company based on these attributes. So report them relative to their home environment. And so every threat assessment they see, I mentioned the verbosity of these longer reports that traditionally get sent out, we just have a bar graph to start with. You can click on it and see more data, more information, and see an analyst annotated report that's still only as long as your notepad. You know, this was one page here, but it's very concise, but it starts with literally a bar graph. Compared to your home location, it's this much more dangerous or this much less dangerous. And so you immediately know, do I need to ratchet up my level of vigilance or is it roughly about the same as Des Moines? And so that's very unique. No one else is doing that and it's all based on attributes. And the business model is selling the app or is it selling the data? Well, we do have an API, so companies can subscribe to the data itself, but the application is a service that we provide for monitoring and the real-time threat reporting. So we've performed several hundred assessments around the world. In the not distant future, we'll have every city more than a hundred thousand is probably going to take us several months to get there because the level of effort that goes into the human analysis, sometimes which involves this overhead imagery analysis and looking at disparate data sources where you have a lot of gaps. So there's a lot of work that goes into building those street-level maps, but that's all available through a mobile app. And so it's based on a month-to-month fee that they pay to be. And an individual pays or an organization or both? Either one, yeah. So we have the mobile app both for iOS and for Android and then for security stakeholders that have traveling teams of employees, whether it's 10 or 10,000 or 400,000, they have dashboards that can be deployed at a site level or at an operations room that provides that real-time accountability of where the people are at and also the ability to interact with them. So a Boston Marathon bombing, they can immediately geofence an area, send out a sign-of-life message request, everyone checks in with their PIN number and you immediately know of my 13 people there, this one needs help. And so that's again something that really differentiates what we're doing. It's fascinating stuff, it really is. And I think when we talk about it a lot at this show and many others, but technology impacting business, in this case, the business is saving lives. It is. Fascinating application. Mike, thanks for the time. Appreciate it. Thank you. That's the light going forward. Mike Bishop from Prussian in Chicago. That's it for this edition or at least this hour here on theCUBE, back with more from the Santa's Expo in just a bit. We'll see you then. It's always fun to come back to theCUBE because, you know,


Anyway, hello everyone. Thank you for coming to this session. I'm really excited about it because my name is Ryan Floyd. I'm an early stage venture investor and I work with a lot of companies and one of the common things that I deal with every single one of them is how do you get those first customers? You know, it's so hard. How do you get the first 10, the first dozen, the first 30? And then in addition to that, how do you figure out who to partner with? You know, especially now in the open-stack communities, it's really matured. I mean, you know, three years ago, it didn't have the large companies that were such a big part of it as it does now. And so I think start-up, small companies, it's really important to figure out how to partner. So we've got three great guests here today. We'll walk through really how did they do it? How did they get their first customers and talk a little bit about how to figure out how to partner. So why don't I just go online and let you guys quickly introduce yourselves and maybe just a little bit about your company, but keep it very short and then we'll get into it. Sure. Thanks, Ryan. My name is Francesco Paola. I'm CEO of Selenia. We are a software and services company that helps enterprises adopt open-stack and overall open infrastructure as well. I can probably hear you. The self-distributed storage system. Now I can really hear myself at school. So partnerships and stuff. So we have a mic here. So please let's make it interactive. We've got 40 minutes, but I would love to hear your questions for the folks here. So please jump up, raise your hand. You don't have to wait till the end and get involved. So maybe, Francesco, let's start with you because I was always amazed at the caliber of customers that you guys were able to get at the very beginning because for most startups, no one really trusts you, right?  You guys didn't even have an office. No, we didn't have a lot of other things. Did you even have a phone number? No. So how do you go from that to convincing a company like Hyundai to do work with you? Sure. So first of all, my co-founder and I, Ken Pepple, saw an opportunity in the market. I spent 18 months at Cloud Scaling. Cloud Scaling was one of the first services companies to help organizations adopt open-source technologies to build clouds. So one of our first customers was actually Korea Telecom. Then we worked with Samsung, worked with AT&T, and as you all know, Cloud Scaling decided to move into the distro space and kind of let the services go. And we saw this tremendous opportunity to help organizations accelerate their ability to use this technology. And so Ken and I started the company in January 2013. And before we started the company, we started making some inquiries with our former partners when I was at Cloud Scaling, when he was at Internet. And one of our partners in Korea actually said that there may be an opportunity at Hyundai, the fifth largest car company in the world. And we're like, well, let's try.  We actually didn't take a salary for about four months, but we brought some money in the door so we could actually pay for some of the logistic requirements and whatnot. And we got a phone call one day from our partner in Korea and that Ryan knows very well. And he said, look, I know you guys are just starting this, but if you can be here in a week, I can get you in front of Hyundai. It's the right people. I'll be there to support you. And I said, sure. So Ken and I looked at each other and we're like, we didn't even have a name for the company. We didn't have a name. We didn't have a logo. We had nothing. Just Ken going out at the time in Moscow of all places to bring some money in the door. And so we said, look, let's get something going real quick. And we said, let's try to come up with a name. So we went through the, and you've seen Silicon Valley. Actually, that's actually what happened for us, right? We threw some names on the board and we said, yeah, we like this one, this one. We went to the URL. There's no URL. We're like, time was running short. We said, let's pick, let's use a URL that I had from a previous company and let's use that for now. And then we'll change it. We'll change the name because we need something right away. And then we're like, well, we need a logo, crowdsource the logo. 99 designs in 48 hours. We got a logo. We like that one. We'll take it. We need a website. And Ken said, okay, I'll put five pages together. And overnight, he had a website. And in the meantime, I'm writing the methodology to give a story to actually what we were going to be doing, right? Business cards, FedEx Kinko's 24 hours, we got the business cards, use my home address, doesn't matter. I get on a plane. I get to Korea, I meet the client and based upon, of course, I had to put a pitch deck together on the flight there. But based upon the the partner that we had, and I'll explain the partner when we talk about the partners based upon the partner relationship based upon the credibility that Ken and I personally had in Korea because they knew that we work with Korea Telecom, they knew we'd work with Samsung. They actually made inquiries. We had letters of reference written by KT and Samsung in terms of for us personally, not for our company, to vouch for us. Three months later, mid April, actually, the project kicked off in the middle of the Portland OpenStack Summit.  But, you know, 18 months later, and millions of dollars later in revenue, there's still a customer of ours, we wrote a case study, which is available on the Open Stack.org website. But the key there was the fact that we were very, very focused on the end objective. The end objective was to portray ourselves as high value providers of services as experts. We had the backing of former customers, even if it was prior lives, that they were willing to vouch for us. We were very, very focused on quality of how we presented ourselves and quality of the work that we've done in the past and to portray that quality using case studies, for example, and ultimately the relationship that we had on the ground work. But it was it was a fly by night operation. But even if it sounded fly by night, we knew what we were doing because we knew that what was it was important to a customer like Hyundai. They needed to trust you. They needed to build a personal relationship. They needed to see that you were for real. It wasn't just a couple of concerns. It wasn't just the Ken and Chesco show when we got off the plane. And ultimately the trust that we built in those few weeks of meetings and discussions and having the partner there really helped us to see the deal. It sounds like if I was to blow it out a little bit, there was there was kind of the fake it until you make it part of the strategy. Yes, exactly. And and then really pulling on some of these relationships that you had with prior customers to really push you guys forward. Adam, how about with you? I mean, you guys have been at it for a little while now. Yeah, what is some of the secrets? I mean, in terms of how did you get, you know, convinced those first customers to take a take a risk? Yeah, for us, for us, it was a it was a long journey. We started back in 2010. And, you know, we're a technology company. We had to invest several years into getting our network virtualization to a point where it was ready for production, right? So when we started going after those customers, you know, finding the first one to take the chance on us is certainly very challenging. We had to end up, you know, going after the ones who are also willing to take a risk. And it's a risk for us as well. So we ended up going with, you know, a startup who is basically doing a the first open stack public cloud in Norway, Zeta IO.  And he, you know, didn't have funding yet. And but he had some some previous customers from his previous work. And he, you know, was trying to build this open stack cloud. And was there a prior relationship there? Or how did, you know, no, no, it just he, you know, we were involved with the open stack community for quite some time. So I think that he found us through the community, looking at the options that were out there, who's working on networking in open stack.   And, you know, of course, we QA it and we run it on internally but doing it, you know, doing it live with real customers, where he has customers paying him was kind of scary, right. So that was that was the challenge for us to get that first small customer. But then, you know, they become a reference. And they will talk to the other people that we're trying to get to use our stuff and kind of slowly build from there. And that's kind of how we've done it from a lot of word of mouth. So start from one, it scales out, you know, very slowly and then starts expanding to more and more reference accounts. And so exactly. So, you know, we've got fake it till you make it. We've got, you know, leverage all the relationships you've got. Sorry, I don't mean to trivialize that.  Right. And maybe don't be picky about those first customers, you'll be able to use those as reference points. That's right. You know, going forward.  Your mom, your dad, which dream host, for those you don't know, ink tank came out of, you know, dream host. So, so, but I guess you could still use it as a reference. So is that part of what enabled you guys to grow so fast? If you take dream host as the kind of creator of the use case of what we're trying to solve, which was very much there, and particularly trying to solve storage problems in an open stack context, what we wanted to do is deliver an elastic block store that was available to open stack customers. There was no real project that was available that could do something like that. And at the same time, internally, Sage Weil, one of the founders of dream host had spent the last eight years of his life building this amazing distributed object storage system that could do block and file an object all in one. Our requirement was if we're going to use open stack to build a cloud, that we're going to use stuff to back that to be the storage layer of that cloud. So, you know, even before ink tank was a company, that was my goal. And I was the GM of emerging technology as a dream host at that time. And, you know, the big part was trying to figure out what platform we decided to pick. And we looked at all the different platforms that are available and realized that the only one that we can really influence and felt that had longevity in it and had the right open source credentials at that time. We were pretty picky on what we meant by open source was open stack. And it was in a maturity phase where we were immature, open stack was immature, we can kind of grow together. It was a good bet. And what happened was when we made that decision and started getting involved in the open stack ecosystem, everyone who was involved in the open stack ecosystem started coming to us and saying, we'd like to use SAP to be a lost block store in your cloud, to replace Swift as object. You know, and that's what really kind of started getting us going. So those proof points were really important. So by the time ink tank was founded as a company and it split off as a separate entity, we already had a list of people that were lined up to be our customers. So we hit the ground running because there was eight years of work that went into it. Plus we found a really interesting market fit and we solved a real problem which wasn't being solved by traditional means. Cool. So another interesting part of your story, though, I think that, you know, just maybe transitioning a little bit. I mean, with with ink tank is, you know, one of your close kind of partners, customers was Red Hat, right? So, you know, tell us a little bit about how that worked. I mean, talk a little bit about partners. Yeah, yeah, sure. Yeah, it is a little funny working at Red Hat now and being in charge of storage partnerships, particularly when you're kind of in the other side of the house. And we were partners with the RELL OSP team, the guys that deliver the RELL OpenStack platform. And, you know, they have a fairly wide ecosystem of partners and a lot of them are different storage partners. They have met up as partners, they have scality, they have, you know, they have solid fire. And we were also one of those partners that were like, yes, we would like to plug into Cinder and become an official partner of Red Hat, so that if we have joint customers that we can support each other. At the same time, there was an internal division within Red Hat that was Gluster and we competed against them and they marketed us against us as well. They saw a lot of traction happening in the SAP product and they were putting out marketing material to compete against us at that time as well. And it got a little tricky, you know, we were trying to figure out how do we partner with a company and then they also have a division that kind of competes with us. The good thing about the Red Hat is very clear is that the lines were, you know, pretty clear between how we interacted with RELLOS-B. The RELLOS-B folks said, look, we're interested in building an ecosystem. They never stopped us working with them. We never really had any tremendous issues on that side. But we also just knew that out in the market, we would have to face Gluster and answer some hard questions on how we performed against Gluster and where we went. And at the end, I would say that, you know, our growth continued to go up and we became an attractive acquisition. And Red Hat decided at some point we would like to have Ink Tank as part of our portfolio. So now I represent the storage BU as well. And within the BU, I deal with partnerships with SAP and Gluster. So my job has kind of changed a little bit. Sleeping with the anime. So how about just, you know, from I'm interested in, any of you guys can take this one. I get this question a lot about, you know, good customers versus bad customers. I mean, when you don't have any customers, I mean, any customer is a good one. But can you give us some insight? I mean, as you learned, you started to develop some of these, you know, some of the customers and grew the business. What's an example of some, you know, a bad customer? Is there such a thing when you're starting out? And if so, what are some of the characteristics of a, you know, maybe I shouldn't say bad, tough, tough customer, maybe not best for the business.  I mean, the lifeline of a company that makes its living on primarily on services, which is what we do today is to handle the customer. I mean, there was when I was at a previous consulting company, high level IBM executive came over to be the CEO. And he said there's three rules to consulting. It's number one is handle the customer. Number two is handle the customer. Number three is handle the customer. Right. And so not all customers are perfect, not all customers are great, but ultimately we need to understand is how can you align their objectives and your objectives to achieve the same goals. And that's ultimately what happens more often than not when you are in a challenging situation with a customer where you're not setting the appropriate expectations. For example, you're not making sure that the right people in the organization are getting the right credit. There's many things that you can do to right a wrong. Ultimately, sometimes you do have to walk away from a customer or you get kicked out of a customer, which has happened many times, not at Selenia, but in prior lives. But ultimately, you do have to make sure that goals and objectives are aligned, that you're always communicating, that you develop a relationship. And ultimately, whatever is in the contract, the lawyers will say holes. But ultimately, if you have that relationship, you can work through major issues. And there's always a give and take. I mean, so that's that's for us. It's always you're always on 110% with a customer. You're always in negotiation mode because everything's a negotiation with them. And ultimately, as long as your goals are aligned, you will get there. Yeah, one of the things I've been talking about a few times with some people today is, you know, this is a marathon, right? And we don't know how long it's gonna take until we get to the point where we are really, truly successful. Where our company is very tied to the to the speed at which OpenStack adoption grows, right? It's fortunately, you know, this year has been great. We're getting a lot of new customers. We're seeing a lot of new deals coming in. But we still aren't sure, you know, at what point will OpenStack reach kind of the mass market? Startups have a limited runway. And I think Medocorp is in an interesting position because we didn't take typical capital from a venture capital firm. We raised money from some strategics and primarily from a Japanese government sovereign fund. Their outlook on returns is much longer than a normal venture capital firm. So it has allowed us to say no to some of the opportunities that come in, which may be a bad idea. You know, we had conversations with a very large internet company who wanted to do a project, you know, it would be multimillion dollars per year. But they wanted us to re-architect our entire product for their use case, which probably only fit in their use case. For a starving startup, maybe it's very hard to say no to that, right? I mean, that could keep you going, pay the bills. But at the same time, you end up going down a path and you may not be able to turn back. And your product may end up only working for that person, for that one customer. So that's something that I think we were fortunate in being able to walk away from, that not everyone has the ability to do. So I think one of the important things we're learning is we have to be very careful about how fast we scale the startup. We can't just hire a ton of people and hope that the business comes because we may run out of money, right? So I think that's one of the interesting things that I've been thinking about recently that was kind of fortunate. There's some negative aspects of the way we took funding as well. We don't have all the great connections that a VC from Silicon Valley may provide us. But it did allow us to basically turn down some opportunities like that, which I think in hindsight would have been a bad idea. Yeah, so trying to keep the business scale to the opportunity set and then I think also the employee size. I mean, Sir Chesco, you got to deal with the same thing. I mean, you know, with mainly services, you got to have bench strength, but you don't want to have 30 folks on the bench and not be able to feed the family. I mean, it's yeah. Exactly. Exactly. So it's a delicate balance.  We actually been very diligent about growing the company at a measured pace. We're trying to grow faster now, so we're looking for outside funding. But ultimately, Adam's completely right. You can't sell your soul for the purposes of revenue, even if you're a services company, right? It's better to take your foot off the accelerator from a growth perspective and stay true, because ultimately, we had opportunities to go and work on cloud stack projects. And I had done that when I was a cloud scaling. But we knew that we needed to be true and stay true to our mission and our goal, which was to become the premier provider of services around the open stack ecosystem. And we stayed true to that. But but that's there's a compromise there as well. Did you see that Ben as well at Ink Tank in terms of some some tricky customer situations that you didn't want to take on? Well, I'll tell you straight up, we've signed some awful deals. And I think it's OK to sign awful deals. What made an awful deal? Well, there's there's a lot of elements to awful go. I can get that into a second. But I think you got to understand what the goal is when you're small, right? If if your goal is growth, if your goal is customers on the board, relevance, growth, then maybe you optimize to be able to get those things as long as they fit within your category of this is a customer that, you know, fits my mission can prove that I've hit certain milestones. When you're in midsize, you know, you change some of that, you you might say this particular type of deal is not scalable. I can't do this long term. I'm going to deprecate this product line or I'm going to change my approach over here and do something a little bit different. When you're a big company like Red Hat, you can't do anything unless you can have it scale out to, you know, the eight thousand people that work in this company be pushed out through the sales force and through the channel and sold in a completely different way. So there are things that we could have done. Nimbling is a startup that we wouldn't be able to do otherwise. So it isn't so much the elements of the deal. It has more to do with what stage size what size company are you in? What are your goals are you trying to achieve? What's the thing that's going to get you to that next milestone? And startups have this built in funding milestone unless you're super loaded that it's a good it's a good health step to be able to say to yourself as well as the rest of the world. Yes, I am achieving my targets. I am validating a market. I'm hitting the growth targets I'm interested in. If I continue to go at this rate, you know, if the metric you're looking at is is profitability, then you can push for that. If the metric you're looking at is customers, you can push for that. If there's some other metric that you have that you're that you're looking for, you push for that. But you can sign some pretty awful deals.  I'm sorry we have to let you go now. Go in peace.  Yeah, I mean, it's tough. It's honestly a little bit tough because it has nothing to do with, you know, you not valuing the partnership or the relationship or anything like that. It has to do with your your goals. Your your goals as a company and you're trying to achieve what you're trying to do. Yeah. So it changes a little bit. So so, Adam, I wanted to talk more about partisan. I was wondering from a customer strategy standpoint, was was open sourcing minor not part of that strategy because it's sort of unique where you you did that kind of later in your life as a company, right? So it quickly kind of tell folks that that help accelerate the gain of customers. And it was an interesting trick. Not every company can do that, obviously, but I wish I could say that it was a brilliant strategic move to wait until a certain timing. But probably the timing was would have been better if it was earlier now in hindsight. But but, you know, we definitely were all of the people, most of the people at the company did not have a lot of open source experience, but they did see that, you know, the space that we're very tied to open stack is is heavily open source, right? A lot of the vendors are open source, a lot of the the solutions that are being chosen like SEF were open source, right? SEF was gaining, you know, massive traction, you know, partly partly because it's an awesome project, but partly because it's also open source, right? There are other proprietary solutions out there that did not have the same, you know, kind of thing happen. And on the networking space, you know, we were watching this very closely every six months there's a user survey, what's happening, you know, you see SEF kind of rising up and eventually taking the top spot. But on the networking side, you know, basically what you see on the networking side for neutron plugin usages, you see the reference implementation of neutron, the OBS plugin having some usage and then there's the long tail of all of the the various plugins there, right? And it's basically, you know, very fragmented. So none of them are really taking the top spot. And we know, you know, that the OBS plugin, it's really a reference implementation. It's not totally meant for production. Most people who are doing production workloads are using some solution there, right? And, you know, the reason why we felt that this was the case was because there wasn't a great, you know, open source project out there that's vendor neutral that really fit the bill.  Scary that it's a button click essentially to make that happen. But we were able to make that decision finally and we did it. And, you know, that was back Paris summit six months ago and now, you know, coming here, you know, spending a couple of days here is very clear that this was definitely the right decision. I mean, since since Paris we have had a lot of traction, you know, in the first two months of this year, you know, we had more people coming and trying our stuff and moving towards production, paying us for the enterprise version than, you know, all of last year by far in the first two months. Crazy. Last year was very slow.  And coming to the conference this time, seeing where we were much more well-known, whereas six months ago, one year ago, we were, you know, some weird Japanese named company that people kind of heard of. Very interesting and definitely a, you know, proof points that, you know, it was the right decision for us.  And the reason we chose you is because you're open source among other things. But really, that's one of the main factors. So it's really about finding the gap in the market and going after that.  At the time it might have seemed too late. It's not. Yeah. Yeah. Yeah. Big leap of faith. Yeah. Sure. So, you know, getting back to the the partner comment that you may have been is interesting, you know, having you haven't seen it. And now obviously you're on the side of Red Hat where you're managing a lot of these partnerships. But, you know, this challenge of, you know, your situation changed, getting acquired and and then having to basically tell these partners to go away in in peace, right? So maybe you could talk about how do you think about it now as Red Hat? I mean, what advice would you have for folks in the audience about partners? Is it even important to partner with companies? What does that mean? What are they, you know, what should someone expect to get out of a relationship with Red Hat? You know, what what insights you have? Well, the stuff product is and it's a it's the storage layer. So if you think of a distributed storage system, you have server vendors, you have networking cards, you have controller cards, you have hard disks, you have flash drives or flash flash vendors with arrays. You have people that are building appliances. You have people that are trying to take the software and actually put it into their software solution and deliver storage out of it that way. You have service providers that want to build a cloud and charge Amazon type rates. But they want stuff to back their cloud. So they need some sort of service provider licensing licensing. The whole ecosystem of partners is very, very big. The vast majority of partners, vast majority, were able to keep. But there was a small amount of partners that didn't fit. And some of it is like canonical or what is right? That probably a tricky relationship to hold on. No, canonical, not so much. But there's there's others though, right? The we had some L3 agreements on community open source. So when we started out with when we started out with SAF, we had a pure open source product that was just the community bits. And then over time, we actually had the community version and then a downstream version, which was the ink tank distribution of SAF, which is called Ink Tank SAF Enterprise. And and that Ink Tank SAF Enterprise had pieces of it that were proprietary. So they had something called Calamari, which does the management and monitoring and some of the other features that that make it more of an enterprise product as part of it. When we got acquired by Red Hat, we open sourced everything. And then there was it made less sense for us to have old L3 support agreements on community bits rather than our downstream. So because of a business model change that we had to make, we had to go back to some of these older agreements and say, you know, we're not going in that direction because it's not long term sustainable for us. And we knew it wasn't sustainable, but we did it to get the deal done in order to get the name on the board in order to continue the traction, right? Yeah. So what we try to do in order to hedge our risk over there is not sign long term agreements. So we try to keep things to a year or two years at the most, which is actually kind of short term in the scheme of things so you can switch out of it if you need to. If you don't feel like you've got this thing nailed. So take that as one piece of advice you'd give us with your red hat hat on. What else? What other advice in terms of like partnering with a company like Red Hat and maybe just we can extrapolate to HP or Cisco or EMC or any of the larger companies? Yeah, I would say, you know, if you are a partner of Red Hat and you're the OpenStack conference, so I assume you're going to be interested in partnering with the RELLOSP team because they have a great product around that. And they've got a 200 and something partners that plug into that. I think it's a really good idea not to just be a number and not to do the bare minimal work, but to work very closely with the marketing teams, work very closely with the product, try to figure out what joint customers you have, see if you can get white papers done, case studies, things that prove joint value. If they see and they have collateral around that, that means you can actually leverage the greater field sales team. There's a lot of people selling Red Hat as well internally and we have partners selling it. But if we have material to back that up, it means that your solution would get out there more broadly. But it's very easy to take advantage of that. All you have to do is ask and for the most part and just be there often. You know, Solid Fire has done a really good job of being engaged with the RELLOSP folks and they've seen good traction come out of it. And I can say that there's a handful of partners that have really just spent energy on it. And some of it is time and some of it is money and some of it's sponsorship and some of it's having that marketing team available and things like that. But if you make yourselves available and just that team can see you as a resource when they have problems to solve, then that works well in your case. And the best thing ever is when you have joint customers. So if you bring customers to them, they appreciate that and they will bring customers back to you as well. So if it's a win-win, it works. But that win-win takes a lot of work. You can't just sign up and do the bare minimum. If you do that, you're not going to get too much traction because you're just a number in the pile. Just go ahead. I second what exactly we've been saying. I mean, the lifeline for us at the beginning and still somewhat today, but the beginning of the journey was we needed partners not only to gain a distribution channel. We also needed partners to help us with the delivery side. And so the key there was that we had to find the right partner that shared common objectives with us. Common objectives from how the types of customers that we wanted to win and common objectives in terms of revenue and making money. And so really for us, it was around finding a partner with complementary capabilities around the sales and distribution side as well as the delivery aspect. And so actually the example that I'll use is the one with Red Hat in Asia because we found that in Korea and the Southeast Asia, there was starting to be a lot more demand for our kinds of services. We just didn't have the scale. Not only that, but also we didn't have the reach in certain regions. And so we spent quite a bit of time, like Ben mentioned, in terms of developing joint go-to-market strategies, joint case studies, joint sales briefs so that we could then have Red Hat be a proxy to us in the market. And it was very clear and we defined this upfront what the responsibilities were from a delivery perspective for Red Hat and what they were for Selenia and that actually worked out really well. But again, it's communication. You have to invest in the partnership. You can't assume it's gonna happen once you sign a contract. And again, the common goals and objectives are absolutely critical. Any quickly any quick questions audience? So what makes a bab? I mean, we're talking about maybe not so great customers. What about partners? You can invest a lot of time and waste a lot of time partnering with large companies. They've got a lot more people. They can have lots of meetings, lots of emails and they can overwhelm you. So you're laughing because you, Ben, right? You know exactly what I'm talking about. It's not evil, but it's kind of this bear hug for small companies that can be smothering. Are there things that you can identify that make a sort of a maybe not the ideal partner relationship? Like what makes you feel like you're forcing it that people can take away from conversation? Is it my question? Your question? And I think anybody, any, yeah. Yeah, I mean, I can start. I mean, again, the investment in the relationship and the continuing, continuous nurturing of that relationship, sometimes you don't have the resources to do that.   We can do this on our own. And that actually happened to us, not with Red Hat, but with other organizations where they said, look, we can do this on our own. We don't need a Selenia for whatever reasons. But again, if you don't nurture the relationship and there's a change in the guard in terms of who you interact with, then you just have to be careful. And in some cases they'll take business away. Not because they're malicious, but because it's the best thing for them to do. And the partnership wasn't important for them to begin with because they never had that trust, so. And I just wanna say, like I wish I had this advice several years ago, because we made all of these mistakes.  We have a partner now. We're gonna have business together and not resourced it and nothing happens, right? And it goes stale. And we certainly learned our lesson there. And definitely it has to be, you have to know what you wanna get out of it and you have to communicate that well with the partner and try to come to an agreement or understanding of what is it gonna take to achieve these goals. And definitely working with a big partner is a huge investment in resources, right? We are partnered with Dell, for example. Dell's a reseller of ours. First of all, getting in agreement with Dell to do that is not easy, right? It took eight months to get to just an agreement. And then now you have the agreement and nothing happens, right? So now you have to spend another six or seven months enabling them, training their field staff, trying to figure out where you fit if they're offering competitors. How does the sales team know when to bring you in versus a competitor? Very, these are things that you have to answer and explain and proliferate across a giant organization. So hopefully the organization has good tools to help amplify your voice. Dell, for example, does. They have some internal webinar things for their field staff, which 400 people will come on. 400 sales people will come on and listen to you talk. And that's been very successful, but it's slow, right? It's taken us a good half year before we started seeing actual joint deals come together. And it's a mix of strategies that has worked for us. So it is of course bringing in a customer to them. That's of course been the most successful thing we've done to strengthen a partnership with not only Dell but other distros, right? The best way to get their attention is to say, I've got a customer, I'm gonna bring them to you. Let's do this together and show them that this is a solution that the customer will like and they'll choose. And then you can use that as the case study to show to the other parts of the regions and give confidence. But if you don't do that, we always ran into a lot of issues where I think the field teams didn't wanna bring us in because they thought it would be a risky move, right? They'd wanna sell what they know. And if you bring something new into that and it's not clear that it's gonna be a success, then they don't wanna take that risk. So it's just something you have to do. So you gotta prime the pump, basically.  Wanna partner with you? Is there anything that you just can see me that this is not gonna be a good partnership with the company? Not because it's an evil partner. So I mean, just say, yeah, it's not gonna be a good fit that maybe is not obvious. Well, yeah, if you're gonna compete directly against me. I wouldn't really like that as much. And you wouldn't believe how many people come to me and try to partner. No, no, we're really complimentary. We're really complimentary. Just saying it doesn't make it so. Look, exactly. And you know, here's the thing, it's, I mean, we're talking about partners, but think about it, it's a marriage, right?  You gotta go in there with the right expectations. You gotta make sure the expectations are clear between both parties. Call that the prenup. Right? You know, once the expectations are kind of all set and everybody understands that, everyone who's in a marriage thinks they put the most work in. So you have to assume that you're gonna put more work than your spouses into that marriage. Right, right. So that's kind of an important thing, just understanding that maybe sometimes the workloads are not ideal between the two. You might take a lot of work. Sometimes they might take a lot of work. If you have any sort of issues, you communicate it. You bring things of value to the partner. Customers are things of value that you can bring to a partner, but there are other things that partners need. Sometimes they need marketing help. Sometimes they just need to be told they did a good job in a press release. Right? Like, easy things. So, and if you accept the idea that you're gonna have sometimes in that relationship that's gonna be really high, and then you're gonna have other things that are gonna go down, as long as you both have a mechanism to get through that, you'll have a good partnership. If you don't, then it starts to go sour really quick and it doesn't work out. And so, what makes a bad partner, what makes a bad partner is, at some point, if the expectations are different, and that's what I said, if you're gonna compete against me, that's one thing, but there's a lot of other things. There's different expectations that people have, and sometimes it's just not communicated well, and it just takes some time to level set. What we do when we go through partnerships on my team is we have a whole checklist of these are all the things that we plan on delivering, let's put dates behind it, let's assign owners, let's have a scheduled sync where we keep on going, so we try to keep track of all of this stuff. But, you know, we're a big company and sometimes we lose track of some of these things, and that's where we need to be reminded of it sometimes. So, like, it takes work. It all takes work. It all takes work. Well, both really important times, partners and early customers, I know it's tough, but I appreciate you all sharing all your stories and taking the time, and I appreciate all of you taking the time here to join us at the end of the day. Do you have a quick question? Okay, sorry. Well, as a venture investor, I'll give various a sync dancer.  And that's, I think, the start. And then if there's no resonance there, I would pivot very quickly.  That's not even that compelling to them, because they want to buy from you, right? Because they know you, they trust you. So that's where I would start, yeah. Okay, go ahead, yeah. What about lettering? Now with investors. No, I'd say, pretty much universal, I mean, I think people value in the sense that you've got a relationship with a customer, but we really want to see people that have bought stuff. The way I sort of think about it is, something that's really hard, because customers will tell you they want to buy, because it's easy to say, right? It's just they, it's human nature to be nice, right? So, oh, I'm gonna buy something from you. And they tell you that, they'll even write a letter of intent, but it's non-binding or something, right? But until they actually got it, go get that check approved. You don't really know.  But that's not, if your question is, is that as valuable as the customer? No, but I think- Is it worth chasing them at all? I wouldn't, no, I wouldn't spend a lot of time chasing them. I mean, you should have some referenceable, you can talk about it in terms of beta. I mean, what's better is to have someone actually using it for free, than to get a letter of intent or something. You better have someone using a product and say, yeah, this is great. Especially when they release it, we'll pay something for it. That would be a better, better thing to do. I want to be sensitive to time, because it's late. If you have some questions, I'll stick around for a little bit, and hopefully the panelists will too. Thanks again for everybody coming. Give everybody a round of applause. Thanks.


We have five flavors of leukocytes that we're going to talk about. And you're going to remember your leukocytes and how abundant they are based on this not very nice mnemonic device. I'm not going to write down the words of the mnemonic device, but I'm going to tell you what it is.  They're very nice because, I mean, monkeys probably really like bananas and so it seems kind of cold-blooded to say no bananas.   So let's write down who they are. We have neutrophils. They are the most common. Let's see if we're going to have a problem, neutrophil, no problems. We have lymphocytes. Second, in fact, let's do our abundance numbers right now. Neutrophils are about 50 to 70% of all white blood cells. That seems like a lot. That's what it is. That's crazy. That's a lot. So when you're looking at a blood slide, most of the white blood cells that you're going to see are going to be neutrophils. This is abundance not of all cells. This is just of white blood cells because what we know is that there's a jillion red blood cells for every one white blood cell. Lymphocytes, there are between 20% to 40% of your white blood cells are lymphocytes. We have between 2% and 8% of our white blood cells are monocytes. Eocinophils, between 1% and 4% of your white blood cells are eocinophils. That's the eating part of the Never Let Your Monkeys Eat Bananas. And then we have basophils.  So tell me, when we're doing our Easter Egg Hunt, our scavenger hunt for white blood cells in lab, who are you going to have the hardest time finding? The basophils are definitely going to be the most challenging. So let's fill in this chart for the neutrophils first. So I'm going to start out with their function because, you know, that's the first thing on the list. The function of the neutrophils is primarily phagocytosis. And in Wendyland, that is yumpsilization. These guys are roaming around and yumpsilizing bacteria, mostly bacteria. That's who they mostly are getting rid of. They don't live very long though. That's the story. They live between one and two days. So they roam the blood. They're floating around in the blood. There's lots of them, relatively speaking. And they're just yumpsilizing bacteria everywhere they go. They also, they have granules in their cytoplasm. And I'm going to show you that in a second. But something that you'll notice that end with fill are filled with granules in the cytoplasm. And think of granules as like Kool-Aid, Kool-Aid powder, where when they're inside the cytoplasm, they're like Kool-Aid powder. And then you can dump that Kool-Aid powder out into the blood and that now you've got all these chemicals out into the blood that can go do something. Well, the neutrophils, one of the things that their neutrophils can do is, I mean, one of the things that their granules can do is cause fever. And so the granules consist of a special chemical called a pyrogen, which causes fever. It's kind of interesting. Okay, so what do they look like? Well, since you asked, they look like that. They have a distinct nucleus and the nucleus is multi-lobed. And while my little image is going to be like, oh, yeah, it looks like that. They're not all going to look like that. But you will see this multi-lobed nucleus. So let's go look. Back to my favorite site ever, which is the University of Michigan Histology website. Can you see my blood? Look at all. This is what we're going to look at in lab today. Look at all the red blood cells. Holy, yeah, there's a trillion of them.  If you notice, do you see how this one and this one looks different?  In fact, oops, I kind of want to go down here. Like those guys look even different than these guys. Okay, let's just go in and look at them. Look at my multi-lobed nucleus. Neutrophils are filled with granules. And you can kind of, in this vision, you can kind of like, dude, I see granules in there. Most of the time, you can't see your granules. You're going to identify your neutrophils in your nucleus and at least compared to our other fills, the number of granules in there is really, really small. While we're here, take a look at the garbage next to the red blood cells. There's garbage in this side. There's like dirt in this side. Those are your platelets. You can actually identify your platelets in your blood slide. All right, so we've got our neutrophils. You have a sense of those guys. Let's talk about lymphocytes. Okay, I want to talk about lymphocytes next because they're the next most abundant. But we're going to talk about eosinophils next, so we're not going to fill these out in order. And if you think about it, go ahead and try and guess why I'm doing that because I almost forgot why I was doing that. I'll be right back.