Shippable SaaS – How Docker is Reshaping the way we Buy and Consume Software
One could say that we are living in the Golden Age of Software – specifically Software-as-a-Service. As a business or consumer today, you have a nearly endless supply of software solutions ready to go at the click of a button. Hosted in the cloud, you can get started with a new CRM system, a new ERP platform, an ecommerce website or a marketing tool, in no time at all. The typical models are either subscription based, per user per month, or usage based, e.g. clicks, sales, data points, etc.
Why is it we love the software as service model so much? I’d argue it’s really more about the cloud model and not so much the as-a-service model – i.e. one doesn’t scale up or down their need for ERP services on a daily basis – but not having to think about complicated software upgrades, server maintenance and pesky high availability or disaster recovery planning is pretty awesome.
In return for all of these goodies, most of us have generally accepted a few trade offs along with the SaaS delivery model, or shippable SaaS:
- that we’ll be sharing the platform with other users at nearly every level;
- that we’ll buy infrastructure (hosting, delivery, acceleration, etc) along with the software;
- that our data will be in a remote datacenter or cloud that we do not directly control;
- that we’re pretty screwed if the SaaS company goes out of business, doesn’t pay its bills or do what it says it will around security, availability, etc.
Depending on your business needs, losing control of some or all of those items isn’t a good thing and could be disastrous. However, the benefits have so clearly outweighed the risks in recent years that the vast majority of the market has charged full steam ahead into SaaS services. Recent estimates show that SaaS will grow at nearly 21% next year alone! I suspect you’d be hard pressed to find a startup today that chooses an on-premise CRM versus one of the popular cloud hosted SaaS options.
But that may all be changing. And the culprit? A little technology called Docker.
Software in an AWS Dominated World
Dreams of delivering platform independent, complex software stacks have been pretty dreary for the past ~5 years, as the gap between AWS and the rest of the cloud platforms became so great. Nobody could match AWS in its feature set and scale, leaving developers with an AWS-first and AWS-only approach to infrastructure automation. Recreating AWS services in other places (like OpenStack, for example) proved to be a losing battle.
So what was a software company to do if they were writing a complex, scalable, highly performant software stack? Well, offer a SaaS version of their platform, of course (and do so on AWS services, in the majority of cases)! Due to this trend, overall quality of service has gone way up to the end user, but portability took a massive step backwards. In fact, for those writing the software, it was hard enough to do your dev work in your local environment and ship to AWS, let alone ship to a customer site, random cloud, hosting provider or (gasp!) a colocation environment. So, as a software startup, you’ve been pretty much forced into the SaaS business, figuring out answers to those hard questions above and running a complex multi-tenant operation whether you liked it or not. Your software business was suddenly a services business – with 24 x 7 support phone numbers and an SLA on your network availability. Hmmm….
But all that changed when you got wind of Docker.
Docker Containers to the Rescue
I’m not going to explain the basics of containerized service architectures (you can read more here or here), but let’s just say that the idea of building immutable and resilient platform services has become within reach of developers, even those that know relatively little of the “ops” side of the DevOps coin. Full platforms such as Tectonic (Kubernetes + CoreOS + Docker) or Rancher are making that easier by the day.
In fact, developers are often first interested in Docker infrastructure designs because containerizing your environment can solve a major pain in their daily life – that moving target of an up-to-date dev environment. Most developers still do the vast majority of their work on their local laptop, writing and testing code in a local environment. Needless to say, even with tools like Vagrant, keeping your local dev environment in line with a complex production AWS setup is pretty much impossible. Docker enables you to version control your environment the same way you do your code. With some planning, you can not only ship composed infrastructure, but you can ”snapshot” your production environment and run it locally quickly and reliably. This is a massive time saver and also dramatically increases the quality and capabilities of every application developer, who can now count on coding, testing and deploying in a consistent environment.
What this also does, is encourage developers to normalize their operational environment – instead of using a cloud-specific service for traffic management, such as an Elastic Load Balancing, you might use an orchestrated HA Proxy setup in Docker – that enables you to run traffic management service exactly the same in your local environment or in your production setup. This reverses the portability trend that has been ongoing for years – in which developers got enticed by the ease of use of AWS (and other) cloud service providers’ walled gardens and instead is driving more infrastructure agnostic application development.
Now, if you’ve architected and built your application and infrastructure platform (they’re starting to look a lot like the same thing!) in a cloud-agnostic, environment-agnostic manner, what’s to stop you from shipping that same platform to a colocation environment? Or perhaps just a client’s own AWS account or bare metal server deployment? The answer is, not that much.
Choose your Deployment Model
Once you’re shipping software along with its scalable, highly available infrastructure in an immutable, cloud agnostic model, it’s possible to reconsider the option of shipping an entire SaaS platform (infrastructure automation via Docker included!) to a customer and charging them only for licensing and support. I’ve heard the term “Containers as a Service” (CaaS) used for this model, in which the customer can choose to deploy a supported container stack into their own AWS account, leverage a bare metal cloud provider like Packet or Softlayer, or deploy on their existing hardware behind their firewall in a private datacenter.
What will drive adoption of this consumption model (e.g. software only) for customers is the new found ability to offer the same level of service in availability, upgrades, and performance that one has come to expect from high quality SaaS services. It’s now possible for the software provider to manage their shipped SaaS platforms to the same level of quality and experience that customers have grown to love so much in the pure-play multi-tenant SaaS hosted software market. But adoption will only come if there is a similar or better end user experience.
But Is Anybody Actually Doing this?
You might wonder if this idea of shippable-SaaS is just a pie-in-the-sky concept from a bunch of container nerds or whether it will actually take hold? In fact, you can see both new and established companies starting to ship their software in this way. Check out AeroFS or Tray.io, both of whom offer their cutting-edge SaaS services to you as an orchestrated fleet of Docker containers. And there are already vendors, such as Replicated, that are starting to show up to help SaaS companies ship their containerized platforms to enterprises.
I see the next year as a watershed moment for startup software businesses – where an old model (shipping your software to customers) gets married with a services business (management / maintenance) and allows customers to choose again how and where they host their mission-critical software applications. For customers, it’s a win/win: in the worst case, they get increased flexibility in their hosted SaaS software and, in the best, they get complete control over it with none of the messy management and scalability issues. So get ready for a new acronym in your vocabulary – CaaS is just around the corner!
