22059 slides

Editor's Notes

• #4: I wanted to give you a little background on myself.I’ve been in consulting for almost 30 years now. Early in my career a good friend of mine told me that I should never forget where I came from – i.e. always stay technical.I’ve been fortunate in my 20 years with TUSC in that I’ve been able to remain technical and be involved in a number of customer accounts.I’ve also been involved with a number of startups – as a founder, acting CIO/CTO, board member, etc.The last couple of years I was fortunate enough to teach a graduate level class at the University of Denver called “New Venture Creation.” It’s all about the process of taking something from an idea into fruition – whether it’s within an existing company or a brand new company.My point is that I understand the pain that businesses experience when it comes to technology. I’ve been speaking about the Web since 1994. Why? I was asked to debate that client/server was here to stay. I quickly knew it was not when I did my research on the Web. Back then I started talking about dynamic content generation. Not long after I talked about XML, then Web Services, then grid computing…I can tell you that these technologies are here to stay.Today I’m going to share with you some information about a startup that I was involved in that started about 3 years ago now. This is when we implemented our first grid technology. That startup is alive and well today and extremely successful – why? A lot of the success is due to use of the grid, another part of the success is the result of Web Services – a light weight SOA implementation. Both provide for virtualization or loose coupling as we’re going to talk about here today. Web Services allowed the business to write it once and use it everywhere. The grid allowed us to scale quickly and to provide redundancy throughout. Enough about me, let’s talk about the agenda.
• #6: Whether you’re working for yourself, in a startup, in a large company or wherever, I believe you will have a lot of the same goals that we had a this startup.A friend of mine had invested in a startup company. They had spent about $3M developing an application that wasn’t working out. The last investment made used the IP to secure the capital in – a final stage of death for a startup. My friend asked if I would review their IP. We quickly realized that the IP wasn’t worth anything. It was much too limiting – too small a scale, too small of a market (Denver only), undocumented code, etc.However, the concept was good. The relationships were good. So we worked out a purchase agreement and came up with a goal to be the best valuation engine and provide the best real estate intelligence in the US. Originally we thought we would do that one market at a time, but that didn’t work out…it just wasn’t possible to sell anyone values for “Denver.” People wanted valuation data for the entire US.We invested $20K to do a proof of concept. We bought some hardware and software and build a demo based on Oracle software and Oracle’s Application Express development environment.People quickly loved what we were building. We focused on the default mortgage world because it was “growing rapidly.” This was all prior to the huge subprime fallout – but we saw it coming.The beauty of the business model is that it’s much likely software. You can build the data for a property and sell it to 10 different people (or more) and there are 100M properties in the US. That’s quite an inventory of product at $10-20 per valuation. We needed to scale quickly.We used Web Services so that our customers would have access to the data and we could just charge them “by the drink.” The less cash you can build a startup for, the more equity you’ll retain, so cash conservation is very key! But…if you screw up and have an outage, you’ll lose your customer for good.
• #7: Once we proved the concept, we learned more about the industry and knew we needed to raise some cash to get the business going.We also had to purchase the data needed for the US – the upside is that it’s available. The downside is that it’s expensive, and everyone else has the same data – which is low quality.So we need a differentiator…which turned out to be MLS data. We secured exclusivity to that data.We purchased a bunch of hardware, put everything in a data center and started building a full scale application.As I mentioned, Web Services were a big part of the virtualization.The Web Services use the grid to deliver to the customer. Most everything is serviced Business-to-business. However, the services are also consumed by ApEx (the UI).More on iPerspective soonLet’s take a look at the architecture we implemented for the business to business transactions and for the UI layer.
• #8: This is a great reference architecture. We’ll take a look at the grid virtualization here in a minute.This is the architecture that is still in place today. This architecture delivers a very robust and scalable environment.Why isn’t ApEx out of the box robust? Everything that gets painted in ApEx is getting generated from the DB. What I’m suggesting is that you use ApEX to do page painting and that you use iPerspective (or hand written services) to talk to your databases. Not just Oracle either – any data source!Our first “ApEx” application (actually, it was Oracle’s App Server with the Web Toolkit, but that’s what ApEx is built on) had 30,000 concurrent users. We had to have BIG Oracle boxes to support this application, but it did scale up to 30,000 users.Using this architecture, the scalability is virtually limitless. In fact, you’ll see that beyond scaling, there are other advantages to this architecture, such as failover, virtualization, easier migration and so on.Let’s talk about the architecture from the bottom up – data sources – Oracle, MySQL, whatever.Then the App Servers, iPerspective servers – who’s Web Services connect to the DB – only when needed.Then your ApEx servers – could be running on small boxes – Oracle Express, Oracle SE one, etc. At this layer, customers can also access these services. Write it once and use it everywhere!At the top – your clients of course
• #9: We have 2 grids in our configuration. One for data that’s sitting in the Oracle and MySQL environments. Another for address processing and geocoding. Address normalization, correction, and geocoding can be a very expensive process for a business. We figured out a way to do this for about $1000 for 100M properties – which about 10M get normalized a month. The failed company had spent $100k for the Denver MSA alone!You’ll notice the DMZ, which is a key point in this graphic. Nothing is exposed!The Web Services virtualize the low cost computing grid! We’re going to talk more about the costs of the grid in just a minute. Let’s talk about why a grid can be of value to you.
• #10: There are many motivations for building a grid computing environment.Our primary driver was value or cost, but also scalability and redundancy/failover.Virtualization is a side benefit in my view. In other words, customers simply call a service and it returns a whole set of information – as if that information is coming from one server. The reality is that the course grain services that our customers use call a number of finer grained services to get the job done. For example, let’s talk about the Intelligent property report on the right side of the page. This is a service that can be called by a customer or the UI. One operation in the service returns a PDF and another operation returns the raw data behind this report.The data in this report comes from a number of data sources. But it all starts with an address from the customer (or through the UI). The Web Service virtualizes all of the work that done behind the scenes. The fine grain services do the work. For example, the getIdFromAddress service calls the address servers (in a round robin fashion) to normalize the address. Based on the normalized address, we then look up the property ID that matches the address. By normalize, I mean that you might type street and someone else might abbreviate, but we always stored it normalized. Each of the subsequent fine grain services use the unique property ID to return the additional data. Another fine grain service calculates the value of the property and establishes comps or comparable properties to back up the valuation. Calculating a value is not an easy process – we calculate the value about 5 different ways, then triangulate on the “right” value for the property. You’ll also notice graphs, sliders, maps, and images in this report. Initial Google Maps were used, but later we moved the processing to a mapping service from ESRI. The images might come directly from the county, from the MLS service or from a picture provider.Keep in mind that this entire report needs to be generated in about 5 seconds or less…and we need to be able to generate MANY such reports concurrently. Processing speed is important when customers provide batches of 100k properties that they want valued – today. In fact, the industry does benchmarking of valuation companies. The benchmarks give you 48 hours to return your results.In other words, if we couldn’t provide course granularity and virtualization – we would never be able to get the job done. If we couldn’t scale the application, we would never land deals like the Realtor.com deal where we had to have pre-established values for every property in the US. If you don’t have redunancy, customers will drop you in a heartbeat. Customers monitor our services 24x7. One blip on the radar and an entire escalation process goes into motion!Sure, you can do something like this with unlimited computing power, but we didn’t have that ability. We had a limited budget. Zillow raised $87M to do much of this!Let’s talk about some of the specifics as to why we wanted a grid…
• #11: We were able to fit our entire database onto Oracle SE One – that wasn’t an issue, but there are limitations – i.e. 2 sockets max, which was a real limiter. Also, there are no grid or clustering capabilities for $10k per box. There’s also no partitioning in the SE license. Our database is about 4Tb total.We considered using Oracle Express (the free version of Oracle), but quickly realized that wasn’t going work. There are far too many limitations with Express. Although we could get the country down to about 400Gb, that would require that we precisely partition our database into 100 partitions or instances. That wasn’t practical.MySQL is free and there are no limits, but we quickly realized that it’s about where Oracle was back at version 5 (or maybe 4). The indexing schemes are severely lacking. Many queries that we ran were complex and caused full table scans, which brought our MySQL boxes to a screeching halt in a hurry. So we opted to physically partition our 400Gb of data. Initially we partitioned by counties. There are more than 3000 counties in the US, but the top 1000 counties have 90% of the population…and counties like LA county, CA and Marion county, AZ are HUGE. So we moved to a partitioning schema that’s a bit more even – zip codes. There are about 10,000 zip codes in our database, so we have 10,000 physical databases – or schemas in MySQL. Queries are executed against a schema – full table scans tend to hit a maximum of about 10,000 records, which never kills our machines.Let’s take a closer look at the grid itself.
• #13: Some lessons learned. Not everything was wonderful of course. We learned from our mistakes. Initially we had a lot of hardware failures. Rebuilding boxes was killing us. Virtualization to configure new boxes became key to us.Our replication schemes chewed up a lot of network bandwidth – it became the limiter to replication. We had to change our strategies rather than just cycling constantly to replicate, but more intelligent replication – i.e. only when data in Oracle changes does it get pushed out to the grid.We wrote everything from the ground up initially. Primarily because there weren’t any proven packages available at the time. This included our data loading / ETL processing. We later moved our ETL processing to Pentaho, which provides a lot of virtualization and grid capabilities out of the box.The bottom line is we learned a lot!
• #14: Nothing is as easy as it appears – even when it appears really easy. Nearly out of the gates, we had an offer for $10M (real money) for what we built. Roll that acquisition forward – that company ceased all business recently, so it’s good we didn’t sell! It took another $1M of investment, but the good news is that by the time we gave up equity, our valuation was higher, so we gave up very little equity in exchange for the money.I’m a big believer in not doing what I call “drinking your own Kool-Aid” – don’t invest in the early/next stages of your own idea. Prototyping – yes, invest, but minimal. Everyone will tell you that you’re idea sucks or that it’s great…but you’ll know if it’s great or not based on how easily someone writes you a check.Using virtualization allowed us to focus on what was core to the business. Better values for properties. Better data. More data – i.e. MLS data. More services than the market offered – i.e. audit your appraisers valuation. iMVI which you see to the right, etc. We were able to change very quickly based on demands from our customers. We provided an extensible API for customers, so they called the Web Service and we did all of the heavy lifting virtualized – in seconds or even subseconds…
• #15: With all of this virtualization, as I mentioned, this company could focus on the essence of what makes them better than the competition. Large companies are slow to respond to the market needs and demands, which changed rapidly especially when the entire subprime market was crashing down at their feet. With virtualization, customers experience was simple, but what was going on behind the scenes was quite complex. I’m happy to tell you that what was once a $20,000 investment is valued at about $30M today. Give it another 2 years and the value is likely around $100M. In fact, due to the virtualization and scaling ability, the business has primarily fixed costs, which means that after you pass the breakeven point, nearly every dollar in is profit. This would not be possible without virtualization. It would not be possible without a low cost virtualized computing grid!Surely this is true in your business too! If you can respond quickly, you’re ahead of your competition. If you can do this inexpensively…again, it results in higher profits.We turned what we learned into the iPerspective technology. It provides for virtualization of Web Services. It allows you to access any data source (Oracle, MySQL, etc) as a service. It allows you to access a grid of data in a prioritized fashion. In other words, we greatly simplified this with our technology. This is done not only for data, but also for technical services (i.e. business logic you’ve written in Oracle PL/SQL). We also integrated other data sources and APIs into the product, so you can virtualize email, other services, etc.You can build your own grid or you can rely on someone elses…so let’s talk about Cloud computing.
• #16: As I mentioned, you can build your own virtualized computing grid, or you can rely on someone else to do it for you. Amazon has built an incredibly powerful virtualized grid of computing power. The EC2 cloud. If you want to spin up a virtualized image, you can do this with EC2 for 10 cents an hour per machine. Build your business around this model and you’ll have a robust and powerful business model!There are many advantages to cloud computing and paying for software as a service.This is something to consider and look into!
• #18: I have written a number of white papers and presentations on virtualization topics. From Web Services to Web 2.0 to XML. I have a blog where you can find current information as well. You might be interested in case studies too – of which I’ve written plenty. I’ve authored 5 books for Oracle Press – all in the Web space.Let’s wrap this presentation up now.