How cloud computing evolved and a march towards a Kubernetes future
At the turn of the millennium, when you needed a server, you had to get in touch with a hosting provider and place an order for a hosted server. Getting through the booking process meant you needed to be precise on the hardware required, because ultimately that company had to go and source everything. Your server would be sitting there, in a rack, basically with your name on it.
Companies and freelancers around the world all had to do it, usually at the cost of several thousands of dollars a month for each server you were running. Although it cost a lot, that was the only option. The whole concept of cloud computing was in its infancy with Virtual Private Servers, and today’s well known providers such as AWS and Google Cloud didn’t exist. In fact, if you’d asked someone back then if Amazon or Google would enter this area, chances are they’d say “never”.
The high running costs, bundled with the technical burden of looking after a bare metal server meant that developers were busy not doing development work.
Hello Cloud...
In April 2008, Google Cloud announced App Engine. We all remember it well. They changed how we thought about servers and also how developers think about running their code. The idea that you could run your web application without the hassle and pain of managing servers was a game changer.
One of the major providers, Rackspace, invested heavily into forging a new way forward. They developed a set of software components called OpenStack. This software set the benchmark for what customers expected. Ultimately, what OpenStack provided was management of bare metal servers, for rapidly available virtual servers. You could fire up a server, run something intensive and destroy it. This introduced the concept of time based billing for servers; no more contracts for unused server resources. At the time, you’d be hard pressed to find a developer who didn’t run a couple of small Rackspace instances for random things like their website, or a Minecraft server.
Adopting a fundamentally similar approach we saw the rise of AWS and Google Cloud with a similar offering to that of Rackspace’s OpenStack. In a seismic shift, businesses were abandoning their legacy servers and moving huge workloads across to these more flexible cloud servers. Under the hood, all of these various cloud providers offered a similar product; instantly provisioned servers with the specifications you required, with the ability to independently scale CPU, memory, and disk space.
Development Tools
Following on from the strides made in improvements to hosting, development tools to support this new way of working followed closely behind. The first and foremost was Vagrant, which was released way back in 2010. It was arguably, the single most important tool for developers to have in their arsenal. The concept of having a local virtual machine, entirely provisioned by some text, without any need for manual configuration was liberating. Within a few years, it was hard to find a software development company who hadn’t adopted Vagrant into their development workflow.
The idea of Vagrant was quite simple. If you’re writing code that needs to run on CentOS 5, why aren’t you developing it inside of a CentOS 5 box?. It didn’t matter if you were running Windows, Mac or Linux on your development machine, you could have this little virtual machine (or several) running within your operating system. Available at the drop of a hat and easily rebuilt if you break it.
A few years after Vagrant, another tool was released called Docker. Docker provided a fundamentally similar result for users as Vagrant, although Docker took it a step further and created layers of the image. These layers meant that reusing (for example) nginx between two projects with vastly different package requirements was substantially faster. Take District5 as an example. We have images for almost everything we’ve made. At the base of it, we have the ‘District5 - Base Box’, which we then use in a ‘District5 - Nginx’ box, and in turn (depending on the project) we may have a ‘District5 - PHP-FPM’ box, or a ‘District5 - NodeJS’ box.
If we went back 10 years, it’d be hard to imagine developing without Vagrant, it was a legendary release, and a piece of development history that we only have fond memories of. (Long live `vagrant up`)!. We didn’t see Docker coming, but in retrospect, it was inevitable.
Docker brought huge advantages to developers. You could develop within the same operating system environment as you wanted in production (similar to Vagrant), but at the end of it (and this is important), you just package up that entire container. It meant that your exact environment was available for other developers to use, or for you to run somewhere as a service.
Kubernetes; When two forces combine
Whilst groundbreaking, the early versions of Docker were cumbersome to use and it took a few years for its full potential to be realised. The rise of the container was upon us. The logical next step was taking that hand crafted image and running it within a cloud environment. It wasn’t very long before you could do exactly that with AWS and Google Cloud. Gradually, the argument from a developer when something was broken stating that “it works on my local machine” became harder to justify.
A huge collection of pre-built containers have been made publicly available over the years. The chances are, if you need a niche configuration, someone’s already built the base image for you. You just pop your code onto it, build it and you’re finished.
Kubernetes (k8s if you’re in the industry) arrived next, taking these containers along with the best bits of cloud computing, and turned it into a code based exercise. You can create a few configuration files, which describes the infrastructure and turns it into a working system. This allows you to have a cluster running which you could scale up or down with a single command from your terminal; the complexity of the infrastructure running was only limited by your knowledge.
We’ve arrived at what feels like the perfect point in infrastructure management. There’s definitely still a place for cloud servers, and arguably your pods within a Kubernetes cluster may be fundamentally ‘cloud servers’, but for businesses who care about regional availability, planned redundancy and dropping large DevOps expenditures, it makes sense to explore Kubernetes.
Does Kubernetes fit every scenario? No. In fact, whereas we run a number of clusters dotted around the Google Cloud network, we still have a large number of ‘good old fashioned’ cloud servers (or instances, as Google Cloud refers to them). They provide a solid foundation for many things, whether it’s running an automated Jenkins instance, or simply used as a reverse proxy into a network, there will always be a place for them. (We’ve set a reminder to check this in a few years, just so we can remember saying this when the next big advancement is made).
So what does Kubernetes offer? At the most basic level, Kubernetes offers precise orchestration and automation. Kubernetes helps alleviate the worries of developers and DevOps around the world when it comes time to think about scaling.
Imagine if you’re in the e-commerce industry (or any product sale industry) and you’re running a Black Friday event. We’ve seen them first hand, and they aren’t pretty. Every year developers would pray whilst endlessly drinking energy drinks to make sure they’re at the top of their game ‘when’ something happens. It didn’t used to be a question of ‘if’, it was always ‘when’. There are no points given for resolving a problem when the web application falls over.
Kubernetes brings with it the simplicity of scaling up your services within seconds, or even scheduling it around peak usage events.
District5 don’t believe in failures when there’s a reasonable expectation that a scenario can occur. Additionally, we don’t believe in paying over the odds for you to have something reliable but sitting there largely under-utilised most of the time.
Our knowledge transforms businesses of every size. Whether you’re just thinking about a simple, one page, informational website, or you’ve got a legacy system that you think may be costing you a bit more than you’re comfortable with, we’re here to help. Send an email to our dedicated solutions team at solutions@district5.co.uk and someone will help guide you to the right person. We have specialists in a range of areas who you can speak to about your concerns, and we’ll work closely with you to resolve them.