Atomic Units for a Company

What is this “atomic unit” analogy you speak of?

The least divisible unit of interest for a company. In math, that is numbers (or even more fundamentally, sets). In physics, that is equations. In chemistry, that is molecules. In biology, that is cells.

What is the atomic unit for a company?

McDonalds: Hamburgers
Barnes and Noble: Books
Coke: Can of coke

It is the base unit that the company cares most about. Figuring out the atomic unit for a company is both enlightening and limiting. Enlightening because it gives you a focus, it lets you rally to what you are good at. It is limiting because it is incredibly difficult to be as good at selling anything outside the purview of your atomic units–few companies who try to have multiple atomic units are able to succeed.

The atomic unit does not need to be as specific as the examples above. Anything you can warehouse and ship in a small box
Netflix: Digital media in various forms
P&G: Household items

Further more, atomic units are very similar among competitive companies (eg. Burger King, Borders, Pepsi).

There is a major amount of confusion in the “Cloud” and part of the reason for that is many different companies selling many different atomic units are being grouped together. One way to make sense of it all is by understanding the atomic units of these companies at a generic level.

IaaS: Resources
PaaS: Apps
SaaS: Utility


  • SaaS is defined as B2B subscription based service

IaaS: Resources

Examples: Amazon Web Services, Rackspace, Joyent

RAM, CPU, Disk, etc. Infrastructure as a service is all about providing resources on demand. When you look at a service like Amazon Web Services, all the tools center around resources, all the documentation is about resources, all development is focused on resources and the main thing people use it for is resources.

On demand resources is why the hourly pricing model works so well at this level. Intuitively, resources come and go all the time.

PaaS: Apps

Examples: AppFog, Heroku, AppEngine

Applications, and mainly web applications right now, take a completely different perspective. The amount of effort required to connect resources together is often underestimated. It is why companies hire IT departments, it is why system administrators are always in need. Going from a single host running apache+mysql all in one to a system architecture with separate load balancers, caching servers, app servers, database servers with redundancy and failover is a lot of work both up front and ongoing maintenance.

The other thing that PaaS does is configure and manage IaaS from an apps perspective. Tools like CloudFormation are great, but approach IaaS management from a resources perspective. Apps see the world in a much different way than resources do.

The P in PaaS stands for platform, so PaaS’s responsibility is to create a platform not only for applications, but connecting applications to services.

Apps, unlike resources, do not tend to come and go frequently. The need for on-demand hourly pricing is not as important with this model in most cases except when you temporarily burst app usage or test/dev scenarios.

SaaS: Utility

Examples: Salesforce, Parse, StackMob

The fundamental unit for SaaS is really selling utility. Whether you are selling utility directly to a person (Salesforce) or selling the utility to a mobile client side app (Parse, StackMob), this is a fundamentally different concern than either selling resources or apps.

This is a controversial claim, so I want to go into more detail here. Parse’s TechCrunch series A announcement proclaimed it “Heroku For Mobile”. I think this classification is fundamentally off.

What makes a good SaaS company is better tools and more tools. The core competency is how well those tools work and how much time they save the people using them. The development of all the tools (user management, social integration, push notifications) is independent of the competency around the platform powering the tools.

The reason that some SaaS is mislabeled as PaaS is that all truly successful SaaS companies need a PaaS to power their SaaS. Whether they build it themselves (, or use another PaaS to power them does not change the fact that they are fundamentally a SaaS company. Big SaaS companies with huge resources like Salesforce have a fighting chance to push down the stack into PaaS (although even then, they acquired Heroku so they must have thought they needed help from the ground up). Small startups might not find a PaaS that is flexible enough for their use… yet. But PaaS is still young technology and will mature quickly addressing those issues along the way.

The way companies like Parse, StackMob and others will end up differentiating is not by having the best PaaS powering their utilities, but rather by having the best developer utility.


When a company understands its atomic unit and focuses on it, it can thrive. When they reach and try to move up the stack or down the stack, and either do not put the resources into it that it requires or don’t have the resources to pull it off successfully, it is on a bad track.

Understanding all of this, some predictions can be made.

  • Companies with SaaS aspirations are going to have to figure out their PaaS strategies in order to be successful
  • IaaS companies core competency is not the same DNA as PaaS companies. AWS is trying to climb into PaaS from a resources perspective with Beanstalk. Unless they partner or reinvent from the ground up with apps in mind, they are not going to get much traction because of this DNA impedance
  • Mobile startups that think they are PaaS when they are really SaaS are going to have a hard time finding as much success as the ones who focus on utility and win true market share


Just because a SaaS company has been forced to develop their own PaaS solution doesn’t mean that SaaS and PaaS are the same. Just because a IaaS company has tried to develop their own PaaS solution doesn’t mean that IaaS and PaaS are the same.

There is a lot of confusion in the market right now for Cloud. A lot of confusion is due to a fundamental misunderstanding of the core competencies, atomic units, and business models behind the companies in this space. Companies that are great at one atomic unit are usually not good at others. The companies who recognize this and embrase what they are good at, or put enough resources into moving up or down the stack as possible, are the ones to watch.

Share this post
Facebook Twitter Google
Try AppFog: The new PaaS Hackers love
  • Why 2013 is the year of ‘NoOps’ for programmers [Infographic] — Cloud Computing News

    [...] infographic also aims to clearly delineate the different layers of the cloud stack, something he opined on in a December blog post. PaaS isn’t a feature of IaaS, he explained, but “a full reinvention from the ground [...]

  • Why 2013 is the year of ‘NoOps’ for programmers [Infographic] | Ubuntu Cloud Portal

    [...] infographic also aims to clearly delineate the different layers of the cloud stack, something he opined on in a December blog post. PaaS isn’t a feature of IaaS, he explained, but “a full reinvention from the ground up.” [...]

Powered by Olark