What do I do to stay involved in IT?

In my opinion, one of the things that separates a "professional" from a "worker" is a demonstrated desire in learning about IT. The people who excel are always the ones who are reading about new developments, techniques and strategies.

In my case, I've always enjoyed learning about computers. I could keep my finger on the pulse of most of the IT universe 30 years ago. There was much less to keep track of and things moved much more slowly. As time has gone on, keeping track has become harder and harder to do. I still retain the simple desire to learn, but I don't always choose the most lucrative things to learn about. I'd estimate that 75% of the things that I've ever learned have not been put to good use.

In the 21st century, it's impossible to really "keep up" with IT. There is such a breadth of systems, applications, tools, languages, environments, hardware and software being created and maintained by millions of people that you literally can't know it all. Just keeping up with a particular area of concentration can be hard enough, and with the demands of "real life", I have come to believe that it's just a question of how quickly (or slowly) you fall behind on most of it.

I still read a number of blog articles. I follow about 25 blogs that are specific to SQL Server and about 170 sites that are IT related in some way. In the mid-oughties, IT blogs were a staple of my daily diet of news and information. I'd probably spend 1 to 2 hours a day reading posts. It seems that people are updating them less and less frequently and I find that there is a lot of rehashing of introductory subjects. (This is particularly true of things posted to LinkedIn.)

Since Google has announced the pending shutdown of it's Reader application, I've switched to Feedly. I'm  less efficient with Feedly than I was with Reader and Bloglines seems worse.The number of things I'm reading is down. In short, it feels like this area is dying out. I've decided to take this as an opportunity to find new sources of information.

I spend a lot of time on The Enterprise Cloud Site. There is a lot of comment there on how to best use "cloud" technologies (or perhaps how to avoid being run over by them). The site has a particular focus, and that focus requires me to stretch beyond my core competencies  The exciting part of cloud technology is that it potentially allows SMBs access to technologies that they would not otherwise be able to afford. The not-so-exciting part is that cloud technology puts pressure on the careers of administrators.

I listen to podcasts. Nothing really new here, podcasts are a great way to fill dead time. The interactive questioning between a host (or hosts) and a guest speaker allow podcasts to flesh out a topic in ways that a blog posting cannot. My favorites are:

• The "SQL Down Under" podcast, which you can find here, discusses a wide range of SQL Server issues. It tends to run a bit over an hour.
• The "RunAs Radio" podcast, which you can find here, focuses on a wide range of Windows administration issues. In addition to episodes dealing directly with SQL Server, there are also very interesting episodes discussing the virtualization of domain controllers, problems with passwords, hadoop on Azure, SharePoint, clusters, security issues and so on. These shows are about 30 minutes long and it is easy to listen to them even if they aren't 100% in your area of expertise.
• The ".Net Rocks" podcast, which you can find here and focuses on primarily on Windows development. Listening to IT podcasts that are out of one's particular area of concentration can be useful. It's always good to see something through a different perspective. It's good to know what the programmers are going to be interested in and how they might want to use (or abuse) the servers under a DBA's care. (LINQ is the classic example.) The .Net podcasts can get into into some fairly arcane programming issues, so sometimes I'll cut them short or just skip them. They do pump out a good number of episodes, so it can still be hard to keep up with them.

All of these podcasts are available for free through the iTunes store.

I'm still (very, very slowly) working my way through sessions from TechEd North America 2012. You can find those at this RSS feed, via Channel 9. There are many presentations, often given by people involved in the development of the product, feature or service. These presentations can get into very arcane things that are entirely out of my scope. Even when they are within my scope, they may describe situations that I will never see. I have found a few gems  in there, like a presentation on the new features in Windows Server 2012 file sharing.

It's sort of old-fashioned, but I attend my local SQL Server User's Group. In my case, that is PSSUG. I will be teaching a class for the next few months. This leads to a scheduling conflict with the regular PSSUG meetings. I plan to switch over to the Philly Business Intelligence User's Group because it meets on a different night.

In the future, I'm looking towards refocusing towards more formal learning in the form of MOOCs and, after 15 years of database administration and 25 years of IT experience, I might actually get around to taking those MCSE exams.

What to do about Google terminating Reader?

So, at about 1 am this morning, I found out that Google is shutting down it's widely-used Reader application. I read four different takes on it (I think I saw it on BGR first) and only then headed off to Reddit. (It's all over the Internet now. Apparently, other writers recovered from the shock more quickly than I did.)

 

Ironically, I found out that Google was smothering Reader while using Reader. 

 

This is particularly frustrating to me. I use Reader more than any other single thing. Reader channels probably 95% of my Internet interaction. I use it for a few hours every day. I use it at my desk. I use it during commercial breaks on TV. I use it when my wife falls asleep on the TV couch and when I can't sleep. I use it while waiting on line at McDonald's. I use it on commuter trains and on long car trips. It's a constant companion, I've spent more time with it than any pet and nearly any human. If my phone is charged and I'm not doing something else, I'm reading articles. Between my two Google accounts, I subscribe to about 225 feeds and I've read more than 315,000 items since the summer of 2010. I had so many feeds that I moved my "business stuff", which I had organically/non-strategically added to my personal account, off of my personal account and onto my business account a couple of years ago as an organizational tactic.

 

I've been using RSS feeds for so long, I'm not sure when I started. Eight to ten years ago, before I started using RSS feeds, I used several folders of bookmarked websites and went through them manually. I'd have to look at the website and remember what I had read and what I had not. Some folders were checked daily, others were checked weekly or monthly. This became unwieldy, as lots of sites do not update regularly and I spent more time scanning for things to read than actually reading. At some point, I made a strategic decision to stop reading web sites that had no RSS feed even thought they often had valuable content. (I'm looking at you, Storage Review.)

 

To read feeds, I first used Akregator when I used KDE/Linux for my main rig. After moving away from Linux, for a short time I tried Windows fat clients. That stopped when I wasn't allowed to plug my laptop into my client's corporate networks. I needed something I could access with a large number of machines and did not require an install, so that I could read during lunch and on breaks. Obviously, that called for a web site. I tried iGoogle and Bloglines. Neither never really clicked with me and I gave them up when I moved to Google Reader. I never even looked back. When I started using smartphones, the Reader web site was among the first that I bookmarked. When I moved to Android from S60, the Reader app was one of the first apps I installed.

 

This is a great opportunity for Yahoo, Bing, BlogLines and any other vendor. (Microsoft has kilotons of programming talent and megatons of infrastructure. They should be able to write and put up a replacement for Reader in a few weeks. They'd probably make the mistake of somehow making it Windows 8-only.) Google is making a mistake by abandoning a piece of the chess board. They were the de facto standard. Little "Add this to Google Reader" buttons are all over the Internet. They will be disappearing. Now someone else is going to get those users and those eyeballs. The upside is that we might get some innovation in the RSS space. First, we will simply have to replace what we are loosing.

 

I presume that this is somehow related to Google's push to remake themselves as "Google Plus". Reader was just about the only reason I ever posted anything to G+. When I realized it was easier to share things via email than G+ and there was no way to monetize things I sent to G+, I stopped posting to G+. Now I will have absolutely no reason to go anywhere near G+. 

Why kill Reader when G+ is a ghost town? Surely, Reader can't consume very much in the way of resources. Why not kill Orkut? If Google is "tightening up" it's offerings, why do I see so much hype around driverless cars and those X Ray glasses? Where is the revenue generation for those services? They are clearly spending tens of millions of dollars (or more) on these ever-forthcoming products. Does Google expect me to stare at ads while I walk down the street while wearing their glasses or drive down the road with their cameras on the top of my car? Does Google expect everyone to act as roaming data collectors for their databases?

In the post announcing the shutdown of Reader, Google made reference to the usage of Reader dropping. Every change they made to Reader in the last three years made the service worse, not better. If usage has dropped, Google has only themselves to blame. 

 

It's as if Microsoft and Google have entered into a contest to see who can make the biggest mistakes.

 

I'm often asked if anyone can rely on SaaS. Not if it is a free service, clearly. If such a popular service is dropped with little or no warning, less popular services must be even more prone to evaporation. Things are likely to get worse as the behemoths try to put up walls around their gardens.

 

(As a semi-related side note, when did Reader stop supporting OPML export? They support OPML import and OPML is the Lingua Franca of RSS aggregators. Google likes to brag about letting you take your data with you, but any data professional will know that the format of the data is almost as important as the data itself. If you can't import your data into another system, it's useless until you write a conversion tool. The careers of many programmers have been built on writing such tools. The vast majority of Reader users will not be able to write such a tool and they will have to rely on the kindness of strangers. I suspect that many of them will migrate their feeds manually, with many feeds being left behind and many blogs seeing a drop in pageviews.)

I am reminded of the del.icio.us fiasco from serveral years ago. That service seemed to come from nowhere and was wildly popular for a time. Yahoo bought it, screwed it up, and I (and many, many others) stopped using it. When Yahoo said that they were going to shut del.icio.us down, I migrated my data into Evernote and never looked back. Looking at it now, it seems that del.icio.us somehow got out from under Yahoo and is/was trying to rebuild what they had. Of course, they can't. There are elements of the Digg implosion in here, too. They had something good, they felt compelled to change it, their users found the changes were for the worse and they left. Surely, the Googlers are familiar with del.icio.us and Digg.

 

Looking at iGoogle now, I see that it is also marked for death and has already been eviscerated, so I won't be going back to that. I was surprised to find that Bloglines is still around. I've already moved a few feeds into BlogLines, but they don't seem to have any mobile app and I am still looking at this as an experiment. I may wind up with a few different solutions, each picked to follow certain types of feeds or to segregate "personal stuff" from "business stuff". For example, Shorpy's, a site for (large) historical photos, is better viewed on a desktop. CraigsList feeds often require a quick response, and I'd like to keep them on my phone.

 

My first steps towards migration are to cut down on the number of feeds I do have and to start trying other services. This morning, I tossed about 40% of my personal subscriptions. (Looking at CraigsList just makes me want to buy someone's old gear, anyway.) I am down to 31 subscriptions, from about 50. I'm not going to touch my 175+ "business" feeds yet. I'm starting by moving things to my re-invigorated Bloglines account that I don't need to read every day or really need to be viewed on a larger screen, like my The Big Picture and Shorpy's feeds. 

 

Why Programming Environments Matter, Gaming Edition

As I do some posting on another site, I've been running the BGR live stream of the Sony Playstation 4 launch on my second monitor and I've got something to say.

I'm not a "gamer". I stopped playing games back in 1999 when I found that I had lost yet another weekend to Quake and Tomb Raider. I spent innumerable hours playing Quake, TR, Doom (and many others -- the late 1990s were kind of slow for me, socially speaking) on my Micron Pentium II. Before that, Falcon 3.0 (and Commander Keen and Wolfenstein 3D) on my Northgate 386/33. In medieval times, Ultima on my Mac Plus and Adventure on my Atari 2600 occupied my time. I was never all that good, but the games absorbed my brain in a way that TV never did. I had to stop playing games because I didn't do much else in 1999, besides go to work.

 

Since then, I have watched developments in game hardware and software from the sidelines. I do have some observations about the situation with the forthcoming PS4 and XBOX 720 consoles and I'm interested in how the competition between Sony and Microsoft plays out

 

It's interesting to me that the much-hyped (back then) "Cell" and "Xenon" microprocessors (Sony and Microsoft, respectively) have been dumped in favor of x64. The older consoles both used parts derived from PowerPC architecture. When those consoles were released, there was a lot of gushing over "lifelike" animation and how powerful the chips were. (I'm sure that the stuff shown at Sony's launch today will look awesome. A year from now, what you see today will look weird. Ten years from now, it will look crappy. People's ability to detect animation seems to improve just as fast as the technology improves. Much like nuclear fusion and rocket boots, real-time, life-like animation is always a few years off into the future.) Additionally, it was alleged that both companies minimized piracy threats by using an unusual (meaning not x86) architecture. 

 

PowerPC chips were originally designed to be a scalable family of commodity, general-purpose parts. They were used in Macs, in various industrial situations and as on-board computers in vehicles. PowerPC didn't pan out and it isn't a viable option anymore. It hasn't been an option for serious computing since before Apple did away with them in 2006. Several years later, both high-end console companies are moving to x64. I presume that they have something up their wizardly (crypto) sleeves to clamp down on the pirates. 

 

(I do wonder why they haven't gone with ARM. Is it that 64 bit ARM processors won't be viable until later this year? Is ARM still not "quite there" with computing power? I keep hearing that games are GPU-limited and not CPU-limited, so why would it matter ifthe CPU is a little "light" on power? Is AMD hurting so badly that it needs to sell parts on a long-term contract to help guarantee it's survival? Couldn't Intel just open the gates and flood Sony and Microsoft with underclocked parts having the performance of earlier-generation 32nm i5 parts? Maybe some souped-up Atoms? Surely Intel need to use those fabs for something and it doesn't look like it will be chips for cell phones.)

 

With the switch in processor architectures, the obvious problem is that you won't be playing any of the games you already own on your PS4 (confirmed by Sony during the product launch) or XBOX720 (unless Microsoft comes up with something wizardly before the launch). That means that you will need to keep your old consoles around. Since everyone who wants a gaming console seems to have one, that means a lot of old consoles will be around for a while. Games are going to have to get a lot better before the new consoles start moving in impressive volume.

 

 

Enough meandering -- here's the real rub: 

 

One of Microsoft's superpowers is making things easy on developers. (Arguably, this is their best superpower.) Many of these developers will be coming from other areas of programming that Microsoft already dominates. They will be bringing their understanding of how to program the "Microsoft way" with them. Small learning curve. Easy. Fast-moving projects.

 

I have never heard anyone say that writing software for the PS3 is easy. It was hard to write for the PS3, it will be hard to port PS3 software to the PS4 (and take advantage of the PS4's improved feature set) and I expect that it will be hard to write software for the PS4 from scratch. Big learning curve. Hard. Slow-moving projects.

 

In short, Microsoft and Sony have pressed the reset button. The playing field is back to square zero and they are now in a drag race. Microsoft is much better at building development environments than Sony is.

 

The 6.4 billion dollar question is -- who will have more (and better) software, more quickly?

You know who I'm betting on.

Consequences of Casual Development

I did a fair amount of work with Lotus 1-2-3 back in the day, writing spreadsheets for other people. (I was paid and everything. Amazing.)

 

Tracking down errors in those spreadsheets was always a pain in the neck. Time has marched on, mercilessly. 1-2-3, Symphony, Jazz, Improv and even Quattro are just historical footnotes now. I haven't built a serious spreadsheet for anyone since 1991. I do use Excel, more as a "user" and not as a developer. I've never really dug into any of it's debugging features. For my own purposes, I use the relatively anemic Google Spreadsheet because it's good enough 90% of the time and I always have a browser window open.

 

I've often wondered (a nice word for "daydreamed") how people debug complex spreadsheets. Spreadsheet power users, while they can spell SDLC and know their way around a VLOOKUP(), do not strike me as the types who have backgrounds in TDD.

 

Apparently, I am not the only person who wonders and perhaps more people should wonder.

 

Enough of the meandering commentary...

If you are interested in software lifecycles, are following the BYOD/empowered-user movement or have simply wondered "Is it as bad everywhere else as it is here?", I suggest reading this (warning: some economy loonies in the comments) and some additional (#longread) commentary by IT people located here.

One of Microsoft's basic strategies has been to get developer tools into the hands of users and to simplify "programming" so that those users can be effective. They even invented a term for this new class of empowered users -- "power users". Excel is a result of this strategy. In addition to a rich language of functions, there is also a macro facility built on VBA. Word, Excel and Outlook are all automate-able tools for people who aren't professional programmers. Even Microsoft's Access database is more aimed at "power users" than full-fledged coders. (Plenty of people who wouldn't know how to start coding an IIS/SQLServer or LAMP web site are perfectly comfortable in Access. I'll even go out on a limb and say that Access works great for some projects. I've certainly said that before.)

 

Microsoft is continuing this strategy with it's latest "BI" initiatives. BI takes the drudgery of coding reports and puts it squarely in the hands of the users, which actual developers tend to like, while exploiting the power of modern computers. More on-target for this blog entry, it allows people to do even more with Excel. Great -- as long as we realize that this strategy is not without risk. Many users (and their managers) do not grasp why IT departments spend vast sums on QA. Perhaps those users need to lose vast sums before realizing that QA is an investment and not just an expense.

 

How I Migrated My Source Code from Subversion to Git

While at University in the eighties, I didn't learn much in the way of useful software development tactics or strategies. It was just a question of fulfilling the homework requirements and getting past the exams. I was an EE student and not a ComSci major, after all. When I started my first job out of college, which was as much about programming as it was engineering, I was introduced to version control in the form of the PolyTron Version Control System, or PVCS. At that time, I worked in a two-person coding group. PVCS kept us from stepping on each other's work and allowed us to track our changes, using nothing more than the legendary MS-DOS command line.

 

When I moved on to my second job, the coding environment was more complex and chaotic. I was surprised that the version control strategy consisted of occasionally pkzipping the source files. The product itself was somewhat confused. I've worked on many projects since then, and it always seems that the better-run projects have their VCS strategies mapped out. The development team's understanding of how to best use a VCS seems to correlate to the quality of the system being built. If the developers use the VCS as a dumping ground, with little distinction between it and a group of folders on a file share, it is often true that the project itself will be a mess. Ditto if checking code in happens infrequently, as some sort of afterthought. Ditto for lack of integration testing, among other things. As time has gone on, it seems that more and more teams do avail themselves of VCS and do learn the "ins-and-outs" of their chosen VCS. I believe that the large number of distributed, open-source projects that exist today have contributed to this positive development.

 

I've used a number of different VCS over the years. As I mentioned, PVCS was first. (I once interviewed for a job that entailed providing integration between PVCS and Visual Basic.) The second one was a version control system on SunOS called SCCS. IIRC, SCCS was extremely basic, with a pedigree that dates back to the seventies. I spent a couple of years working with SCCS and make files. I helped evaluate ClearCase for a few days. (We didn't adopt it. IIRC, it was pretty neat, but it took up too many resources on our HP minicomputer and we couldn't afford enough licenses for our development team.)  I used Microsoft's Source Safe and TFS. I managed to avoid using CVS for very much. 

 

My go-to VCS software for the better part of the last decade has been Subversion. I like Subversion for a few reasons. It is tiny and easy to install. Creating a repository is so easy that you can create a repository for a project that will only run for a day or two and throw the repository away afterwards. Subversion has built-in diff and merge tools, making it easy to see what you have changed between commits. It is easy to set up a server for subversion. I used to run my own subversion servers, on top of apache on linux using old Sun and Dell workstations and dealing with firewalls, port forwarding and DDNS. Eventually, after a series of power failures at my apartment, I moved my Subversion to a freebie online service. Running my own server was just too much effort and not enough reward. No one was going to hire me to run their Subversion server for them, so there wasn't much use in practicing all the time.

 

So, why move away from Subversion? I have been contemplating such a move for a couple of years. One (weak) reason is that I'm not using my repository as much as I used to. My Subversion repository has 3043 commits, spaced out over seven years. I haven't been committing very much this year (the last change was in July) as I find myself doing less and less interesting stuff. In addition to fewer commits, I'm keeping less in my Subversion repository than I used to. I'm relying on Microsoft's SkyDrive and similar products for some of the stuff that I used to keep in my cloud-based Subversion repository. For example, I've moved my copies of the SysInternals utilities from my Subversion repository to SkyDrive.

 

A stronger reason is that the popularity of Subversion seems to be dwindling in favor of Mercurial and (particularly) Git. Git has a lot of weight behind it because it is used by the linux kernel developers. Both systems are interesting in that they don't rely on a central point of control. Instead, everyone has a full copy of the repository and updated source code is passed around using a more egalitarian method. Each repository is more of a peer than a centralized point of control.

 

I'm not particularly worried about sharing my own stuff (it isn't groundbreaking or anything), but I think that knowing Git is more useful than knowing Subversion nowadays. I certainly see Git mentioned in more job want ads than Subversion. I don't think that you can really learn something without using it frequently (at least monthly, preferably daily), so it's time to chuck out Subversion and pick up Git. 

 

I'm not going to recite each detail of the process here, as there is plenty of information available online (you've probably already seen much of it) and no one has asked me for details. I'm only going to provide my highlights and observations.

 

Moving my repository from Subversion to Git was simple. Basically, Git supports direct importation of Subversion repositories via the "git svn clone" command. All you really need to do the import is the Git software. I installed the software, did a little prep work and ran the import process.

 

(It also seems that you can use Git as a sort of front-end to a shared Subversion repository. This way, you can use the Git tools without forcing a migration away from Subversion. This is an interesting idea and it certainly might be useful on large projects. I'm an army of one here, with no other person's wishes to get in the way. I'd rather keep things simple, so I did not explore this feature.) 

Installing the Windows version of Git is as easy as downloading an installer from a web site and running it. (You don't need a full-blown linux-like environment like Cygwin. I have used Cygwin before and Cygwin (particularly the X server) is great, but if you don't need a lot of linux "stuff" and you don't need bash, then Cygwin is overkill.) If you are on Windows, you want to make sure that you are running a recent enough build of Git. If not, the Subversion functionality may not be included. If you are on linux, it is possible that you already have git on your system. You may need to install additional packages such as git-core and git-svn. Exactly what packages must be installed and the exact commands to install those packages may vary by distribution, as it is with all things linux.

The only pre-migration task to be done is to create a small text file that maps users from the old Subversion repository to email addresses in the new Git repository. This was simple for me (four old users each map to one common email address), but could be tricky in environments with many users, particularly if those users have moved on. The hardest part of creating the text file was making sure that I had an entry for each of the old users in the Subversion repository because I wasn't 100% sure how many users I had used in the last nine years. There are scripts available that can look through the history of the relevant Subversion repository to create a text file that functions as a starting point for you to edit.

 

While actually running the import process, I ran into two real problems. The first problem was that the import process asks for user input at a certain point (it asks about the security fingerprint for the old subversion repository) and it seems that the libraries that are used to accept that user input do not work inside of a PowerShell shell window. My workaround for that was to Ctrl-C out of the attempt, close the PowerShell shell window and then use an old-fashioned CMD console window to run the import process. That worked fine and, so far, I haven't had the problem come up again and running Git in a PowerShell shell window has been OK.

 

The second problem cost me much more time. I used the --stdlayout command line switch because all of the examples I had seen did. The switch causes the import process to assume a certain, widely-used layout for the source code that exists in the Subversion repository. I did not follow this layout when I initially set up my Subversion repository and I never missed it, partly because my code is simple and partly because I haven't had the opportunity to bring others into the project. In short, with the switch, the import process looks for source files in certain locations. Since I did not set up those locations, the import process didn't find anything to import. The process simply ran for a while and then reported success without actually importing any code into my new Git repository. After spending some time swearing, I broke down and read the documentation on the command line switches. I realized that --stdlayout was trying to do something that didn't pertain to my repository. Removing the --stdlayout switch allowed the process to go forward.

 

As an exercise, I also ran through the same import using my linux Mint Virtual Machine (VM) running on my ESXi 5.1 server. The results were pretty much the same. Obviously, I used bash and I didn't have the PowerShell input problem. For whatever reason, running the import in the VM was around twice as fast as running it "on the metal" on my Windows 7 laptop. This is surprising because my ESXi server is pretty slow, being a six year old HP workstation with a pair of lowly 5150 Xeons.

 

Now that I have my repository out of Subversion and in Git, all I have to do is get used to the Git workflow and command line syntax.

Notes from PSSUG: SQL Server on Windows Azure and Visual Studio Debugging & Source Control

This blog entry consists of my notes and thoughts from the PSSUG meeting at Microsoft's offices in Malvern on 2012/12/12. Any misunderstandings are mine. The evening was broken up into three parts.

First, Kevin Howell presented "Visual Studio 2012: A Complete IDE (Debugging and Source Control". He covered some of the enhancements since Visual Studio 2010. He did a quick demo of server-side debugging of a stored procedure, and pointed out a few configuration changes that you must make to your solution before you can use this feature.

Kevin particularly likes the schema comparison feature, now part of SQL Server Data Tools, which I think debuted back in Visual Studio 2008 or 2005 as an add-on/down-loadable thing. He points out that you need to be using the Premium or Ultimate editions of Visual Studio 2012 to use schema comparison feature. The comparison feature does seem greatly improved, even over Visual Studio 2010 and is light years beyond what was available five years ago. To me, the VS interface still looks very busy, and it seems hard to know where to look for particular things.

The solution/localdb duality also seems a little confusing. I presume that a developer can make changes to the solution without updating the database running on localdb. When you then compare the localdb database to the "production" database running on a server somewhere, you will not see those changes. Microsoft does not seem to believe in shared database development environments.

One of the things that Kevin did was use the "Clean" menu pick before a "Build". I'd never noticed Clean before, even though I've used SSDT's predecessors to reverse engineer scores of databases. If you are having trouble with odd build errors, you might want to give Clean a try.

With the new Visual Studio comes a new version of TFS. (I keep meaning to switch from subversion to git.) It seems that you need to be running SQL Server 2008 R2 to host TFS 2012 and that you need to have Full Text Search (FTS) installed. (You need FTS to use TFS. Is there no coordination between acronym teams at Microsoft?)

Second, there was some time spent on PSSUG business.

• The election of board members was completed.
• Upcoming PSSUG and PASS events were detailed. Most importantly, as far as I am concerned, SQL Saturday #200 will be held in June, 2013. There is some talk of having more sessions than last year and perhaps some sessions that could be longer and more detailed than the one hour sessions that have been the rule in the past. In any event, it should be a great day as many people will have much practical experience with SQL Server 2012 by then. IIRC, the last SQL Saturday held here filled up a month or more in advance. You can register now.
• The Microsoft Technology Center (MTC) in Philly has created a web site to provide MTC news and videos shot during PSSUG presentations. (Microsoft's offices are really in Malvern, but I'll let that slide.)
• This might only be news to me, but SQL PASS will be held in Charlotte next year. Perhaps I can scare up the budget for Charlotte, it might even be within driving distance of Ashdar World Headquarters here in Downingtown. Seattle is awesome but it's a big drain for a small business.

Third, Rodger Doherty of Microsoft presented on "SQL Server on a Windows Azure Virtual Machine". He points out that SQL Server 2008, SQL Server 2008 R2 and SQL Server 2012 are supported. Since we are dealing with Virtual Machines (IaaS) and not SQL Azure's (PaaS), I would guess that older versions of SQL Server would run. However, if you have functionality or performance problems you should not expect to get help from Microsoft.

While Windows Azure provides some redundancy due to the way data disks are implemented, it does not provide a complete High Availability (HA) solution by itself. For true HA, you must use features provided by SQL Server. There is no support for Windows Failover Clusters, but database mirroring and AlwaysOn are supported. (The one quirk is that AlwaysOn listeners are not supported "yet". This might be a networking/VPN problem than a SQL Server problem.) The biggest HA hurdle to get over is latency, especially if you want to be in more than one region.

I'm 95% sure that log shipping still works, too. Microsoft doesn't seem to talk about log shipping very much anymore, but it occupies a warm spot in my heart. Log shipping is so non-fancy that I think it would be hard to break. If Microsoft's version has a problem, you can always write your own log shipping implementation in a day if you need to.

Licensing, as always, demands some attention. Right now, you have two options. There is "pay by the hour" licensing, in which you select from a gallery of images. This works pretty much like AWS. These images are sysprepped, apparently just like you would prepare them for a local, multiple-install scenario. It's important to realize that, once set loose, the image will first go through the usual steps of a sysprepped image and may reboot several times before the VM is ready for use. This process could take as long as 10 or 15 minutes but it is still much faster than going through a requisition process for a new local physical server.

If you are on Software Assurance, you can opt for "bring your own" licensing. This means that you could possibly do a p2v of a machine, copy the VHD to Azure and start running it on Microsoft's equipment.

The big part that seems to be missing is something like AWS's "reserved instances", where you can get a discount from the hourly rate if you commit to a longer period of time. There doesn't seem to be support for MSDN license holders yet and TechNet members are definitely shut out, though I do see references to "free" account offers floating around every few months. With AWS giving away small VM instances and a price war looming or already in effect, it would be great for Microsoft to follow suit.

As far as running SQL inside of Windows Azure, one should not expect high-performing I/O. You should expect more latency to the disks than you would get in a local set up. It seems that performance is more in line with consumer-grade SATA drives than 15 KRPM SAS drives or SSD. While there is an option to enable write-caching on drives that you put SQL Server data on, you shouldn't do that. It can lead to corrupted databases. If you need speed, you should probably work to ensure that the memory allocation for the VM can hold the entire database.

Each VM has a "D:", which is a non-persistent drive that is intended for data that does not have to survive a reboot. You should consider putting tempdb on these D: disks. If you put tempdb on the "C:", it will count against your storage and you will pay for it. Since the "D:" comes up with nothing on it (not even directories), you need to do a little work to create the directory path and relevant ACLs before SQL Server starts and tries to build the tempdb database somewhere.

Rodger kept using the word "blade". This might be a colloquialism or it might mean that Windows Azure is actually running on blade servers. If so, this just underlines the fact that these systems are not meant for high-performance, bleeding-edge databases. During the Q&A session, he cautioned against moving very large data warehouse implementations to Windows Azure, though smaller data warehouse implementations may be fine.

Pricing is by "VM size". You have a small number of choices. This is similar to the way that AWS started. AWS has added options as time has gone on and demand has picked up. There is no customization of one of these sizes. You can't say "I want lots of cores and RAM, but not so much disk space".

Page compression is supported in Windows Azure VMs. You do still need to be running Enterprise Edition SQL Server, however. The CPU performance penalty seems to be something on the order of 5%. YMMV.

Rodger stressed that these servers are on the open Internet and that you should be careful about opening firewall ports and choosing passwords. If you are running SQL Server on the default port (1433), your SA account will get probed. It is suggested to use port mapping and unusual ports for common services like RDP or SQL Server. If you can avoid opening those ports to the world, that would be better. There is a VPN available, but it is only compatible with certain hardware VPN devices at this time. Such devices aren't necessarily expensive, costing perhaps a few hundred dollars US, but they would tie your access down to one physical location and that might not be easily workable if you have several remote DBAs or are a traveling demo person.

In any case, I would advocate (re-)reading any SQL Server security best practices document that you can find before you start creating servers.

Another caution is that this new virtualization environment isn't officially released yet. That means that Microsoft may reset the environment in some way, nuking your stuff. Unless you can tolerate a couple of days of downtime while you rebuild everything, putting production systems up on Windows Azure right now isn't a great idea. After Microsoft officially opens Windows Azure for business, they are aiming for 99.5% uptime for non-HA systems and 99.95% uptime for systems that use some sort of HA technology.

An Active Directory server should use the smallest instance, as AD simply doesn't need many resources. You can extend your existing AD infrastructure into Microsoft's cloud.

There is a cost reporting scheme. It doesn't seem to be as flexible as what AWS provides, but it may be simpler and allow you to jump into IaaS more quickly.

There is an Early Adoption Cook Book with much useful advice.

Performance troubleshooting of systems may be difficult since there is no access into performance counters from the "host" of the VM.

To sum up my impressions, Windows Azure looks like it could easily grow into a AWS competitor. They will need to make many improvements before they are a match for AWS. To me, the two most immediate needs are a larger variety of instances (with respect to cores, sizing, bandwidth, etc) and some sort of reserved instance pricing. Microsoft has deep pockets and can ramp things up over a period of months or years, just like they have been fighting VMWare with Hyper-V. I would only use Windows Azure for development or test systems first and I would start with systems that require less performance.

That should be the last PSSUG meeting for 2012. See you next year.

Windows Devices Musings, for Late October 2012

With all of the flamage surrounding Windows 8, tablets and phones, I've been resisting making any comments. (I have so many negative comments to make about the Windows 8 UI that I sound like a crazed Unabomber, and there is little to be gained from venting at this point.)  For posterity's sake, I'm going to put down some random musings that might be fun to check back on in 2014.

I believe that the end game for tablets will be Microsoft selling tablets directly and without apology. Microsoft's formerly joined-at-the-hip hardware partners will be left trying to sell 'traditional' PCs (laptops and desktops) with an increasingly tablet-ified Windows. Some vendors may take stabs at shipping Linux distros (again), but that has it's own set of problems. There just isn't enough pricing room when the market wants to buy a tablet for $300 and Microsoft wants $150 or more for their software.

People seem to feel that the Surface tablets are too expensive to compete with iPads. With Balmer's "everything is a PC" mantra, why wouldn't a Windows Surface "tablet" be priced similarly to a laptop, especially when you add a keyboard?

I expect Windows RT tablets to be considered as a failure one or two years in, much like UltraBooks. Windows RT is not the Windows that people are familiar with. The Windows RT tablets have only been out a week and I've seen at least two people who claim to be able to out-type Word's ability to put characters on the screen. That might have been sort-of OK in 1992. Today, it is unacceptable. My guess is that Windows RT tablets sell OK up to and into the holiday buying season, but people sour on them by the end of Q1 in 2013 after they have had some time to see the flaws and Windows 8 Pro tablets are released. Windows RT needs improvements in processor power (or Word's code needs to be tightened up enormously) and screen resolution. At best, Windows RT will be seen as another flawed "1.0" Microsoft product and people will start to wait for the "3.0" release before buying in. I suspect that the third release will not happen.

If the existing hardware manufacturers are very unlucky, Microsoft will decide that they should make traditional laptops (with permanently attached keyboards) and desktops as well as tablets. Since keyboard feature so heavily in Microsoft's marketing for Surface 'tablets', Microsoft is arguably already making laptops. This could push companies like Dell, Asus and HP out of the market. Since Dell and HP use contract manufacturers, it is just a question of Microsoft engaging those same manufacturers. Since MS doesn't have to pay a license fee for Windows, they could be able to bid more than a Dell and still make more money. In short, the way has been shown by Apple and vertical integration is the new "in" thing.

If fewer and fewer companies are making desktops, at what point do the economies of scale that parts for desktops have enjoyed start to dwindle and pricing for desktops starts to go up, rather than down?

Microsoft's reputation for pushing a new technology hard and then unceremoniously dumping it is becoming widespread, unquestioned lore among developers. Silverlight is the stand-out example. I just rebuilt two of my systems and the only reason I have to install Silverlight is Netflix. The strategists at Netflix must feel like chumps.

One of the advantages that Windows has over other operating systems is it's ability to run on lots of different hardware: graphics adapters, network cards, RAID adapters, fiber channel HBAs, etc. Basically, you buy the gadget, stick it into the computer, install the drivers and off you go. Tablets aren't like that. (Arguably, computers aren't like that anymore either. I remember when there were dozens of graphics chip manufacturers. There are now three significant players in that space.) Apple tightly controls the hardware that goes into it's iDevices. (MacOS has always had a more limited range of hardware that could be used. Since most Mac users aren't using expandable machines like Mac Pros, this isn't as obvious as it used to be.)

Android is more fractured, but vendors choose the hardware that goes into a tablet or phone and then custom-build the software for it. It's not like an owner is going to replace the graphics card in their tablet. It isn't physically possible. My point being that the market that Microsoft is pushing Windows into erases one of the strengths of Windows.