Cloud Hosting – Basic Overview and Considerations

This article is aimed at people who are traditionally used to running production environments Bare Metal, or using a single VPS to host their sites/platforms. People who now need to understand the practical considerations of hosting their application in a more scalable way.

For the purpose of this article I am going to assume the application in question is Laravel based, realistically this isn’t particularly relevant (save for the fact that you need to be able to control your configurations across all servers).

I will soon be writing some case studies about the work I have done at various assignments, but for now this is all based on experience, but strictly hypothetical.

Additionally, to keep things simple for the purposes of this article, I am going to talk about Digital Ocean, and assume we are using their services. Whilst we all know that essentially AWS is the monarch of cloud scalability, at an entry level Digital Ocean is easier to cost and manage.

This article is not a deep dive! It just outlines, at a very high level, the things one would need to consider before moving to this kind of setup.

Our considerations

A brief list of the things that we need to be thinking about

  • Serving web traffic
  • Running the Laravel Schedule (cron)
  • Running Queue Workers
  • MySQL
  • Queue Driver (I tend to use Redis)
  • Cache Driver (again, I tend to use Redis – but the File driver will not work in this instance)
  • Log Files
  • Sessions (I tend to use either database or Redis, depending on the application, but as always, the File driver will not work in this instance)
  • User-uploaded files, and their distribution
  • Backups
  • Security / Firewalling

Digital Ocean Implementation Overview

For the purpose of this article we’re going to spin up a number of resources with Digital Ocean to facilitate our application. In the real world you will need to decide what resources you need.

  • 3x Web Servers
  • 1x Processing Server
  • 1x Data Server
  • 1x Load Balancer
  • 1x Space

Annotations on the above

Something that is worth taking note of, early doors, is that your servers are expendable at any given time. If you kill a web server, your application should survive.

In the real world, I would suggest that you use a managed MySQL and Redis (or Cache + Queue driver) service, to mitigate your risk on those droplets, making all of them expendable.

Notes on other tools

I personally would always recommend, in this environment, using Continuous Integration to test your application, and using Merge requests to ensure that anything which finds its way into a deployable branch (or a branch from which versions will be tagged) is as safe as it can be.

I would also advise Test Driven Development (TDD) because this is probably the only way you really know that you have 100% test coverage.

I am going to come onto deploying to your environment at the bottom of this article.

Part 1: Building Your Servers

It makes good sense to build the base requirements of your server into an image/snapshot/etc (depending on your provider), and then your redistribution process is much easier, because you can spin up your servers/droplets/instances based on that image.

Whilst the Data Server does not need to have any application knowledge, the others will all need to have your chosen version of PHP and any required extensions that your application needs to run.

Once you’ve built the first server, take a snapshot of it, with SSL certificates and such.

I would advise running supervisor on this server, to ensure that Apache / nginx (or your chosen web server) stays running all the time, to minimise and mitigate downtime.

Part 2: Serving Web Traffic

Whether you are using Digital Ocean, Amazon Web Services, or any other provider; they all offer Load Balancers. The purpose of a Load Balancer is to balance the load, by distributing your web traffic to the servers available. This means that in times of peak traffic you can add more web servers to handle the traffic (this is known as horizontal scaling – the opposite of vertical scaling which is where you upsize your servers).

So, build the servers that you need, and make them capable of serving web traffic. Then fire up a Load Balancer, and you can assign these droplets to your load balancer.

Once you have done this, point your DNS to point to the Load Balancer, so that it can distribute the traffic for that domain.

If you are using CloudFlare, make sure you forward port 443 (SSL) to port 443, and set the SSL to parse-through, so that the handshake between destination server, load balancer, and browser can succeed.

Now that you have web servers, you need to make sure that you have the backing to fulfil this.

Part 3: Running the Laravel Schedule (cron tasks) and Queue Processors

You do not want to run the cron on your web servers. Unless, of course, your desired effect is to have the job running X amount of times per interval (where X is the amount of web servers you are running).

For this kind of background processing, you want another server, which is where the processing server comes in. This is the server which is going to do all of your background processing for you.

This server needs to be able to do all the same things that your web servers can do, except it just won’t be serving web traffic (port 80 for HTTP and port 443 for HTTPS).

This is the server on which you will run either artisan queue:work or artisan horizon, it’s the same server which you’re going to be running your schedule on too. Of course, this could be separated out to different servers if that works better for your use case.

Part 4: Data Server (MySQL and Redis)

As I say, I personally would be looking for managed solutions for this part of my architecture. If I was using AWS then, of course, they have Elasticache and RDS to handle these problems for you. If you’re using Google Cloud, they also have a Relational Database service.

Or, you build a droplet to host this stuff on. If you host on a droplet, ensure you have arranged adequate backups! Digital Ocean will do a weekly backup for a percentage of the droplet’s cost. If you need to backup more frequently, I’ll cover this off later on,

This server needs to have MySQL (make sure to remove the Bind Address) and Redis (take it out of protective mode, and make any modifications as required). Install these, get them running, and if necessary set up how Redis will persist and the resource limits/supervision for MySQL.

Part 5: Log Files

If, as they should be, log files are an important part of your application, you want to get them off your servers as soon as possible. Cloud servers are like cattle, you must be prepared to kill them at a moment’s notice. If you’re going to do that then you need the logs (which may contain useful information about why the server died) to not be there when you nuke them into oblivion.

There are loads of services about to manage this. Though what I will say is that it is just as easy to run an Artisan command to migrate them to Digital Ocean Spaces periodically. Space start at $5/month. AWS S3 Buckets are also exceptionally cost effective.

The key point here is, don’t leave your log files on the web or processing servers for any longer than you need to.

Part 6: Interconnectivity

Quick side note here, when you are dealing with Droplet-to-Droplet communications, use their private IPs, which are routed differently, thus faster and don’t count towards your bandwidth limits.

Part 7: Sessions

I am only going to touch on this really quickly. You need to be using a centralised store for your session (Redis or MySQL work perfectly well), otherwise (unless you are using sticky sessions*) your authentication and any other session/state dependant functionality will break.

Sticky sessions are great, but be careful if you are storing session information on the local web server (the one the client is stuck to) and that web server goes down, because the assumption on any web server is that anything stored on it is ephemeral.

Part 8: User Uploaded Files

Your application may well have user uploaded files, which need to be distributed. We know by now that they cannot be stored on any of the web servers due to their ephemerality.

On this one I would advise use whatever stack you’re using, in this example we’re using Digital Ocean, so use Spaces (which is essentially file storage + CDN). If you’re using Amazon Web Services use AWS S3 bucket(s), with CloudFront for the CDN aspect.

Configure your driver(s) as appropriate to use Digital Ocean Spaces, which is S3 compatible. Your user uploaded files still work as they always did, except they will no longer be stored in storage/* for reasons I’ve probably reiterated half a dozen times in this article.

Also make sure than any public linking you’re doing, to article or profile images, for example, is respecting the appropriate CDN location.

Part 9: Backups

It is almost impossible for me to describe how your backups should work, as I don’t know your environment. However, Spaces and S3 are both cost effective, and are where I would advise you store your backups.

Depending on how you want to backup, there are 101 ways to take those backups. But nothing (logs don’t count) from your web servers should be backed up, they should only contain the necessary configurations to serve traffic.

Your files, theoretically, are unlikely to need backing up either, because they are sitting within a managed service, and if you have used manage MySQL / Redis / etc services then you don’t need to back them up either!

Part 10: Kill enemies with fire (firewalling)

If you’re using Digital Ocean, Firewalls are just included, but whatever solution you are using your security policies need to reflect the work your servers are doing, roughly outlined below.

  1. Web servers need to accept port 80 (HTTP) and port 443 (HTTPS) traffic, but only from your Load Balancer
  2. Your Data Server (assuming MySQL and Redis) need to accept port 3306 (MySQL) and port 6379 (Redis) traffic, but only from the processing and web servers
  3. Your Processing Server should not accept any traffic from anywhere
  4. You may wish to put exceptions in for your deployment tool, and potentially your own IP address so that you can shell into your servers, view MySQL and such

Part 11: Deployments

Personally, I love Envoyer, I think it’s brilliant. But the key point to take away with deployments in this scenario is that it can no longer be done manually.

If you have 3x web servers + 1x processing server, you cannot shell into all 4 and do git pull and git checkout and all that stuff, you need to manage that process for you properly.

If you use Envoyer, there are loads of resources out there on how to get it set up just right for your application, but the key point is you cannot just do it by hand.

Your deployment process should be capable of running without you (Continuous Deployment) following successful Continuous Integration, for example when a merge request is successfully merged into Master, you may wish to deploy straight to your production servers.

Deployments will need to cover NPM/Yarn dependencies, composer dependencies, and anything else your application needs to worry about, perhaps migrations, or clearing views, caches, and configs.

You will also need to know how you are going to deploy environment changes (a change of MySQL host address, for example) to your servers instantaneously.

Part 12: Manual Stuff

If, for any reason, you need to run anything manually, like Artisan commands, then you would log into your processing server and run them there.

Ideally you would never need to do this, of course. But it is worth noting how you would go about doing this.

Links

  1. Digital Ocean
  2. Amazon Web Services
  3. Envoyer – Zero Downtime Deployments
  4. ScaleGrid – Managed RDS Solutions (MySQL and Redis)
  5. Laravel – the PHP Framework for Web Artisans
  6. CloudFlare – the web performance and security company

6 tools I couldn’t live without

Hi everyone

So today I thought I would do a quick post, as it has now been just over a year since I started as the Senior Systems Architect at Speed Agency. We’ve had an amazing year, seeing the design, development, and delivery of a number of bespoke systems, including our own modular content management system. Of course, to achieve all this we use a whole bunch of tools. Here I thought I would summarise my favourite;

#1 Digital Ocean

Now, I know there are competitors out there, however I haven’t used them. The reasons I love Digital Ocean can be summarised here:

  • We run a very strict set of processes with regards to the deployment of changes to our live environment. The snapshot functionality means I can have a single (or multiple) staging environments built in next to no time
  • Their customer service is absolutely top
  • Their availability is high, and their prices very reasonable
  • The server monitoring is really pretty damn good, especially as it’s essentially a free extra
  • And all the usual stuff to do with Volumes, Floating IPs, etc.

More information about Digital Ocean

#2 Status Cake

I’ve used a number of different suites to monitor uptime, I’ve never found one which is better for configuration, server and website monitoring (amongst other things). Also, very very few false negatives – which are a nightmare to manage if you’re handling SLAs on uptime!

Track your uptime and server statuses with Status Cake

#3 Packagist

I’ve done a blog article on Packagist before, however I have to say I love it. The power of managing modular code and dependencies through Composer, added with the closed-source nature of private packagist is just great.

Find out about Packagist

#4 GitLab

We started using GitLab for managing issues and our Git repositories. I’ve got to say, whilst it might start to fall down against its Goliath-size counterparts (such as Atalassian’s BitBucket + Jira haymaker of a combo), it has lasted us very well, it’s a great system to have, it’s open source, easy to use (particularly if you’re familiar with GitHub) and has been a great toe-in-the-water for this style of project management.

Learn more about GitLab

#5 Confluence

I’m a true nerd for documentation. I love it. I mean I love it more than I love flow charts, which is really saying something. Confluence is phenomenal. For managing, exporting, modifying, discussing, sharing, and structuring your documentation this is the absolute bee’s knees. Seriously, if you need to document your source code, project paperwork, or anything in the software development arena, sign up for it, right now, don’t even hesitate.

I don’t know why you don’t already have Confluence

#6 draw.io

There is a standing joke in my office, in which I am referred to as Sheldon (though my computational personality tends to find me also referred to as Laurie Bream) – this is because of my absolute adoration for flow charts. From processes to systems designs to user-workflows I absolutely swear my draw.io, which allows you to draw these diagrams, export them as XML files for later, and export as a number of useful formats (PDF, for example).

Get your workflow on with draw.io

In Summary

Tools and software should make your life easier. The above 6 things have made my life infinitely easier, and helped me structure, grow, and enhance my team’s capacity and capability by providing smoother, more efficient processes and workflows. I can’t take all the credit, of course, all those tools were at some point referred to me by a colleague, friend, Search Engine, or somewhere; and none of them would have any effect if my team didn’t take the whole hearted approach to adopting the things that I have mentioned above. Every team has a critical mass which makes systems effective, and my team are the best at adapting to our ever changing requirements.

I’d love to hear what tools you have which make your job easier, I can’t promise I won’t think “oh, that’s a good idea!” and consequently adopt the tool myself 🙂

Until next time,
Johno

Edit: Considering this is essentially 6 links I thought I’d best state – there’s no commercial interest in this post, I’m in no way endorsed by those companies, have no affiliation, no referrer links or anything included!

Pure OS: The way forward?

Tonight is just a quick one, not my usual essay. I was just curious to see what other people though. Being a PHP Developer I primarily work within LAMP environments. Occasionally having swapped out Apache for Nginx, but I am by far a specialist.

Until recently I was able to jump around through the Linux command line and do whatever I needed to without much issue, but nothing heavy.

I decided, as I often do, that I wanted to expand my skill set and start looking at pure OS, doing everything from scratch, how hard could it be, right? Previously I had used control panels like cPanel and Plesk to make management easy, as I’ve been offloading mail management to the likes of Office 365 and Google Suite, because they’re awesome at it and provide drive solutions, I figured there wasn’t that much really left for my server to manage.

So I put on my big boy pants and launched a Droplet with Digital Ocean and got learning how to set up and manage my own LAMP stack environments. I’ve spent a bit of time learning a few bits, and realised a few things, which I thought I would share. I’m by no means an expert, but these are just some soundbites I’ve picked up

  1. Setting up LAMP stack isn’t difficult
  2. Neither is setting up SFTP and Mail (though I’m dubious on mail and will leave it to the pros!)
  3. Neither is setting up SSL (seriously, look up LetsEncrypt!)
  4. Control panels are heavy!
  5. You really don’t need much on your server to do basic website stuff
  6. If you keep it lean, tiny servers can do amazing things

If you’re a developer, and have never tried to build and manage your own servers, seriously give it a go.

On a side note, some other useful tips and guides – please take heed – this isn’t new knowledge to me by any means, but thought it might be useful if you stumble across this article.

  1. Disable root login access!
  2. Chroot your FTP users
  3. Only install what you NEED. If you’re not doing anything with SFTP (because you’re only using git, for example), don’t install it
  4. Research what you’re installing, only install it if you need it and trust it
  5. If this is the first time you’ve tried to manage your own DNS, most panels create aa bunch of stuff for you; at the very least you need to create a CNAME record for ‘www’ and point it to ‘@’ (so that www.website.com also works as well as just website.com)

I think that’s everything for now. If I think of anything else I’ll pop it in a little soundbite.