Combell & Kubernetes: past the hype, a new generation of Cloud applications
Containers, Docker, Kubernetes… All these concepts are currently very trendy, and everyone is using them, or wants to use them. And this is no different at Combell. The technology has been on the radar for over five years and we have been using it in-house for quite a while now. Is it time to make an offer to our customers? Let us discuss this with Wesley, Thijs, Jachim and Maarten.
The evolution from virtualisation to containers has changed technology. But has it also changed the way of thinking about ICT?
From dedicated servers came virtualisation, and from there came the Cloud. Developers want to be able to work faster without having to worry about the underlying infrastructure. The development of containers and the rise of technologies such as Docker and Kubernetes are therefore a godsend in this context.
Everything is in line with the evolution that the Cloud has undergone over the past ten years. Business requires us to be fast – not only to run fast sites and applications, but also to get to the market faster.
The Agile mindset has changed dramatically. System administrators and Operation engineers are aware that they also need to be agile and work quickly and cyclically – that is how ‘DevOps’ came to be. And virtualisation acted as a driver. From there came the big Public Cloud platforms: complete abstraction is made of the physical platforms and users get a set of user-friendly APIs, which allow them to automate more tasks in their work routines – things that are in flux, that are constantly changing, that can cope with the changes, under pressure of time and great competition.
Since then, we have gained extensive experience. Kubernetes was initially a complex issue. You start with a lab setup, so that you can learn to work with it. Three iterations later, you understand the concepts, and you also realise that those concepts are there for good reasons. And now we have entered the phase where we are using it ourselves as a platform for internal microservices.
Many of us realise that Kubernetes is so different from everything else we have known until now. Because it is an abstraction platform, which helps you alleviate workloads, making you independent of an underlying player!
“Everything revolves around Kubernetes. Until you ask the question: how many do you have in production? And then, people often remain completely silent.”
Kubernetes approaches infrastructure in a very different manner. But did its popularity not come from development first?
There is a bit of history behind it. As a developer, you want to code on your own computer. You usually work on different projects side by side. Over the years, various virtualisation tools have been developed: these ensure that you can quickly launch an environment on your computer. Using a tool like Vagrant, you can work on the code of one project, break it down and do something else – which may not have the same version requirements... Another version of PHP, and so on.
Suddenly, when developers use Docker, they see that it does not take two or three minutes – for the VM to be ready – but only three seconds. And they quickly get used to such a workflow, as it is very convenient. Because you can also easily run a lot of containers on a single computer. You should try to run 10 or 20 Virtual Machines on your laptop... It will definitely not go fast, and it will be quite painful. With Docker, that suddenly feels very easy, and the technology is hot.
Now, you can see that they have come to know a certain way of working, which they want to adopt in acceptance and production. And they will discuss this with their manager: “This is a fun way of working. We can standardise in this way. This makes our lives easier. We also want it in production.”
Now, as a developer, you do not need to wait two days for a colleague to set up a server for you, so to speak. It is infrastructure-as-code. It is easier for everyone. As you deploy the code, you specify what the infrastructure on which the code is running should look like. This is delivered in a dynamic way. The highlight is that it is easier for everyone – for both the provider and the user. It is similar to the concept of ‘pets’ versus ‘cattle’. Your server is just a dumb environment fully managed by automation, which is provided by Kubernetes.
“Where did it all start? As with everyone – in the playground! It is awesome technology.”
How do you successfully carry out Kubernetes projects?
When a customer says he wants to build ‘cloud native apps’, what exactly does he mean? Often, the bottom line is that he wants to run containers. In such cases, we ask him: do you have a microservices architecture? Will it be worth the effort if you have one monolithic codebase?
This affects your way of working. The way you approach projects. We should not be fooled by the typical hypes that exist in ICT, and believe that everyone already fell for them. In Belgium, a lot of people are involved in this process. Everything revolves around Kubernetes. Until you ask the question: how many do you have in production? And then, people often remain completely silent.
If you look at it abstractly, you want the resources to be used efficiently. There is a certain overhead, which you create. For example, there is a ‘control plane’, on which you do not run a useful workload. It is there just to keep things going.
Most of the time, it all comes down to... Microservices or not? If you are only going to run one Pod in Kubernetes, you may want to seriously rethink that choice. If you are a company that continuously designs APIs, Kubernetes is the obvious choice. But if you are a company that designs Drupal sites (which are just one block, a database and some PHP code), then you can of course use Kubernetes for that, but the benefits will not be outstanding.
Where does Combell stand today with Kubernetes? What have you accomplished?
Where did it all start? As with everyone – in the playground! It is awesome technology. You first get to know it, and then gradually things become more serious.
Kubernetes is for the time being a bit like the final step in the evolution of containers. The release of Docker was the first step in the democratisation of container technology. You hear about the technology and see the hype around it, which eventually fills you with enthusiasm and makes you want to try it. But then you also run up against its limits, for example when it comes to storage and networking. The next step was the orchestration of several containers with Docker Compose. But this tool has its limits too: at some point, the host is full of containers. And you still need to configure Nginx, for example, to make those services available to the public.
Today, we still use Docker and Docker Compose in production, but Kubernetes is the next logical step because it makes abstraction of the hosts on which the services are running. Kubernetes allows us to orchestrate a collection of services across different servers, without having to worry about clustering, scalability and deployment.
Now, we have finally taken the step to production, albeit for the time being only for internal services. For example a Slack-bot, an internal 'Chatops' bot. We also expect to release our first customer facing service on Kubernetes soon.
Can Combell customers also enjoy the benefits of this?
We have been hesitant for a few years because we felt that there was not enough adoption among the specialists in our network. But that discussion is now over. We do believe that this is the future. And we therefore feel that we should focus on it.
We are now struggling with the question of what Combell can do to bring added value. How far will we go to guide our customers? That is the challenge. I think we are technically ready now. This is also a great business opportunity to stand out from the competition. But we want to go the extra mile, which means that setting up a ‘bare’ Kubernetes is not enough. A whole range of additional services and guidance is also necessary to help the customer in his quest for an efficient way of working.
Combell's three pillars are customer stability, security and speed. That is why we have also studied the technology for a long time and thought carefully about what our added value could be. We believe that we are ready and can achieve a lot in collaboration with our customers.
We can e.g. help developers stay within their comfort zone and continue to use the same tools. Our mission is to remove the complexity of Kubernetes and integrate Kubernetes' API into the CI/CD tools our customers already use.
Do you need help with the next step in your container project? Feel free to contact us by e-mail at k8s@combell.dev and we will be happy to assist you with our solutions.
Over the next few months, we will be taking a closer look at the technical aspects of Kubernetes and answering questions such as:
- Why is it so beneficial for developers? And for which workloads exactly?
- How to deal with the monitoring of Kubernetes services?
- How to organise an easy-to-use CI/CD workflow with Kubernetes and Gitlab?
Stay tuned!
Related posts
