Have you ever connected with someone on LinkedIn only to find sometime down the road you see their name on an update email and have no clue when/where you met them? I have, and every time it happens I wish LinkedIn had the ability to write private notes about a contact so I could write myself a little reminder.
Guess what, LinkedIn can do that! Not sure how long it’s been able to, but I just found it and figured I’d share.
Amazon, our bff when it comes to hosting, published on a case study of our use of AWS yesterday. In particular, they discuss why we chose AWS over their competitors and how we use Auto-Scaling. More info in the study: http://bit.ly/97yOfN.
I did want to expand a bit on the lessons we learned during our Auto-Scaling experience. If you’re thinking about going that route, which I highly recommend for the right kind of problems, be able to answer these questions about your architecture before diving in too deep:
How will your machines “start their work” when they come up?
You need to have a way for the machines to know what to do and when, once they come to life. We use TopShelf to run services that periodically ping some web services asking for records to process.
How will your auto-scaled machine get your latest bits?
You don’t want to have to rebundle your AMIs every time you make a change that’s to be deployed on an auto-scaled server. Instead, build a way for auto-scaled machines to auto-update themselves when they come to life.
For example, our AS machines have a simple batch script that downloads a zip file with the latest processing bits, deploys them, and restarts the appropriate services.
Can you save money by leveraging different size machines?
We have one Auto-Scaling group that’s a single small machine with a min and max count of one machine. That means no matter what, we always have one small instance running. Let’s call this the “small auto-scaling group.”
We also have another Auto-Scaling group that consists of medium instances with a min of 0 and a relatively large max. Let’s call this the “medium auto-scaling group.”
The number of machines Auto-Scaling spins up within the “medium” auto-scaling group is actually determined by the performance of the “small” AS group. That enables us to keep the cost of our idling servers low with a single small instance, but provide extra power in the form of 0-N medium instances when records are available for processing.
Note: since small & medium instances are both 32-bit servers, we can use the same AMIs for both groups. We do have custom code in our processing service however that changes the number of processes we run based on the number of processors the machine has. You should consider doing the same.
What happens when your machine is terminated?
Make sure whatever processing you’re doing on your auto-scaled machines isn’t affected by having a particular machine terminate at any point. Since Auto-Scaling is determined by machine performance metrics, once you’re below your load threshold, machines will start terminating automatically. Make sure your infrastructure is prepared to cope with processing services that terminate mid-job.
If you’re like me, you’ll come back from a conference like HIMSS with a stack of business cards, all of which have barely legible notes on the back serving as a reminder to follow-up with newly found contacts.
Wouldn’t it be great if there was a way to track who you’ve followed-up and who you haven’t, assign yourself follow-up reminders, track your on-going discussions with contacts, and be able to use it for both conference connections and new customers? Lucky for us, there are apps that do just that.
Customer Relationship Management systems (CRMs) do precisely what they sound like they should – they help you manage your customer relationships. We’ve started using one, Highrise, and we’ve had such a good experience with it, I wanted to share a little about it.
Quick Demo Video – full screen version here: http://bit.ly/bfLFaGVodpod videos no longer available.
It’s well hidden, just beneath the “Basic” plan, but you can sign up for a free Highrise account which will support two users here: http://highrisehq.com/signup
Other inexpensive CRMs are:
We’d love to hear other techniques/tools you use to track your customer and contact interactions, so fire away!
There’s one metric, above all others, that represents the state of the healthcare information technology industry – the number of two-story vendor booths at HIMSS. While there are always vendors that take up an acre or two of floor space, the number of exhibitors with double-decker exhibitions fluctuates based on the industry’s outlook.
At HIMSS 2008, just before the recession hit hard, I counted a dozen two-story booths in the literally mile-long corridor of vendors. Last year, when the economy was tanking and the HITECH stimulus $ was a big unknown, I only saw two double-decker booths. This year, we’re probably in the 6-8 range, despite the economically tumultuous times. The reason for the rebounding is undoubtedly, the ARRA/HITECH Stimulus funds.
Thanks to the adept implementation of the legislation by the Office of the National Coordinator, the support of organizations like HIMSS & HITSP, and the enthusiasm of an industry primed for a federal booster shot, vendors and providers alike are spending $ and hiring people as if we weren’t recovering from the great recession. People on the exhibit floor, on the shuttles, and in the bars are abuzz with talk of “meaningful use” and the tone is overwhelmingly optimistic.
If the goal of the HITECH stimulus was to get this sector of the economy moving again while advancing the use of electronic medical records, the rebounding number of two-story booths means we can safely check-off one of those goals off the list. Based on the progress I’ve seen and the discussions I’ve heard so far, the second is not far behind.
We make heavy use of Amazon Web Services (AWS) for our hosting, large scale data storage, and load balancing needs. In fact, the latest release of Breeze leverages AWS’s Auto-Scaling functionality to automatically bring additional servers to life during times of heavy load.
For anyone interested, here’s how:
As records come in for processing, Amazon’s CloudWatch monitors the performance of our processing servers and, once a certain CPU threshold is exceeded, more servers are added to the job. These new machines are configured to automatically jump in and start lending a hand in the processing. When all of the charts have been processed, the additional machines are terminated and the system goes back to its normal state.
Obviously, the best part of this system is that we don’t do anything. The system automatically resizes itself based on load which means we can processes large batches of records at any moment, without having to pay for idling high-end servers 24/7. Ah, the power of the cloud.
After hanging out with other Seattle upstarts for a while now, here are my favorite Seattle startup networking resources:
- Seattle Tech Startups – The Seattle tech startup mailing list
- Seattle 2.0 – Great resource for news and startup events through-out Seattle
- Seattle Tech Calendar – Exactly what it sounds like
- Poker 2.0 – (Reserved for Tech Startup Execs & VCs/Angels) Terrific, relaxed low-stakes poker, food & beer. One of my favorite events. Contact me for an intro.
- ideakickSEATTLE – Got an idea for a company and want some feedback? Got some skills and want to find someone with an idea? Just want to meet some great? Awesome event for building meaningful relationships. (started by a real stand-up guy)
- Tech Cafe – Monthly lunches sponsored by a local startup
- Hops and Chops – Good people, casual conversation at Spitfire every Thursday from 6:30 – 9:00
- NWEN – Northwest Entrepreneurial Network. More structure & a bit more establishy than other events/organizations.
- Open Coffee – Tuesday mornings from 8:30 – 10:00 at Louisa’s in Eastlake.
- Startup Drinks – Monthly drinks at a bar somewhere in Seattle
- Encrypted File System (EFS): This option lets you encrypt some folders in your hard drive, without having to encrypt the entire drive. That means you don’t have the (relatively) small performance hit of encrypting the entire drive, but if someone steals your hard drive, they’ll be able to see the names of all of your files/folders (although they won’t be able to see the contents of them). This assumes you have a very strong password protecting your login – if you don’t, there’s no point in EFS because someone could simply brute force your password and get your files.
- BitLocker: If you have the Ultimate or Enterprise versions of Vista or Windows 7, you can turn on BitLocker and encrypt an entire hard drive. Note, BitLocker only encrypts the drive your OS is installed on (most likely C:) and requires some special hardware, which your computer may or not have. Pros: encrypts entire drive & doesn’t rely on your login password for security. Cons: slight performance hit, requires Ultimate or Enterprise versions of Vista or Win7, and requires special (although fairly common) hardware.
- TrueCrypt: An Open Source version of BitLokcer which works on any Windows OS version (e.g. Windows XP, Vista Home, etc.). Cons: not quite as fast as BitLocker.
Now, if your laptop gets stolen, at least you won’t have to worry about notifying hundreds of patients that their data has been compromised.