OneDrive: Getting Rid of Groove.exe

Do you use OneDrive? Have you had problems with OneDrive sync to Office 365 and/or SharePoint document libraries? If you have, it’s possible you have a problem with competing OneDrive sync programs running on your system.

The old “OneDrive for Business” sync application (for Windows) has been replaced with the new “OneDrive” (for Windows) sync application that combined the OneDrive (Personal/Consumer) and OneDrive For Business (e.g. Office 365 OneDrive) capabilities. The new capabilities of the new OneDrive application seems to work…

Except when the old “OneDrive For Business” application is still running at the same time on a system as the new OneDrive sync client application. Underneath the covers, this old “OneDrive For Business” application is actually the “Groove.exe” application that is part of the Office application (for Windows) installation.

The problem results from the fact that the Office 2016 install is now separate from the OneDrive “New Client” installation. And Office 2016 still includes the old ODFB-Groove.exe installation and auto-run.

The “Transition from the previous OneDrive for Business Sync Client” page doesn’t actually stop Groove.exe from running even after you’ve installed the new OneDrive Sync Client. The “Fix OneDrive sync problems” page also doesn’t tell you how to get the old ODFB client to stop running. Several pages tell you to uninstall the old OneDrive for Business application, but that won’t work because it’s NOT listed as a separate program in the Control Panel>Uninstall or change a program page.

The result is that your OneDrive situation gets seriously confused on your system. The ODFB-Groove.exe still wants to sync with Office 365 and SharePoint, to the point where it gets in the way of the new OneDrive sync.

How can tell if you have this “battling OneDrives” on your system? Here are the symptoms:

1. You have more than one “blue cloud” icon in your system tray.

   The old ODFB-Groove.exe icon looks like this:

   

   The NEW ODFB icon (provided by the new OneDrive client application) looks like this:

   

   Notice the difference? It’s subtle. The old ODFB has a white border around the clouds (while in the systray), while the new one doesn’t.

   If you have only the white bordered clouds, you only have the old ODFB (running Groove.exe)

   If you only have the icon with no white borders around the clouds, you’re running the new ODFB (OneDrive) and you should be fine.

   If you have both icons, your system is going to give you problems with OneDrive. Which will lead to the next symptoms.

2. You have a SharePoint icon in your File Explorer’s Navigation Pane (the left pane):

   

   This indicates you have synced a SharePoint Document Library (or more) using the old ODFB-Groove client.

   If it has a “T” underneath the SharePoint, that means your old ODFB is seriously confused and misconfigured:

   

3. You still have Groove.exe in your Office application folders under the Program Files (x86) directory:

   

   (this is what it looks like when you do a search for Groove.exe on your Program Files (x86) directory

   We’ll actually, this alone doesn’t indicate fully that you’re running Groove. Exe. If you look in the Detail tab of your Task Manager, you’ll also see Groove.exe is running.

In several forums many people suggest renaming the Groove.exe file to have a different file extension (like .old). This does seem to fix the problem by keeping Groove. Exe from running after reboot — but this only works temporarily.

[Side note: It’s not clear to me where Groove.exe actually gets started. It’s not listed as one of the Start-up programs (see task manager), nor is it mentioned in any services. It seems some other Office 2016 executable that executes on startup/login also spawns the Groove.exe process. It’s definitely not obvious.]

The “fix” of renaming Groove.exe only works temporarily because Office 2016 notices that Groove.exe is missing and restores it at some point. Part of a built-in self-healing mechanism I imagine.

And because of that Groove.exe starts running again at some point and the “White-bordered cloud” reappears in the system tray. Not good.

It turns out the fix is to reconfigure the local Office 2016 installation so that it excludes the “Groove” feature (basically disabling it.) How, by running the Office 2016 Deployment Tool with an updated configuration file. Specifically, the configuration file needs to include the element:

<ExcludeApp ID=“Groove” />

This is the magic cookie – Running the Office 2016 Deployment Tool with this line will keep Groove.exe from running once and for all. Why this isn’t the default when the new OneDrive client is installed boggles the mind. I found this information thanks to Hugo Costelha on this technet forum page.

But not so fast.. The exact configuration of the configuration.xml file you set up for the Office 2016 deployment tool depends on which version of Office 2016 you’re running. It varies based on what Office 365 subscription you have (or have been assigned.) Here’s the page describing what “product Ids” map to which O365 subscriptions. For my system, the configuration file has this in it:

<Add OfficeClientEdition=“32” Channel=“Current”>

<Product ID=“O365ProPlusRetail”>

<Language ID=“en-us” />

</Product>

<Product ID=“VisioProRetail”>

<Language ID=“en-us” />

</Product>

<ExcludeApp ID=“Groove” />

</Add>

In this case, I added the Visio product info because I also run Visio.

Now running the Office 2016 Deployment tool with this configuration file makes sure my installation conforms to this configuration:

setup.exe /configure configuration.xml

 Turns out there are a lot of configuration options (and command line parameters) that are available for the Office 2016 Deployment Tool (which just shows up as setup.exe when ‘installed’ – unzipped).

So you need to make sure that the configuration file is correct for whomever you’re running this config tool for.

If you have the right automation tools (e.g. SCCM) that can automatically generate the right configuration file and run the setup.exe without intervention (and remotely), you can get this going (and you likely work in an enterprise). For use, we don’t have that infrastructure, so it’ll require going to each machine, picking the right config file (based on common subscription setups), and running it. Of course, none of the office apps can run while you run this setup tool – so they’ll have to do without the local Office apps for a while. (For O365 users, then can temporarily switch to the browser versions of the apps if they really need to.)

Running setup with excluding the Groove app works. It does not remove the Groove.exe file – it just doesn’t run it anymore.

Of course YMMV. It’s Microsoft technology.

================

Here’s a couple of other related items:

This page says that if you are running Windows 10 or Office 2016 that you already have the new OneDrive sync client. That’s BS. You may not. To make sure, download and install the new client anyway.

Where does the name “Groove” come from? It comes from the company that Ray Ozzie set up that created a really cool collaboration environment that supported dynamic synchronization. The company was Groove Networks and the product was called Groove, one of the first enterprise uses of peer-to-peer networking..

Styropod: taking smartphone Video for Architecture & Demos

While starting a new project, I often find myself watching a number of application demos and walkthroughs, both for existing systems and for potential new systems or components. This includes walkthrough of legacy systems about to be replaced (“this is how it works today…”) and vendor proof-of-concept demos for new products being considered.

The problem is that it’s hard to remember the details of a demo. Handwritten notes are too often sparse. Many times I find myself wanting to refer to a specific UI behavior or function shown during demos.

In most cases, these demos take place in a conference room with a projector that throws the screen display up on a wall. So the obvious solution is to record a video of the screen displayed on the wall (with the permission of the meeting participants.)

Here’s a quick sample video I shot (it’s not framed correctly because I rushed it. Normally you want to make sure the entire screen is within the video frame.)

Sample Video taken with Smartphone using StyroPod

So I’ve found myself recording as many demos or architectural design sessions I can. I also found that using my iPhone 4 is completely adequate to record these demonstrations and presentations. Even though the videos recorded this way won’t win any awards, they offer a number of advantages over only handwritten/typed notes; the video captures:

• Complete visual recall – You can always go back and find out exactly what happened in the UI or how the app/system functioned. No more saying “I think I remember seeing it do things this way.”
• Explanatory commentary – It’s easy to hear the running commentary accompanying the visuals.
• Related Side conversations – You can catch important side conversations that have relevance to the project.

Using videos of projected screens

Here are just some of the ways I’ve used these videos:

• Screen Snapshotting – There’s usually a handful of points in a demo when the screen/UI shows some critical visual state, but it’s impossible to know when they occur. It’s easier to go through the video later to take those important “screen captures” that can then be shared or documented.
• Capture of design reasoning – Too often we see the ‘end result’ of a design, but don’t have any record of the design reasoning or discussion that went into it. The video will often contain that design reasoning in the form of accompanying comments (e.g., “we ended up with this design because..”)
• Training – These videos make quick-and-dirty training materials, especially early in a project and for new team members.
• Reference material – These videos allow for historic references and easier side-by-side comparison of designs.

Projection screen videography via a Styro-pod

In the past, video ‘taping’ demos – particularly of the projector screen – in conference rooms required a camcorder and tripod. Now it just require two pieces of equipment: a smartphone and a Styrofoam cup.

The smartphone is easy: most of us (at least us techies doing architecture and system design work) have smartphones, most of which now have HD (usually 720p) support. I myself currently have/use an iPhone 4.

The Styro-pod (or StyroPod)

Typically many modern conference rooms have a projector on the table or mounted from the ceiling, with the computer’s displayed on a screen or blank wall. All that’s needed is a way to point the camera at that projected image.

Sure, I’d love to use a cool tripod setup, including a table-top tripod such as a GorillaPod. But not only do I travel with enough equipment as it is, I often will end up in a conference room without my bag – but I always have my phone with me. (In typical nerd fashion, I carry my phone on my belt.)

Just standing up the phone the table, leaning it on a solid object to get it at the correct angle to point towards the screen, usually isn’t enough. When I started to do this, too often the phone would simply slip and fall, especially if the table was bumped (which happens more often than not.)

The solution came in the form of a small Styrofoam cup that I took from the nearby coffee station. I found that I could easily cut an appropriate angled slot in the bottom of the cup and just mount the phone into that slot. Poof: StyroPod as an Instant stable platform. (Should I ™ that? 😉

Before I cut the slot into the cup, I find the approximate angle and distance I need to place the phone on the table so the projection screen fills in the video image. I the cut a slot at that angle for the depth of the phone. It doesn’t have to be exact; I found that the cup allows for some amount of adjustment through a little pushing or twisting. (If the cup gets screwed up somehow, I just start with a new cup.)

Tips

Here are some quick tips on using your smartphone to record these quick reference videos.

• Plug it in – Recording video sucks up the battery
• Use HD (if available) – The more detail you can capture the better.
• Make sure there’s Lots of free storage/memory available – You’ll need about 2GB for 30 minutes of video (at least for an iPhone 4
• Turn on Airplane mode – if you get a call while recording, it’ll stop recording.
• Watch for video length limitations – on the iPhone 4 it seems that videos are limited to just under 4GB, which gives you about 4
  0-60 minutes, depending on video complexity.
• Import and name the videos as soon as possible – the labeling rule applies here. Also, the sooner you import them into your laptop/pc, the sooner you can delete the videos from your phone and have space for more.

It’s been done

Of course this is nothing new. YouTube has plenty of videos of “screen captures” taken with smartphones. Microsoft’s Channel 9 is a great example of taking informal videos to capture architecture explanations and design overviews. However, I continually encounter IT and software organizations that still consider video too high-tech to capture the demos, designs, and discussion that drive their system designs.

Instead of having low-cost (but visually useful) videos of design and demo sessions, too many companies spend their time and money getting people in a room to explore design ideas (and reasoning) – and then rely entirely on people’s ephemeral memory and hard-to-share handwritten notes . How many times have you heard “do you remember seeing…?” and other comments when your team members try to recall details from a demo or design session?

Why not use screen-capture software? Ideally, yes, using a screen capture tool like Captivate, Camtasia, or CamStudio provides for a higher quality video from computer screens. They’re great; however, they have to be installed (and tested) ahead of time on the laptop/pc used to demonstrate designs.

Also, screen capture software (even if it’s installed on the ‘demo machine’) is not as fast and versatile as using a smartphone. Not only are smartphones readily available, but they can not only capture the “screen”, but can also easily capture the whiteboard discussion that accompanies architecture design presentations.

A smartphone can quickly turn a vaguely recalled discussion, demo, and even excellent set of ideas that emerged on a whiteboard into a useful architecture artifact. In the case of whiteboard discussions, often the most important information is in the action: how the diagrams evolved and discussed, not the final static whiteboard image at the end of the meeting.

Limitations (but no show-stoppers)

There are many limitations in taking smartphone videos of demos and architecture presentations; I’m sure you’ve already thought of several.

In addition to the specific smartphone limitations mentioned above, here are what I consider critical shortfalls to consider:

Video is a sequential medium – Unless you spend lots of time editing, viewing a video takes time (but that’s kind of the point as it contains all the detail – even the dead-air and fluff.)

• Privacy concerns – some folks may not like the idea of having a demo or screen discussion recorded. By only recording the projection screen, it’s easy to keep to other meeting participants visually out of the recording, which can lower resistance to recording.
• Size and sharing – With file sizes in GBs, it’s still not easy to store and share these kinds of videos. Enterprise portals typically won’t support uploads that large. YouTube is an possibility (uploading as unlisted), but that increasing the potential privacy and confidentiality issues. So far the primary means of sharing I’ve used are USB drives and traditional internal file servers, but I’ve also started using Dropbox and SkyDrive as well, since those allow for controlled access.
• Useful shelf-life – Not all videos taken this way are useful, especially over time. But like with digital photography, it’s ok to take lots of videos and get rid of them later (or just archiving them). And remember, the best camera is the one you actually have with you (and use).
• Keystoning – With the smartphone on the conference room table, pointing upwards towards the screen, the angle of the lens creates some visual distortion. Yeah, it’s not great, but it’s a minor issue from my standpoint.
• Environmental concerns – Using a disposable Styrofoam cup isn’t the best environmental choice. I haven’t used a paper cup as a smartphone/camera stand yet, but it’ll probably work as well. Maybe someone will create a foldable adjustable stand for recording video at an angle. Perhaps Lego blocks are a better choice (As an AFOL, I’ll give a try sometime.)

So the next time someone starts an application walkthrough or a architectural design on a whiteboard, grab a cup and fire up your smartphone camera.

my moleskine mods

I’ve been using Moleskine Pocket notebooks for several years now. I ended up become a fan and avid user of these notebooks because, unlike the many types of notebooks or organizers I had used in the past, the Moleskine Pockets fit, well, in my front pants pocket. Other small notebook designs, such as Franklin Covey Compact Day Planners or the original TimeManager I started with in 1986, just didn’t work because I had to carry them (which meant I usually didn’t) or use a bag. Instead, the Moleskine Pocket notebooks fit – with Pen as you’ll see – in my pants front pocket.

A few years ago, it seems Moleskine changed some of the materials and assembly process, leading to pocket notebooks that started to show weaknesses in several areas.

Below are two examples of these weaknesses. The left photo shows how pages started ripping from each other, thereby losing the binding. The right photo shows a separated bottom (closed) edge of the rear cover pocket.

So, I ended up with the following mods to my moleskine to make it ready for use:

• Taping the pen to the binding
• Adding reinforcing tape at key weakness points using two different kinds of tape
• Taping in printed copies of common information I want in all my notebooks

Taping the Pen to the Binding

Although not a new mod, I experimented with a number of pen types before I settled on the following combination: A Pilot Precise V5 pen, with its clip inside the binding and the cap taped to the notebook itself. I used a Pilot Precise V5 pen because the top of its cap is flush with the top of the notebook, allowing it to fit nicely in my pocket with the pen. The pen body snaps firmly to the cap, which makes sure the pen stays in place while the notebook/pen combo is in my pocket.

I use black Hockey Stick Tape (cloth tape) to tape the pen cap in the binding, as well as for reinforcement on other parts of the notebook. I did end up adding a small strip of hockey tape into and over the top edge of the binding; otherwise, the pen clip can rip out the top part of the binding. Here’s a close up of the pen area:

Generally, I add an additional strip of hockey tape along the top half the outside binding to give it further support. Then I tape the cap on using two strips of tape.

Adding more tape for strengthening the weak points

After adding a few more strips of hockey tape to the edges (including the bottom edge of the back cover’s pocket), the end result looks like this:

I then add a small strip of the hockey tape on each of the cloth sides of the back cover pocket:

But that’s not enough. To keep the Moleskine pages from ripping, I add clear packing tape to the inside center at the following pages:

• Inside the front and back covers
• Inside the first and last inside cover (blank cardboard) pages and the first / last paper sheets of the notebook repectively
• Between the 7th and the 8th paper sheets from the front (not including the front inside cardboard page)
• Between the 7th and the 8th paper sheets from the back (not including the back inside cardboard page)

Here’s the clear (shiny) packing tape tape inside the back cover:

Adding common information in the notebook

I also have a set of two printed pages with common numbers and information I regularly need to refer to (like by passport number). I cut those two pages down so they fit in my moleskine and then tape them into the back cardboard inside (last) page using clear packing tape. Generally, I use a personal (sort of secret) encoding method for any sensitive numbers on the pages I tape in.

My Moleskine notebooks typically last two to three months before they fill up. When I archive them into a box, I use a standard labelmaker (using 1/2” tape) to create a label indicating the year and months of that notebook:

I occasionally
scan or photograph select pages out of my notebooks into Evernote (which supports handwriting recognition so I can search my handwritten notes.) I’d like to be able scan all my pages out of each of my notebooks, but it would take far to long. (And using a LiveScribe pen won’t work because there’s no Moleskine pocket notebook that has the “Dot” paper – the LiveScribe pocket notebook is a lousy substitute – as well as the problem that the LiveScribe pens are too large to tape to the pocket notebooks and stick into my pocket.)

At this point, the Moleskine Pocket notebook remains my primary form/media to write in/on. I also make heavy use of Evernote (including on my iPhone and iPad). I’ve started using Note Taker HD on my iPad as well. Note Taker HD is the most innovative table writing program I’ve seen on the iPad; it works pretty well with the new Wacom Bamboo Stylus for the iPad. However, it’s still not as convenient as just pulling a small notebook out of my pocket – which I’ll always have with me.

I’m still debating with myself if I should buy a few boxes of Moleskine Pocket notebooks to last me for many years. Prior to 2006, I purchased one box of 20+ notebooks (can’t remember the exact count) because the company was pretty small. Now it seems Moleskine is (I hope) here to stay and will keep making these great books for at least the rest of my life.

iPad and Zite

I recently picked up an iPad 2; ok, I actually stood in line for 4 hours to get one. Fantastic device. Steve Jobs was right in 1984, it just took him 16 years to realize the original vision for the Macintosh: The computer for the rest of us.

After hearing about it on Twit’s iPad today, I fired up the app Zite, which provides a newspaper/magazine style experience in reading articles linked in my twitter feed (and similar RSS feeds). What’s nice about it is that Zite gets through the often cryptic twitter messages that wrap the links to interesting articles. Instead, it brings those articles into a easily browsable iPad friendly format for easy review and reading. Additionally, it adds a TiVo-like rating system so you can specify what articles you like and which ones you don’t.

Although I haven’t used Zite all that long, the automatic categorization system seems to work well so far. I suspect that Zite will take the role of one of my primary news apps. I particularly like the sharing feature, although it’s a bit redundant to tweet about an article that I got via a twitter feed. Zite also avoids the duplication of articles, even when they are linked via different shortened URLs, which is relatively common given the twitter accounts I follow.

The only complaint I have so far is actually a feature request: add the ability to copy the entire article to my Evernote account. (Yes, I know about emailing into Evernote, but only the link gets emailed.)

A side note regarding the iPad 2: while using the iPad the evening after I got it, I noticed that the battery percentage dropped by 1% every few minutes. I thought to myself “the battery is going down really fast.” Of course, I realized after I did calculations that at the rate it was dropping, the battery would run out in … ten hours. Oh, right. Interesting how I perceived a rapid drop with the visible percentage count, versus I hardly notice the battery indicator on my iPhone ( where I’m not showing the percentage.)

DoubleSight USB Monitor TIPS

I recently bought myself a DoubleSight USB Monitor (specifically the 9” DS-90U), as I was getting tired of only using a single laptop screen when traveling.

As MS has proven, using a second monitor improves productivity – particular when software development is involved. Also, given that much of my communications with others occurs through channels that require my continuous partial peripheral attention (e.g., email, IM), I was constantly switching windows or managing screen real estate while trying to get work done.

I had been looking for a portable USB monitor for a while, considering both the DoubleSight and the Mimo models. I finally chose the DoubleSight for four reasons: 1) cheaper, 2) good reviews from “traveling” users, 3) 9” is more than 7”, and 4) I’m an Amazon Prime customer. However, you may find the Mimo is a better choice for you. I’m not aware of any other vendors of portable USB monitors.

I found the physical form factor and engineering is extremely well done. The monitor itself is solid and has a hard plastic cover. The foldable stand was also well-built and strong. Here’s a photo of how I set it up (to the right of my laptop screen.)

Using Windows 7, it’s a cinch to change the orientation and relative height of the monitor. I chose to stand the DoubleSight in Portrait style, as it’s about the same height as my laptop screen and takes up less horizontal space. As I use the screen for “side channel” applications (like Sametime), Portrait works fine for me.

I made sure to download and install the latest driver from the DoubleSight web site before plugging in the monitor for the first time. I’m not sure it mattered, but I figured I’d keep control over the driver install process.

Based on my experience with the monitor for the past couple of months, here are some tips for anyone getting a DoubleSight monitor:

• Don’t expect a high-speed monitor – the USB monitor uses the CPU and regular RAM, not the graphics chip. It’s not bad though, as Aero glass seems to work fine, even on my anemic old ThinkPad T60. I haven’t tried running video over the USB monitors yet (but have no need to.)
• Plug in the correct plug!  The cable that comes with the monitor is a dual-plug USB cable, which enables folks with low-power USB ports on their PC to use 2 USB ports for power. My T60’s USB ports provide adequate power, so I only need to use one of the two plugs on the cable. However, I found that you must use the main plug (with two wires coming out of it), rather than the secondary plug. (See Pic). The first time I accidently plugged in the secondary (thin wire) plug, the DoubleSight’s power light was on/green, but the DoubleSight wasn’t working.

  I spent about 10 minutes trying to figure out if the monitor was bad or if I had a driver problem. Neither, I just plugged in the wrong plug – the secondary plug only supplies power and does not provide a full USB connection. So if you find yourself wondering why the screen remained black after you plugged in the DoubleSight, it’s because you used the wrong plug.
  
  I tried using a regular USB cable with a Mini-USB port, but it didn’t seem to provide the power correctly. In theory, a good Mini-B USB cable should do the trick; for now, I’m carrying around the “double cable” (a bit cumbersome.)

• Secure the Attachment Knob for Travel – The stand folds up nicely, but the screw knob for securing the monitor to the stand could easily be lost when traveling, rendering the monitor less useful. Here’s the knob holding the monitor to the stand:
  
  Although not foolproof, I used a set of velcro dots to secure the knob to the stand when it’s folded up. I used 3 velcro dots, rather than one, to make sure the knob stayed on as tightly as possible during travel. Unfortunately, the stand isn’t as compact with the knob velcroed to it, but that’s a small price to pay for making sure the knob stays around.
  
  Here’s knob attached to the stand via velcro:
  
• Be aware what happens when using a laptop – When I closed my laptop cover for the first time, Windows 7 cheerfully made my USB monitor the main “external” monitors. Not a problem, but a bit jarring the first time.

That’s all on that subject. Enjoy.

Testing image insertion in live writer

Testing Insertion of an image…

ANOTHER BLOG POST ON CLOUD COMPUTING

With apologies and respect to Sherman R. Alpert and Richard B. Lam, who published the original version for Java and the Internet in 1997:

Originally titled: The Ultimately Publishable Computer Science Paper for the Latter 2000’s: A Tip for Authors – Too long.

For the benefit of potential authors requiring advice on how to get published, we present the form and the content of the paper most likely to be accepted for publication in a respected computer science or IT journal in 2009.

Abstract
Blah blah blah Cloud Computing . Blah blah blah SaaS blah blah blah blah blah blah blah Web 2.0 blah.

Introduction
Blah blah blah Cloud Computing blah blah blah. Amazon EC2 blah blah blah blah Internet. Blah blah blah blah? Blah blah blah Web. Blah blah blah Google (blah) blah blah blah. Blah blah blah blah Cloud.1 Blah blah blah blah. Blah blah blah. blah blah blah blah. Blah Cloud blah blah Web blah blah. Blah blah blah blah blah blah AWS. Blah blah. Yadda yadda yadda. Blah blah blah blah Cloud. Blah blah blah. Blah blah blah blah blah Web blah. Blah blah blah Amazon. Blah blah blah. Blah blah blah Private Cloud. Blah blah blah blah. Blah blah blah blah Public Cloud. IaaS blah blah blah. Blah blah blah blah. Blah SaaS

Figure 1. Our inspiration

blah blah blah Eucalyptus. Blah blah blah blah. Blah blah Cloud blah. blah blah Data Center blah blah. Blah Open Source blah blah blah Security. Blah blah blah Cloud (blah) blah blah blah. Blah Christopher Hoff blah blah. Blah blah blah blah? Blah IBM, Cisco, HP, Oracle and Microsoft blah blah Internet. Blah blah blah Grid (blah) blah blah blah. Blah blah blah blah Amazon. Blah blah blah Servers blah. Blah blah blah. Blah Internet blah blah. Blah blah blah blah Web. Blah blah. Blah blah blah. Blah blah blah Cloudbursting blah blah. Blah blah. Blah blah blah. Blah blah blah blah blah Cloud.

Conclusion
Blah blah blah Internet. Blah blah blah blah. blah blah blah blah Cloud. Blah blah. Blah blah Cloud Computing. Blah blah blah blah. Yadda yadda yadda.

References
1. Blah, B. and Blah, C. Cloud Blah blah blah. Yadda yadda yadda. Blah Blah, 20 whenever, pp. blah.
2. Blah, B. and Blah, C. Blah Data Center blah. Yadda yadda yadda. Cloudification Journal Blah Blah, 20whenever,
pp. blah.
3. Blah, B. and Blah, C. Blah blah blah. Yadda yadda yadda. Blah Blah, 20whenever, pp. blah.

Patterns for moving to the Cloud – a ms seminar review

Technorati Tags: Cloud,CloudComputing,Microsoft,Azure

Today I attended a web seminar from Microsoft entitled “Pragmatic Patterns for Architects – Patterns for moving to the Cloud”, which was actually an introduction to approaches deploying applications into a cloud environment and related patterns. Here, for your enjoyment or argument, is a quick summary of that seminar.

There weren’t any particularly new cloud approaches/patterns mentioned in this seminar, but I really liked some of their visual models they used to describe the patterns and identifying key architectural issues. Azure was mentioned and referenced, but the seminar was largely agnostic about what cloud platform is being used.

The seminar covered 5 different "patterns" (really approaches) to bringing applications to the cloud. An underlying statement (which I disagree with) is that the cloud is only just about moving applications, not about special “cloud” applications. However, for the scenarios they described, the 5 patterns they talked about provided a good introduction to thinking about what it takes to move applications into the cloud.

The 5 patterns they described are:

1. Transference – Moving applications or services from in-premise operation to cloud operation for economic, consolidation, or prototyping purposes. This really is the simplest of the patterns, but only works when applications are generally stand-alone, with no major integration to on-premise services.
2. Scale & Multi-Tenancy – For this they described applications that are subjected to possible rapid growth (e.g. viral web site) that cannot be predicted. They indicated the primary driver for this approach is the economics of avoiding over capacity.
3. Burst Computing – This approach is also driven by the economics of avoiding over capacity.
4. Elastic Storage – The example they used for this approach was storing/sharing MRI images in healthcare, where data growth could occur exponentially. They described the economics for this being driven by storage management costs, not storage technology costs.
5. Inter-organization Communication – The example they used to describe this approach was a clinical trial applications, requiring a large and changing number of organizations to use the application. The primary driver they mentioned for this was the economics of infrastructure management.

The presenters did point out that these were only a “starting set of patterns”, not an exhaustive list.

What I liked in the presentation is the simple visual model they used to describe how the patterns are realized. It’s a almost typical stack model, only that model is used to indicate which components (and when) operate on-premise, in a hosted environment, or on the cloud.

One of their early examples was describing how using Security Token Services to provide brokered authentication services between a hosted app and an on-premise Active Directory server. (yes, the first example was not a cloud based application, just a service) Not surprisingly, the example revolved around hosted Exchange:

What was interesting here was their use of lines, color, callouts, and color animation to provide a clearer example of how this application operates and integrates across layers and across infrastructure/services providers.  In the image above, the red lines/outlines were part of a visual sequence of how authentication (or auth rejection) is accomplished in this model.

Transference

Their ‘takeaway’ for the Transference pattern was to watch for dependencies across different providers. In some cases (with legacy apps, I suspect many cases), the level of refitting or customization of an existing app may be too large to justify a move to the cloud.  However, I suspect this could be an opportunity to for CSC to build/provide services that make it easier to move legacy applications to the cloud while maintaining the illusion of direct integration to any remaining on-premise or hosted systems/components.

Scale/Multi-Tenancy

They made a point to describe this as the “opposite to the pattern of predicting the growth of a web site”.  The walked through an example (see diagram below) where the number of servers being allocated were easily configured (up or down) in the Azure app configuration file. (They did not provide any example of how this scaling could be done dynamically based on load.)

 

They did point out a key aspect of cloud that doesn’t get mentioned enough (except by Mark Masterson): You can turn off what you don’t need. Deprovisioning in the cloud is much easier and cost effective than trying to deal with unused hardware.

Burst Computing

For their Burst Computing pattern example, they got more Azure specific, where Azure supports the notion of "Worker Roles" for processing (ie batch or background processing). Users would never interact directly with these worker roles, but rather use the presentation (‘web role’) components to send/receive data. The data or commands would then be sent to/from the worker roles via tables or queues. Here’s the diagram they use to describe this setup, using a sample application “PrimeSolvr”.

I found it strange that they didn’t use the popular term “cloudbursting”. Someone have a trademark on that already?

Elastic Storage

With Elastic Storage, the described the common problems of file/DB storage & limits of on-premise storage growth, including the issue of server affinity of data. The examples they dived into were more about relatively independent data objects, such as blobs and simple tables. This reminded me of Greenblatt’s idea o
f Moby Address Space that came out many years ago (in my old Lisp Machine/Symbolics days)

In their "MRI Image" storage example, the described that the application (primarily front-ends) would need to take into consideration the access model ("code near" vs "code far" models– e.g. how to chunk the data appropriately for faster response and to avoid timeouts.)

They did allude to the availability of relational data structures in Azure through TDS – Tabular Data Streams; something I’ll have to look at more closely later.

Inter-Organizational Communications

The last pattern focused on applications that have a large or unpredictable number of organizations using & collaborating with a complex application.  Here they described an example (more of a pub/sub model) that uses the .NET Service Bus to route messages coming in from different orgs. They mentioned that this still required a polling model for notifying receivers. There doesn’t seem to be a formal ‘push’ mechanism with Azure yet (but I’m just guessing as I haven’t dived into Azure yet.)

 

In describing the workflow support in Azure, the presenters described the possibilities of hybrid models, where components of an application can be hosted across all three major infrastructure provider types.

 

The web seminar was hosted/presented by Microsoft’s Strategy & Architecture Council, part of Microsoft’s MSDN Architecture Center.

As this was an introductory seminar, they didn’t go into the many aspects/issues still being worked out with cloud computing (e.g. security, compliance, etc.) Still, it was a useful seminar (at least for me), particularly since it gave me some great ideas on how to visualize ‘cloud app’ architectures.  Unless you’re a guru already with Cloud systems, I recommend this seminar, the recording of which should be online soon (go to the SAC blog to find out when.)

Ten deadly sins of Architecture

Here’s a repost of something I wrote about 4 years ago. I think it still applies.

 

This is my first take at some thoughts on Architecture that have been swirling in my head for many years. Much of this comes from my experiences and the vast knowledge and wisdom of my many architecture friends & colleagues.

The ten deadly sins below summarize many of the common mistakes I’ve seen (and made) in system/software/application architecture over the past 20 years. These traps can be just as fatal as the typical software project management mistakes. The 10 are (by title):

1. Pursuing “Holy Grail” Architectures
2. Set in stone: Fixed Architecture
3. Materials-Free architecture
4. Architecture as first-order goal
5. Architecture by Edict
6. Spray-on architecture
7. “MIT Layer Syndrome”
8. One-size fits all
9. Instant Architecture
10. Pattern Madness

I’ll summarize each of these below and (if I get to it) try to post a more detailed essay on each. Actually, I’d love if others could chime in with their own experiences to support these sins, debunk them, or add new ones. Note that these sins are related to architecture, not just technology or software development.

1. Pursuing “Holy Grail” Architecture

I’ve seen many projects where the architect or designer is targeting a perfect architecture, an ideal state of design. Often this takes the form of a specific architectural target, such as Unlimited scalability, a perfectly abstract object design, a perfectly normalized database, or complete platform independence. Another form of this sin is complete focus on a single architectural design concept, such as Service-Oriented Architecture, or Thin-Client. (“If we implement SOA, we’ll have complete flexibility!”)

2. Set in Stone: Fixed Architecture

This one really annoys me: designing/implementing an architecture with the assumption that it will never change or need to change once deployed. Even worse are architects who assume their architecture design will not change (nor need to) throughout its implementation and deployment. Good Architecture must assume some aspects of change (if not accommodate change). Heck, even a building’s architecture changes over time. One of the best architects I’ve ever worked with describes system architecture more akin to landscaping (rather than building design), as the architects role is to design an evolving, living system.

3. Materials-Free architecture

Software architects love the abstract. Often this love is at the expense of reality. It’s easier to come up with a great architecture if you don’t have to consider the realities of the materials used to implement it. By not considering the building materials, you end up with conceptual great architectures that can still fail because of the materials, like the Titanic’s brittle hull plates. Architecture designs are only hypotheses until they are tested through actual systems.

Don’t, however, think that I’m proposing the opposite: that architecture is entirely driven by materials. Quite the contrary. Materials by themselves make for lousy (or accidental) architectures. It is good architecture design that enables the best use of the materials and build around their limitations. Moreover, architectural practices enable us to change the materials over time. Just don’t expect the architecture to overcome all limitations of the materials.

4. Architecture as first-order goal

Why does the system architecture exist? Unless you’re working with Grant money, it shouldn’t be the architecture itself. Too often architects make the architectural design the goal of the project, relegating the true goal to a secondary, if not lost, priority. Architecture is only a means to the goal – a working system for a shared purpose (usually involving making more money.) (e.g. SOA is not the goal.) If you don’t get this point, read (or listen) to the book The Goal.

5. Architecture by Edict

Pre-designed or pre-fabricated IT/App architectures (e.g. ERP, CRM products) aren’t necessarily a bad thing – if the trade-offs are thoroughly understood. However, too often architectural decisions are made and implemented by edict, rather than reasoning. (This sometime goes together with sin #4). Most of us know of CIOs that have said “we’re going to use ____ to solve our problem”, and then leave the architect or IT staff to perform superhuman acts to actually make it work (and – unfortunately – often do make it work, leading the CIO to think she/he has made the right decision.) With basic technology platform choices, such as J2EE vs. .NET, it may be fine (both can work.) However, simply deciding on an architecture, or worse, core software product, before understanding the business and architecture requirements usually leads to disaster.

6. Spray-on architecture

One of many gems of architecture wisdom it learned from Lynne Whitehorn-Umphres is that you can’t just add architecture after the fact, which she referred to taking “Spray-on” approach (Refactoring can help, but can’t solve fundamental architectural problems.) Scalability, Security, and many core architectural design stances must be addressed early rather than later.

7. “MIT Layer Syndrome”

Over 15 years ago, Bachman Information Systems developers (actually one from MIT) had to design a graphic UI/Window system from scratch in LISP (running in MS-DOS). Too achieve maximum flexibility, it was designed with a large number of abstraction layers (e.g. bitblt, rendering, drawing, shapes, window, canvas, feltboard, etc.) A well designed system with abysmal runtime performance. Abstraction layers are important architectural constructs. There’s a danger, however, of the seductive nature of these layers – they make architecture look/sound better than they actually turn out to be. Joel Splosky has a good writeup on this issue. (Note: As David Krieger once pointed out, all software is based on abstraction. The only real things are valent electrons flowing through silicon – everything else (OS, Apps, architecture) is a set of structured illusions that make systems ‘work’).

8. One-size fits all

Thin Client. Yeah, right. ’nuff said.

9. Instant Architecture

EAI, XML, BPM, SOA, etc. – All you need is one architecture. Or better yet, how about one platform or product? Anyone remember Broadvision? How about your investment in CORBA? Simply buying an ‘architecture’ is not enough, sometimes downright wrong. If you do by a set of architectural practices and implementations, know what you’re getting into. Here’s the basic trade-off: get a basic architecture platform (e.g. J2EE, .NET) and you’ll have to build on top of it. Or, get a pre-build ‘instant’ architecture (e.g. ERP, BPM pure-play) and live with the architectural choices of the vendor (or the death of the vendor).

10. Pattern Madness

I’m still trying to work this one out. Patterns have been around for a long time, but there’s been more interest in patterns recently (read: last 5 years). What I’ve seen in some cases is that some architects equate architecture with patterns. Simply apply a generous amount of Sun Blueprints and, voila!, they expect to have an architecture. Good architectural designs use patterns, but patterns do not themselves make an architecture.

 

HP 110 – Portable computing redux

HP just announced a new netbook, the HP Mini 110. Engadget has a posting with Video covering this new netbook, which seems to replace the HP Mini 1000. Unlike the HP Mini 1000, this 110 seems to have a bit more beefy features (except that it lost Bluetooth). My impression is that they took many of the great features of the (somewhat anemic) HP 2113 and applied them to the HP Mini 1000.

The HP 110 caught my attention not just because it looks like a great Netbook, but that it has the same name/number as the original laptop, the HP 110, which I remember seeing in prototype form on a trip in 1984 to HP’s site in Corvallis, OR. Check out the specs on this baby. 300 baud modem!

HP 110 – 1984:

(Image from OldComputers.net – go visit there.)

HP 110 – 2009:

Anyway, when did modem ports disappear on laptops/netbooks? I wasn’t really paying attention, so I imagine it’s been a few years since POTS modems on most laptops and all netbooks have gone the way of the Dodo.