How can you have a service as reliable as Google’s?

You never see the Google homepage “down for maintenance” or “currently unavailable”. There are millions of people around the world using Google 24/7, yet their service is always available.

How do they do that? And can you do that for your applications too?

Google developed the technology they use, but it’s available to you too. You can run it on your own hardware, Google Cloud, Microsoft Azure or Amazon Web Services.

Applications using that technology can be developed, tested and demonstrated on a desktop PC running Windows, a MacBook running OSX or a Linux system.

It’s a solution that is scalable, resilient and secure.

And there’s no licence cost.

Sound interesting?

The bad old days

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, they’d need 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.

What is resilience?

Resilience is the ability of the service to tolerate some level of failure and still function.

Lack of resilience meant that any significant issue on the server would result in a loss of service. With a single server, a catastrophic failure would mean no website. There wasn’t even any 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 initially solved by building ‘high availability clusters’. The principle was to have multiple servers running the website, configured such that the failure of any one didn’t result in the website being down. The service was resilient even if the servers weren’t.

What is scalability?

Scalability defines how well your service responds to changes in demand.

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 multiple servers that helped with resilience could manage a higher workload than one server alone could, but that’s not ideal. You’d be paying for multiple servers 100% of the time, but for most of the time it’s likely that fewer – or even one – could run your site.

Why the cloud is better (but not perfect)

The next 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.

If you set up auto-scaling correctly  then when the workload on your web servers rises, additional server instances are automatically started to share that 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?

Enter containers.

What are containers?

Today’s solution is much, much smarter. You may have heard words like ‘container’, ‘microservice’, ‘Docker’ or ‘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.

How do I manage containers?

There is software that manages containers, and one example of that is Docker.

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 and your application – on any (or all) of them.

Docker is powerful and continues to grow. When you outgrow Docker, you can use Kubernetes (“queue-ber-net-eez”).

What is Kubernetes?

Kubernetes manages the Docker instances. It can:

• ensure that enough instances are running
• manage networking and security between the instances
• share the workload across the underlying systems, be they AWS instances or your own servers
• manage storage

And much, much more.

If you want a wide-scale, highly resilient, highly secure and largely self-managing environment, Kubernetes is the answer.

Is Kubernetes complicated?

Kubernetes can manage applications from a single server up to a world-wide implementation across hundreds of data centres. It has many powerful features to make life easier for developers and users alike.

For example, it supports namespaces, which allow the application code to be deployed into multiple environments. You might choose to have a Production environment, a Development environment and a User Acceptance Testing environment.

Kubernetes can fit in with your development and deployment workflow, integrating with Continuous Integration and Continuous Deployment (CI/CD) systems.

It is fair to say that it’s non-trivial to design and implement a cost-effective Kubernetes infrastructure.

But Kubernetes isn’t just for ‘the big boys’. 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, and when you’re ready you can 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’). And Google have proved it works.

Much of our own infrastructure runs under Kubernetes.

Google has 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.