Fighting Your Tools

As I mentioned recently, I am working on a refactoring of how Glassboard handles its push notifications system. The short-version is that the current incarnation uses an Azure Worker Role to handle messages of a Storage Queue via C# and a lot of custom written code for tying into each push notification provider we use.

When we last spoke, I was pretty convinced with throwing out the C# code in favor of a Node and TypeScript flavored solution. I was also debating using Azure’s Notification Hub service for delivering the pushes to further lessen my code liability. I have been working on this for the past few days, but it hasn’t been going exactly as I had hoped.

For those that don’t know, TypeScript is a language layer similar to Coffeescript that compiles down to plain old Javascript. It’s got a great syntax that allows you to have typed variables, and just hit 1.0. TypeScript also allows me to be a lazy developer because it integrates natively with Visual Studio’s intellisense. Given that I’m spending most of my time in Visual Studio working on this backend provider, it made sense to give TypeScript a whirl.

If you’re interested in seeing some sample TypeScript, here’s a snippet from Glassboard. I really like the syntax, though having to write my own accessor methods is very cave man.

Microsoft also recently went to a 1.0 beta with their NodeJS tools for Visual Studio that make it super easy to build and deploy Node to Azure. Since I am working with Azure’s storage and CPU emulators in Windows already, using these tools made sense too. I’ve never had much luck bridging the emulators from my VMWare instance to my Mac’s network stack anyway. The Node tools also have built-in support for debugging Node both locally and remotely, which is super awesome.

So, good language. Good toolchain. What’s the matter?

It turns out that Windows has a really annoying problem with long file directory paths. In short, a file name must be less than 260 characters, and a directory path must be less than 248 characters. Otherwise, you get this error constantly.

Unable to copy file ".node_modulesazurenode_modulesrequestnode_modulesform-datanode_modulescombined-streamnode_modulesdelayed-streamtestintegrationtest-handle-source-errors.js" to "objDebug.node_modulesazurenode_modulesrequestnode_modulesform-datanode_modulescombined-streamnode_modulesdelayed-streamtestintegrationtest-handle-source-errors.js". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:Program Files (x86)MSBuildMicrosoftVisualStudiov12.0Node.js ToolsMicrosoft.NodejsTools.targets 74  5   Cloud

Now, imagine you are working with a framework like Node that relies heavily on package modules, which also rely on package modules, which also rely on package modules. You’re going to run into this pretty much every time you build.

I tried working around it at first by mapping a virtual drive for my Development projects, but the nested node modules still became too much for Windows 8 to cope with.

This is a bummer for a variety of reasons. For one, using the Node tools for Visual Studio is nearly impossible for any development situation that relies on a suite of npm modules. As you can see from the error above, I’m trying to use Microsoft’s own Azure module and running into the issue. It pretty much prevents me from building my project and testing it locally in Visual Studio.

And as a developer, I’m bummed for the people working on the Visual Studio Node Tools project. They’ve built something really great, but I’m struggling to use it because of a long-time Windows bug (yes, this is a bug).

I will never complain about HFS+ again.

I have a few options to deal with this issue.

  1. Keep going ahead with what I’m doing and hope that one day Windows stops being Windows.
  2. Work on getting the Azure Emulator to work through VMWare to my host Mac so that I can write the TypeScript code in Sublime Text natively on my Mac.
  3. Throw away two or three days worth of work and go back to a C# solution that likely won’t run into this issue since its dependency model relies on namespaces rather than directory structure.

I’m leaning towards option 2 or 3 even though the Stubborn Developer wants to take option 1.

Option 2 is nice because I can still use TypeScript and Node to manage this portion of the project. I’m pretty sure I can figure out the VMWare issues I’ve had if I sit down for a few hours and tackle it. The tradeoff is that Sublime’s TypeScript support isn’t nearly as powerful as Visual Studio. I’m a lazy developer. I like my tools to enable me to be as lazy as possible.

Option 3 is appealing because I have a good chunk of the code already written in the legacy system. Since I’m switching to Notification Hubs, I can trash a good chunk of the existing code base and wrap it in the Azure SDK’s handling library.

Thanks to an Azure Friday series of videos I’ve got a better understanding of how to handle not using threads to manage the processing on the Worker Role as well.

I’m taking a day to weigh the pros and cons so I can choose which route I want to take. Until then, the lesson learned from this is that new and shiny doesn’t always mean better. Now I’m behind on my ship goal by several days.

Back to work.

Read more about. . .

Refactoring in the Cloud - Notifications

One of the things I have been thinking about a lot recently is the architecture of Glassboard. Now that I have everything mapped out for where I want to take Glassboard’s direction going forward both financially and functionally, it’s the time to look at how to actually build that functionality into the existing code base.

The Current Glassboard Architecture

Glassboard’s backend is powered by Microsoft Azure. In terms of computing, there are three main components: two worker roles and one web role.

Azure defines a Web Role as a server that has a running copy of the IIS web server on it, so that users can connect to it. A worker role doesn’t run IIS, but is still a Windows Server instance that you can use to do things like background processing on it and offload some of the heavy activities from your main server role.

This is a rudimentary diagram of the Glassboard architecture as of April 2014.

Glassboard's Architecture

  • The Kitchen Sink Web Role: I currently deploy a single web role that autoscales between 2 and 4 instances based on user traffic. This single web role does a lot. It handles all user authentication and signups as well as managing and distributing the Glassboard JSON API (through WCF god help me). In addition, it also has a few web hooks connected to it, and the Glassboard web app which is a rudimentary ASP.net MVC application with a Backbone.js exterior. It’s a beast.
  • Attachment Processor Role: When you upload a photo or video to Glassboard, it’s thrown into this role to do some post-processing like rotating it to the proper orientation and compressing to save us some server side bandwidth. Right now it’s using ffmpeg, Handbrake and a bunch of scripts to accomplish this. It’s more brittle than Greg Oden’s knees. We’ll get to refactoring it eventually.
  • Notifications Role: The Notifications Role handles distributing all the push notifications and emails that are sent out through Glassboard. Currently it supports Apple’s Push Notification Service, Google Cloud Messaging, Google’s legacy Cloud to Device Messaging, and Microsoft’s legacy Windows Phone Notification Service. Email is distributed via Sendgrid.

Everything in the current Glassboard architecture is housed in a single Visual Studio solution with about 36 C# projects in it. It’s a lot of code to manage. Luckily it’s also well tested, which makes it easier to manage.

Current Notification Role Issues

There are a few technical and ideological issues I have with the current notification architecture.

To send messages between the web role and the attachment processor and notifications roles, I use Azure’s Storage Queue mechanism to pass messages. When you post a message to one of your boards, the web role generates a new XML payload in one of our storage queues that the Notification Role listens for to handle the processing.

Sometimes this queue and the processing gets extremely backed up. Usually the CPU usage spikes to around 90% or higher for long periods of times which can lead to message postings being delayed for several minutes (in some cases I’ve seen hours) at a time. This is no good, especially when building a messaging service.

I’m not sure what the cause is for the spiking CPU other than a lot of delicate C# threading issues which I’m guessing are running amok.

The other issue I have with the notification role is how much of the code for things push notification services is in-house built. At the time Glassboard was originally built a few years ago, there weren’t too many open source solutions for handling push in C# I’d imagine.

I’m fairly conservative when it comes to third-party dependencies, but for things like push notification services there’s not much sense in maintaining your own code library to connect to the service when there are a few good solutions out there used by hundreds (thousands?) of startups and businesses around the world. They’re well implemented, battle tested, and code that is maintained by the community.

Being on C#, that limits the amount of options I have for dealing with push providers. PushSharp seems to be the main provider out there.

The New Notifications Role

Given that I’m not a fan of the C# threading model currently implemented, the amount of code used to power something that’s relatively simple, and the homegrown nature of many of the push wrappers we’re using, I made the decision to rewrite this portion of Glassboard’s architecture using Node. Hang on. Put those Buzzword Bingo cards away. I’m not a fan of rewriting for the sake of rewriting either.

Ultimately, my decision to switch to Node is all about code management. I’m confident I can accomplish the goals of my notification roles with a lot less code using Node than C# thanks to it being a bit less verbose of a language and a variety of NPM packages I can take advantage of for handling APNS, SendGrid, and GCM. The less code I have to manage and maintain, the easier my job is as the sole developer of Glassboard.

I don’t believe I will have any performance degradation in switching from C# to Node for this portion of the code either, though it’s hard to tell before actually writing the code. If anything, I’m optimistic that performance will improve.

A Fork In The Road

There’s two different ways I can approach handling push notifications being distributed through my new worker role. The first is to use these npm packages like node-gcm and its similar ilk to distribute the messages myself like I have always done. The difference being mostly in the language being used (Javascript versus C#).

The other option is to take advantage of Azure’s Notification Hubs which will handle distributing the messages to devices for me. Notification Hub has some advantages that stand out to me:

  • It works with all the platforms I care about: APNS, GCM, and WNS.
  • It handles platforms I don’t care about, but might again someday: Kindle.
  • It does all the device feedback management for me so I don’t have to keep track of which devices I should be adding or removing (such as when a user installs or uninstalls Glassboard).
  • Tagging devices based on certain features seems appealing. For instance, I could tag all of a user’s devices by their UUID and then easily distribute a message to all their devices in one message.

This all sounds great. Why not just do this? Cost.

Notification Hubs are another cost layer on top of the existing charges I’m paying Microsoft for my cloud instances and storage. I’m still in ‘losing money’ mode with Glassboard, so I’m trying to be fairly conservative with my spending.

Glassboard currently sends around 150,000 emails a day according to Sendgrid, but I have no idea how many push messages it sends because it has never had a way to track that sort of information. If I opt into Notifications Hub, I’m likely going to be out at least $200 extra a month, but that could also sky rocket to an even higher amount.

Now you understand why I am giving so much important to data and analytics these days.

My gut says use Notification Hubs. My wallet says roll my own.

Service Bus vs Storage Queues

One last thing I’m still debating is whether to keep using Azure’s Storage Queues for managing the messaging between the different components in my cloud stack or to use the new-to-me Service Bus functionality, which looks to offer a few more features. The Notification Hub functionality Microsoft offers is powered by the Service Bus, which has me considering the switch.

There are plenty of decent articles out there comparing Service Bus vs Storage Queues, but from a more abstracted level that leaves me still questioning which way to go. The conservative developer in me says keep using what I’ve already got because no major Service Bus feature stands out to me as a must-have right now. The liberal developer in me sees Service Bus as the more modern architecture that will likely be able to grow with me as Glassboard (hopefully) expands in years to come.

Feedback certainly welcomed.

Writing The Code

Even though the core architecture of two worker roles and a single web role won’t change with this refactoring of Glassboard’s notification architecture, hopefully this has been at least a little eye opening in terms of how Glassboard is built, and how I envision it being built going forward.

The obvious next step is to write the code, which I started earlier this week by writing the unit and integration tests for the new Node code base.

Since I spend so much time in Visual Studio these days, I thought I’d give the Node tools that Microsoft released a try. Then I remembered that while I love what Microsoft is doing with the cloud and Azure, Windows is still Windows.

Never stop being Windows, Windows. pic.twitter.com/33NI4UsLHZ

— Justin Williams (@justin) April 16, 2014

Read more about. . .

Build 2014

I spent last week in San Francisco at Microsoft’s Build conference. Build is an annual (at least I think it’s going to be) event the company holds at Moscone West to share their latest offerings for Windows, mobile, and Azure. I’m not a developer for any of the Windows platforms. Glassboard, however, runs on Microsoft Azure so I was interested in attending both to learn about the new offerings and to put some names and faces together with people I’ve started interacting with recently.

Overall it was a positive experience as someone who only recently dipped his toes back into what Microsoft is doing recently. The last time I used (or even cared) about Microsoft technology was the late 90’s when they were a giant, evil corporation who was charged with being a monopoly. I switched to the Mac when OS X was announced in 2000 and hadn’t really touched since.

Fast forward 14 years later and Microsoft seems to be a whole new company. New products. New CEO. New development offerings. And less of a focus on Windows, Windows, Windows.

Sure, Windows is a key part of the Microsoft ecosystem (and rightly so), but it also no longer seems to be the central focus that directs everything they do. I sat through two THREE HOUR (emphasis mine because oh my god so long) keynotes that prominently featured iOS devices, the Apple logo, iPads, Androids, and even Linux. A few years ago this was the company that dismissed iOS as a failure to launch and instead focused on how they could go from a Windows computer on every desk to a Windows Phone in every pocket.

Windows Phone is still a key piece of technology for them (and 8.1 looks great), but they realize that integrating their services into the other platforms as first-class citizens is best for business.

Whether this was a plan set in place by Ballmer before he left, or new under new CEO Satya Nadella’s watch I don’t know. As an outside just starting to look in, however, it’s refreshing.

A True Partner

One of the biggest differences I noticed between an event like Build and WWDC was in the subtle messaging. Both Apple and Microsoft are massive companies that make billions of dollars and answer to their shareholders. Both companies also offer development platforms for third-parties to integrate with.

What’s different though is that it feels like Microsoft is more interested in working with us as a partner whereas Apple has always given off a vibe of just sort of dealing with us because they have to. Maybe that’s a little sour grapes, but as a developer it was a nice change.

Build was announced far in advance allowing people ample time to schedule and book their travel. Microsoft released the full schedule of the event the night before so you could plan your week out in advance (or just decide to wait for the videos later on). They even provided previews (and access) to upcoming technologies that aren’t ready just yet, but to give us an eye on where they see things going.

It was cool to get a free Xbox One to play Titanfall on, but they also had several sessions during Build that talked about how to actually build an application that can run on that Xbox so that when the time comes that they release a full SDK and support for that, developers will be ready. They provided that to everyone, not just a few select partners that also share a stock ticker symbol.

Open Source

Microsoft isn’t exactly a showman company. The keynotes were well presented, but they also lacked the pizazz of an Apple event where everything feels as cool as a night out with Frank and Dean.

The one area where I sat up and thought “OK, that was cool” was when Anders Hejlsberg publicly open sourced the new Roslyn C# compiler platform on the Keynote stage at the end of his demo.

Roslyn is a key piece of technology for the future of Microsoft and they’re now managing it as an open source project. This allows for a few things: outside contributions and feedback on the platform from fellow developers for one. More importantly, it allows the Xamarin folks who had implemented their own C# compiler to work on MonoTouch. It’s now possible for Microsoft and Xamarin to collaborate together on a single compiler rather than both building in parallel.

Apple has the LLVM project, which is similar in many ways, but I also can’t imagine them working with a third-party vendor such as RubyMotion (for lack of a better example) to make their jobs easier.

I still hope that some day Apple will open source the core iOS and OS X frameworks the same way Microsoft does with .Net and Google does with Android. I’m not holding my breath, but I can dream.

Overall though, Microsoft seems to be embracing open source in new and interesting ways that the old Microsoft never seemed to care about. Previously when they open sourced a piece of technology it’s because they were no longer interested in it. Now, key pieces of functionality that the future of the company is based on are out in the open.

Bizarro WWDC

A week or two before Build, I received a text message from Dave Wiskus of Q Branch/Vesper asking if I was still attending Build. He then informed me that he, Gruber and Brent would be attending the conference as well as part of the keynote.

2.5 hours into the second day keynote, lo and behold my long-time Mac and iOS development friends showed up on a Microsoft stage talking about how Vesper’s sync services are powered by Microsoft Azure.

None of those guys are Windows users. None of them are Windows Phone users either. They’re happily using Microsoft’s cloud services platform to power the backend of their iOS only app.

It was a bit surreal to experience Moscone West with a few other long-time WWDC attendees and compare how similar (and positive) our experiences seemed to be. Outside of there being a DJ spinning house beats above a sea of coding nerds on level 2, we came away impressed.

Showing The Other Side

Kind of excited that @justin and @gruber and @brentsimmons are all doing high-visibility Microsoft stuff. Competition is good.

— Michael Yacavone (@notio) April 4, 2014

If you follow me on Twitter, you were probably pretty tired of seeing me tweet things with hashtag #bldwin (you’re lucky I was kind enough to hash them so you could mute if desired). The reason for the excess tweeting was twofold:

First, I tweet a lot anyway. Second, and more importantly, I know my audience is primarily filled with Mac and iOS developers. We’re all fairly busy people and may not always look up to see what is happening outside of the Apple ecosystem.

Build allowed me three days to immerse myself in technologies that I know almost nothing about. I came away impressed with it too. For all its past faults, the New Microsoft is doing things that are on the cutting edge of technology. Their Rx extensions library is everything I hope ReactiveCocoa could be: a fully functional extension to the core C# language built and maintained by Microsoft. Their unit and integration testing story for Windows Phone is light years beyond what either Apple or Google offer for their respective mobile platforms.

Avoiding Longhorn 2015

John Siracusa has a famous article called Copland 2010 where he talks about Apple’s need to begin looking for a replacement for Objective-C and the Cocoa frameworks before they get to the point where it’s too late and they’re in for several years of hurt much like the transition from Classic Mac OS to OS X.

I still love Objective-C and the Cocoa frameworks, but having worked on Glassboard’s Azure backend and Android app in parallel, I’ve seen a different world outside of the Apple prism. What we have is good, but there’s so much more potential to be great with the emerging and more modern development technologies out there.

With things like C#, the Roslyn compiler/frameworks, and the modern WinRT runtime, it feels like Microsoft is way ahead of Apple in the future looking regard. As a developer, I’m jealous of a lot of the technologies coming out of Microsoft. As a user? They’ve got a long ways to go before I consider using Windows over a Mac.

That said, this is the new Microsoft. They don’t need me to use Windows or Windows Phone as long as I use Microsoft services like Azure, Office 365 and the like.

I can’t believe I’m excited about and interested in working with so many Microsoft technologies. The times are a changin’.

Read more about. . .

The Parts of Your Platform

The simpler devices get, the more complex our jobs as developers becomes it seems.

When I first started my independent developer career way back in the dark ages of 2006, building an app usually meant building a desktop product that persisted data locally. In some cases there was an Internet backed service tied to it, but it wasn’t the norm. This was before Dropbox, people.

If you truly wanted Internet connected services, you built web apps. Using a mix of HTML, CSS and a sprinkling of Javascript you could build web pages that could replace your desktop apps with something that could run on any device and any browser.

Once mobile came on the scene, web apps weren’t as ‘sweet’ a solution as some would have liked us to believe. The pendulum swung back towards native app development, but with the added bonus of being network connected at all times.

For an app that connects to a third-party service such as Dropbox or Twitter, always-on connectivity means implementing a third-party API in your app and using that as the foundation for your data access. It’s a little more work than our desktop days, but certainly not that big of a hassle.

Fast forward to 2014 and you’re starting to see convergence of mobile and those web technologies. Mobile apps from smaller developers are starting to offer online services either as a value add (such as the wonderful Day One app) or as the foundation of the service (such as Glassboard or soon-to-be from Vesper).

Mobile apps requiring their own custom backend data isn’t new for many operations, especially those with a large staff and a bankroll of venture capital money to burn. For the mom-and-pop shops like Second Gear and Q Branch, it’s a whole new world that just became more feasible just recently.

So, what changed?

App Pricing And Expectations

When I released Photos+ last year, one of the biggest sources of feedback I received was “where is the iPad version?” Nevermind that I just spent several months perfecting the iPhone version, consumers expected that the app would be run on all their iOS devices.

Beyond just expecting your app to run on both an iPad and iPhone, users also expect that data to sync effortlessly between those devices.

Implementing that amount of functionality isn’t impossible, but at $2.99 per app or so it becomes really hard to make the economics work in your favor. If you can instead sell a service for a monthly or yearly fee, however, and then give the apps away for free it becomes a bit more feasible to make the economics work. Still difficult, but at least less of a crapshoot.

The Cloud!

Everything is in the magical Cloud now. All your files are on Dropbox. All your photos in Photo Stream. Everything else in Evernote.

Cloud computing has eliminated the need to be a sysadmin and host your own server hardware in favor of renting resources in the cloud. Amazon, Microsoft, and Google are the big three and are all jockeying to lay claim to all the CPU and storage on the web.

Glassboard runs on exclusively Microsoft Azure. All user data is encrypted and stored in Azure Table Storage. Images and videos live in Azure Blob Storage. The actual platform app itself runs on an Azure Cloud Service, which makes scaling as easy as adjusting a few sliders on the Azure web site.

Backend as a Service

Take the cloud computing paradigm, and simplify it even further and you get Backend as a Service. With a BaaS provider such as Parse, Google App Engine, or Azure Mobile Services, you don’t even have to worry about provisioning resources on the cloud. Instead you just import an API wrapper into your mobile app and configure a few cookie cutter options on the BaaS provider’s web site.

These providers make cloud-enabling your product incredibly simple. The tradeoff of using one versus the more traditional ‘cloud’ is that costs rise exponentially much quicker. It’s a tradeoff that many are willing to make, plus competition has made pricing a bit more competitive than it was even just a year ago.

The Parts of a Platform

We’ve accepted that running our own server-side resources is becoming a reality, we should analyze what that really means. And more importantly, understand what is involved.

1. The API

The brain of that powers any cloud-enabled service is its API. It doesn’t matter what language you write it in as long as its secure, stable, and reliable. Glassboard started out as a full C# product, but I’ve been rewriting parts of it in Node where it makes sense.

Most of the time your users won’t see your API firsthand, unless you offer it publicly as a value add to your customers. Whether it’s a public API or not, versioning from the start is always a good idea. You’ll inevitably get to the point where you want to add or change your API’s functionality. By versioning your API from the start, you can ensure that legacy clients aren’t immediately cut off as you improve your product.

If you’re running a marginally successful service on an API, it’s worth your financial and time investment to look into services like New Relic and Runscope. New Relic does magic things to figure out bottlenecks and other slowdowns in your API clients. Runscope is an API monitoring service that lets you test the health of your API as you run a suite of tests against it.

2. The App(s)

Whether its iOS, Android, Windows Phone, or OS X, the app is the nut of any platform. It’s what your consumers will predominantly use to interface with your service and will shape their opinion on it.

This is likely going to be where most of your time is spent, assuming you want to build something that stands out in such a crowded market. There are plenty of hybrid app solutions that can get you on all platforms quickly, but quick doesn’t necessarily mean quality.

Glassboard has native Android and iOS clients. Each one is built using the system-specific APIs and designed to look and behave like a first class citizen on their respective platform. It’s far more work (and cost) than the hybrid approach, but I believe a better app experience in turn leads to a better conversion rate to paying customers of the service.

3. The Management Backend

This is the one most people forget. Once you’ve developed your API and built the app(s) to consume it, you likely have a user base that is going to be emailing in support requests and bug reports. Those requests likely mean you need to look into the data stored on your backend.

You aren’t an animal. Running raw SQL queries from the Terminal is neither safe, nor ideal. You need yet another app for your platform. The only difference is that this one is for internal use only.

The admin portal is the piece that most developers forget about until after they’ve shipped, but it can also be one of the most important part of your product once you reach a level of success. Let’s imagine you outsource your support to a third-party company (I recommend and use AptFolk). Ash and crew are a smart group, but they don’t know the internals of your product or how to connect to your servers. Nor should they need to. By offering a web or mobile app that allows them to look up and adjust account information or whatever else is relevant, you’re making your job easier.

Beyond just support, metrics are essential to measuring success or failure. There are simple vanity metrics that are useful for showing on an app like Status Board:

  • Daily signups
  • Active users
  • [Your Specific Data] created
  • Daily/Weekly/Monthly Revenue

For more advanced metrics, I recommend a third-party provider that specializes in things like customer segmentation, funnels, and other more advanced functionality. I use Localytics, but I’m actively shopping for an alternative. Mixpanel is also a nice service, but gets expensive real quick.

Every Piece Matters

The good news is that even though our jobs as app developers is becoming more all-consuming, the tools that enable us to do this are becoming far easier to use. I couldn’t imagine running my own servers back in 2008, and now I don’t have to. Cloud computing takes care of the heavy lifting and let’s me focus on the product itself.

Just because I don’t have to worry about imaging and provisioning servers doesn’t mean I can slack on other parts of my product’s development cycle. The API, apps, and backend platform are all equally important pieces of the puzzle that defines your product. The app may be the only public facing one, but without the API it doesn’t exist. Without the backend management portal, supporting your user base becomes a nightmare that impedes development.

Treat each piece of your product’s stack like it’s the most important, user facing portion bit. Quality isn’t just mean for the surface.

The Full Stack App Developer

Whenever I look at job boards, I notice that a lot of web development jobs are wanting someone who is a ‘full stack’ web developer. To me, that means someone who can build the front end of the application using HTML, CSS, and Javascript as well as the backend using whatever server-side framework is in there. To top it off, sprinkle in a bit of knowledge on cloud computing.

The ‘full stack’ paradigm is starting to make its way to app development going forward as well. It’s no longer enough to just know how to write code for a single platform. To be truly relevant and valuable you need to have an understanding of API design and implementation and cloud computing as well.

Ignoring the cloud or web services because they are out of your comfort zone is no longer an option. The app economy is shifting. Adapt or die.

Read more about. . .

On Glassboard & Windows Azure

Stackmob announced it is shutting down this afternoon. I know a few folks that are using their services and are now going to be forced to look for a new provider for their backend services. I thought I’d share my experiences.

It has been nearly two months since I took over operations of Glassboard. The experience has been interesting, enlightening, challenging, and fun all at once. I’m hoping to talk about these lessons and experiences more here both as a way of documenting my progress and to hopefully garner feedback as I go forward.

I had an eye on last week’s announcement of Microsoft’s new CEO. Obviously because I follow the technology industry, but also because I now have a vested interest in Microsoft going forward. You see, Glassboard’s entire backend is powered by Microsoft technologies: Windows Azure to be specific.

Satya Nadella, the new CEO at Microsoft, was the head of the Azure side of MIcrosoft’s business before ascending to the top of the food chain, which is why I’m optimistic about the company’s future. I truly believe Azure is the best thing the company is doing right now.

Most people are surprised when I tell them that since I inherited an Azure backend rather than choosing it on my own accord, but I think that is what makes my thoughts more interesting. If I thought it wasn’t on-par with what Amazon is doing, I’d take the time to migrate off the platform over time. At this time, there are zero plans for that. I’m extremely happy.

The Glassboard API Architecture

Glassboard’s Android and iOS apps, like most mobile apps, are powered by a REST API. The API app is an ASP project that uses WCF to distribute the JSON payloads. If there’s one thing I hate, it is WCF. A lot. My next big backend project is converting from WCF to the new Web API 2 technology that is a lot easier to work with. It’s all written in C#, which I have found to be a pretty nice language.

The API is deployed to a Cloud Service, which is similar to a virtual machine but with less of an administration headache. I have the Glassboard Cloud Service set up to automatically scale between 2 and 4 Cloud Service instances depending on how much of a load is on the service at any given time.

Your messages are encrypted and stored using Azure Table Storage. Your photos, videos, and files are stored in Azure Blob Storage. Azure’s storage system is familiar to anyone who has used NoSQL. There’s also a little bit of SQL Server mixed in there for some stuff where a relational database made sense. This is by far the biggest cost point of my monthly bill, but it’s also pretty close to what Amazon is offering.

I also am using storage queues to communicate with Glassboard’s attachment processor and notifications cloud services. This works pretty well, but the Service Bus may be a better choice going forward. I’m honestly not sure yet. I need to read into it more.

Oh, and I also deploy the Glassboard marketing site to an Azure Web Sites instance through GitHub. Whenever I push an update to my web site to its public GitHub repository it instantly deploys the new version to Azure.

Other than the Glassboard marketing site, I manage all of this and deploy it through Visual Studio 2013 on a Windows 8 VMWare instance on my Mac. I came into it with zero experience and in two months have gotten to the point where I am comfortable with nearly every aspect of it.

Is it the right tool for you? That’s up to you, but like Brent I am a fan and am glad to see Amazon have a legit competitor in the cloud services area.

With Stackmob shutting down, I know a lot of developers are looking for a new backend as a service. If you’re doing Node, Azure is worth looking at as it is a first class citizen. If you’re looking at Parse as a Backend as a Service replacement, Azure is worth looking at too. Their Mobile Services product is a direct competitor. I haven’t used that portion of the platform personally, but I am happy enough with the Azure offerings I already use to recommend it.

As more apps are requiring a server-side component, cloud service providers are becoming more important. My hope is that Microsoft’s Nadella continues to recognize that as CEO and keeps funding the best product (and only product I regularly use) they have going today.

Read more about. . .