 Well, good afternoon everybody. My name is Jason Bloomberg. I'm president of Zaptink. We are Devel Technologies Company Zaptink's been around for about a dozen years industry analyst firm became a training firm focusing on Agile approaches to architecture So we were talking about so I went so it was the hot topic increasingly talking about enterprise architecture and cloud computing Fired last year by Devel Technologies a US government contractor But I'm still the guy against travel the world speaking at conferences. Everybody else is stuck in DC They're all jealous. I'm here. So Zaptink it's 12 years of existence is pretty pretty much been focused on the enterprise right big organization Whether public or private sectors now with the US government is part of our focus But we talked enterprises all over the world and we talked to many many different enterprises and we found one universal truth They're all completely screwed up You might if you work for a larger organization, you might think your company is uniquely pathological, you know but action in reality bureaucracy and Strange ways of spending money and making decisions and of course a competent people throughout the organization are just Common to what it means to be an enterprise. So but here we are in Silicon Valley in a technical show So my sense is that only some of you may actually work for a large organization So how many people here work for over consult for a software vendor? Oh Fewer than I thought okay, so maybe about 10% how many of you work for a consult for what you might call a web of company a company Whose business is really based on the internet? Okay, so how many of you would work for a consult for an enterprise large organization public private sector? Okay, so it's interesting. Maybe it's I miss you at the show or maybe it's just it's app They could tracks the enterprise people either either way Here's our here's sort of how we view the enterprise it the dark side Okay, so most of you in the rooms are no one talking about so what do you have an enterprise it? Well, you have legacy right big monolithic apps. Sometimes they're old sometimes they're not but they're big and expensive difficult to to Scale difficult to work with they tend to run in single partitions that not you know They they run on big servers. It's difficult to scale them If you have a transactionality in a traditional database, right the the old world of sequel databases that are acid Transactionality can be very expensive and they have a single point of control which sort of goes without saying right if they're in a larger Organization in your IT shop obviously you're going to control that application So that's sort of the starting point But what's happening in the world here is this whole picture is changing and cloud computing in particular is is basically Forcing enterprises to rethink this this dark side model. So Let's look at your applications in the enterprise. So here you are. I don't know if you have one like this spaghetti code anybody any spaghetti code? You don't want to admit it right, but there's a lot of it out there, right? So older applications Maybe old obsolete code or code has been tweaked over so many years by so many people Nobody really knows how it works or maybe you've lost the source code or lost the documentation Or maybe there wasn't documentation or maybe the documentation is all in Italian That's all and nobody speaks Italian. That's happened. This happens too. So what we're going to do We're going to take this and we're going to put it in the cloud All right, that's going to fix all the problems with CIO right about cloud and in you know business week or something Oh, we're going to move into the cloud. It's going to clean up all our legacy issues. It's going to run faster It's going to be scalable for your last day. Okay, so here we are zap thinks Secret technique for moving spaghetti code into the cloud ready There we are Then the cloud Okay, well, unfortunately, there's more to it than that. That's really what this talk is about right? You have to think about how that application is architected moving to the cloud requires more than just picking it up and sticking it Somewhere right the cloud is not just some big server in the sky. You have to get into what's really going on to understand How we can do this? Okay, so let's say probably isn't quite that bad We have a modern distributed application written in Java C sharp whatever right? It's follows all the object-oriented best practices So you might look at something like this and now the CIO comes along and says let's put that in the cloud Okay, so how are we gonna do that? There we are Well, even with something like this where it's not necessarily spaghetti code it follows, you know modern programming best practices You still have this problem right the problem is that the cloud requires you to consider certain architectural issues that are unique to the cloud or not so unique but are Characteristic of the cloud and of course this talk being focused on on data. We're going to be focusing on that part of the story Okay, so this is an important point right if you have the existing applications in your legacy environment Your enterprise environment and you're looking to move to the cloud for whatever reason you want better elasticity You want to pay as you go financial model for your infrastructure. You want to leverage platform as a service tool and whatever your motivations are Typically that's going to require you to rethink the architecture for your application But the good news is you'll end up with a better architect application Right the principles that the cloud requires you to follow our prints are good practices in general I will see this when we go through a few of them Okay, so Here's sort of what why the cloud why the cloud is Requires this level of architectural rethink so here's an app before the cloud right traditional distributed application We have our three tiers right a persistence to your our middle application to your our our presentation to your Okay, we know sort of how to deal with this right, you know how to scale it etc and Deal with various issues. Okay, what if we want to move this into the cloud? Well, probably here is we can put our persistence here in the cloud, right? There's a number of cloud based database vendors or other Vendors at the show and they'll talk about how they can either give you cloud-based persistence services or maybe their Applications or tooling running the cloud, but essentially we have it's elastic right we can scale this same with the application to you We can put the applications here in the cloud. We can make that elastic. We can make that dynamically provision Non-empty provision. So how many database instances or application instances we have well We don't know it could change from day to day minutes a minute hour to hour and that requires a new way of thinking about How are we architect those tiers? Of course, we're going to be focusing more on this year in this stuff So what are some of the challenges? Well elasticity is perhaps the most important of the Essential characteristics of the cloud right when we say that we want the cloud to be elastic It means whatever resource we're talking about Server storage, etc. Can't we get dynamically provision them and we can provision as much of that resource as we need in an automated way And if we don't need that resource anymore, we can deprovision it in an equally rapid automated way So this gives us a level of mystery, right? We don't know how many instances we're going to have because number could change depending upon our capacity requirements and Right, and so it's we have this notion of mystery We also have this illusion of infinite capacity, right? You always have enough capacity even if you need more you have this illusion that you have an infinite quantity Well, I know there's no such thing as infinite capacity All right, but it's a cool illusion and this is part of why we use the term cloud is because cloudy It's infinitely large, but even though we really know it isn't but but that's the illusion that if we get a Lasticity, right? That's what we get Okay scalability right the old way the enterprise way the traditional way is vertical scalability Right if we want to make our Oracle database need to scale it then we need to you know Add more big machines right and we all typically run in the same cluster So we want to add more resources to individual boxes works well for monolithic applications And that's the way traditional enterprise apps that were architected of course a new way You hear about it. I've been at this show now a day and a half It's like every single session talks about horizontal scalability right scale out instead of scaling up adding commodity servers as opposed to Buying very expensive servers, right if you want to add more capacity add more servers so now your applications have to be able to run on Multiple servers where each individual box the hardware might be Relatively less expensive right may not be some very expensive piece of hardware So you have to architect your applications according Okay fault tolerance another Difference with the cloud which if you think about it really isn't that it's different It's that the cloud shines new light on to fault tolerance best practices that we sort of like to keep in the dark before Right so the old way how do we deal with fault tolerance? We want to have a highly available system. Well, we can do set up a raid discs, right? So we're done in the ray of independent of inexpensive discs That's one way of you know dealing with the hard drive failures We can do mirroring where we have you know two Databases that are maintained you know an identical at all times or one goes down It's which the other and this can give us a level of high availability But essentially it's within a single partition, right? We're basically doing it within the context of a single application environment So the cloud way well, we're not buying really expensive hardware. We have commodity hardware. It's all be hidden from view We don't really care about the specifics of the hardware and we're not Expecting systems not to go down like commodity hardware. It's expected to fail Right if your Amazon you have how many servers you have Hundreds of thousands right they're failing all the time Google failing all the time, right? So it's not a question of avoiding failure. It's a question of responding to failure in an automated way Hard drives are going to fail servers are going to fail things are going to go valley up all the time so you want to have an automated way of reacting to failure So one of the if you know so far box goes down a new box comes up or a new virtual machine instance new storage instance Comes up and says well, what do I what am I? Okay, here's what I am goes finds it. You know what data should I have goes and finds it Hey, what should I be doing now? Figures out what it should be doing and it can basically pick up where it left off in an automated way So we want to be able to provide for a level of basic availability in the cloud Where essentially any individual thing can go down the overall application keeps working and that's essentially what we need by basic availability Okay, this is the cap theory. No, it's interesting Talking about the cat theorem now for about a year and this this is the first conference I've ever spoken at where I've heard other people actually talk about this So this is this is something I've seen three or four times in just the last two days So so you may have you know, this this crowd may be sort of familiar with it I'm sort of getting the sense that this is becoming a more familiar topic For data, you know data people I was enterprise data world and even there not that many people had heard of it So this is something that's definitely shifting in the marketplace But essentially what the cat theorem says is that no distributed computing system can guarantee immediate consistency Basic availability and partition tolerance all at the same time. You can have any toe But you have to give up a third one. So this can be a real challenge for an enterprise environment where they're Comfortable with traditional relational databases that essentially Guarantee consistency availability but run in a single partition, right? They're not partition tolerant The challenge of the cloud is we want to be highly available or we want to have basic availability That is a partition tolerance, which means we have to give up immediate consistency And that is that is a challenge that we have to deal with in the cloud environment So just to find these terms basic availability essentially means that individual parts of your Infrastructure can fail and the overall application will keep working So every request receives a response about whether it was successful or failed, right? So even if a box crashes the overall application keeps working So this is important characteristic of the cloud, right? Clearly you wouldn't want to be in a cloud environment where we're not in control of the individual nodes Because that's our cloud provider to control of them and if one of them goes down our application crashes Well clearly we want to avoid that Partition tolerance this one is the it may be the one that is the least familiar Essentially when we say a system's partition tolerant It means that the individual nodes can stop communicating with each other. There can be a network issue And the overall application will keep working now if a node just fails Then that's an example of it no longer communicating So that's sort of included in this but even if all the nodes are up and running If there's some sort of communication issue where there's no way for these servers over here to communicate with those over there For a while the overall application should keep working So this is also some characteristic that we want from a cloud environment But we don't want to be in a situation where the individual nodes in our in our cloud infrastructure You know some sort of network issue or whatever latency issue. We don't want that to bring down our application Remember if you're using a public cloud for example, you have no visibility into that So the last thing you want is for your application to stop working and it turns out of this because there was some You know, some you know switch went down inside of data center somewhere. Well, obviously that's important consideration for you Okay, so what about consistency now consistency this is this is a tricky term and it's even trickier than I thought it was 48 hours ago Right because I learned a lot doesn't last two days There's many different flavors of consistency and this could be one of the tricky parts of the consistency story is There's a lot of theory a lot of different types of consistency and it can be very confusing But we'll talk about a few different kinds here Not all of them a few different kinds the first one we'll talk about is what it's traditionally called high availability consistency So this is something that relation traditional rational databases, right? The the old sequel databases offer, right? That is essentially they can guarantee That all views of the data are always the same, right? That there's never going to be some user somewhere that sees or two users that see different views of the data at the same time Right, they can guarantee that and there's a lot of stuff that has to go on under the covers in order to provide that guarantee The challenge here is that it has to work within a single partition, right? So if you have multiple partitions, then there's no way this kind of Application can guarantee that kind of immediate consistency. So it says here to see an asset Actually, I learned a bit yesterday. There's a more to that the consistency in the asset requirement for transactions atomic consistent isolated there's a durable when they say consistency it means that Essentially all of the operations of the database may take consistency of triggers and indices and all of that but at you can still definitely say that a traditional racial database should provide a Level of essentially immediate consistency for all views of the data Okay, so what about enforced consistency with enforced consistency and essentially we're willing to give up basic availability Because we want to be partition tolerant So essentially we're saying that if our data are inconsistent at point in time But we'll just we're not available until we clean up our act and we do some sort of synchronization steps Okay, we're not we're consistently you can guarantee consistency because if you're not consistent The the consumer of your data when there's a user application has to wait until you are consistent And that's one way to enforce consistency So this in this situation is when consensus is important where it's important that all your knowns have to agree with each other or your application can't work properly, but it's okay if You have to wait around for however long it is and we'll leave you milliseconds until your data are consistent So then we have the notion of immediate versus eventual consistency so immediate consistency where all nodes agree on the Same data at the same time y'all agree on the day at the same time all nodes always consistent with each other Well, this is what we can't guarantee in an environment that should be an environment that is partition tolerant And it has basic availability what we can give you is eventual consistency So the eventual consistency basically what we're saying is that the data may be stable by two different users Might see different copies of the data different views of the data at a particular point in time until such time as We can bring it back in consistency with enforced consistency. We say up, you know We're out to lunch until we can fix this with eventual Consistence will say well you can read our data. It just might you might have to wait around for nothing and Or it's for synchronization step and sometimes that might only be a couple milliseconds later So it may not be a big deal, but it's something you have to think about in the context of whether your application can support that Okay, so eventual consistency. This is Sort of the the wrench in the works for a traditional enterprise You know architect and the enterprise is used to traditional systems. So how do we ever have? You know an ERP system or you know our you know inventory system or whatever the enterprise that is if you know We have different you know different Versions of the truth at a point in time. There's just no way the boss would go for that, right? Well in reality eventual consistency has been with us Since Babylonian times, right? It's been around for a long time the Babylonians invented modern accounting, right? the Double entry accounting well double entry accounting, right? Even if you're doing it on paper if you're doing it in clay tablets You close the books at the end of every reporting period So at the every month you bring all your data into a consistent state in the meantime You may have inconsistent data right this account might not agree with that account because you have Reconciled the books yet. So that's a familiar behavior even before we have computers where the periods of consistency might be a month Right now. It's down. We're already about milliseconds. Well, that's it. That's what computers bring to life so eventual consistency is familiar for any any process any business process that has an out of hand settlement step So even real-time stock trading What perhaps the most time-sensitive process you might find in an enterprise? Even real-time stock trading has an end-of-day settlement But if you track of all the trades during the day at the end of the day, they figure out where all the money goes But that's that's you know those accounts may not be consistent during the day Mobile phone roaming that's my idea the mobile phone providers have to reconcile all their accounts that might take them a Few days before you know one company knows how to build another company when you you know took your phone to the country Okay So if we can't have acid we can't have that same kind of high availability immediate consistency Then what can we have? Well, we can have base, right? So we're dropping acid and we're raising our pH Going from acid to base now. I didn't make up these words. I know it's like there's some arguments in the blogging spirit It's like oh, it's sort of a you know a lame kind of base thing You have to try was that but actually the acid acronym was contrived in the first place So anyway, whatever it was my fault. I didn't make these up based actually been around since before the clap Right base has been around, you know since the web 1.0 days What does they stand for well basic availability soft state and eventual consistency so basic availability right the sort of availability we expect from the cloud eventual consistency Stale data are okay some of the time and then soft state I haven't talked about soft state. So what's the deal with soft state? Well soft state basically means that the state information any node has About some what's going on somewhere else might be out of it So each node has to know to expire it after a certain amount of time So if you work with caching mechanisms, this is a familiar behavior I catch you expire after a certain amount of time But the example I like to use is the instant messaging right you have your instant messaging client You're little smiley-faced means your buddy is available, right? But let's say your buddy Goes to a tunnel drops off the network. Well your buddy's phone wasn't able to send you An unavailable message So your phone doesn't know that your buddy's not available So it's a little smiling face roll out even though they're not available But of course your phone is smart enough to know that if it doesn't get that information refreshed after a certain amount of time Then it's expired right and your buddy will go unavailable after certain So this is familiar behavior right familiar behavior for any kind of caching mechanism or anything that the Communication between those isn't 100% reliable Which in the real world is a very common situation It's sort of the enterprise context where we're assuming the network is always working. It's a bit artificial Right the real world. It's not like that right in the real world We can't always have communication between those and that's essentially what it means to be partition tolerant Right, so there's always this trade-off between partition tolerance high availability and immediate consistency so one of the Requirements that eventual consistency gives you is that Your data may be inconsistent. You may have stale data until such time as you can synchronize your data So synchronization but synchronization takes place after the fact, right? If you require synchronization before your data are available, that's the fourth consistency Available, right? So what we're talking about here is synchronizing Out of band there may be a moment or two of the data are out of sync Moment or two might be millisecond depending upon your technology. Well, this is really that bad Well, it's a familiar behavior again, right? If you've ever synced your phones calendar with your desktop calendar with your company's server calendar Right, it's a familiar behavior. Sometimes, you know, you make an appointment Take it on your calendar might take a couple minutes for it to appear on your phone Of course, if your phone's turned off It will take a long time, but it's a familiar behavior So what some of the vendors at the show are talking about is because they work in a cloud environment because the horizontal is scalable They have to perform a synchronization step because they want to guarantee High availability. They have to give them eventual consistency So they have to form a synchronization or application step and then they're spending all the effort making that as fast in this Stable was possible. Other vendors are focusing on a different part of the story Okay, so for the enterprise developer the architect, you know the enterprise application architect Looking at your existing applications and saying, well, I want to move this to the cloud I want it to be elastic, which means it has to be partition tolerance So how do I deal with this requirement for eventual consistency? Are you ready for inconsistent data? That's the key question So for example, let's take an inventory application. What do they do? Well, they keep track of how many widgets are in the inventory, right? That's what they did, right? So two users query the database at one time. They might get different numbers They said what eventual consistency it's all about So that could be a problem If somebody places an order for an item that they think is available They pay their money and then the system gives them the error says sorry We took your money, but we can't give you the product. Please call our customer service. Nobody wants that, right? So what's the desired behavior? Well, I mean depends on you have to think about it, right? One example might be while you get below a certain threshold and you give the user a message saying well We'll attend to reserve this product. We won't charge you credit card until we can guarantee Five months later, they get an email saying yes, you got your product or sorry, it's out of stock But your card is only charged if they got the product So what this means is if you have some legacy inventory application You might have to make adjustments to the business logic in an application And you're back to spaghetti code. So that could be a challenge, but again it depends on your situation So it's not these problems aren't resolvable The real point here is you have to think about what it will take to take some existing legacy out Put it in the cloud and have to think about what are the consistency issues that Partition tolerance introduces how I meant what what are my what are my priorities the cap theorem is a theorem It's math in the matter. We prove it. We can't get around it What we can do though is we can move the priorities around right so what are what are our priorities? How am I going to make the consistency step more more more rapid or how much I'm gonna ability to I eat or what those are the questions you have to ask so To leverage the cloud essentially have to think elastically and we talked to a lot of different people and this is perhaps the hardest part About really understanding what the cloud is all about but you can't think of the cloud as just a Virtual server or a virtual database which will store it well You have to think about it as elastic versions of those things right how many nodes there are to support that storage Instance or that server instance or whatever it is can change over time can go up and go down Well that impacts how you actually architecture application So that may be right. There's this The chaos monkey. So the example there is that's a Netflix. I made it from Netflix. Oh Cool, so you know about the chaos monkey not from Netflix. No. Oh Okay, so it's a it's a ringer Well anyway, Netflix has his name you call it chaos movie right there in a cloud environment And they put together this this you know small you know small app that randomly kills processes and services in their production environment Right keep them on the coast right because the whole point is that the whole application There's a whole world Netflix application has to stay up even if a random service or random, you know Process random whatever So they actually put this in production. So can your legacy application environment withstand your chaos monkey? If not, it may not be fully ready with the cloud Okay, so we went from the dark side to the light side now of course pure as we'll say This is still the dark side because Lucas switched out a picture Anyway But the light side right the world of web scale now the challenge here Right, we have the enterprise context and we have the cloud But the enterprise wants to do all this cloud stuff and they're being forced whether they like it or not To think about things the way the world of web based Applications have been working now for what 20 years, right? So Google Amazon eBay all these companies have figured this stuff out and now it's like really enterprise to get one the program Right, they have the one move to the cloud They got to figure out how to build and manage and architect apps that can take advantage of these best practices That the ebay is and Amazon to the world figured out now for a whole generation So hypermedia based applications not just web interfaces but leveraging hypermedia to Be the core of what your applications are partition tolerance space transactionality Resilience you write something goes down it comes back up. Yes. It should be a built-in capability of any application And the no single point of control, but if you think about You know a lot of these app store based Applications there are many different pieces that were together and the pieces are provided by different people There's no single point of control. Well, that's that's quite daily enterprise great thinking The last thing enterprise wants is an application in their environment. They don't control, right? But that's a whole new way of thinking So do the poster so you didn't pick up posters pile in the back There's any extras. I'll leave them on the literature table after the diner so That's what we're talking about in the poster Our vision for enterprise IT in 2020 only seven and a half years away now Basically, it's not just oh, we're going to be service oriented or it would be in the cloud Or we're going to use mobile computing, but all those things are more many different trends that interrelate very complex web Changes that are coming or they're in progress. It's not just in the future. We're in progress now So this is a part of the story, right? And you know that you hear this at this conference is all about whole new ways of thinking about dealing with information and about dealing with scalability about providing business value about building applications right whole new world that the enterprise is Only sort of getting an idea that there's this whole new world out there and they can move to a global environment They can move to the cloud they can be hyper media driven But it requires Rethinking what it means to build applications and to deal with information and it's just it's changing so many of the factors In the enterprise today, so it's an exciting time. It's It's interesting to speak to different audiences because everybody sees it a different way Right if you're coming from like you're working in eBay for 20 years You look at this and say well, why would you do any other way, right? But if you've been working at some insurance company for 20 years, it's like my boss will never go for that It was a very different kind of perspective Thank you very much. There's my content information My Twitter Twitter handle everything. So how are we doing? Questions? Oh, come on. We got some questions I think Brian Slutton gave a really good rest talk yesterday, and I'm wondering How does it is are the restful principles part of what you're talking about here? Oh, I love that's a whole separate talk Yeah, so that those don't spite the worst Well, I'm finding and I've been doing research on rest now for a number of years is that most people Completely misunderstand rest But there's like two versions of rest There's the version that Roy Fielding laid out in his dissertation And there's a version that it seems like everybody seems to think what's this but it does not end So I didn't go to this box. I didn't know which one he was I don't know if he got it right or if he was got it wrong So the common misconception is that rest is about API's Right that you want to build you have a uniform interface you create these restful API's and there's some better There's a lot of value there, right? That's a key part of the story You know, it's uniform interface gives us an additional loose coupling that web services promise I'm going to deliver and that's important part of the story. But the way we see it sort of Coming from the architecture perspective is rest is about building buildings and API's are the more for the rest It's I want to sign this big building I don't know how to do that, but I'm sure no I don't make more and you're missing the big picture The big picture of rest is rest is for building distributed hyper-media applications Like the world wide web Fielding looked at the web and said this is cool, right? It's immense. No, he's in charge. It's normally resilient, right? Has all these great properties and wouldn't it be great if it was still those properties instead of core architectural principles We can apply to a whole class of Distributed applications and that's what he was talking about when he talked about distributed hyper-media applications So rest stands for representational state transfer by transferring application state to the client in the form of representations That gets missed in a lot of discussions of rest Separating application resource application resource state only the resource state gets stored the persistence here application state is transferred to the client and the point is that we're building distributed hyper-media applications where the API RESTful you know uniform interface API supports that this is all a part of the story and also fits into the cloud story Because we need to be able to scale the middle tier. We can't maintain state information We could put in the database when that introduces issues although at least one of the matters to show is Addressing that issue can we maintain application state in the database and how do we scale that? That's not a RESTful approach. It's an alternative approach RESTful approaches will let's maintain application state on the client And what does that mean? Can we and how do we support that in the context of hyper-media application? So I don't answer your question, but I can just keep going about that body It's several different points that are worth considering. Yeah, it's a whole talk itself here And I give that one other conferences, but since this is a data center conference, you get the cap theory Well, yeah, I think Jason was just pointing out that that there are different approaches and the RESTful approach If people can understand it and get to it would seem to be the standard approach Well, so we have the standard approach on the web. Yeah, right, but it's it's Unfamiliar in the context of enterprise apps, right? So we don't want to maintain state information here because we want this to be elastic So and we could put it here And some of the vendors at this show do very well because we have these all these new ways of storing information that Persistent here now we could store state information there, but that's not RESTful. The rest approach is to move it here Well, now we have to worry about security and other issues, but that's what it means to build a hybrid application Anybody else Well, thank you very much