Plan Exit/Migration Strategies for your 3rd Party Integrations


In this highly interconnected world our products or services rarely operate in complete isolation. We rely on 3rd or external parties for services or logic that we’d rather no do ourselves, well at least most of us. When I first started in software development I always did it myself. “My solution will be better, it will be exactly what I need, my implementation will be more flexible, etc, etc, etc” those thoughts would always come up when I needed something outside the domain of what project I was working on.

third_party_systemsNow days, I look for external products or 3rd party solutions that meet the 80% rule. “Will this product/solution meet 80% of my core needs?” If it does, I jump on it. I’d rather spend my time taking the product or service the last 20% (which probably has more value to my business) then coding the entire thing. You might be able to build a better wheel, but should you try? When your trying to build a while new vehicle should you spend your finite amount of time and energy on it.

Because of this my products usually have a good number of external integrations, but that brings risk along with it. What if the service shuts down? The API changes? They pivot into something completely different. What happens when the stop supporting the product or code base? So what do you do? As my friend Dale would say, “That’s an uptown problem” and for the most part I agree with him. You can’t see into the future so how can you really mitigate that risk without waiting a whole lot of time.

Although it is a “Uptown problem” it can very quickly and without notice become a “it’s in your house” problem. As it did for us at Resgrid which is a SaaS deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).

So what should you do before hand? Here is our list of data you should collect when you intergrade a 3rd party solution into your product.

  • Research alternative services/products and compare contrast it with your current solution. This will help you identify other potential external 3rd party migrations. Keep the list short, at max the top 3 other solutions, but elect the ‘Plan B’ option and have some additional information on it compared to the others.
  • Spend an hour and determine if it could be done “in house” and how much time and effort would be required. Determine the high level work that would need to be done and how it may be composed.
  • Is it possible for your product to work without the service? If so can you turn the feature off easily to hide the issue. Do some brainstorming and have a plan of action if this is the case.

Share your findings with the team to build up some institutional knowledge then store it in a wiki or central documentation location. When you may need this knowledge it could be without notice. For us at Resgrid, we discovered an issue sending SMS gateway email’s to AT&T customers during our standard Friday deployment. Customers not being able to receive text messages from Resgrid is a big deal so we investigated and decided that we needed to implement Twilio. A day latter we had a working solution in production and our AT&T customers hopefully didn’t notice any issues. Because we had been investigating Twilio already we had some institutional knowledge built up and could implement it quickly.

If we didn’t have the knowledge built up, we could have wasted a lot of time researching alternatives, putting hacks in place and possibility making it worse. Just because something may be an “Uptown problem” doesn’t mean you shouldn’t invest some time now to help easy pain in the future.

Taking Google’s Services for Granted


Recently I was on boarding a large department into Resgrid which is a cloud service company, SaaS deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade). 

I was in a with them for about an hour. As I was going through it I noticed that the BigBoard, which is used to display a snapshot of data usually on a monitor mounted on a wall, wasn’t setting the correct address, so it was defaulting to Carson City (nice feature for a department in another country). So I’m completely baffled why the map on the BigBoard won’t center correctly. I knew it was working at one point, the code tested and validated, but I went along and continued to onboard them, making a note to check this out latter.

326696-google-logoLatter in the day I pulled down the latest DB from Azure and fired it up, and logged into the department, pulled up the BigBoard and bam, it’s working. I’m seeing a map not of the dessert of Carson City, but of their location. No data changes, everything is the same as prod, I doubled checked all the data, reviewed all my git commit history to ensure I didn’t change anything between prod’s deployment and master, nothing. So I move along, nothing to see here, and worked on some other issues they reported. I left the BigBoard open on a tab while I worked, a couple of hours later I look at it and it’s back to Carson City. So began the process of stepping through the code to see where in the hell the bug in. After a couple of hours I discovered that the geocoders stopped working.

Currently Resgrid uses 2 geocorders, Bing and Google. Yahoo shut theirs down and I haven’t gotten around to enabling MapQuest or Nokia HERE yet. We use multiple because sometimes one or another falls down on geocoding an address, Yahoo was actually pretty good at UK and Australia addresses compared to Google. I dove into the Google geocoder to see what’s up and saw the request was denied with an OVER_QUOTA error, oh snap. We had been using the free/public version of Google’s geocoder which only gives 2,000 geocoding transitions per day. Every time the geocode was called it would call out to Google. Which means if someone sat on the BigBoard it would generate 1440 geocode requests just but itself, every day!

So began the mad dash, low-carb monster fueled coding binge. I reorderd the geocode code, signed up for an API key on Google so we could track request counts and most importantly enabled our Azure Redis cache to cache the request of a geocode request, both for reverse and forward. The Bing Geocoder returned nothing, so I think they banned that api key, so I signed up for a new one as well.

As a friend Dale would say this was one of the first of many ‘uptown problems’ Resgrid encountered as we grow. But the more I look at the problem it should have never been an ‘uptown’ problem. For so long I’ve been doing the same thing, just relying on Google’s services to work all the time for free. I didn’t bother caching the result incase it was requested again. This was just being a poor netcitizen, this data isn’t in flux, forward and reverse geocoding results are what they are, the latitude and longitude of my house still equals my house and vice versa. This is a clear cut golden case for caching the results.

The things I can no longer take for granted are growing in number every day. Developing a global SaaS app has ruined DateTime handing, TimeZones, EF CodeFirst and services like Geocoding for me. I think I developed a few more gray hairs with just this issue alone and the fact is that it could have been avoided.

Small is Beautiful; How you treat the small counts

Most of us have probably heard the adage “You can judge a society by how well it treats its prisoners” from Fyodor Dostoyevsky. He is not the only one to share that line of thinking; “A nation’s greatness is measured by how it treats its weakest members” from Mahatma Ghandi or “you measure the degree of civilization of a society by how it treats its weakest members” from Winston Churchill.

small-businessThere is a pattern here, how you treat the smallest, weakest or least privileged members reflects on you as a collective. I’ve been thinking a lot about my interactions with Microsoft, Telerik and Xamarin lately as a small time developer in the ecosystem and a from the perspective of Resgrid as a bootstrapped SaaS startup and I’ve come to the conclusion that how technology companies treat their smallest customers/developers reflects on them as an organization.

There are a lot of companies out there in the technology space that just don’t want to have anything to do with you if you’re not going to throw four plus figures at them, minimum, a year. Then there are those that would rather try and pressure you to pay a lot of a product when you’ve told them time and time again you can’t pay for it. Finally, there are those out there that will give you a steep discount and actually make you feel important.

I’ve dealt a lot with Telerik over the last year and I have to say, rarely has a company made me feel more like my opinion matters. I may have issues with their products, pricing, feature sets, priorities and implementations from time to time, but never have I ever felt slighted when I email, call or send in a support request. They know I’m a bootstrapped startup, but they still give me an amazing level of feedback, interaction and communication. Special shout outs to Rob Lauer and Stefan Rahnev from Telerik. Telerik not only makes me feel like a VIP, but they also work with me on price. I can tell them my budget and more often then not they will work to keep me.

On the other extreme is Xamarin, who was co-founded started by Miguel de Icaza, of GNOE and Mono fame. With his roots, background in open source and community you would think Xamarin would be all over helping the little guys and building an robust eco-system. First and foremost Xamarin Free product is a complete joke. You try to build anything that takes a reference, even against the .Net Framework, and BAM no more development for you. I recently signed up to try it out, hit the brick wall of “no development for you” with their free product and then asked a sales rep what discount pricing was $650 for WP, iOS and Android annually. When I made the sales rep aware of my situation and line of thinking, never heard back from him.

Finally there is Microsoft who is kind of in the middle. I’ve had downright amazing interactions with them and the BizSpark program in general. I recommend it to anyone who is starting a company, even if your not a MS/.Net developer. 3 years of $150 Azure credit a month, boy you got a deal there. On the other hand interactions with developer/platform/channel evangelists who are supposed to help bring a developer/small business up in the ecosystem seem to fail, if I don’t have a hundred thousand bucks or are building a Windows 8 Store app or Windows Phone 8 app they want nothing to do with me. “Hey I already have this app, can you get me in a program or help out” Nope sorry and they run away, mission accomplished. When talking with them it’s what can you do for me, not what can Microsoft or I help you with. I have no confidence that when I do develop that Windows 8 Store app that they will be around to help get me deals, get my business into programs or help with support.

It’s all part of their own endgame’s really. Microsoft wants Windows Phone 8 or Windows 8 Store apps at all costs, Xamarin’s sales rep’s apparently want a big commission or a large logo they can slap on their “look who’s using us!” page and Telerik, well they just seem to want developers using their products. The sooner companies realize it’s people like me and small business are the start of something big the sooner they may get that big sale and people recommending their product or service.

Service counts, and how you measure the greatness a company is by seeing how it treats is smallest customers.

Go to Top