Businesses that run on the cloud: Annex Products

I ran into Rob Ward at a recent StartupGrind and he came across as very personable, relaxed and successful. He is a Founder at Annex Products, who make the incredibly popular Quad Lock cases for mounting smart phones on bikes, cars and people.

We caught up a few days later for a coffee near his office in Prahran. The Annex office had a cool set-up with ping-pong table, arcade machine, 3D Printer, quadcopter and lots of prototypes. His team were working behind 27-inch iMacs running Solidworks for CAD and for everything else it was the just usual Dropbox, Pages, Numbers, Adobe Creative suite and Final Cut Pro.

I intended to ask him about the different platforms they used to manage and run their business, but we spent quite a bit of time talking about sales and marketing. He sees Annex as a brand and product design business. Great design is important but “isn’t enough to stand out from the crowd”. You need good sales and marketing.

Rob learnt sales and marketing the hard way (or the best way he’d say). In the mid 90s he was out walking the streets selling OptusVision cable TV to Australians. I remember thinking that was a horrible job at the time but Rob reckons it gave him the best possible sales education. Maybe I missed out!?

The best sales and marketing tools Annex use are Facebook Ads, Email lists – “the best customers are return customers” – and AdRoll, a “retargeting” platform. Retargeting works by keeping track of people who visit your site and displaying your retargeting ads to them as they visit other sites online. That’s important because many people don’t buy the first time they visit your site. They just need a little reminding!

Some of the other key systems/platforms they use are:


Kickstarter: He had to perform some magic in setting up a prerequisite US Bank account to get started, but this step got the ball rolling and “proved” there was a market for their product. (The US bank account issue does not exist anymore, at least for Australians.)

eCommerce customer interface:

Shopify is the businesses storefront. Rob mentioned how easy it was to set-up and use – “Why would you build your own?”. They use Canadian developers to tailor the site (Responsive design etc.). Why Canada? Because Canada has great Liquid developers. (Liquid is a templating language for Shopify). Previously they’d sold Opena cases on a “cheaper solution” (not Shopify) and then one day Ashton Kutcher tweeted about them and knocked their system over. The ecommerce platform provider at the time gave them as much infrastructure grunt as he could and they still fell over. Shopify has never had this problem.


Paypal and Stripe (which only just kicked off in Australia making it easier to use accept payments from anywhere in the world).


Shipwire: You previously needed a US account to get this started just like Kickstarter. It’s easier now. Shipwire integrates with Shopify, and a heap of other commerce systems. They store your products in their warehouses, provide shipping rates and inventory back to your storefront, arrange delivery etc. These guys are crucial if your business ships a physical product.

Customer Support:

Zendesk: Keeps track of customer issues and details. As the Annex business hit scale, there was no other way to keep track of this stuff.


Capsule CRM: Annex primarily use this to manage relationships with their B2B customers.

Accounting software:

Xero: Accounting SaaS provider. Cool… but it’s still accounting.

List Management:

Mailchimp: Manage your email lists.

All of these platforms are software-as-a-service. The ecosystem they play in has forced the major players to integrate well with each other. This truly is a business without on-premise IT (apart from their iMacs).

Rob takes the approach of “do and change” with his business so he’s not too concerned about change. If a SaaS provider they use started to alienate their base or went out of business I imagine he’d take it in his stride and move to someone else. Possibly a few late nights and stressful moments, but Annex would get through it.

One thing he kept iterating was how easy it was to set up these businesses.

So check them out. It’s a great example of a contemporary global niche business, where the barriers to entry get lower and lower.

Start your own business. Looks easy enough!

Is the cloud just… web services?

My work colleague turned around to me and said, “Web Services aren’t APIs”. That didn’t sound right so I started investigating. What is the difference and why is it important?

Applications have been built and constructed from re-usable and shared components since the bloody epoch. It’s why software is eating everything. Once a standard interface – and usually a corresponding library – is agreed upon there’s little reason to go back to first principles again. It’s division of labour, driven by pure need, evolving organically.

Then along came ubiquitous, always-available connectivity and expanding bandwidth. Why bother compiling and distributing an API/Library when the same API call could be made to a shared network service? A web service.

So a web service is a type of API. Not all APIs are web services though. APIs are the public interface for a piece of code – it is what you can call from within your code. It may be a web service, but it could also be a Java library or similar.

Wikipedia has a web services as “… a software function provided at a network address over the web”. That’s a pretty good definition. It must also be loosely coupled, which means that both the service caller and owner agree on the interface but know little about each other. The back end class can be substituted as needed.

Companies are themselves creating their own web service APIs. Here’s an API for business listings at Australia’s Yellow Pages and here’s one I’m looking at now to do some useful work on my expanding Evernote database. Both of these are web services with some extra API management capabilities. Grab yourself key and start developing!

Amazon was miles ahead of the curve on this. This famous post by Steve Yegge describes the famous Jeff Bezos mandate (in 2002!) that all teams at Amazon must:

  1. Expose their data and functionality through data services,
  2. Teams must communicate only through these interfaces (no direct database links etc.),
  3. All interfaces must be designed to be accessed externally

and a few other things. Talk about ahead of the curve.

It’s the future mesh of interconnectivity. One big “programmatical” mash-up.

There are the web services you own and the ones you don’t. With regards to the ones you do own, you’ll have to think about how you maintain some control of the integration. Two possible models are shown below. Do you have an integration bus/relay/proxy in each cloud so as to minimise network traversals, or do you have a few centralised integration points to make control and standards (and non-functional requirements like logging, access control, templates etc.) easier.

Web service cloud options

For the web services you don’t own but use, how much do you rely on single vendors, how do you manage keys and how do you manage different standards/skill sets etc.

I’ve always thought of “The Cloud” as a technology theme that is behind many new implementations, but I’m starting to think “the Cloud” is just a biblical plague of web services. It’s even hidden the in term “as-a-service”! All SaaS, PaaS and IaaS providers have public web service APIs built in from day one.

IaaS could mean twice the work for IT

In my last blog I wrote about Cloud Management platforms, and how they enable integration of multiple clouds (public and private).

One purpose of this is to drive standardisation of infrastructure. This is the usual drive for standards, strategies, life cycling and consolidation that has been with us for years.

Tech-heads get excited about new stuff like node.js, ruby on rails, Ubuntu, skinless servers etc., but in isolation these technologies provide absolutely no benefit to a company. They cost money to buy, build and support. When these component technologies are combined with application logic and data though, they can add immense value. This value must exceed – by a decent margin – the sunk cost of deployment and support.

IT vendors move between mass standardisation/commoditisation and differentiation – sometimes doing both things at the same time. AWS, GCE, and Azure strive to provide a base server at the cheapest cost – ie. commoditisation – but at the same time offer differentiated, non-standard services like Azure Service Bus and Redshift – to get the customers in (and keep them).

Also, over time enterprises accumulate legacy bits and pieces that are too old, too important or too expensive to replace. There they (dis)gracefully age until something serious happens.

All these drivers work against simplification and standardisation. A good friend I use to work with was asked by the IT Group Manager what he would do if, in his role as IT Infrastructure Manager, he had a blank cheque and infinite time. He said something like trash the whole lot and start again. From scratch. Clean out the “detritus”.

Head In A Cloud (jb912 via Flickr)

If you’re an established enterprise you’ve probably spent the last couple of years trying to understand The Cloud and what it means. The years before that you probably virtualised the hell out of everything on some hypervisor, and before that you tried to get everything on commodity servers. Along the way you migrated many workloads to the latest and greatest, but not everything. You probably still have non-cloud, non-virtualised, non-commodity gear around. Do you really believe all workloads will end up on IaaS?

(If you’re a start-up, it probably makes sense to start in one cloud. As you grow though you may end up getting stuck using their proprietary technology. That may be ok, or not. Ask yourself, could Netflix migrate off AWS, and what cost?)

You have standards for deploying servers in-house (something like Linux or Windows on a hypervisor), you have standard network switch configurations and whatever passes for standards in the storage space.

You don’t want to manage a second (or third or fourth) set of standards for your IaaS provider(s).

Comparing some pretty standard IT infrastructure objects against some AWS objects:

[table th=”1″]

In-house technology, AWS technology

VM template,AMI

Load balancer,ELB

Firewall policy,Security Groups


At best they are only packaged differently (VMs vs AMIs) and their guts are pretty similar. At worst, they have different capabilities, configurations, and therefore standards and expertise (load balancers vs ELB).

If you buy the Hybrid cloud direction we’re heading according to Gartner and your own observations then…

It’s two – or more – standards trying to be one, and that’s possibly double the work for IT.

Another argument for Cloud Management Platforms such as RightScale, Scalr and Kumolus? Thoughts?

What is a Cloud Management platform?

The Cloud keeps diversifying. New offerings come on the market each month. IaaS vendors innovate and create new services to help their customers (and if it also locks them in that’s okay too).

That said there is a core set of capabilities everyone looks for in an IaaS cloud. You may want to build an Ubuntu image with a particular number of vCPUs and memory. You don’t really want to concern yourself with the cloud server types that a vendor like Rackspace or AWS provides.

You don’t want to specialise in understanding the API of every cloud vendor when configuring your continuous deployment tools either.

You just want a server, operating system and some software that you can move between clouds. You’d love it if cloud providers agreed on some standards. If only.

Cloud management platforms – like RightScale (Ed: corrected) or Scalr -manage this disconnect.

Most cloud management solutions are aligning their security models, virtual networking and API strategy with AWS. They aim to provide their customers with the ability to migrate workloads between owned and non-owned clouds. They are both open source and proprietary.

Cloud management platforms represent both an immediate necessity for managing complexity and also an opportunity to start building sophisticated IT operations management platforms that allow better planning for the IT function, an ERP for IT if you like.

The following diagram shows where Cloud Management platforms reside in the Cloud stack (as distinct from Cloud platforms).

Cloud Computing ecosystem
It’s important to understand the difference between a Cloud Management platform (managing lack of standards between clouds) and a Cloud platform (turning your hypervisor and other shared resources into a private cloud)

For your cloud management platform to perform its function of integrating with your private cloud it needs to integrate with your internal cloud platform. Most organisations have created their private cloud by taking their existing investment in virtualisation and adding a cloud platform tier.

The expected features of a Cloud Management platform are:

  • Public/Private Cloud integration
  • Manage Compute, Store and Networking consistently.
  • Metering – The ability to track usage and apportion costs.
  • Templates – to support quick provisioning
  • APIs – to enable integration of other business systems such as billing systems and CRM. Integration with configuration management platforms such as Chef and Puppet to describe infrastructure in code.
  • Role-based access – d’uh.

There is a lot of confusion about terminology. This is partly because of the rapidly changing market and also because vendors are developing solutions that overlap different areas. Maybe they are trying to confuse us on purpose! Terms such as Cloud Brokers and Cloud Infrastructure Management are bandied about.

What is your Cloud Management strategy? Do you need one? Or are you picking a single vendor to keep it all simple?

2 more differences between in-house and AWS

In my previous post I talked about three differences between in-house and AWS deployments and specifically how it affects your architectural choices. Today I’ll talk about two more.

Typical AWS StackCaching

This whitepaper by AWS illustrates their design philosophy and is well worth a read – especially from page 11. The two concepts of loosely coupling and massive parallelisation strike at a core difference between traditional and cloud computing architectures.

If you’ve worked with large traditional applications you’ll be aware that it is common for the database and storage tiers to be a performance bottleneck. Databases like Oracle are monolithic beasts that are hard to scale without spending a lot of coin and difficult to replace once they’re in place.

Whenever you see an AWS architecture there’s typically a database-boosting caching tier. Cloud workloads are typically more elastic and read-intensive (ie. web apps) so cloud architectures must handle bursty and read-hungry workloads.

The AWS caching product is ElastiCache, which comes in difference instance sizes just like EC2. ElastiCache is based on the open-source object cache memcached, or the NoSQL DB Redis (your choice).

The first time a database object is accessed it is read from the database and put in the cache. Every subsequent read is then directly from the cache until the time-to-live (TTL) on the object is reached or the cache restarted. Typically you set up multiple instances in difference availability zones for high availability. You must make sure that the TTL is set on database objects so that they get cycled regularly in the cache.

In the diagram above there is a separate caching tier. Another option is to install memcached on the application instances. In this case each cache instance is stand-alone and dedicated to its own application server.

Another increasingly popular alternative to caching is to use exclusively NoSQL databases. NoSQL databases provide eventual consistency but can’t do complex database operations very well. They are easy to develop with.

Security Groups

In an in-house architecture the network is divided up into a number of security zones that each have a trust rating: Low trust, high trust, untrusted etc. Zones instances (subnets, VLANs, or whatever) are then separated by firewalls (see below)

AWS replaces firewalling with the concept of security groups. I haven’t been able to find any information about how AWS actually implement security groups under the hood and that’s one problem with them. You have to blindly trust their implementation. Assuming AWS security groups will have vulnerabilities from time to time, you need extra protection. There’s also little in the way of auditing or logging and a lot of rules and constraints about security group usage too.

For business critical applications, where data and service protection are significant issues, extra security technologies to consider are: host-based firewalls (eg. iptables) and intrusion detection, web application firewall SaaS (eg. Imperva), data encryption technologies, using a Virtual Private Cloud, two factor authentication and vulnerability scanning amongst other things.

To get around this problem one pattern that emerges is that of keeping critical data and functions in a secure location, and sharing a common key with the application running in the cloud. For example, to be PCI-DSS compliant, many organisations hand off their credit card processing to a payment gateway provider so they never have to handle credit card data. The gateway passes back a token and transaction details to the application. The application never touches the sensitive data.

Security groups simplify your set-up though and are great for prototyping. You don’t need a network or security expert to get started. One of the reasons you went to the cloud was probably because you didn’t want to touch the network after all!


The differences I’ve chosen to focus on in this two-part blog are: load-balancing, storage, databases, caching and security groups/firewalls. The reasons I’ve chosen specifically these is because the implementation of, and philosophies behind, each drives a different overall design approach. To build your own hybrid clouds these differences will have to be reconciled.

3 differences between in-house and AWS

To support Gartner’s latest hybrid cloud predictions and become a broker of cloud services, IT will need to minimise the architectural differences between on-premise and cloud infrastructure and use standard cloud building blocks.

On-premises IT and AWS are different though. Traditional enterprise applications have evolved on open, interoperable, heterogeneous platforms, while Amazon evolved out of the requirements of an on-line retailer who needed serious scale.

Here is a typical cloud-based application pattern in AWS. This is a single-site deployment with a data-only DR site. Compare it to the typical enterprise stack. There are some differences.

Load balancing

Traditional load balancers are customisable, tuneable, and built on high performance hardware. Load balancers by the likes of Citrix, F5 and Radware can perform a wide range of functions (eg. load balancing, fire-walling, vulnerability protection, address rewriting, VPN, VDI gateway).

Load balancing in AWS is a bit different to what you’re used to. Amazon’s native offering, the Elastic Load Balancer (ELB) is presented as a service to customers and the hardware is completely abstracted. AWS ELB can load balance across Availability Zones. This is geo-load balancing, a feature you have to pay extra for with on-premise load balancers. It also natively supports auto-scaling of EC2 instances, of course.

AWS ELB has some shortcomings though. You cannot create a static IP for load balanced loads, log HTTP(S) traffic, drain hosts or configure different load balancing algorithms, all of which is standard functionality in an on-premise load balancer.

An alternative load balancing option in AWS is open source software like HAproxy, or spinning up the equivalent of F5 etc. inside an AMI. The benefit of these approaches is that it more closely represents your internal set-up making hybrid load configuration easier. The downside is that it can be more expensive and more effort to set up. These alternatives are shown as greyed out above.


AWS storage has “unlimited” scale so businesses don’t need to worry about outlaying for big storage arrays every year.

For application and database storage in AWS, EBS Storage is really your only choice. AWS EBS IO performance can be poor and unpredictable though compared to on-premises storage options. For better performance you need to pay extra for provisioned IOPS. You can also create your own RAID volumes from EBS block devices but this can break EBS snapshots and lead to higher costs.

The most requested EBS feature is the ability to mount an EBS disk to more than one EC2 instance. On-premises infrastructure has always had the option of using shared storage as a way of creating clusters, transferring data and sharing configuration. This EBS constraint seems like a deliberate choice to force you to create EC2 instances that stand alone with no inter-dependencies, as a way of mandating/supporting the auto-scaling philosophy.


A highly available database hosted in AWS looks quite different to its in-house equivalent. One reason is that workloads in AWS are often web applications with a high read requirement. Databases in AWS are also built using EBS storage with its constraints on shared storage and AWS has been strongly influenced by MySQL and its replication methodology. Here is a basic architecture for a highly available on-premise and AWS database

AWS v Onprem DB

An AWS database can have multiple slave databases, which can also be used for database read operations to improve performance. Replication and the management of failover between nodes is scripted or manual. The storage replication occurs within the database tier so it may be slower. Transaction logs maintain database consistency.

In a typical in-house database there is expensive and complicated clustering software that provides well integrated availability. The data replication occurs within the storage tier, which should be faster and leverage existing storage assets. There is a single floating DNS/IP Address for the entire DB tier, which simplifies application set-up. There is no opportunity to get extra read performance from failover/standby servers though.


There are other differences between AWS and in-house that I’ll cover in a follow-up blog. I’d be interested to know what you like or dislike about the different approaches to infrastructure and how it has affected your planning.

Busting them freakin’ IT silos

This is a rough approximation of most IT Infrastructure organisations I’ve worked in – minus management of course!

Cloud Mgt Org - before - small-1

As you can see it’s very silo-ed. The only reason it functions at all is because IT people are highly developed socially, able to communicate without using jargon, and can comprehend the bigger business issues without being too precious about technology. Pfffft… Bollocks! The only reason it functions at all is because of large cross-silo teams of project managers, infrastructure architects and service managers that run around like Mel Gibson in Gallipoli trying to get the message around about what needs to be done.

A typical workflow for an IT project might be something like this (The cells with green indicate cat-herding, high-cost activities):
Project Engagement

If you’re lucky, some activities may have been automated and orchestrated (shown above as green/orange), which expedites and standardises projects.

This process is implemented in a pretty predictable and fixed way. And for good reason. “Management by Projects” has been a pretty consistent way of running IT even if weekly time-sheets are a menial fiction we all loathe. It’s only the mega-budget, long-term projects that have a special way of going awry.

The organisation in the first diagram won’t scale in the era of cloud computing though. It’s too cumbersome. Everyone loves cloud computing because of the low transaction costs (initial build cost and time-to-market). Instant gratification wins most of the time even if it costs more over the long term.

An organisation structure that can support this instant gratification will be one where the silos have shrunk. I’ve attempted to show this in the updated organisation below:

Cloud Mgt Org - after - small-1

IT Generalists and specialists with a propensity and willingness to cross-skill are moved into new Cloud Infrastructure and Service Operations teams. Over time these teams grow as your “traditional” silos atrophy.

You’ll still need experts in silos, whether in-house or out, to look after physical assets and organisational-wide compute, storage and network domains but the new cloud groups will be responsible for delivering IT and business projects.

Your silo-ed database specialists will have experience with big database technologies that aren’t that flexible and your storage and networking specialists will be experienced with enterprise-grade technologies that don’t necessarily have a cloud equivalency.

In many cases the perception, quite rightly, will be that cloud equivalents for databases, networking and storage are unsophisticated and lacking in features. The perception is right but changing.

The new organisation should drive efficiency, consolidation and consistency making internal IT environments (internal cloud, hybrid cloud etc.) more competitive with external cloud platforms.

This new world requires upfront investment and a faith that if you build they will come. But they – the business – will also need some encouragement. And the best way of doing this is to:

  • Limit their platform options – Stop putting things on legacy platforms. Use your cloud options.
  • Let them “play” on the new system – Users can spin up their own sandpit environments with a light-touch approval process (have them auto-expire… the sandpit environments, not the users!)
  • Encourage development teams – Talk about the concepts inherent in cloud platform development.
  • Develop a cloud business architecture with agreed terminology and artefacts.

It’s not exactly bustin’ them freakin’ silos but it’s a start. Now we only need to deal with the organisational politics to make this all happen….