Saturday 28 April 2018

Something-As-A-Service in the Cloud

Source: Pexels

I'm going to be writing quite a bit about Azure, Office 365 and SharePoint over the next few months.  The initialisms IAAS, PAAS and SAAS will come up from time to time, so it would be helpful to explain these terms in advance:

  • IAAS - Infrastructure As A Service
  • PAAS - Platform As A Service
  • SAAS - Software As A Service

Before we talk about the Infrastructure, Platform, and Software parts, let's talk about the as-a-service part.  What does this mean?

To understand as-a-service, you need to know what cloud computing is.  This has been a buzzword for a good few years now, and it's the backbone of as-a-service.  Wikipedia provides a good definition:


"Cloud computing is an information technology paradigm that enables ubiquitous access to shared pools of configurable system resources and higher-level services that can be rapidly provisioned with minimal management effort, often over the Internet. Cloud computing relies on sharing of resources to achieve coherence and economies of scale, similar to a public utility."

In less technical terms, cloud computing providers have huge racks of servers loaded with useful tools like databases, storage, load-balancers, web servers, and software.  They then lease space on these servers to remote users, along with access to the (usually pre-configured) tools.  This is referred to as AAS, or As A Service.  It's important to understand that cloud computing is a service provision model, not a generic term to refer to remote computers, which it's often misunderstood to mean.  Cloud computing is what's used to deliver AAS.

AAS is in contrast to "on-premise" where the servers, databases, storage, etc are all physically located within a company.  It's much cheaper to lease space on a server with access to the tools you need than it is to buy, configure and mantain all the servers and tools yourself, especially if you only need access for a short or ill-defined period of time.  Think of AAS as the digital equivalent of hiring a van - they buy the van, service it, clean it and repair it, and different people hire the van as and when they need it, then return it.  The van leasing company has the costs but makes a profit once the hiring fees have covered those costs, and you get the van you need for a relatively small outlay without any of the hassle and cost of having to actually buy a van.     

So, cloud computing providers lease space and tools as a service, but different users want different services.  Therefore there are different service models of AAS, of which the 3 standard ones are IAAS, PAAS and SAAS.  These service models are defined by the National Institute of Standards and Technology (an agency of the American Department of Commerce) in their NIST Definition of Cloud Computing (link to PDF).  This is a surprisingly readable 7-page document which is a model of economy and information, and if you're at all interested in cloud computing or AAS then I encourage you to spend a few minutes reading it.

In short, the service models explain which parts of the tech stack the vendor is responsible for, with the obvious correlation that the customer is responsible for the other parts.  Here's a diagram showing how IAAS, PAAS and SAAS divide up the responsibilities between the vendor and the customer, with On-Premise included for comparison:


Reproduced from Kevin Remde's Technet blog
With On-Premise, you manage all of the hardware and all of the software in the tech stack.

With IAAS, the vendor manages the hardware, but you choose the operating system and everything above it.  This is typically used for things like web hosting and data centres.

With PAAS, the vendor manages everything except the application and the data.  This is commonly used by software companies as a base for developing an application.

With SAAS the vendor manages everything.  A good example of this would be GMail, where every part of the tech stack is managed by Google. 

With both IAAS and PAAS the customer can choose how many resources to use as and when they need them (this is why cloud computing is often called "computing on demand").  The billing is usually dynamic and depends on the resources that have been consumed during the billing period.  It's typical to buy IAAS/PAAS capabilities and spin up additional virtual servers as required (a virtual server is a software representation of a real server), then apply a template that provides standard O/S, Middleware and Runtime.  With IAAS the customer maintains the template and with PAAS the vendor provides one or more templates to choose from.  The customer pays for every server they use.  With SAAS you're getting access to a piece of software and usually the price is determined by the number of user licences you buy.

As an example of how this works, consider the following scenario:

  • Vendor A buys, configures and maintains networking, storage, servers and virtualisation to sell as IAAS.
  • Web hosting company B buys IAAS from vendor A, then configures several templates for O/S, Middleware and Runtime that will appeal to different customers.  They then sell this as PAAS.
  • Software development company C buys PAAS from company B, picks a template and a number of servers, then develops a piece of software on it.  
  • Finally, company C sells their software as a SAAS offering to customers around the world, running on company B's PAAS, which runs on company A's IAAS.

It's not uncommon for a vendor to offer at least 2 of the 3 service models, although normally this would be IAAS/PAAS or PAAS/SAAS.  It wouldn't make a lot of sense to offer IAAS and SAAS without PAAS, because if the vendor has the capability to offer both infrastructure and software services then they've got the capability to offer a platform service.  

That covers cloud computing and as-a-service to the level that I'll be using it over the new few months.  There might be cause to look into deployment models (also covered in the NIST Definition of Cloud Computing), in which case there'll be a separate article, but that can wait until it's needed...


Thursday 26 April 2018

More Strings to the Bow


Over the last year I've been working on a SharePoint implementation in my day job as a contractor.  I have a few years' experience doing content management and site collection administration on a SharePoint on-premise instance from a previous role, but this is brand new, SharePoint online, evergreen SAAS where O365 and Azure are important elements.  There are a million things to learn, and a million more after that, and then you might, might know enough to say that you know what you're doing.  

All of which is very exciting and I have indeed learnt millions of things.  However, this has left me with a problem: this blog.  AgileDocumentation was always intended to be a blog that was generally about technical writing and specifically about documenting in agile environments.  Whilst I'm the Scrum Master/agile coach for the SharePoint project team, and I'm writing lots of documentation - how-tos, instructions, design docs, comms, etc - it's not an agile documentation role.  So I haven't blogged much over the last year or so because my mind was on non-agile documentation things.

But I still think of myself as a writer.  At my core, what I am, what I do, what I enjoy, is writing.  So maybe I can't write about writing as much as I used to, but I can still write about technical subjects.  And that's what I'm going to do.  

Agile Documentation will still be in its heart a blog about technical writing, and I hope to return to that subject as much as possible.  It's just that you might find it's pivoted towards the technical side of SharePoint, with some O365 and Azure thrown in, for a while at least.  Think of it as an extended series on getting an enterprise-level content management system set up.  That's documentation-related enough for me.  For now.