Ben Halstead
About me
CTO of Brightpearl – leading provider of Software as a Service (SaaS) for small business.
I’ve previously held senior technical positions at BSkyB and lastminute.com
My interests are high-volume and high-availability web applications and putting together the teams to build them.
About this presentation
In this presentation I’ll be talking about the technical questions you should be asking yourself if you’re building a SaaS application.
I won’t be covering features, visual design or usability.
Instead I’ll be concentrating on platform selection and putting together the right team to build your app.
Contents
This presentation is split into three sections:
Designing a SaaS application – basic requirements and definitions, including
some introspection about what SaaS means in practical terms!
Cloud hosting: IaaS and PaaS - making your application available to your
customer using modern hosting techniques.
Building a team around IaaS - IaaS changes the traditional technical team
Are you really building a SaaS application?
An important question, as the characteristics of a SaaS app can be very different from those of a web site or a web application.
Q: Which of these would you consider to be SaaS applications?
A: All of them, depending on your point of view
Most of those businesses/apps/sites meet one or more of the Wikipedia definitions of SaaS.
Like a lot of terms in IT, SaaS can often be about self-identification and marketing. We need some practical definitions…
Some practical definitions
Exclusively accessed via the InternetSoftware for business or personal productivity
If not free, then charged for on some form of subscription model 10 years ago would have been provided as a bespoke intranet tool 20 years ago would have been a high cost ‘productivity suite’
Flexible workflows – multiple ways to do things
Has the potential to be critical to a business’ success
SaaS non-functional requirements
If your application matches most of those definitions, you are indeed building a SaaS application. This means that you will need to build a platform which can support the following:
High availability and fault tolerance – people might be staking their careers and
businesses on your software, it needs to be available and reliable.
Asymmetric load – if youare providing flexible and powerful tools, your
customers will amaze you with the variety of innovative ways they will find to try and bring your app to its knees!
Getting it right first time
Your platform needs to meet all of those non-functional requirements from launch.
Never believe that you’ll have the chance to go back and fix things later and be aware that if you don’t meet your customer’s high expectations right away, you are unlikely to have a ‘later’.
Fortunately many of these requirements are much easier to meet thanks to modern hosting.
The obvious choice for SaaS startups
Very few startups would be well advised to use a ‘traditional’ hosting arrangement where you either lease fully managed or partially managed servers from a hosting company or even build your own data centre.
Instead startups will use a provider of Infrastructure as a Service (IaaS) or Platform as a Service) components such as Amazon AWS or Rackspace Cloud.
The fuzzy line between IaaS and PaaS
IaaS is generally defined as providing managed access to low-level components of a network architectures like servers, load balancers, firewalls and storage.
PaaS describes a sliding scale from ‘productised’ versions of these components (like Amazon’s RDS database products) to fully managed environments where you can deploy your application with no knowledge of the production environment. Only using IaaS is more ‘pure’ and minimises the risk of vendor lock in, but can be a bit hair-shirted – some of those PaaS products will make you life a lot easier. The rest of this presentation will use IaaS as an umbrella term for some blend of the two.
The benefits of IaaS
Instant provisioning – no four week cycle of speccing, procuring, installing and
enabling hardware.
Datacentre automation – tear down and recreate your platform in minutes
instead of weeks.
The small print
IaaS providers are not keen to mention the number of tricky responsibilities a traditional hosting provider would normally shield you from that are now your responsibility.
Security – maintaining firewall rules, applying security patches and many aspects
of penetration testing and DDOS protection will be your responsibility.
Resilience – many techniques like database clustering, server failover and even
Performance – you will have limits on your ability to optimise your applications. There are subtleties in the design of some core pieces of software (like Apache and PHP) which need careful tuning in order to run well on IaaS servers.
Disaster Recovery – many mainstream IaaS/PaaS providers have a patchy record
when it comes to outages, including incidents when their own protective measures have failed and multi-day outages have occurred.
These caveats mean that to realise the full benefits of cloud hosting, your
application, and your technical team, needs to be designed from the ground up with IaaS/PaaS in mind.
The changing role of technical operations
The traditional hosting model, where infrastructure was managed in house and hardware was a significant and long-term investment, required that companies build a large technical operations team.
Traditional tech ops teams were completely separate from the development
process – developers became naïve about the realities of running an application in production and tech ops didn’t understand how the app was used.
The move towards IaaS and PaaS gives us a unique opportunity to challenge the traditional organization of tech teams.
Fewer specialists, more smart generalists
With a traditional tech ops team, it was often necessary to recruit into very narrow roles – Cisco network specialists, MySQL tuning engineers.
IaaS and PaaS generally abstract away most of these specialities in favour of higher level technologies like Linux, user level network protocols and SQL.
This means that’s you can divert your limited funding towards a few smart people with more common skills.
Greater responsibility for developers
Removing some of the specialist technical operations roles gives us an opportunity to reconnect developers with the production environment.
Fostering a ‘production mentality’ in developers is vital if you want to build a scalable application that won’t need a ground-up rewrite every 18 months.
This changes your recruiting priorities – you can no longer hire ‘programmers’ who are only interested in code; you need to hire smart people interested in every
Deployment environments
Cloud hosting and desktop virtualisation mean that for the first time in many
years, it is possible for developers to be working on ‘production like’ environments at all times.
All shared environments (integration, UAT, staging etc) should run on your production IaaS infrastructure.
This will further reinforce the production mentality in your team and means that in the event of a production issue more people will be able to help.
Data centre automation
In order to manage all these different environments, you should invest in data centre automation.
When implemented correctly, this will mean that every environment used by your technical team and customers can be provisioned and configured in minutes.
Data centre automation is easiest to achieve when you have production aware developers who can work with your tech ops team to build scripts
SaaS applications have non-functional requirements that are very different to those of traditional web sites and web apps.
You need to build a platform with these non-functional requirements baked in. IaaS and PaaS make it easier to build and deploy these sorts of platform that ever before.
It’s not a free ride though – you will need to think carefully about performance, security and resilience.
You won’t need as big a tech ops team are you might think
But you should expect to developers to take on additional responsibilities. A production mentality at all times is vital if you don’t want to find intractable performance problems that can only be fixed with a platform rebuild.
