Building a Secure, Resilient and Scalable Linux Infrastructure

Imagine a technology solution that can run equally happily on your own hardware, Google Cloud, Microsoft Azure or Amazon Web Services. An infrastructure that can be developed, tested and demonstrated on a desktop PC running Windows, a MacBook running OSX or a Linux system. A solution that is scalable, resilient and secure. Sound interesting?

The history

To understand what’s possible today, it’s helpful to look at how technology projects have been traditionally implemented. Back in the olden days – that is, more than 10 years ago – businesses would buy or lease hardware to run all the components of their applications. Even relatively simple applications, such as a WordPress website, have multiple components. In the case of WordPress, it needs a web server of some kind, such as Apache, a way of handling PHP code, and a database. So, they’d build a server, set up Apache, PHP and perhaps a MySQL database, install WordPress and off they’d go.

By and large, that worked. It worked well enough that there are still a huge number of servers configured in exactly that way today. But it wasn’t perfect, and two of the bigger problems were resilience and scalability.

Resilience

Lack of resilience meant that any significant issue on the server would result in a loss of service. Clearly a catastrophic failure would mean no website, but there was also no room to carry out some kinds of scheduled maintenance without impacting the website. Even installing and activating a routine security update for Apache would necessitate a few seconds’ outage for the website.

The resilience problem was largely solved by building ‘high availability clusters’. The principle was to have two servers running the website, configured such that the failure of either one didn’t result in the website being down. The service was resilient even if the server wasn’t.

Scalability

The scalability problem is a bit trickier. Let’s say your WordPress site gets 1000 visitors a month. One day, your business is mentioned on Radio 4 or breakfast TV. Suddenly, you get more than a month’s worth of visitors in 20 minutes. We’ve all heard stories of websites ‘crashing’, and that’s typically why: a lack of scalability.

The two servers that helped with resilience could manage a higher workload than one server alone could, but that’s still limited. You’d be paying for two servers 100% of the time and most of the time both were working perfectly. It’s likely that one alone could run your site. Then John Humphrys mentions your business (in a complimentary way, naturally) and you’d need ten servers to handle the load (but only for a few hours).

Enter the cloud

The better solution to both the resilience and scalability problem was cloud computing. Set up a server instance or two – the little servers that run your applications – on Amazon Web Services (AWS) or Google Cloud, and if one of the instances failed for some reason, it would automatically be restarted. Set up auto-scaling correctly and when Mr Humphrys causes the workload on your web server instances to rapidly rise, additional server instances are automatically started to share the workload. Later, as interest dies down, those additional instances are stopped, and you only pay for what you use. Perfect! Or is it?

Whilst the cloud solution is much more flexible than the traditional standalone server, there are still issues. Updating all the running cloud instances is not trivial. Developing for the cloud has challenges too: the laptop your developers are using may be similar to the cloud instance, but it is not the same. If you commit to AWS, migrating to Google Cloud is a non-trivial undertaking. And suppose, for whatever reason, you simply don’t want to hand over your computing to Amazon, Google or Microsoft?

Docker

Today’s solution is much, much smarter. You may have heard words like ‘container’, ‘microservice’ or ‘Docker’; you may have even heard of ‘Kubernetes’. These are already changing the face of big application computing today.

Each component of your application – the website, the database and so on – runs in a container. A container is a self-contained, minimal software ‘box’ that runs just that one component.

There is some very clever orchestration software that manages these containers, and that’s where Docker and Kubernetes come into play. Docker is a mechanism for running the containers themselves. It’s operating system agnostic, which means it run anywhere: on AWS, on your own hardware, on Google Cloud, on your developer’s laptop. If your developer is running OSX on her MacBook, you’re running Windows on your office system, and your production system is running Linux, that’s fine: you can run Docker – and thus the containers – on any (or all) of them.

Kubernetes

Kubernetes manages the Docker instances. It ensures that enough instances are running, using whatever criteria you specify; it manages networking and security between the instances; it shares the workload across the underlying systems, be they AWS instances or your own servers; it manages both ephemeral and persistent storage: the list goes on.

Kubernetes is designed to run scalable, resilient and, if needs be, complex applications, and has built-in features to make life easier. For example, it supports namespaces, which allow the same application code to be deployed multiple times. You might choose to have a Production namespace, a Development namespace and a User Acceptance Testing namespace – or you might choose to have one namespace per git branch. Kubernetes can fit in with your development and deployment workflow, integrating with Continuous Integration and Continuous Deployment (CI/CD) systems.

Kubernetes isn’t just for ‘the big boys’, either. You can run a Kubernetes infrastructure anywhere. Run it on your laptop as proof of concept. Once you’re happy with it, migrate it to a server. That lets you explore it further, but of course you have a single point of failure in that server, so now migrate it to Google Cloud. Or to Amazon Web Services. Or whichever cloud provider you like. And, if you want to, you can build your own hardware infrastructure in house and run it there.

This is the future

Kubernetes is born of a Google project, GIFEE (‘Google’s Infrastructure For Everyone Else’). Google have been insanely successful running applications distributed across huge numbers of servers in a well-coordinated, secure way wherever they want. And now you can, too.

If you like this article, please share it and follow me on LinkedIn. Thank you!