Building Scalable Systems Without Docker

The era of the big application is upon us. No longer is it just scalable databases or load balanced web servers, today we deploy highly available messaging queues, private cloud infrastructure, big data platforms with relative frequency.

The way we deploy these applications is changing to. When I started in IT is was either manual or scripted using BASH or a shell of your liking, these days its could be Docker, Cloud images, apt, yum, snap, or automatically installed using Puppet, Chef, Ansible or, Juju.

Of course actually deploying applications is one thing, configuring, managing and scaling these applications is another thing entirely, this is where software automation tooling comes to the fore. Some people will tell you Docker is the way to go, certainly in some cases it is, but Docker isn’t a golden bullet, it still has its own problems and deploying onto bare metal might be a more acceptable solution. For the remainder of this blog post we’re going to look at Juju, which is developed by Canonical. Juju is relatively new but steadily growing in the world of big application deployment because of both the deployment techniques but also because of it’s hooks, relations and state which allow for codeless setup and configuration of applications.

Lets start simply and look at setting up a blog. In its most simple terms for a wordpress blog, you will require a webserver and a database. apt install mysql apache2 php5 and you’re pretty much done right? Well yeah, but lets assume you want to serve a massive amount of content from your wordpress with high volume traffic, who doesn’t want the most visited blog in the world, right?

So if you are running a high traffic blog, what else is required? Maybe a load balanced database? Perhaps a memcached server to serve cached pages instead of them being generated from scratch every time? Maybe you also want more than one blog engine? So how about HA Proxy to load balance the traffic? Great we have our scalable server, okay well what happens if a component crashes? How about some monitoring with that as well?

So our requirements have grown from simple apache2 and mysql to:

  • Apache2
  • Mysql master/slave
  • Memcached
  • HA Proxy
  • Nagios

Not quite as simple now, right? Also, of course this could all run on the same server but in reality you wouldn’t want to, there would be no resilience also performance issues when everything is thrashing the same box.

So lets design the infrastructure. You’d have 1 or 2 webservers, 1 or 2 HA Proxy servers, 1 Mysql Master, 1 Mysql Slave, 1 Memcached server and a Nagios server. That’s 6 servers as a minimum. So now you need to spin them up, install the software you desire on each and configure it to expect supporting services to be located elsewhere on the network. Its no longer a 10 minute job. Thankfully Juju offers us the ability to do all of this for free.

juju bootstrap aws
juju deploy cs:~arosales/bundle/wordpress-site-3

In 2 commands we have spun up WordPress, Memcached, HA Proxy, Maria DB and Nagios with no expert domain knowledge. The good news is the fun doesn’t stop there. Suddenly a news outlet catches hold of your blog and you get flooded with more visitors, no problem Juju happily support scalability as well.

juju add-unit mariadb-slave

and we suddenly have an extra database node in our replication pool serving requests to visitors. After a while those numbers drop back down again

juju remove-unit mariadb-slave

and you’ve decommissioned the node.

So thats quite a simple example, of course Canonical built Juju to deploy much more complex software. Let’s look at the extreme and examine the Juju Openstack deployment. At its bare minimum it has 16 different applications distributed over 4 servers, and this is the basic setup! Once deployed you get Dashboard, Compute, Network, Block Storage, Object Storage in your own private cloud, but getting it setup manually is an expensive task. This is where Juju excels:

juju deploy cs:bundle/openstack-base-49

If you have a MAAS setup matching the minimum spec this is all that is required to configure Openstack and all the various underlying subcomponents is a scalable manner. This alone saves so many man hours, its unreal! Of course the great thing is that adding more compute, network capacity or storage is again a one liner!

As you can see from a simple blog to the more extreme Openstack setup, Juju excels at deployments and scaling, it makes life much easier for the Devops folks giving us more time to innovate and bring more great features to the charms. Of course you don’t have to deploy either of the examples here, writing Charms these days are pretty well documented and examples are available all over the charm store, all you need is some time and BASH or Python skills. The other good thing about Juju charms is the crowdsourcing of operations, if you don’t know how to do something in the underlying application, chances are someone else will and send you a pull request to improve your charm.



Leave a Reply