Technology as a field is littered with acronyms. TLD, CPU, GUI, etc. And if you noticed that those acronyms all have three letters, we even have an acronym for Three Letter Acronym (TLA). However, some of the most prevalent acronyms in software these days are those for *aaS , the ubiquitous <Something> as a Service technologies that are dominating the landscape.
Companies large and small are using these services to accelerate product development, offload work, etc. The big three “as a service” options are: infrastructure, platform, and software. Let’s look at defining those three, along with what I’m going to call NaaS or “Nothing as a Service”, more on that later.
Which of these you use determines how much of the work you are doing yourself and how much you are abstracting away to the provider of the service. Depending on what your business is, you might want to abstract away all or none of the effort involved in providing functionality. While there are always exceptions and overlap between the acronyms–they are only abstractions, after all, the general principles hold.
SaaS, PaaS, IaaS – Climbing Down the Ladder of Abstraction
Software as a Service
Starting at the highest level of abstraction, we have Software as a Service (Saas). In this model, the whole shebang is in the vendor’s hands and you just use the service. These providers range from enormous enterprise-level software offerings like Gmail and Office365 Online down to micro-SaaS providers like one of my personal favorites: Freckle, which provides time-tracking for freelancers and teams. At this level, there is no installation of software, no updates, etc., just open your browser and go.
Platform as a Service
Next on the list is Platform as a Service (PaaS). In this model, you don’t want to think about the server or its internals, you want to point to a virtual machine, tell your code or container to go live there, and let your application take over from there. This is where Engine Yard fits in the scheme of things, along with Heroku, Openshift and others. In addition, most of the larger IaaS providers also have offerings in this area.
Infrastructure as a Service
Further down the chain of abstraction we have Infrastructure as a Service (IaaS) providers. We run into the heavy iron here: Amazon Web Services, Microsoft Azure, and Google Cloud are the three dominant players, with IBM and VMWare playing catch-up. Here, the line between what you are doing and what the provider is doing gets thinner. You are typically using virtual machines on someone else’s servers rather than servers of your own. Which, of course, allows your servers to be anywhere your provider has a data center, allowing for lower latency, scaling, etc.
Nothing as a Service
Finally, at the level of no abstraction, we have what I like to call Nothing as a Service (NaaS). You are responsible for everything from taking the server out of the box, operating system configuration, network connectivity, down to making sure the power is plugged in.
Each of these options has their plusses and minuses and a company may find themselves using any or all of them. Which you choose should be based on how central application is to your business. In most cases, companies probably don’t need to host their own email server, so a SaaS solution frees IT resources to work on more core business functions. Similarly, if you don’t want to spend your time tuning the JVM, a PaaS like Engine Yard may fit your needs.
Probably the best analogy I have come across for showing these levels of abstraction is from this post, which has the following image:
I think this does a brilliant job of explaining what we have been getting at: choose the provider that fits your needs at the time. Thanksgiving dinner, you are going to cook for yourself, pizza after a softball game is an evening out.
It’s Time to Eat
It’s getting close to dinner time and the last thing you want is a bunch of hungry people bugging you for food. You know what, before we get too lost in the restaurant metaphor, let’s just stick to software and talk about which XaaS you should choose.
You Probably Want to Use Software as a Service When…
When the application isn’t core to your business or it’s something that you are not adding value to it, SaaS is probably the way to go. If your business only uses email for employee communication, don’t set up an Exchange Server. If you are adding value to email by connecting it to your proposed application–for example–then you need to lower your level of abstraction.
These are probably the easiest calls you will make in this space. There are so many great line-of-business SaaS applications that you have to have a good reason not to use one. I suggest that first among those good reasons comes from answering the question: “Are we going to make money off of this software?” How you make money from it is dependent on whether you are a startup or an enterprise, but irrespective of that, you seldom go wrong keeping value at the forefront of your thought process.
World-Domination Starts at IaaS
Given what I can only assume is your desire for world-domination, I’m sure you have plans floating around your mind (and maybe your pitch deck) about data center deployments, CDN’s, DevOps, etc., let me suggest that you should nearly always start with IaaS.
Why? If you are following Lean practices (and if not, why not?), and your first Minimally Viable Product (MVP) requires you to set up any level of infrastructure, I am willing to bet that your definition of “minimally” is too big. IaaS allows you to quickly build the smallest possible increment of your application, down to deploying single functions on AWS/Google/Azure. Any slice of time that you spend in early iterations building out infrastructure is opportunity cost keeping you from getting your MVP in front of potential customers. By all means, keep dreams of scaling out percolating in your subconscious, but focus on delivering a solution worth scaling first.
When is it time to PaaS?
When to move off of IaaS is a question with no hard and fast answer, but let me offer a few guidelines. It’s time to start thinking of PaaS when you:
- Have paying customers using your application. How many is a bit of a fluid question, but let’s put 25 up as a target.
- Have some funding. This means you are either an enterprise, have some VC money backing you, or have bootstrapped yourself to the point where you are paying yourself.
Meeting these conditions minimizes risk for your application and your company. These conditions are necessary, but not sufficient. You’ll know it is time to move on when the limitations of the abstraction are limiting the building of the next iterations of your product. Better to move one iteration late than one too early. If you are encountering no friction, make no changes.
My Baby is All Grown Up Now
One way to look at the XaaS ecosystem is that it exists to grow and nurture your application to the point where you might not need it anymore. But just like your parents, they are available (hopefully) whenever you need them. Going the Nothing as a Service route is the last step in the evolution of an application and it is the rare product indeed that gets this far. The conditions for outgrowing PaaS are impossible to reduce to a simple set of rules. More likely, an application expands into multiple regions PaaS, breaks into microservices, etc., in order to avoid the overhead of setting up servers, networking, etc. It is, as they say, a high-class problem. If you are in this situation, congratulations! There is nothing I could convey in a blog post that will have more than a superficial relationship to the decisions you’re making.
Everything we’ve gone over here are just guidelines. Your particular situation may require ignoring part of all of these suggestions. Pick the level of abstraction that makes sense for your business needs and get to make something awesome.