Saturday |
|
|
| Interviews and Articles |
Q&A with Esmeralda Swartz, VP Marketing and Business Development.Introduction Lightwolf was founded by Larry Dennison and Esmeralda Swartz, who first worked together from the early days of core routing specialist Avici Systems to that company's flotation, before co-founding Soapstone Networks, a provider of multi-vendor resource and service control software. The new company follows from their experience in distributed systems and communications software and passion for building high-performance scalable software. Q: How and why did Lightwolf come into being? Our background is building massively distributed systems and scalable, non-stop software. In the data management area, we saw a real need to apply that expertise to the database layer. The database market is currently ripe for innovation, particularly in transactional Big Data. We looked at what was going on in the cloud and the enterprise market and recognized that there was an unmet need around a horizontal scale-out database solution that leveraged both cloud and enterprise relational techniques to support the scale and performance needs of Web 2.0, SaaS, and large enterprises. A lot of focus for many start-ups is around either developing distributed key value store products popular with the NoSQL camp or a storage engine to replace MySQL or take on Oracle. There has been a lot of activity by companies attempting to build products that borrow from techniques developed internally by companies such as Google, Facebook, and Amazon. These companies built their own scale-out architectures because commercial solutions could not address their requirements. This was due to a couple of factors: the need to process massive amounts of data meant a scale-out not up solution and their business model dictated that they run on commodity hardware. They recognised that they were not going to be looking to traditional database companies so they looked internally. The rest of the world has started paying attention to companies that have successfully leveraged commodity hardware and open source software such as MySQL and MapReduce and started to say to themselves, 'well maybe I can begin to utilise the same building blocks and techniques for my own interests'. What they end up uncovering is that these solutions are well suited to search, social networking, software regression testing in the cloud, and similar types of applications. But, in order to achieve the horizontal scale-out, a lot of the requirements for the database were relaxed along the way. These companies also had the advantage of being able to tap into internal development resources to build capabilities on top of their open source software. Also, when Oracle acquired open source MySQL this left a vacuum in the market for those companies that wanted to continue to use MySQL, but had questions about its future now that it is part of Oracle. It is important to recognize that MySQL has been the only real success in the open source database area, but although it is a good database, it lacks a number of features many companies desire as their business grows and they become more successful. Customers want to improve MySQL, but do not want to move to a high-end Oracle database to get the features. Unlike a lot of companies out there, we do not presume that every company that is interested in an alternative database solution wants to move away from SQL. Most companies want to query for whatever information they want in the form they are accustomed to, often times that means SQL. We're building a hybrid transactional data management solution that sits between the application and the database and supports both structured and unstructured data. It delivers the horizontal scale-out without compromising on relational features. Over the past 6 months we've spent time with CIO groups and application architects at some of the largest enterprises including financial institutions, social networking companies, SaaS and Web 2.0 providers to understand what they are doing in the data management area and to validate the Lightwolf solution. The reaction has been extremely positive. A lot of Web 2.0 and SaaS companies are commenting on the same thing - they need to spend scarce development resources sharding applications across 10s or 100s of MySQL databases and this is impacting their ability to grow as a business. In the case of large enterprises, they need to improve business intelligence query performance 1000 fold to support live BI. They realize that parallelization across 100s or 1000s of commodity CPUs is the only answer. What all of these companies have in common is that they would like to continue to use their existing database solution, whether MySQL or other database but they want a layer of software abstraction that is either internally developed or comes from a commercial source that sits between the database and the application layer to scale-out. They do not want to have to touch the application or change out their existing database and a lot of products require just that. In the case of a Web 2.0 or SaaS provider, as they become more successful you also need to move from where you initially started - where you were providing normal "web quality" - to more enterprise quality. Improving the service provided to customers becomes increasingly important. Operational features become critical as you scale-out your business. Scale-out means a lot more than just scaling out your capacity, it also means scaling-out operations. Things like the automation around on-boarding new customers, 24/7 support become important, and much of this is tied to the database layer. Q: Do you have alpha releases with anyone at the moment? We're in prototyping stage at the moment. We are currently raising our funding. Presently, we have been coding the components on the system and bringing those up and that has allowed us to validate the product. We're at the point where we want to start getting it out to some targeted companies so they can put in their SQL queries and their data to see that the product can do what we say it can do. Q: Where would you envisage first starting to sell it - in the enterprise or to Web 2.0 businesses? The first customers that we're going after are Web 2.0 followed very closely behind by the SaaS providers and then moving onto large enterprises. One of the things that we've recognised for example is that if you look at the BI requirement from large enterprises, it's very applicable to what we are doing. Large enterprises are also looking at cloud techniques to solve their Big Data needs. They want to use MapReduce techniques for unstructured data, but also need relational capabilities and support for structured data. Technically, live or real-time BI means that new data needs to be ingested at high rates, without interfering with running queries. But you need to build up credibility and operational hardening before these guys will take you seriously. In the Web 2.0 case, what they have typically done is leverage open-source databases and are beginning to run into the scalability issue. They require horizontal scale-out to support a growing customer base and application complexity, but at the same time they need operational capabilities such as non-stop operations, online capacity management and migration, traceability and auditability of transactions, and flashback. These capabilities become more critical as you grow. Often, the question for Web 2.0 companies is how do keep your existing customers happy and also grow your customer base. You need to add additional functionality to applications and demonstrate business continuity capabilities that perhaps were not as important when you first started. Much of what we're providing are techniques on top of their existing database that normally they would never have the ability to take advantage of unless they went to a really expensive database from a company like Oracle or built it themselves. Even if they were willing to pay the price for a high-end scale up database solution, they eventually hit the scalability wall. Lightwolf is the buy decision evaluated against an internally developed make solution. Q: Taking Facebook as an example, it seems strange that they found a gap and couldn't find a commercial solution. Facebook has built its own distributed software layer solution on top of MySQL and have been able to successfully support their customer base. If you look at the number of MySQL databases they are using, they're one of the largest users out there. Looking at the number of users and the amount of data they needed to support, I don't see how a commercial solution could have helped them when they started. One of the things that Facebook and companies like them did was point out the need for alternatives. Similarly, Google was one of the first companies to draw attention to massive scale-out architectures with their Big Table architecture. Their business model dictated that they scale-out across thousands of commodity servers. At the time, their data needs were unique but now everyday enterprises, although they are not at the same scale, have similar requirements. What companies like Google and Facebook have that makes them different are lots of developers and lots of money to roll their own; Web 2.0 or SaaS providers don't always have access to internal resources to do the same. If there was a commercially available solution that they could take advantage of to solve their pain point and the ROI made sense then that is something that would be appealing. Q: Do you have a set time that you'd like to go to market with the product? We are targeting the end of summer 2010, so September time frame, to do some real-world testing. We've been spending a lot of time trying to be very precise in mapping requirements to our initial market entry and also coding away. What's interesting is that if you look at what it takes to develop a horizontal scale-out solution for the cloud or private enterprise, it's basically a big distributed system problem and that's the background of our team. If you're appraising the problem with a database mindset and not a distributed system understanding then you're not going to build the right product. What's been missing are solutions that address things like non-stop operations to enable SLAs that don't really exist in public cloud. If you haven't built and deployed non-stop software before, for example, then you don't have an understanding of what it takes. You end up developing point products not solutions. This is what we're seeing from many of the startups - you may have a group of really smart college students with a PhD thesis, they write some software and are looking to commercialise it or perhaps some engineers with an open source project that has gotten some traction, have received some VC funding and are looking to get support dollars. This is fostering a lot of innovation in open source which is great, but if you haven't had the arrows in your back then it's really difficult to understand what is going to prevent you from ever getting in the door with many of the enterprise companies, particularly when you want them to pay for the software. When software is free, companies are a lot more willing to tolerate missing capabilities. Q: Are there many start-up competitors to you? There are no direct competitors that we've come across doing what we're doing. Indirect competitors can be easily placed into one of two camps, NoSQL or direct database replacement. As I mentioned, what a lot of companies are trying to do is build on cloud techniques along the lines of a distributed key value store, so they provide limited scale-out for unstructured data, but do not support things like ACID transactions and a strict consistency data model. This makes it very difficult for enterprises to evaluate these products against their day-to-day needs. If you're an enterprise and you're running a financial transaction then you can't go down and you require classic relational capabilities. The other camp is building a storage engine as a database replacement, and often they too end up relaxing requirements along the way since it is difficult to be compatible with status quo. Q: What about the public video services such as YouTube or Limelight - would they still have a need for it? Absolutely, in fact what we're seeing is that the requirements for Big Data are coming from what we are calling "micro" applications. If we look at the carrier space a lot of the mobile apps are micro apps. They're not $100,000 apps, they're a couple of dollars each but there are millions of them and that's one of drivers for this type of solution - the need to support hundreds or millions of these smaller transactions. This is leading to traditional database solutions coming apart at the seams. You see attempts to solve the bottleneck with point products like caches, but it becomes a short-lived performance victory. Q: Is there a carrier market for the product you currently have, and will you be using those carrier's you used to deal with? Yes, although we're not starting there. When my co-founder and I founded Soapstone Networks we were also consumers of a relational database as part of our resource and service control solution that we provided to carriers. We ourselves ran into the database bottleneck as a database customer. If you look at what carriers are faced with it's exactly that - a bottleneck. You need to understand where your data is, get to it, and quickly process or data mine it in a meaningful way. Q: Why don't you start with those carriers that know you? There is a well established pain point in the markets we have looked at. They already recognize that they need alternatives for data management because they are dissatisfied with current solutions. For Web 2.0 and the SaaS providers the alternative to not solving the problem is death, they stop growing if they can't add customers. From the time they recognize that there's a problem they have about six months to bring something in or build it themselves and deploy it, so it's a very quick road from pain recognition to pain resolution. That's been consistent with all of the Web 2.0 and SaaS guys that we've talked to; it's a universal problem. It is not the long sales cycle typical in the carrier market. Q: As far as revenue is concerned, where would you earn your money from? Presumably you wouldn't just sell your product to a Web 2.0 or SaaS provider once, for example, and that's it? It's a software subscription, so subscription and support. We are also employing a free download and try model to get people started with our solution, the first eight nodes are free which allows them to validate the solution. The product was built to optimise around cost/performance so an initial starting point we're looking at is under $10,000 per managed node beyond the free nodes for the Web 2.0 and SaaS customer base and then as we add capabilities we're looking at a factor over that for enterprises that have different requirements. Q: What would you do as far as support is concerned? Is it an expensive element? This is one of the reasons we started with Web 2.0 and SaaS, as what they expect for their own product is automated self-service support, so they are accustomed to low-touch. We will have a download and try model from our website with the expected documentation and videos to get them familiar with the product. If they like what they see, they can download and try it. We are very aware that making the management system easy to use is a given. Even getting it up and running, this has to be wizard based and it needs to be self-contained. They don't want something that's going to be complex and don't expect a high-touch direct touch sales model. One of the things that makes us different is we support standard SQL, so if you know SQL you know how to use our product. We don't force any changes at the application layer to use our product. Q: What do you think the market is worth? In terms of the total addressable market for this product, it's a billion dollar market. If you look at just the business intelligence piece, that in of itself is a multi-billion dollar market. We think to start, sharding for Web 2.0 and SaaS customers, it is a few hundred million market. There is nothing else out there that does what we're doing. Q: Is that a problem to some extent? Everyone acknowledges the need for a transactional horizontal scale-out solution and that the time to introduce it is now. There have been attempts at building solutions but they typically don't deliver, they fall short technically or they are too disruptive to introduce into a customer's existing deployment. You've heard about application virtualisation, that's the holy-grail that everyone wants to achieve and what stands in the way is a database virtualisation solution. We're doing it in a way that's not disruptive to what the customer has. This is our history, having competed against Cisco and Juniper at Avici Systems. We understand the need to be an easy drop in solution. Using the case of Web 2.0 and SaaS, they're using MySQL or Postgres. Large enterprise have standardized on Oracle or other high-end database. If you're going for a database replacement they don't want to replace their existing database, so good luck! What they want is something that allows them to achieve the scale-out and performance around the queries. But they want a distributed software layer that sits between the application and the database. Any product that forces customers to move their data off their database and onto your solution is extremely disruptive. If you're a mature company, that's an uphill battle, never mind a startup. Q: Does your product require them to spend more on hardware than they're currently doing? No. It allows them to do the opposite as what many of these companies have counted on is achieving their scaling performance improvements by buying the latest and greatest hardware and scaling with Moore's Law. The issue is that database technologies have not themselves been scaling with Moore's Law for a while, so they can't rely on a scale-up solution. They need to scale-out and they don't want to add more expensive hardware and continue on that treadmill. What they'd like to do is utilise commodity hardware which is the underpinning for horizontal scale-out products. That's the Google model; it's the $2000 or less server because since that is what fits their business model. If you think about it from a Web 2.0/SaaS provider standpoint, even if you could afford the expensive hardware solution in combination with an expensive database, you still run into the scale issue, meaning they can't even buy their way out of the problem and they're running up against that wall.  |
||||||||||||
