Interview with Amazon’s Jeff Barr: WorkSpaces and CloudFormation
Editor’s Note: What follows is the second part of our interview with Amazon Web Services (AWS) Chief Evangelist Jeff Barr. In this interview, we discuss some additional AWS tips for Windows Server administrators, talk about the new Amazon WorkSpaces service, and briefly mention the Amazon CloudFormation offering. Check out the first part of our interview for an introduction to AWS aimed at Windows Server administrators.
James: What specific advice – maybe in the form of 2 or 3 top bits of advice — would you give someone who is a Windows system administrator and may be approaching the cloud from a Windows-centric view of the world? Coming from the Windows Server stack, what is the best way to take advantage of AWS?
Barr: I always tell people to just go to the AWS website and sign up for the free usage and launch a server. Then see the difference. Time yourself and see how long it takes to launch a server in the cloud. Compare that to how long it’s going to take you to rack and stack [a physical server] and get something running. Look at the flexibility. Look at the diversity. All of these barriers we talked about lead people to think of servers as a very static resource. Usually you allocate it, you set it up, and it’s now yours for a long time to come.
Another conceptual leap people make is from seeing servers as a static resource to seeing servers as a dynamic resource. It might be an incredibly useful thing to have those thousand servers for tomorrow afternoon. [System administrators] need to get into that mindset and think “Oh yes, I can get as many servers as I need for as long or as short of time as I need them.”
At first [using the cloud] is about seeing that it’s quicker to get the existing job done. The big leap is when they say, “Well, because it’s so quick and I don’t have to keep them for long term” and suddenly it’s like “I can do different kinds of jobs I couldn’t do before.”
They can actually be the change agent to get people to understand it. They are in a great position to do that. They are the ones that talk to people all around the organization. If they’re the ones that can say, “Oh, yes we can give it to you for long term if you need it, but if your project can last for the quarter then great.”
Or if it’s a project we’re going to roll out in pilot form in North America and if it succeeds, we’re going to take it worldwide, let me tell you all the flexibility we have available for you. I think those [pieces of advice] would help. I encourage them to launch Windows Servers [in AWS], and to take a look at Amazon WorkSpaces. If they need to launch Windows desktops in the Cloud, Amazon WorkSpaces is currently available in production form in four separate locations, with more locations on the way.
If they need to provide virtual desktops, WorkSpaces is a great way to do that. They can use their existing Active Directory [infrastructure] f they’d like. They can literally pull up their Active Directory in our management console, go through and click, click, click and say I’d like all these people to be provisioned with WorkSpaces. In a matter of 15 minutes, they’ll have virtual desktops provisioned in the cloud. They can configure the software packages, the amount of storage, and the amount of CPU power.
James: Just to clarify, Amazon WorkSpaces doesn’t provide a full version of Windows 7, but it provides the “Windows 7 experience” feature of Windows Server 2008 R2 to end-users via remote desktop services (RDS), correct? Maybe you could explain why you took that approach with Amazon Workspaces?
Barr: Correct, Amazon WorkSpaces provides users with the Windows 7 Experience, provided by Windows Server 2008 R2 with RDS.
Amazon WorkSpaces is a new cloud-based desktop computing service based on Windows Server 2008 R2 that provides the Windows desktop experience via remote desktop services (RDS). (Source: Amazon)
James: What other advice would you give? You mentioned the benefits of just signing up for AWS and trying it out.
Barr: Having given lots of talks on this over the last almost 12 years, the presentation is one thing and it kind of gets to the sense of what it could be, but there’s no substitute for that hands on. The dynamic nature of this and the fact that you can say “Well, let’s pull up our menu of different instance types, basically, the server menu. You need this much RAM, you need this much disk space, you need this much compute power. Let’s pick from I don’t even know how many we have. The last time I counted I thought we had 19, but I’ve actually lost count of the number of instance types that we have. There might be twenty something different instance types. Almost no corporate data center is going to give you that level of variety. They’re going to say this is our standard unit that we’ve chosen. You need to wedge your application into that environment.
I think a fundamental part of the cloud model says don’t force fit your application to the hardware. Build your application and then choose the hardware that then becomes the best fit for the application as built.
Because you don’t know when you’re building it. Is it going to be memory intensive? Is it going to be CPU intensive? Or it might change over time. You can effect that change in minutes if you’re cloud based.
A lot of these things come down to agility, flexibility, cost benefits, easy experimentation, no need to make commitments. Going global. I think that’s certainly an aspect of flexibility but something that’s probably worth calling out explicitly.
A lot of times within organizations something new doesn’t always start out with a really clear mandate to grow into some big, complicated thing. It’s always a little experiment. Someone was experimenting a little bit and said hey, I tried this out. Then someone said oh, that’s kind of neat. Put another couple days into that and see where it goes.
The Cloud is really at home in that model because they don’t need to say well, my experiment has been thwarted because those blankety blanks down in server administration wouldn’t give me a server. Now it’s simply I launched a server and it’s costing me less per day than my Starbucks bill. So, that easy experimentation.
I think part of our experience here personally within the company is that as a company we do many, many experiments and the nature of experiments is that a few succeed and many do not succeed. I didn’t say fail. Fail is different than not succeed.
To me, failure says you started on something, you got the amount of capital investment you need to do it, and then by conducting the experiment you’ve actually burned through all the capital that you had.
Then at the end you’re like OK, I’ve used up my money and my experiment didn’t succeed. Therefore, it’s a failure.
The Cloud model, I look at it as let’s iteratively experiment, and instead of failing we have yet to succeed.
I think that’s a very different message because you can start really small. You say well, I’m going to start on a really small server.
It’s not drawing in any audience so I’ll hold my funds to myself. I’ll iterate on the design until I get the thing that really works. Then I’ll go big and I’ll launch bigger servers and actually spend my budget. I think getting all these things just kind of intrinsic to the thought process of system administrators is what’s going to help them to get to the point where they’re ready to really be at home in the Cloud.
James: A good question to close out on then is, if you’re a Windows server administrator and you’ve got all this advice that you’ve just given, what if they’re looking at moving a specific workload into AWS, whether it’s Exchange or SharePoint or SQL Server? Do you have different guidance for them for all of these different platforms?
Barr: We’ve got quite a bit. If they want to go at it themselves, we have whitepapers for moving the platforms. We have a number of partners that are in the business of helping to make that happen.
Then we have a team of incredibly skilled folks called Solution Architects. Or Solutions Architects. I never know if there’s an “s” on there or not. I think they’re officially Solutions Architects because they do more than one.
Solutions Architects know a hundred times more than I do about every part of AWS. They can be deployed on site. They’re available through phone. There’s no charge or anything like that. They’re there to help our customers to succeed.
It can be as simple as answering a few really deep tech questions or it could be let’s get your entire architecture on a whiteboard. Let me actually identify the parts that we need to move first. Let’s figure out the dependencies and help you to make that happen.
James: Do you have a list of all the different platforms you have that guidance for?
Barr: I’d have to dig that out. I know for sure that we have SharePoint and Exchange. We also have something called Templates. One of the most interesting parts of AWS is a service, almost like a meta service, called CloudFormation. AWS CloudFormation is a templating language that lets an architect design an entire collection of all different AWS resources the servers, the databases, the message queues, the DNS configurations and then configure and launch that entire architecture with a couple of clicks. They get to fill in a form to enter any runtime parameters. We have templates for SharePoint and Exchange, I believe.
This concludes our two-part interview series with Amazon Web Services Chief Evangelist Jeff Barr. Be sure to check out part 1 of the interview — which focuses on Amazon Web Services basics for Windows Server Administrators — if you missed it. I’d like to thank Jeff (and Kerri Catallozzi) from Amazon for taking the time out of their schedules to accommodate the interview.