You are here

AWS re:Invent CTO-to-CTO Fireside Chat with Dr. Werner Vogels and Seth Proctor

This video features Amazon’s CTO, Dr. Werner Vogels, speaking with NuoDB's CTO, Seth Proctor at AWS re:Invent's CTO-to-CTO fireside chat event.

Video transcript: 

(Werner Vogels):     OK, thank you.  Thank you all for coming out here.  This is the second fireside chat of this afternoon.  We just had one with three founders of companies.  Fortunate they were really technical so we had great technical conversations as well.  We’ll have now conversations with three CTOs who are actually also founders of companies.  So probably we’ll have similar style of conversations where we’ll dive maybe a bit more deeper into tech.  In case you don’t know me I’m Werner Vogels.  I’m also a CTO, in this case from a bookshop around the corner.  Can I have Seth Proctor of NuoDB on stage?  (applause)  Have a seat, man.

(Seth Proctor): Thank you.

(Werner Vogels):     NuoDB, yeah.  Man, who wants SQL? 

(Seth Proctor): Who wants SQL?  Everyone.  SQL is the new like NoSQL.

(Werner Vogels):     OK.  (laughter)

(Seth Proctor): SQL’s back in.  It’s totally cool.

(Werner Vogels):     OK, so give me the 30 second pitch on the kind of stuff that NuoDB does that other SQL databases don’t.

(Seth Proctor):  Absolutely.  So new NuoDB is a SQL database, fully relational, kind of all the gnarly heavy lifting multi-way joins, big transactions, complicated analytics that you could do with an Oracle or something you can do with NuoDB, but it’s designed around a fundamentally new peer to peer distributed architecture.  So it’s designed to scale out on demand, it’s designed to use only the resources you need to run multi-region and to be active everywhere so that you can solve latency problems, data residency problems, kind of other interesting things people care about.

(Werner Vogels):     OK, that’s cool.  Multi-region?  So first of all you guys launched a new product recently?

(Seth Proctor): We did, yeah.  A new release of our product last week.

(Werner Vogels):     And it had very specific features?

(Seth Proctor): It did have very specific features, yes.  In the same vein of who needs SQL, the people who need that get really excited when you say you’ve updated the SQL optimizer, new indexing capabilities, optimizations for running hybrid models to be able to do real time analytics on your operational data.  Some really core architectural features like that, yeah.

(Werner Vogels):     OK.  You guys are also well known for sort of the policy driven automation stuff.

(Seth Proctor): Absolutely.

(Werner Vogels):     So tell us what that means.

(Seth Proctor): To me what it means as you’re building increasingly complicated systems today the way you make them scale is by increasingly not specifying every detail of how you do deployment.  And that’s certainly -- that’s a lot of what I saw in your keynote this morning is trying to describe, you know, describe containers automation, how you assemble things declaratively.  And so we’re really focused on how do you run distributed architectures by specifying your SLAs, by specifying the problems you’re trying to solve, and let us take care of running and maintaining that and kind of using resources as effectively as possible for you.

(Werner Vogels):     OK.  So tell me about the SLA side of things.  So what does that mean?  On which dimensions do you give SLAs or on which dimensions ask customers for SLAs?

(Seth Proctor): So today the SLAs are focused more on questions like how many independent points of redundancy do you want, kind of how large are you willing to let a database scale before you want to cut it off because your budget’s limited, you know, what kind of instances do you want to run, because you may be running in a mixed model and you want different kinds of instance types because you’re solving different problems on the same database.  As this feature matures it will let you specify things like what kind of transaction rates do I want, what kind of security policies do I need in place, where do I need to make sure things are running or make sure things are not running.  One of the things you did recently that’s awesome is you opened a data center in Frankfurt and anyone who cares about international data security issues, the canonical example is always German citizens’ data and now we’re actually doing those demos.  So that’s really cool stuff.

(Werner Vogels):     OK, we will get back to that in a minute.  So but SLAs in your case mean it’s more about performance and how you, let’s say, automate things much more than that you would different -- do different engineering for particular customers.

(Seth Proctor): Yeah, yeah, I mean --

(Werner Vogels):     Because I’ve always -- in our case of SLAs, you know, you only get one SLA because you build these for 100% availability.  You don’t build it for 99.95.

(Seth Proctor): Exactly.

(Werner Vogels):     You build it for 100% and so everybody gets the same SLA because technology-wise you don’t do anything else.  SLAs are much more often a legal document than they are an engineering document, but in your case SLAs are two engineering sides because of -- or at least it’s performance specifications.

(Seth Proctor): Yeah, exactly, exactly.  So in our system the developer sees a single logical database no matter how it’s running.  So there’s no sharding, there’s no kind of active/passive models.  It’s just a database.  So operators are free to decide what are they trying to solve, what are they trying to optimize for in terms of resource management, in terms of failure models, and how do they focus on saving costs?

(Werner Vogels):     OK.  Now, OK, coming onto the interesting topic of data residency --

(Seth Proctor): Yeah.

(Werner Vogels):     -- why is that such a specific thing that you guys address?  What, is there architecture, is there engineering that helps with that?

(Seth Proctor): Yeah, I think a lot of it is in our architecture.  What’s been really interesting to me over the last few years is as people are building systems that are running across multiple geographies they’re increasingly concerned with what happens in terms of the legal issues in those different geographies.  And so Germany’s the great example because German laws are so specific about what can happen with their citizens’ data.  And so when you want to provide a service that is globally available and appears to have the same information and same capabilities everywhere you have to think about how you do that while at the same time protecting all those individual laws about where things live on disk, and then later being able to prove through audit that you actually maintained those laws.  And that’s something that our architecture is really suited to be able to support.

(Werner Vogels):     OK.  Tell us about what there is in that specific architecture that is there to help that.

(Seth Proctor): Sure.  So the architecture is built around a peer to peer model.  So there’s complete independence.  There’s no master of anything, there’s no central point of coordination.  Those peers are running in one of two models.  They’re running either in memory or they’re focused on disk.  The memory peers are where we’re having SQL clients connect to the system driving transactions, where we’re enforcing kind of all the consistency and atomicity rules, but then we think about data durability as a separate concern.  And so we’re really not optimized to worry about IOPS on disk per se.  We’re also not really concerned about where the data lives on disk relative to where you can actually drive transactions.  And so for us it’s much more about how do you bring things into caches very efficiently, have their peers work together well, and then separately you worry about where the data may live in one or more locations on disk.

(Werner Vogels):     OK.  So in the multi-region model what are your biggest challenges?

(Seth Proctor): I think there are a couple of big challenges.  One of them is just cutting down on complexity.  I mean it gets so complicated because often multiple regions means multiple people or in large organizations means multiple teams that are administering the same systems.  And so we’re very focused on trying to simplify the tools, simplify the APIs, make that easy to work with.  Certainly from a systems point of view and an architectural point of view we have all the classic challenges of distributed systems, focusing on what happens in the failure modes, trying to minimize the amount of communication on the network so you can really take advantage of virtual systems, you can take advantage of public infrastructure and really run efficiently.  And so that’s a lot of asynchrony, that’s a lot of optimism in our system, that’s a lot of understanding how to reason about the system at all times so when failures do happen you know you’re still a consistent database.

(Werner Vogels):     So given that -- given all that complexity, does that mean that you run the databases for your customers or is it that you hand over the software to your customers to run their own databases?

(Seth Proctor): So we hand over the software to our customers.  And they can run it anywhere.  Obviously we encourage them to run it on Amazon.  It’s a perfect environment for software like this.  But we hand it over to them and that’s part of why we’re so passionate about making it as simple as possible to work with.

(Werner Vogels):     OK.  Tell us what a typical deployment looks like.  Is there a typical deployment?

(Seth Proctor): Right, I was going to say --

(Werner Vogels):     I mean also on the AWS side.  I mean you guys (inaudible) [eight Excels?] at the minimum or...?

(Seth Proctor): In the vein of the last two days’ keynotes, atypical is the new typical.  Or the new norm or something.  No, I mean I think there is no typical deployment.  I think there are customers who come to us that are looking to do some very simple things just around redundancy, around being able to run active in a couple of availability zones or in a couple of regions for small throughput but just reliability.  We have customers who talk about kind of familiar work loads.  At the end of the month there’s a lot of activity, at the end of the quarter there’s a lot of activity.  When a [gain] starts there’s a lot of activity.  You know, all those events when you on demand want to spin up a lot of resources and then shut them down when you don’t need them.

(Werner Vogels):     OK.  So what’s your typical instance size?

(Seth Proctor): The typical instance size varies a little bit and that’s part of what’s nice about this architecture is that you can actually run with mixed instance sizes.

(Werner Vogels):     OK.

(Seth Proctor): Certainly the R3 instances are great for us because those are memory focused and so we’re really able to do things on that memory centric side of the architecture really efficiently and then we can spin up different instances that are focused on storage or if we’re trying to do analytics at the same time we’re doing operational data we can spin up -- you know, I’m really eager to try some of the new C4 instances and see what you can do with those.

(Werner Vogels):     OK, cool.  Especially because they are network optimized to (inaudible) towards EBS so that’s actually great architecture. And some people that have built, let’s say, global spanning SQL servers had to butcher SQL to be able to make that work. You guys have not done that?

(Seth Proctor): We have not done that, no.  This is real SQL.  We have customers taking incredibly complicated applications off of Oracle, DB2, SQL server, and just putting them onto our system and they’re working.

(Werner Vogels):     OK.  So let’s talk a bit about your company just from say a founder perspective.

(Seth Proctor): Sure.

(Werner Vogels):     How big are you guys?

(Seth Proctor): We’re about 60 people at this point. Which for a startup feels great.  For a database it’s tiny, but you know, we’re growing.

(Werner Vogels):     Something that I’ve asked the founders in the previous session is what’s your ratio of sales people versus engineers?

(Seth Proctor): Our company is very heavily engineering focused.  I would say more than half the company actually is focused on engineering.

(Werner Vogels):     OK, cool.  You guys took investment?

(Seth Proctor): We did, yes. A couple of rounds of investment, yeah.

(Werner Vogels):     And so really congratulations on that.

(Seth Proctor): Thank you.

(Werner Vogels):     And especially because it’s a former founder of Informix, I believe, that actually supported you guys there.  What are you using the money for?

(Seth Proctor): Well, we’re using the money in large part for continued development of the core.  We’re building out some really interesting capabilities going into 2015 [sic] that are really kind of stressing the limits of what a traditional database can do.  We’re also using it to be able to grow out, as you said, kind of that sales and marketing piece as we focus on increasing number of enterprise and sales opportunities with the company, yeah.

(Werner Vogels):     Given all the announcements that we’ve made in the past let’s say two days is there anything particular that excites you?

(Seth Proctor): Well, there are a couple of things that excite.  I would say Lambda is just awesome.  I mean I saw that announcement this morning and I just got giddy.  I mean I’m really, really looking forward to playing with that.  I think that kind of asynchronous programming is absolutely how we think about design and it’s just it looks really cool.  Looks really cool.

(Werner Vogels):     OK, cool.  Seth, thank you very much for being on stage here.

(Seth Proctor): Well, it was my pleasure.

(Werner Vogels):     And I thank you for talking with us.

(Seth Proctor): Thank you.  (applause)

(Werner Vogels):     Thanks.