Well howdy there, partner. I don't aim to be stirring up any dust here, but not everybody knows that there is a right way and a wrong way to be herding your web app to the cloud. Might as well tell you, it all comes down to one thing: statefulness, the first born secret love child of the cloud. Now those may seem like mighty strong words to be starting out with, but I don't mean them unkindly. It's just that we can't keep this story under our hats like we used to. Best for it to all come out now, then we'll be done with it once and for good.
Well, to tell the story properly, it all goes back to distributed systems theory, but maybe we could save that one for a long rainy day. Just this here part about statefulness should be juicy enough for chewing on, what with all you web developers rounding up their apps for the big drive.
I've been waiting for someone to speak up before sticking my own neck out, but seems almost nobody wants to talk about it. The public cloud people, I can understand. They were the first to put up their medicine tent, and this is no time to start looking fidgety. Private cloud folks like me, we don't mind letting out a secret or two. It's your cloud. Best you know what kind of animal you've got hold of if you aim to ride it. And developers, well I reckon some know how the story goes and some don't. Those that do most probably can't imagine that anyone else don't. They're funny that way. But I don't blame them for keeping their peace, no sir. Who wants to be the one to stand up and tell a joke that everybody knows?
Well, maybe the joke's on me and you all know the story. But I'll tell it anyway. Can't hurt, and I own as it might help someone from falling into the sheep dip. Mind you, this is what always comes of going against the natural order. You know that. Sooner or later there's got to be a reckoning. On one hand, your cloud is all loaded full of elasticity and fault tolerance, it says so right on the label. Sure, that is, if all your computation is stateless. You read the fine print, it'll be there. But on the other hand, everyone today knows that web apps, they most always have got to be stateful because deep down they are transactional, and you can take that to the bank.
Now, if you ask me, tossing those two monkeys together in one barrel is an almighty potent recipe for trouble. And remember that web apps have become just about the most promiscuous distributed systems there is on this green earth. You just think about that for a minute.
I know this little matter of what might be going on in that barrel can be uncomfortable to talk about, but it's no time to play innocent. We have a job to do. Back when I was young, that was different, a simpler time. No use blaming the old folks now. They plain didn't know any better, most of them. And of course nobody talked much about it either, not then. Even to the ones who overheard some rumor drift in about statefulness, it seemed like a pretty fancy idea for ordinary folk to get their stirrups twisted over. I guess they figured that if they stayed out of trouble it would never come around to them, and the best way to guarantee that would be to not give anybody ideas about partitioning state in the first place. Partitioning state, that was rebel talk.
And maybe that attitude was good enough for those days, when commitment really meant something. Those days, a web client was practically married to a server with HTTP Keep-Alive. No need for fancy words about partitioning state, you were either connected or you weren't, end of story. Simple ways for simple times. There might not have been much variety, but you always knew where you stood.
But then big city servers with their big city ways started to move in. First they had to start in with their sessions, didn't they? Shamelessly sharing session state between client and server so they could hook up for a quick transaction, or even a little old piece of one, whenever they wanted. It bothered some of the older folk, I can tell you that. Treating state as if it weren't nothing but an object to be passed back and forth. But you can't stop progress.
Well, and if anything went wrong, it was always hushed up too. If the server went south and a few sessions were lost, well that should be a sharp lesson to those involved and nobody else's business. And they could always blame the server, that was the way of it back then. Servers were to do what they're told, and never speak unless spoken to. You may call them idle too much of the time, but I don't reckon they ever had it easy.
It went on like that for years. Nobody really gave it much thought, to be honest, so long as having one of those sessions ids was just as good as gold. Even when one server was overburdened, and then another and another, and then those load balancers started to move in on the territory, well, there was a heap of trouble at first, but we knew that it couldn't last. Only thing is, nobody foresaw that it would be the beginning of the end. We were fooled, sure enough, so busy getting a rope around the load balancers that we plumb forgot that there could be any other kind of trouble.
You see, your load balancer don't care a whip, just wants to run a string of servers and never you mind where they come from or where they're going. A client couldn't approach a particular server directly any more, now it had to go through the load balancer. Whatever old session id it might wave in the air, the load balancer wouldn't know or care, wouldn't even look. To them, all servers were the same. It would just farm out the most idle one, and too bad if that didn't work for you. That's why they called them server farms, that's a fact. Showed what little respect there was, even in those days.
Well, that had us worried all right, but in the long run it turned out to be bad for business and bad for the load balancers. The clients and servers had nothing to say to each other without their sessions. Then the load balancers had no choice. Like it or not, they had to become session aware. So now they'd watch the traffic like a hawk, making sure that the client always got paired off with the right server. That brought an end to the trouble all right, and the clients and servers could go merrily on, just as they did before with their session ids and all, pretending there wasn't even no load balancer at all. They got their payback in the end, and peace returned to the land. Or, at least, so it seemed.
Now along comes this latest modern new thing called the cloud, and it makes those big old server farms look mighty hayseed, I don't mind telling you. It's got so many servers and load balancers and what all, you can't even count em. You don't even try. You just say give me some more, and they give you some more. How about that for a business model? But like every slick new city idea, there's a catch. And this one, you can't just pretend it's not there, like we did back when we put those load balancers to rights. I'll tell you why.
See, you don't get something for nothing. There's this thing called the CAP Theorem where they done proved it. You can have any two of your consistency, your availability, and your partition tolerance. Not all three, at least not what you'd call perfectly. So step up now, which is it going to be?
Well, the cloud people, they don't always come out and say it to your face, because it makes folks a mite nervous, but you read the fine print and you'll find that they kind of go light on the consistency part. You say, I'm having a little party here, why don't you all send me over some more of them nice servers like we had before. Dress them up as my web apps. And they'll send them over, right on time. But those servers, there's something funny about them. Except for the web app they're wearing, you can't tell one from the other, and you never rightly know what any one of them will recollect from one moment to the next.
You see what they done there? Those cloud servers, they aren't rightly consistent, not like in the old days. You tell them anything, sometimes they remember just fine, but other times they'll forget. So the only way you can regard them as consistent is if you just give up and treat them as stateless. Remembering stuff is not their strong point.
Another thing, you ask any of them who they are, and they'll tell you they're ephemeral. First time I did that, I thought it was some fancy name like Petunia. Seemed kind of a funny coincidence that they all had the same one, though. Turns out it's a property. Well, you learn something new every day. OK, I guess if they own property it's not so bad. Anyway, taking the good with the bad, that's the pact they've made, leastways as I understand it. I don't judge it. I'm just saying, that's how it is now. It's the new frontier, and it brings new ways.
Now here's the new way when it comes to session state. You want to put a client together with one of these new ephemerals, don't go bothering with no session id. They won't remember it from a dollar three eighty. All they know is how to dress up as your web app. They're not stateful, right? Hell, they're not even reliable. One could just up and walk out on you, any time, for no reason. The only consolation is that a new one wearing the very same web app walks in before you can say beg your pardon. Fresh as a daisy and remembering zero. I had a cat like that once, come to think of it.
This forgetting does make conversation a mite difficult. But it all comes down to you, partner. Isn't that always the way? You want to hold onto something stateful like, in the cloud, you basically have two ways. One way is, your put it on the client to do all the remembering. Maybe not every last word but at least the high points of the conversation. The client has to be ready to play it back any time the ephemeral seems a bit foggy and forgetful. That can be done with cookies if you like. Lots of cookies if the session has a lot of remembering in it, so try not to go too wild there. But if you don't mind the client doing all the remembering, it scales right pretty. Only thing is, you have to look out for highjacking. Like suppose somebody come in pretending to be the client and says to the server, you owe me such and such. The server best ask for proof.
The other way is to use part of the cloud called persistent storage. I'll be danged, this is just what it seems to be, for once. You could be tempted to use it to do all the remembering on behalf of the server, I reckon. But maybe it would be best just for holding the highly persistent resource state and leave the more transient application state to other means. You'll certainly need strong persistence for banking and suchlike where you got to take off your hat and act formal. But some days it flies like a buzzard with a full belly. So, this may seem easy and all, and maybe for you it is. But don't forget, you may toss it over the fence, but whoever picks it up for you is gonna run smack up against the same old consistency problem again. I'd read up on that a little if I were you. Check for bullets before you've drawn the gun, that's what granny used to tell me.
Well now, it surely has been a pleasure. That's all the advice I have for today, but there will be plenty more to say about the cloud, and devops too. No hurry, it will all still be there tomorrow, sure as the sun rises.
