Search results matching tags 'Customer Contact' and 'Best Practices'

Preparation is key to a successful cloud deployment

BuckWoody — Tue, 01 May 2012 13:09:16 GMT

If you want to be wise, watch the actions and outcomes of others. Emulate the successful actions, and avoid the actions that cause failure. That’s true in life in general - and in technology projects in specific.

I’ve worked with several clients who have created or migrated an application to “the cloud” - meaning using Microsoft Windows Azure or another provider. Although the statement in the title of this post is trite, I cannot over-emphasize how accurate it is. In every case of those who had a great experience with a distributed computing environment (which is thankfully the vast majority of my projects),

What kind of preparation do you need to do? Here are some tips I’ve learned in the successful (and not-so-successful) deployments I’ve seen:

Follow standard recommendations for successful projects in general

You and your organization have probably done a few projects before - this one should have the same general attributes: a well-defined goal, a small, motivated team, a realistic timeline, and an adequate budget. I know, I know, you *never* seem to get those things - but if you don’t, you’ll fail. Simple as that.

Educate yourself

Computing technology started out on a single set of hardware for a single purpose - and realizing the limits of the hardware at hand, systems designers quickly realized that scale-out and virtualization was key. No, that’s not new - mainframes almost always worked on the concept of scale-out and virtual machines. But we switched in the 1980’s to single-user systems again, and we’ve been there ever since. By that I mean you install an OS on the things you work on. Now we move back to distributed system concepts, and there are some real differences. You’ll need to learn how those work, and do things a new way. Hey, we’re IT - we LOVE learning new things, right?

Get a partner if needed

There are a few of us white-haired Gandalf’s around that remember how to work in a distributed system, but if it’s new to you, that’s completely OK. You can save yourself a world of trouble by working with someone who’s done this before - a partner you hire, someone from Microsoft Consulting, whatever.

And don’t forget support - who will handle each issue, what is the escalation model, who are your contacts at Microsoft, and what is your “light’s out” strategy?

“A new broom sweeps clean”, the old adage goes, but the old brooms know where the dirt is.

Build a model

Take some time to do a Proof of Concept on your local system and using your Azure hours from your MSDN account if you have one. Going through this build - and being willing to throw it away and try it a different way - is invaluable.

Test your theories

Three statisticians are walking in a field. They see a rabbit - the first guy raises his gun, firing far in front of the rabbit. The second guy simultaneously raises his gun and fires far behind the rabbit. The third guy yells “We got him!”

Not every theory is correct - not every attempt is the right one. Build in your success tests while you’re building your model. Then check them - don’t leave this step out.

Rinse, lather, repeat

This is advice from a shampoo bottle - which I’ve never used (I don’t really have that much hair - especially now). But in a “Cloud” project, it’s important. It’s an evolving system, that gains new improvements at an amazing rate. As soon as you deploy and stabilize you need to start the process over again. If you created your system in a Services model, with contracts for the APIs and abstracted code, this is far easier.

It’s not hard to do a cloud project right. But it’s really simple to do it wrong. Follow these guidelines and you’ll learn from the successes - and mistakes - of others.

How I Prepare For Presentations, And My Speaking Schedule For This Quarter

BuckWoody — Tue, 16 Aug 2011 14:04:45 GMT

I do a little speaking here and there and I’ve been asked about the method I use to get ready for a talk. I thought I might share the method I use, although as you read through this remember that not everyone has the same style, processes and procedures they use. As long as you feel prepared when you speak and the audience learns something from you, you’re doing it right. Still and all, it can be useful to see what someone else does to tune your process even further. Whatever makes your speaking better helps us all, including me, as I sit through quite a few presentations myself.

I do several types of presentations, from working with my direct clients at Microsoft in a very targeted and interactive discussion all the way to a full semester of classes at the University of Washington that lasts for several weeks. I also speak at technical events, and in all of these the audience size an participation levels vary. Even so, I still follow roughly the same process:

Develop The Concepts
Create Animations
Develop A Slide-A-Day
Practice
Tuning And Feedback

Develop The Concepts

When I’m asked to speak on a topic, I try and boil that down to one over-riding goal, such as “The listener should know how large-scale data sets can be handled”. Then I do a work-back outline of how that would happen - introduction, terms, define the problem, explain the options, provide specifics, detail references might be one example. Then I try to make that even tighter, until I start losing fidelity in the talk.

This is where the duration of the talk and the audience makeup is most critical. The shorter the period of time I have to talk, the lower I set the goal. I’ve seen people try to cram a complex set of information in an hour, complete with demos. At the end I certainly have an exposure to the information, but I don’t know that I have retained it. I would rather the speaker focus on one specific part of that deep topic or simply provide an overview and then point me to relevant resources I can study in detail later.

The key is what the audience retains when the talk is over. If they think “wow - that speaker is really smart” that’s actually a failure. They should think “wow - I’m really smart, and now I know how to do that thing the speaker talked about”.

Each of these concepts then becomes a logical flow of mini-goals, and many times, these map to a slide or whiteboard graphic.

Create Animations

It doesn’t matter what tool you use - somehow you need to convey your information to the audience. In some cases, I can draw “word pictures” simply by talking, but technical topics often lead themselves to graphics. I’ve used whiteboards, Power Point (don’t make that face) and even Microsoft Paint with a Wacom Tablet. I try to show a start-to-finish process, or layer components to slowly cement in the listener’s mind what I want them to know.

The rule of thumb I use is to show one piece of a system at a time, to show a larger more complex whole. To show how that system interacts with another, I use animations. All of these are done as simply as possible, using the least flashy animation I can. Any technology I use should be to get the point across, not to show how many fonts and explosions I can cram onto a screen.

I find that almost every concept I developed in the previous step warrants it’s own slide or drawing. If I have too many, say more than 8 or so for a one-hour presentation, then I have too many concepts for a single presentation, or I’m making it too complex. If I have lots of lists on the screen and not many graphics, then I’m reading notes and not setting up a dialog with the audience. Creating a graphic per concept keeps me from many of these errors.

Develop A Slide-A-Day

Speaking isn’t my full-time job, so I have lots of “real” work to do. So after I’ve gotten the concepts down and turned them in to graphics, I take one slide each day when I can and work through the detail of the concept I’m talking about. If I’m using Power Point, I use the “Notes” view to put down the text I want to cover, the references I find on the web, in magazines and books, and the other speakers I credit during the presentation. I give that out electronically after the presentation, since I don’t want people focusing on my notes while I’m talking - I would much rather they listen carefully and take their own notes. Even so, sometimes there are processes or procedures that I need to show. When I don’t show it on the screen, I show it in the Notes view. If I’m using some other medium like a whiteboard, I usually blog the information and then show the link to my blog.

Practice

This is probably the most skipped step I see in new presenters. Yes, you have to sit in front of a mirror. Really. And yes, you have to say what you’re going to say, and time yourself. Really. It feel awkward, and it should. And you need to do this. Really.

I use the “Presenter View” in Power Point. It has the slides (so that you can see the next one coming), the Notes you made, and a timer. It’s a great tool even if you aren’t going to use Power Point in your talk.

But you have to practice. I try to practice my talk at least five times. Interestingly, this isn’t so I’ll say the same thing the same way every time. In fact, it’s quite the opposite. It helps me feel more confident in the information, and allows me to “wander” slightly during the talk and be more dynamic, because I know what I need to get across - I’ve practiced it.

Tuning And Feedback

If time permits, I try to deliver the talk at work or to my wife. I give the audience a feedback sheet with what I want to know, so that they will be critical without being mean. I try to do this with as many different audiences as I can. Based on what I hear back, I may adjust or tune a section to ensure that I get the information across.

So what’s on that sheet? Well, things like “How was the speed? Did it seem like I knew what I was talking about” and so on - but there’s one part that is pretty interesting. I give them a test. I make questions that I should answer during the talk, and at the end I hand out the paper and see if they get those answers. If they don’t it’s my fault. End of story. I either picked people that don’t care about the topic, or don’t listen, or who aren’t interested in helping me. All of those are my bad. If I do an effective presentation, I move the knowledge of the topic from my head to theirs. That’s success.

Speaking Schedule

If you’re interested in seeing the result of this preparation style, I ‘d love to have you join me. I enjoy meeting the folks that read this blog, so if you’re near any of these events then stop by and say hello!

09/23-24/2011 - Orlando, Florida

SQL Saturday 85 - http://www.sqlsaturday.com/85/eventhome.aspx

I have two presentations at this event:

SQL Server Performance Tuning Using Application Path Analysis

There are a lot of resources, products and features you can use to tune the performance of your SQL Server system. Many assume you’re familiar with 400-level concepts, others don’t consider the whole stack of the client, the network, the operating system, platform and the database server. Buck Woody, Microsoft’s real-world DBA, will explain a simple, repeatable process you can follow to tune your entire application – from the client to the server. All of the tools we’ll cover are included with Windows and SQL Server:

In this pre-conference session you’ll cover not only the process, but also review a real-world evaluation. You’ll take home a system and a spreadsheet you can use to monitor and tune your applications, in a simple, easy-to-understand session.

The Saturday event is:

Cloud Computing De-mystified

The cloud! Move everything to the cloud! No, wait, the cloud is awful! Don’t move anything to the cloud! Wait – what’s “the cloud”? Buck Woody, Microsoft’s “Real World DBA” will show you how to figure out where your data should live, based on actual decision points. You’ll learn about Windows and SQL Azure, and when it makes sense to put data locally or remotely.

10/08/2011 - Portland, Oregon

SQL Saturday 92 - http://www.sqlsaturday.com/92/eventhome.aspx

Hybrid Database Systems

With so much interest in Cloud technology, where does it really fit in, and what is the role of the DBA and Database Developer? What is available in SQL Azure, as it compares to SQL Server? Can you leave some data on-premise, and put other data in the cloud? Buck shows you the ins and outs of SQL Azure, how to connect to it, manage it, what the limitations are, and real-world examples of architectures that work.

10/11-14/2011 - Seattle, Washington

Professional Association for SQL Server (PASS) Conference - http://www.sqlpass.org/Events/PASSSummit.aspx

Beyond the Hype - Hybrid Solutions for On-Premise and In-Cloud Database Applications

Despite all the hype, it’s rare for a business to actually “move” an application directly to the cloud. The cost, risk and effort aren’t usually worth the benefit of what you gain. Security considerations, performance, and control are just a few of the reasons that many applications need to stay in your datacenter. But there are times when including a function from the cloud makes a ton of business sense, either to extend part of your internal applications to remote workers, customers or partners, or to act as a HA/DR solution.

In this session, Buck Woody (Microsoft Senior Technology Specialist on Distributed Computing) will talk about how you can embrace Cloud on Your Terms through SQL Server Code Name "Denali" and Windows and SQL Azure architectures, and the considerations for creating a hybrid architecture across on-premise databases and cloud technologies. You’ll learn:

How to create a decision matrix for which elements can be extended to the cloud

A Windows and SQL Azure technology overview, code name Juneau, and DAC Fx

Component options for hybrid solutions, including:

SharePoint

Biztalk

.NET applications

Non-Microsoft languages and technologies

Other RDBMS’s

You’ll receive references, whitepapers and other resources you can use to evaluate your own architectures to see how you can use a secure, high-performance system that expands and contracts as needed.

10/11/2011 - 12/14/2011 - Seattle, Washington

University of Washington - http://faculty.washington.edu/woodyg/

SQL Server Essentials

This course will introduce the student to Microsoft’s SQL Server database management system. Topics included are relational database concepts for production database applications, SQL programming, and SQL Server tools. This course will introduce advanced topics -- at an overview level -- that will be presented in more detail in subsequent courses. The course involves instruction, course studies, and a project that will be completed from requirements to delivery.

During the course you will design a relational database structure from a set of business requirements, developing a graphical Entity Relationship Diagram (ERD), writing Transact-SQL code for the creation of all database tables, views, stored procedures, security, indexes and maintenance scripts for a sample system. Your final project will be the entire system creation, delivered as a series of scripts, along with the ERD and pertinent conceptual documents in a SQL Server Management Studio (SSMS) Solution.

The Conundrum of Cloud Computing Evidence

BuckWoody — Tue, 26 Jul 2011 12:56:08 GMT

“Who is using Windows Azure? How are they doing it?”

I get asked this all the time as I speak to our clients when we mention Windows or SQL Azure as a possible solutions to an architectural problem the company has. I completely understand the question. I’ve worked far longer outside of Microsoft than here, and one of my roles as a Systems Architect was to select solutions from a range of possibilities. When you’re faced with a decision like that, it saves a ton of time if you can find out where others have done the same thing and what problems and successes they had with this or that approach. I’m not a marketing person, so I work with clients directly all the time, and so folks know I’ve seen the way others do things. And they want to know what someone else has done before they try it.

But therein lies the rub.

Most folks aren’t willing to talk about their internal infrastructure much. We talk about how we do things here at Microsoft quite frequently, and if you’re not using this resource, definitely go research what we’ve done. In fact, I don’t think I’ve seen many other technology companies with this depth of information. For instance, here’s a quick list of the areas we talk about on our internal systems:

Microsoft Desktop Optimization Pack

Office System

System Center

Windows

And yes, Azure as you can see is part of that list - we’ve implemented it everywhere. But when I point out that we’re using IT resources just like any other company, I hear “yeah, but you’re Microsoft. You have lots of people to handle the systems, and you can just have the developer who wrote the software come over and fix it if it breaks.” Well, that’s not the way it works at all. When I got here, I met with some folks from Microsoft IT, and I was absolutely shocked at how few people manage our systems. From Systems Administrators all the way to the DBA’s, the ratio of technical resource to machines is really extraordinary, and I had far more folks managing systems for me in my other companies than we have here. And no, we don’t send developers to fix production systems “just for us”, although we will do that when we are using a beta of something that we haven’t even released to CTP yet.

But even with this evidence of ourselves, clients want to “see how others are doing things with Azure”. We do have the customer evidence site, and we have lots of case-studies there. But many of these lack technical details, again, because folks aren’t always willing to share that. That’s understandable - for instance, even though Microsoft does it, I’m not sure I would have the Visio diagrams for my company’s applications posted in a public place. There may even be legal or competitive reasons not to do that. So as you peruse that list, keep in mind these are only the companies that are willing to talk in public about their experience - we have far more on Azure than this list.

J.D. Meiers has a good blog post entry of a rundown of the companies that have released case studies on Azure. And be assured that we have a patterns and practices group that works with the teams here at Azure to make sure we apply what we learn as we help each client. And many of our partners that you use to help you implement technology are here at Microsoft this week, sharing customer stories (with permission, of course), which allows us to learn from them on how you’re doing things - what works and what doesn’t.

As time goes on I think you’ll see more patterns emerge from the engagements we’ve done. Right now those are sometimes a competitive advantage, so you’ll see us generalize the patterns into content we can release. For now, check out those case studies, and do make use of the Internal Microsoft IT sites. They really are quite detailed, and have a lot of information you can use.