Back in March, I wrote post called “Bring Your Own Identity” where I suggested that the next step in device management was to take these generic identity management tools (Facebook, Twitter, Google, Amazon) and allow users to log on with them inside the organization.
Bring Your Own Identity (BYOI) just arrived for business.
It is called “Identity”; it is Windows Azure Active Directory, and yes, it is from Microsoft.
Here’s why you might want to use it — how — and what.
The Backstory: The SaSS-y Company
Imagine a company that is 100% based on Software As A Service — or at least as close as we can reasonably come. You have corporate email in gMail, collaboration in google docs and Google+, project management in LeanKitKanban (or maybe Pivotal Tracker), HR and sales using SalesForce.com, Accounting in Quickbooks online, PR using radianSix. The desktop is just the device you use to get there; employees bring their own devices, use a Chromebook with no traditional operating system or a Mac. Operating System doesn’t matter; everything is web-based.
It sounds wonderful, but the reality to that world is maintaining about a fifteen different logins. One some of them, my email address will be my login; others will have a username. Some will have requirements for a short password with a special character, others a longer without. These tend to change over time, so I will end up with six or seven similar, but not identical, logins — I will likely write the logins and passwords on a piece of paper that I try to hide … and now we have a security problem. Of course I can’t tie these to twitter or facebook because, if I leave the company, the company needs to own the data. There’salso no way I can tie these to active directory, because they are outside the firewall.
This is the void that Windows Azure Active Directory is trying to fill. It exists outside the firewall, so you can use it as a login engine. If the session is cached in the browser, you can “login with Azure” and save the typing step. Configure the firewall with the right holes and certificates, and you can even have desktop login from Azure. There are third-party solutions providers that can itegrate Azure with other systems for you, and good ol’ Centrify, that enables companies to achieve single sign-on with Active Directory to anything – linux, mac, mobile devices, Windows-Based SAP, ERP,and CRM systems, you name it.
We’ve got a lot of potential here, but I can’t help notice that there aren’t many success stories. Device Management inside the firewall, or at least, single login (inside the firewall) has been around for years thanks to vendors like Centify. Outside of it, we have things like the Federal Government’s Common Access Card, that can inject login credentials into the browser — but not much in the private sector. We could use LDAP, and, in some instances, Active Directory outside the firewall, if the vendor supports it, but those integration points are painful and slow.
The Identity AD, things will be less painful … if the vendor supports it.
I know. You’ve heard that one before. We have a solid theory now; what we need are success stories.
I’m with you, and I’m looking for them.
More to come.]]>
On September 10th, the story was that an “anonymous hacker”, security lead for the internet group ‘anonymous’ has hacked into GoDaddy, taking down as many as 52 million websites. The New York Times ran the story that Anonymous used a Distributed Denial of service attack by taking over millions of computers, then directing them all to route traffic to GoDaddy sites, creating an influx beyond the capacity of GoDaddy’s servers.
Except, three hours later, the hacker collective Anonymous claimed, through several twitter feeds, that it was not them. and the hacker anonymousown3er was acting alone.
At least, that’s our story so far. It’s a good story; it’s a credible story, reported by CNN, CNBC, the Register, TechCrunch, and others.
It’s just not true.
Or at least, it might not be true. We think. Maybe.
Then things get weird.
The next day, September 11th, 2012, Scott Wagner, the CEO of GoDaddy, made a public post claiming the problem was internal – a corrupt router table – and had nothing to do with hackers, hacktivists, or Anonymous. Meanwhile, AnonCentral, an incredibly prolific twitter account with one hundred and fifty thousand followers that may be posted by multiple people, was claiming that GoDaddy supported (or had supported) SOPA – the Stop Internet Piracy Act, that advocates argue is so loosely defined that the attorney general can take down nearly any non-us site he does not like.
What is really going on here?
We may never know for sure.
What we do know
GoDaddy was down for six hours, from 10AM Pacific to 4PM Pacific on September 10th.
Assuming this kind of outage happens once every five years, that would be 99.98% uptime, which sounds nice – but GoDaddy’s Service Level Agreement is an incredibly 99.999%. For those without a calculator handy, that is about 25 minutes of downtime, total, in five years – or five minutes per year.
That is a huge promise to make.
Famed Internet Blogger Joel Spolsky explained his faith in those sorts of Service Agreements this way:
Internet providers like Peer 1 like to guarantee the uptime of their services in terms of a Service Level Agreement, otherwise known as an SLA. A typical SLA might state something like “99.99% uptime.” When you do the math, let’s see, there are 525,949 minutes in a year (or 525,600 if you are in the cast of Rent), so that allows them 52.59 minutes of downtime per year. If they have any more downtime than that, the SLA usually provides for some kind of penalty, but honestly, it’s often rather trivial… like, you get your money back for the minutes they were down. I remember once getting something like $10 off the bill once from a T1 provider because of a two day outage that cost us thousands of dollars. SLAs can be a little bit meaningless that way, and given how low the penalties are, a lot of network providers just started advertising 100% uptime.
I don’t think the lesson on this site, today, is not about anonymous; it is not about computer security at all.
Instead, it is about trust.
When someone makes a promise that is too good to be true, look for the guarantee; what happens if the promise is broken?
In case of GoDaddy, my personal site, Excelon Development, was down for six hours. The possible loss to my business is in the five figures — it is, after all, possible that a decision maker, offering a large consulting contract, looked at my website at just the wrong time, saw that it was down, and decided to take his business elsewhere.
The probable loss, of course, is much less.
Black Swans will happen; there will be unexpected things, exactly what SLA’s do not account for. Router Tables or Hacktivist, it really doesn’t matter.
The question to be prepared for is: How will your business respond when they do happen?
My tiny little business decided to take the risk and live with the downtime.
What about yours?
Note: This is an interlude. I want to talk more about the future of the IT profession, but I just checked my account summary from Amazon.com, and I feel sort of like Adam Savage from Mythbusters, when he accidentally carried some razor blades on a plane and no one noticed.
You see, I thought I was on a new tier, called the Free Usage Tier, that gets you 750 hours of CPU time a month along with 30 GB of data transfer per month, all for the first year. My back-of-the-envelope math says there are 24*31, or, at most, 744 hours in a month. In other words, unless you have the demand to spool up multiple machines, there is really no possible way to get dinged. So, while they want your credit card, there really is no financial risk.
But, like I said … then I got the bill.
I mean, yes, my editor told me that he done his own exploration, and forgot to turn something off, and got a small ding on his credit card, but that just a good warning for me. I would be extra careful to turn everything off, and warned everyone else to do the same.
And I was.
I ended up taking a small hit anyway, $8.41 for the month of June. It seemed odd, but that’s no big deal. I went back in, turned off an inactive server that I could have sworn I killed off in the past, and let Amazon have a couple of discount combo meals, on me.
Just to be sure, I checked again today. Guess what?
Another $1.82 of charges so far for the month of July. $1.81 is labelled “Electric Compute Cloud”, and one cent is for bandwidth. What’s that about?
Taking a closer look, I see two things:
(A) It’s 61 hours of fees on a WINDOWS machine — capital W Windows.
(B) The one penny is a ‘regional data fee.’
The windows machine fee I can sort of understand; it turns out the personal AWS license only covers Linux Machines. This makes sense to me, as Microsoft likely back-bills Amazon for the operating system, whereas Linux is free like water.
Also notice the sixty-one hours of charges.
After I got the previous bill, I immediately turned off my single EC2 instance … but that immediately was some time after I got the email, which, likely, was some time after the time cutoff for the fee. If that total was around two and a half days, well, that’s sixty-one hours.
I have no idea what the one cent is for. I have no visibility into it; I can’t explain it, don’t know how I could have predicted it. More than that, I can’t even talk to a human and ask — at least not without upgrading to a premium plan. For now, I paid the penny, sent a cancellation notice, and intend to check vigorously and often for new charges!
Now imagine that the bill is not for a proof-of-concept demonstration of the cloud, but instead an actual enterprise service.
How do you know how much it will cost? How do you budget? How you do you prevent hidden fees?
Suddenly the pain point of heavy load has shifted.
In the old days
We had a different risk. The classic example of the old days was the IBM commercial, a team launches a website with Champagne and Caviar. The team howls with glee as the ticker shows more hits — and keeps howling as the ticker goes crazy. Slowly, eventually, the howls die off as the team realizes the site is too popular; it will quickly become overloaded and crash.
With tools like EC2, the crash won’t come to your site.
Instead, it will be to your checkbook.
Yes, there are tools that are coming to address this, even services like the one discussed on this Amazon EC2 Forum post.
But doesn’t it seem strange to have to set up your own scripts to monitor momentary charges, and warn on the event of a spike, or to have to pay yet another party to monitor cloud usage? I mean, if your utility bills suddenly spike, they should call you, right?
The cloud is young. We’ve got new risks, and plenty of work to do.
Speaking of work to do …
Next time: More on the future of the IT profession, and how we can thrive.]]>
So far, we’ve signed up for a personal Amazon Web Services Account, learned a little bit about the Amazon Management Console, and, yes, even created a server in the cloud. Now if only we could actually do something with it …
Suddenly I have an idea for a follow-up post.
Today I’ll show you how to connect to that server in the cloud, accessing it through Remote Desktop, run software on it, and finally, so your credit card does not get dinged, how to shut the server down.
First, you need to follow the instructions in the previous tutorial; you should end up looking at the Amazon Web Services Console, something like this:
Now things get interesting.
The green light there indicates that the server is booted, but it may not yet have all services running … especially the services we need to connect. The easiest way to get to our server is to wait, about a half-hour, for Amazon to make sure the server is ‘clean.’
In the mean time, we need something: Remote Desktop software to connect to our server. Remote desktop comes standard on Windows Vista and newer machines, but is you have XP or a Mac, you’ll need to download it. You can get that software for free online; both the WindowsXP Version and the Macintosh Version have a free download.
Once we have Remote Desktop, you’ll have to wait; my recommendation is a half-hour, for all the services to be up.
Now Get The Windows Password
Once the services are up, we’ll need to retrieve the the administrative password for the machine. To do this, check the checkbox to the left of the instance to indicate it, then click on instance actions and “Get Windows Password”. (See example below)
Once you click retrieve, you’ll be asked for a private key, in order to decrypt the password from the server:
Do this this you will need that .pem key file you created earlier. Once you upload the file you will get a windows password. Save that to a file, or at least copy it to your clipboard with control-V.
Whew. Now we can actually connect to the machine.
It’s time to Log in to our cloud-based server. Yay!
One more time — use instance management again and click connect. This should bring up another dialog box, and you’ll have the opportunity to download a shortcut file , with the extension .rdp. If remote desktop is configured correctly, you can open the file with remote desktop. (Otherwise, save the file to your hard drive, open remote desktop, and tell it to open the file.)
Once remote desktop has the file loaded, Click Connect on remote desktop and you’ll come to a login screen:
Paste the password, leave domain blank, and click ok; ignore any certificate warnings.
Congratulations — you are in your server!
But … what can we do with it?
Of course, the value of any server is limited to the application we had in mind. Our goal today was to have a server, which isn’t saying much.
Three things we could do with this server are to test in internet explorer 8, to test installing applications on Windows Server 2008 (if we didn’t have a box handy), or to use the server as a storage place for files.
And that;s the real rub of cloud computing. Without an application, ‘give us some of the cloud stuffs’ doesn’t really mean anything.
More on cloud-based apps to come, but today promised to keep things under an hour. Today we wanted to get a real, live server up and running in the cloud, and I do believe we’ve done that.
With this foundation in place, we can add more in the future. For now, though …
Off — Off — Turn it Off!!!
In control panel, select Instance Management->Terminate, then Yes, Terminate. Please do, this, you must do this. If you do not do this, expect a ding from your credit card in a year.
Closing the loop – what we’ve learned
If you followed the instructions in this tutorial, you create an AWS personal account, created a server, and got into it with remote desktop.
Congratulations; suddenly the “cloud” is a less mystical and magical place, and more a think you can touch and feel, or at least a little bit more of a thing.
You’ve also probably recognized that feeling of “my goodness, this doesn’t actually do anything”, and you’re right. That’s what those cloud application vendors I introduced you to earlier have been saying for years: Building applications on top of the cloud is expensive and time consuming, why build when you can rent?
Why build indeed?
More to come.]]>
In the first blog entry I wrote about how to dip your feet into the cloud, mostly by using someone else’s cloud-based application. In the second I talked about how to move the cloud discussion from one of emotion to something a little more nuanced, just a little bit more based on reason.
One thing those techniques can buy you is time; time to go figure out how we are going to do this thing called the cloud, or CRM, or whatever else is the buzzword of the moment.
Let’s say it’s the cloud — what next?
In this article, I’ll walk you through creating a free server in the cloud in about an hour.
No really, we’re going stop talking about Amazon Web Services and start using them. To do this, we’ll create an Amazon Web Services (AWS) account, create a server in the cloud, then connect to it.
Whew. Here Goes.
What You Will Need (And A Warning)
All you need to get started with Amazon Web Services (AWS) is an Amazon.com classic account. That’s right; we’ll be super-charging our Amazon Account to become an Amazon Web Service personal account.
Notice that word personal. In order to encourage adoption, AWS gives away 750 CPU hours per month free for twelve months. That means you as long as Amazon doesn’t need to spool up additional servers, and as long as you turn off your instances when you are done testing, the service will be free.
Note: That’s a really, really important if. In the event that you follow this tutorial and forget to turn your instances off, you will see a bill in the mail, likely in the area of 8-10 cents per CPU hour, for as much as a month.
Don’t forget to turn off your machines. If you do forget, IT Knowledge Exchange nor Matthew Heusser are responsible for blah blah blah legal stuff here.
Step One: 90% of everything is Signing Up
First log into Amazon with your regular old account, then point your web browser to this URL:
1. Click sign up now then follow the instructions to create an Amazon Web Services Account.
2. Amazon will need to verify your identity by phone. To do this, Amazon will give you a special code and the call the phone number on your account. You’ll need to enter that code, then press continue.
3. Next AWS will email you a confirmation; check your email.
Once you have that email, we can move on to actually creating your first server.
Step Two: Create Your First EC2 Server
EC2 is the “Elastic Compute Cloud” (One ‘E’ and two ‘C’s)
The word elastic is important; the number of servers we are using will spool up and down with demand, kind of like your strechy pants that get wider around thanksgiving time if need be. (Okay, my strechy pants. Sheesh.)
For the most part, signing up is easy, it is in creating the servers that people get stuck.
It’s not just the command-line tools. It’s also the orchestration of the servers, the connecting them to a web-page, and, yes, the security issues involved in setting up key-value pairs.
For this time, let’s skip all that, and use remote server administration through a control panel.
To do this, go to this URL:
Select EC2 in the drop down and check the box — like in the example above — then sign if. (If you;d like, you could explore S3, Amazon’s file storage in the cloud option; more about that some other time.)
Once you log in to the console, you should see something like this:
This is the basic management console; the list of Amazon Cloud Services as tabs at the top.
Click launch instance.
You will see a large number of choices; select “Microsoft Windows Server 2008 Base.”
At this point you will work through a five step wizard. You can get by with the defaults for the first and second step (‘Instance Details’); we don’t need to worry about getting a large server or deal with integrated security issues.
When you get to step three ‘Create Key Pair’, you will need to create a key and save it to your computer’s hard drive. I will call this file a .PEM file — This is important. We will need our end of that key (the ‘private key’) to log into our server in the cloud. Note: Matt had problems doing this in Chrome; best browser is probably FireFox.
For firewall you can accept the defaults, then click ‘Launch.’
Ta-Da. Your instance is launching. Wait five minutes and click “close.”
You’ll come back to the Command Console page, but what’s that at right … it says one running instance! Click that.
You’ll come back to the EC2 Management Console Page, for your running instances.
Congratulations! You’ve got a windows-based server up in the cloud.
Oh course, we don’t know how to do anything with it yet, or even shut it down.
I’ll cover that in the next blog post.]]>
Last time I talked about how to respond when the big boss walks into your office and says something like “What are we doing about the cloud? We need some of that cloud stuff.”
I tried to make that advice hold true for most teams — but if your organization has data privacy and security concerns, the question becomes a lot more complex.
Or does it?
Think about both of those statements:
“We need some of that cloud stuffs”
“We can’t possibly go to the cloud, because of regulations and data security issues”
In neither case do we have any data; we don’t what kind of uptime or service level agreements we could get. We don’t know what the applicable regulations are, we don’t know the cost of the conversion or ongoing operations.
In both of these cases, we’ve jumped to conclusions based on some sort of faith.
In other words, what looks like a conclusion is really more of an emotional response.
It turns out that is kind of a big deal.
In “Switch: How to Change Things When Change is Hard“, authors Chip and Dan Heath argue that the brain is constantly fighting between the emotional side and reason — and emotions frequently win. (Those of us who have vowed to get up in the morning and exercise, or give up fatty foods, and failed, likely know what they mean.)
Likewise, if you’ve ever responded to an challenge like “prove it” by brining all your data to the next meeting — all your pie charts, graphs, and powerpoints, only to be faced with complete apathy and unresponsiveness, well, you’ve seen the power of emotion in the boardroom too. Again, Chip and Dan Heath suggest that reason might win the meeting, but without an emotional response, the actual action items to make the change will keep being rescheduled, over-looked, and ignored, until they eventually go away.
Another way to put it: You might win intellectual assent for your idea, but without hitting someone’s emotions, it’s unlikely that the project will get to be your priority, or get funding, or get on the corporate projects list. It’s kind of hard to move to the cloud at night, for free, in your spare time. If you somehow pulled it off, though, I expect you might get brought into a meeting to talk about “Governance”, don’t you think?
Defeating the Lizard Brain
Seth Godin calls this emotive side the “Lizard Brain“, because it is the kind of brain that chickens and reptiles have — a brain driven by fear, greed, and the desire to continue the species. Yet we can trick our lizard brain. Chip and Dan Heath use the example of an alarm clock with wheels, that forces you to get up and chase it in order to press the snooze button; once you’ve pressed snooze, you’re up anyway.
We can do this in the IT Department.
Matt’s Hasty, Generally, Possibly Incorrect Guess
I’m going to take a guess here, based entirely on intuition.
If your organization feels some compelling need to go to the cloud right now, then the corporate culture is likely one of innovation, or at least early adoption.
As the saying goes, you can tell the early adopters, because they’ll stand in line four twelve hours to get a new iPad, just to be the first people to have it. Of course, in a week, everyone else will have one too, but for that week … wow. They’re ahead of the curve.
Likewise, if the company is fighting tooth and nail to find reasons not to change, you’re likely in the early majority, if not the late majority, on the technology adoption lifecycle.
As my friend Eugene Lee recently said about these two groups: ”If you come to early adopters with an 80% solution, they’ll work with you to figure it out. If you come to the late majority with that 80% solution, they’ll response ‘call me back when you’ve got it all figured out.’
Right now, today, cloud technologies are in the early adopter phase.
Now if you agree with the big boss — no problem. If he’s worried about security and so are you, hey, great, you’ve got some time to figure it out. Likewise, if the company wants to throw time and money at the issue and you’d like to get experience with the news tools — hey, cool. You might need to put some effort into setting expectations, but for the most part, you’re good.
It’s when things are different that you’ve got a problem.
Encouraging Late Adopters
The lizard brain is motivated by fear, but fear can cut both ways; you can implement buggy systems or be left behind, trying to sell an MS-DOS based application to Windows Users.
Most late adopters do one thing: Follow the Herd. Or, as I’m sure you’ve heard “No one ever got fired for buying Microsoft.”
The Early Majority needs to know the problem has been solved before, and solved well, by other companies. You can do this through Lunches, Case Studies, References in Magazines, Interviews, or Articles. Once someone else has done the work, there is precedence – and that precedence can overcome a host of objections about regulations, audits, and standards.
The Late Majority, on other hand, adopts technologies when it looks like they are about to be left behind. You might not be able to drag a Late Majority-Culture to the cloud today, but the time is coming. When cloud adoption approaches that of Social Media, which has an 86% adoption rate in US Global 100 companies, your company will want to have an answer. Likewise, Late Majority Companies tend to be risk averse, so the time to start the experiment that might be fully implemented later … that time is now, isn’t it?
If your company is an early adopter, you might get pressure from the other direction — no, it might not be a great idea to put exchange “in the cloud” next week (whatever that means.)
When you try to deal with unrealistic expectations, yes, you can use reason, but try to do it in a way that can create an emotive response. For example “Is it okay if our services go down for five business days? Because that just happened to Amazon’s Cloud in April.” You might also want to mention the risk of a customer-data breach, yes, but also point out that it happened to Sony’s Datacenter in April, entirely because Sony’s model required it’s systems to be available to general public outside the firewall … just like most public clouds.
By moving from a potential threat to a systems failure, one that happened to a real company, with real security, who’s name we recognize, we transform the problem from the realm of theory to one of practice.
A Final Thought
Now I’m not saying that IT should drive every business decision, nor am suggesting you manipulate your boss to get your way. Instead I tried to provide a few techniques to align emotions with the intellect, to help people come to the best possible decision, instead of allowing themselves to be driven entirely by fear and greed.
But what do you think? I look forward to your comments.]]>