When I first looked into AWS and Azure, the notion of scaling out an application was COMPLETELY blowing my mind. I didn’t get it, at all. Like, for real, how would that even work? A server without a persistent disk?
This short post is not going to tell you precisely how to do devops, or even give you pointers on how to build scaling apps in Azure and AWS. No, instead, I’ll share an interesting conversation I had on reddit recently, and how I tried to explain the notion of stateless applications to someone with questions.
The initial question
AWS is a great example of how you could setup a stateless application.
It’s easy to configure an application with a load balancer. We can use the load balancer to gauge how many people are trying to hit our site at a given time. If traffic exceeds the capacity of one host, we can tell our web service to add another host to share the load.
These new workers are just here to help us with traffic and keep our app responsive and fast. They will probably be instructed to pull down the newest source code on first boot, and be configured not to save any files locally. Instead, they’ll probably get a shared drive, pooled among all of the other workers.
Since they’re not saving files locally, we really don’t care about the host machine. As long as users have completed their session, it can die at any point. This is what it means to be stateless.
The workers make their mark on the world by committing permanent changes to a DB or shared drive.
So, new worker bees come online as needed. They don’t need to be permanently online though, and don’t need to preserve their history, so in that sense they are stateless. After the load drops, the unneeded little workers save their changes, and then go to sleep until needed again in the future.
Actually they’re deleted but I always feel sad thinking about my workers dying or being killed, so I have to think about it in different terms
Just my take on how I think of designing and deploying a stateless application. What do you think? Did I get it wrong?
This is a very frustrating error in SCORCH, Opalis, Orchestrator, whatever you want to call it. Bring on SMA because I’ve had enough!
When running a PowerShell Script or an Exchange Administrative PowerShell Command in PowerShell, the activity will fail with:
‘Cannot invoke this function because the current host does not implement it.’
The reason for this is that the command you’re trying to run is trying to send confirmation back to the shell (end-user) to provide Confirmation before enacting a change. The Orchestrator host doesn’t have any mechanism to prompt for change, and thus the message we see.
As it turns out, the error message really was trying to help us, but just incredibly poorly written.
There is a quick fix available for this, add either -Confirm:$false or -Force to your cmdlet, based on the command you’re using.
Suggestion: replace this message with ‘This cmd requires user feedbadk, and cannot be automated in it’s current form. Try reading the Get-Help page for the cmdlet used, and consider adding -Force or -Confirm:$false if your cmdlet requires it’.
Saw this today on the SCCM Mailing list. Very, very nice looking dashboard report which pulls data from SCCM to display an at-a-glance dashboard view of the health of System Center Configuration Manager.
Do you know someone who has been helping the community, active on the forums, or otherwise kicking PowerShell butt and hasn’t been nominated for an MVP or other award?
PowerShell.org is rolling out their second round of nominations for PowerShell heroes. Big congrats to Mark Schill and Francois Xavier Cat, both of whom I’ve spoken with and are well known around PowerShell circles!
Nominations are availble here: http://powershell.org/wp/2014/10/07/accepting-nominations-for-2015-powershell-heroes/