Should we right size instances in the public cloud?

via GIPHY

I’m a big fan of Corey Quinn’s Last Week in AWS newsletter.

Recently he wrote a piece titled Right Sizing your instances is nonesense

Not to be outdone, a blogger Joe at Sunshower.io wrote a counterpoint piece Why Right Sizing instances is not nonsense.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

So what’s the verdict here? Is Corey wrong and Joe right? Or is Joe right and Corey wrong?

I would argue it depends. Corey’s piece emphasizes the big picture, essentially that technical changes can buy more trouble than the money they save. While

1. Corey emphasizes the 300 foot view

Corey’s article uses a broad brush, and in doing so some of his specifics are incorrect. For example the point about older versions of Operating Systems and hypervisor. In most cases your OS won’t know it’s running on a hypbervisor at all, so this seems a very rare edge case indeed.

That said his big picture conclusion seems spot on. Changing instance sizes can be a huge risk if you don’t do so regularly. With legacy apps, who knows how they might behave. In this you carry the same burden as changing instances at all. Your AMI may not be ready, or you may have had some manual steps to build the box again.

Related: How can we keep cloud architectures simple

2. Joe gets down in the weeds of technical specifics

The first thing about Joe’s post that caught my attention was to use the console to change the instance size. You shouldn’t be manually changing instances through the console to start with. What, everything is code, all the way down? Hehe…

Also his points about cost savings seemed cherry picked. If you can save that much money by changing instance sizes, it is well worth the cost to do regression, integration & disaster recovery tests to make sure it will all work. Get on it!

Also: What hidden things does a deposit reveal?

3. Use infrastructure as code, test & retest it

IAC is really the way to go. But that still doesn’t mean you’re out of the woods. Be cautious when changing instance sizes!

With code, there is testing. So change your Terraform code and then verify it works. Now just because you have a variable indicating the instance size, doesn’t mean changing it won’t break something.

Read: Can communication mixups sour an engagement?

4. Weigh the cost savings with the risk of breaking things

Changing an instance size and redeploying could break all manner of things. It’s possible you used a variable for the instance size in some places and hard coded it in others. Or made some weird reference in an autoscaling group.

It may be the AMI you’ve built works on one type of instance but not another. Or that your AMI is deployed in one region but not another. Or that your old instance size is available in us-east-2, but your new instance size is not yet available there. Yes the console wouldn’t have offered it, but your Terraform code didn’t know.

Check out: How I use 5 daily habits to stay on track

5. Put up some guiderails

As you’ll see further down in the comments, Joe suggests to put limits around instance size changes. That makes sense. After you’ve done testing, you’ll have an idea of what these limits should be. No instance size less than 30GB memory? No instance size greater than X. None in region Y. Etc.

It’ll require tweaking your terraform infrastructure code, so it’s not a free change. But it’ll pay dividends if your costs savings are in the thousands.

Also: Can daily notes help you work better with clients?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Why the Android ecosystem is broken

Six months ago I got this crazy idea. Why not leave the mothership? Give up on iPhone and try Android. This is what being tech-agnostic is about, I thought––not being wedded to a single platform. Besides, the iPhone’s digital keypad just wasn’t working for me.

I got a monthly Boost Mobile plan, which uses Sprint. Service was stellar and I mean really good. I could call anywhere and always had a signal, even inside all these pre-war buildings you find in downtown Manhattan. How is this possible I thought? Service is one thing, but thats where the fun ends. A few months into Android hyperspace and I find myself grappling with a system that just doesn’t seem to understand what users want.

Shock and Awe

On Android – first Samsung Transform Ultra then Sidekick 4G I found the app store was like wild, wild west. Buggy apps sat along well tested ones, and only a very discerning eye and mobile guru might know the difference. Syncing was absolutely horrible. The whole platform assumes you want to sync up with Google accounts. I went with Missing Sync from Mark/Space. My addressbook started getting corrupted, duplicate records appeared, syncs would fail halfway through.

What’s more there were tons of started services I didn’t even use like Smart Navigation, Group Texting, and so on. These services seemed to run in the background, hog & bleed memory, and slow down my phone til it started crashing. I actually had to download an app called Easy Task Killer. Apparently a very popular app on the Android phones, I wonder why?

Later on I found out that T-mobile was no longer supporting the Sidekick. No wonder it was so buggy. I can’t believe they’d ship something like this.

My full list of beefs:

  • corrupted data
  • slow to non-functional syncing
  • dangerous apps
  • sharing of private data
  • ineffective calendaring
  • no support for addressbook groups
  • apps not remembering context & position
  • no good email app
  • weaker less feature rich apps
  • kludgy interface

I’ve long since quelled my desire for a physical keyboard. I was struggling with every other thing I would do with the device. Sometimes I’d just give up.

I really wanted to get along with my Android phone but my experience with it only gave me an insight into three crucial areas where it falls short.

  1. An Iron Fist
  2. People complain about Apple’s iron fist in app store approval. You can’t have it both ways. Android completely lacks discipline and users suffer hugely because of it. That weakens the platform.

  3. A manageable set of devices
  4. Developers building for Android must test on a huge spectrum of hardware. Smaller shops are likely to choose a few of the biggest ones only. Phones with a smaller user base likely have a lot of bugs just in the Android version they run. All this bodes badly as users just see buggy software, they don’t know why or how. This perception further weakens the platform.

  5. Affordable development

Building apps costs businesses money. Businesses must balance the costs of building features, test, debug, troubleshoot & release. That’s cheaper on the iphone because you have one device that is much more mature. This has a pile on affect as it strengthens the platform, users spend more on their devices, more users pile onto the iphone platform, so more money can be made building an iphone apps.  On Android higher costs, lower margins further weakens the platform.

A new love for Apple

This whole experience has brought me back to the iPhone 4S, and I have a whole new love and appreciation for the platform and the device.

  • calendar reminders make me more productive
  • data is always right, and where I need it
  • I don’t fumble with menus – I’m faster & less frustrated
  • cross-platform apps are more feature rich on the iphone
  • complex features are hidden in plain view – superb interface
  • pulse, hootsuite, yelp, notes & calendar are all integrated & productive

I also learned that sometimes less is more… much more!