Private Equity – alan williamson

Amazon WorkSpaces, put basically, is a Windows 7 desktop running in the Amazon cloud. You treat it like any other Windows machine, except instead of using it on your local physical machine, you remote desktop into it from any device (including mobile or a tablet) and use it remotely. Amazon manages all the hardware and underlying operating system for you (sadly only Windows 7 is available at present).

Extremely handy for people that are on the move, security sensitive applications, or need to share a desktop (not simultaneously) with colleagues. You can setup all the software you need, snapshot the installation and spin up as many instances as desired.

Amazon provides a secure, hassle-free, client to which to access these desktops in the cloud. Not unlike Windows Remote Desktop, this client gives you access to the remote full desktop, including mapping local printers and sound devices. You don’t however get the ability to transfer files up and down or access USB drives – making it particularly useful for applications that require a certain level of security.

There is a lot of management tools that come with WorkSpaces that makes it powerful for Administrators to provision and control the machine so the users have minimal access to the core machine. For example, when a user boots up, they get their own local D: drive that is persisted between reboots. The traditional C: drive is hidden from view and will be reset upon restarts. An administrator can install software in the traditional way and then create an image from that so other machines may be spun up with that configuration.

There are 3 different flavors available at present:

Value : 1 vCPU, 2 GiB Memory, 10 GB User Storage ($25 per month)
Standard: 2 vCPU, 4 GiB Memory, 50 GB User Storage ($35 per month)
Performance: 2 vCPU, 7.5 GiB Memory, 100 GB User Storage ($60 per month)

Incidentally if you bring your own Windows license, you can save $4 per month from each of those prices. You can also add in an application bundle (MS Office Professional mostly) for an extra $15 per month.

You will notice though that this is not the typical per-hour Amazon billing. Amazon released this service with a fixed monthly pricing model. This was a little disappointing. No matter if you run up the service for 1 hour or a full month; you were paying the same. What is this? Rackspace?!? This is not the Amazon way.

Amazon listened and just last month they released a new pricing option that lets you pay for what you use. The billing stops when you log-off and does not get started until your log back in again. However before you get too excited, there is the question of where does the data go when you are logged off? Who pays for that?

You do.

If you opt for hourly billing, you have to pay a small monthly surcharge with each WorkSpace you spin up. For example, per month the Value package will cost you $25, or alternatively you can pay the $7.50 surcharge and then pay $0.22 per hour you are logged in for.

So what works out cheaper? Monthly or on-demand? Well it all comes down to just how much you are intending to use the machine. For example, if you have your accounts software on your machine, then chances are you won’t be on the machine continually – maybe only a few days of the month.

Making some assumptions about the average working month, we can give ourselves a rule of thumb of when you should use one over the other. The assumptions made here are that there is no weekend work and the average month has 20 working days.

If you do that and crank the numbers, you discover, that the break-even point is around the 4 hrs per day mark. Anything more than that, then you are giving Amazon more money than they deserve.

On the face of it, 4hrs per day doesn’t sound a lot. However, for the situations we are using Amazon WorkSpaces the per-hour billing will save us considerably. It has to be noted, that when you are logged off, the machine is essentially in a sleep state – that means any backup or maintenance software you want to run up in the middle of the night won’t. Conversely, a secure Windows machine is one that is turned off. While the security of Amazon can be setup to be very secure, nothing beats turning off a machine to maintain ultimate deniability to would-be hackers.

WorkSpaces has proven to be really useful for us at ParkerGale, particularly as we manage many different portfolio companies and the variety of VPN/firewalls hoops each company throws at us. I will be evaluating WorkSpaces for my own private development machine over the next few months to see how well it stands up to having everything on my own laptop.

The ease, the security, the flexibility and more importantly the cost, make WorkSpaces a very compelling offering for a company that was about to purchase laptops/desktops for their office. That cost can be offset and instead issued very dumb down Chrome books. That CapEx is once more turned into OpEx without the depreciation or upkeep (or headache upon failure) of the hardware.

So before you go purchasing, run the numbers, take it for a spin and see how you get on.

How often have you heard people throw around the scalable word? Often used in a boastful manner to illustrate they are ready for scale. Being a technologist I treat such boasts with much skepticism; because scaling an infrastructure or enterprise is bloody difficult and near on impossible if not been properly designed from the outset.

Every deal book we see at ParkerGale they all describe their systems as a “scalable platform” – but rarely they are. Too much faith has been put in the wonders of the cloud, which many read and assume that their scaling problems are magically over.

In this article I am going to help the CEO to determine if their platform is ready for the scale they have been told it is.

Because the cloud makes it quick, easy and cheap to spin up servers/resources the assumption is made that scaling is linear. Let’s look at the root of the problem with a simple example and maths that makes it look easy on paper.

Your web site is running on a single server and has never shown any sort of strain. Every one of your 1000 customers get a fast response and never been denied their experience. Great job engineering team.

“No problem” yells the CEO, “add another server“

The business decides to double its clients – 2000 customers hitting on your site. “No problem” yells the CEO, “add another server“. Since 1 server handled 1000 customers, 2 servers can handle 2000 clients. Problem solved.

This logic is hard to argue with on face value. However the devil is in the detail as you recall the classic phrase about how 9 mothers can’t make a baby in 1 month no matter how dedicated each mother is to the process.

While many systems can have more “mothers” thrown at it, a lot of the core systems can’t scale like that. The big one that most struggle with is the good old database; the heart that pumps the data around the company. You generally want all your data in one place so it maybe an analyzed and queried. This comes at a huge cost. Often we see lots of front-end application servers all properly load balanced and designed, only to be failed by the single database serving them all.

Application servers can prove troublesome too; nothing worse than having your session data loaded on one server only to have the another server deal with your request because the load balancer decided to balance you off to another. Not insurmountable, but you have to design for this from the start.

There is an assumption that because a company is utilizing the infrastructure of a cloud provider they have outsourced the scaling problem. If I have 100 sales people doesn’t mean I am going to have x100 the amount of sales. They still need managed and properly allocated their workload. All a cloud provider does for a company is to provision resources quickly.

You can validate your scalability readiness by asking your engineering team some questions.

What steps did they take during development to provision for scale?
1. Teams will often outsource this to the underlying platform/framework they chose. For example if say that .NET/JEE takes care of it automatically; #RedFlag
What is the weakest point of the system?
1. No matter how great the system is, there is always at least one weakness. If they can’t identify any; #RedFlag
What level of scale can the system cope with?
1. Any type of scale! #RedFlag While you don’t need the scale of Facebook, they even have scaling woes.
How much testing was done to confirm the scaling touch points?
1. If they look at you, head tilted like a dog trying to understand what its master just said; #RedFlag The great follow-up question here is to ask at what point did the system break? If they couldn’t get it to break then the testing was not thorough enough.
What about down scaling?
1. This is a great question and usually puts a team into a bit of a panic. Bit like asking if anyone has tried to restore any of the backups. If they have never done this; #RedFlag Scaling back down, turning off resources and making sure you lose nothing, is actually as hard, if not harder, than continually adding to a system.

Scaling an infrastructure is a very difficult task, even if you have the luxury of green-field developing it from scratch, but it is 10x harder if you are trying to make a legacy system scale.

Keep some perspective and do not assume the problem to cope with demand is someone elses – cloud platforms will only take you so far. Development and consultancy shops talk a great game but they too can fail the 5 Quick Scale Questions.

No matter how convincing someone is, scaling an enterprise is surprisingly difficult.