Architect's Corner: Hugo Claria of Naitways talks Kubernetes storage

Today’s Architect’s Corner is with Hugo Claria, head of the hosting division at Naitways.  Naitways is one of a growing number of Portworx customers across the UK and Europe.  We sat down with Hugo and talked about some of the challenges of building a multi-tenant application on top of Kubernetes, including Kubernetes storage. You can also find a PDF of this case study here.

Key technologies discussed:

Container Runtime – Docker

Scheduler – Kubernetes, Docker Swarm

Stateful Services – MySQL, WordPress, Drupal, Magento, Joomla, Redis

Infrastructure provider – On-premises

Can you first tell me a little bit about what Naitways does?

Naitways is an IT service provider company, based in Paris (France). Naitways is composed of two business units, the hosting business unit, and the infrastructure business unit. We were founded 10 years ago with one mission, to help and advise our client with their infrastructure, especially as they move into the cloud. In order to provide the best service to our clients, we have built our entire infrastructure ourselves from scratch. We have always offered a VMware based private cloud, but nowadays, more and more customers are asking for public cloud services. For these services, we are using Kubernetes. We now have around 30 employees and we look forward to hiring new talent in 2018.

Can you tell me a little bit about your role at Naitways?

I was employee #3 at the company. I started as a systems engineer but over the years, I was promoted to manager of the Hosting business unit. The Hosting business unit provides services inside the virtual machines while the Infrastructure BU provides the physical hosting layer. That is to say switches, routers, circuits.

Can you tell us how you are using containers at Naitways?

Yes. We’re doing two things with containers.  First, for our private cloud customers, we have built a Docker service for them managed by Swarm or Kubernetes. These are customers who have already purchased some infrastructure from us, but now they want to try Docker. For these customers, we installed Docker stacks managed by Swarm or Kubernetes inside virtual machines.

In addition, we are also building a shared public cloud infrastructure running on Kubernetes where a customer doesn’t have to worry about virtual machines or even containers. They can just run an application like WordPress directly. We have a provisioning portal interface that will allow users to provision software as a service.

They can pick from GitLab, Nextcloud for file management and sharing, Drupal, WordPress, Magento, Joomla, Redis and a MySQL database as a service.  We provide this pre-packaged software, pre-installed on the computer instance, ready to be consumed by the customer.

We are building a shared public cloud infrastructure running on Kubernetes where a customer doesn’t have to worry about virtual machines or even containers. They can just run an application like WordPress directly.

If they pick MySQL for example, they don’t have to install it, patch it, upgrade it. We do all that.  They just get access to phpMyAdmin if they want, a public IP for access and they are ready to go. This is a click-and-use solution to facilitate our customers’ lives.

What were some of the challenges you needed to overcome in order to run stateful services like databases, and queues, and key-value stores in containers?

One of the biggest challenges was lifecycle management. Once a customer is running in production with a stateful service, I have to think about managing all the operational tasks without downtime.  How do I launch my instance, how do I limit the resources being shared among the customers?What happens when an instance dies? How do I manage my backups?

The Kubernetes API provides a lot of management for the stateless services, but for volume management there is Portworx. That API-based management for our storage provides a lot of value to us as a service provider.

For example, we run an S3-like object store at Naitways. We use the Portworx CloudSnap feature to do a backup and restore from this object store.

Anytime a customer requests a backup, it is really easy for us to provide.

The Kubernetes API provides a lot of management for the stateless services, but for volume management there is Portworx. That API-based management for our storage provides a lot of value to us as a service provider.

We’ve also been able to use Portworx to easily implement customer upgrades as a way to expand revenue.  We have tiered pricing where the customer can pay for what they consume.  If a customer wants more backups or more storage, this is simple to implement via the Portworx API.

The other real business value of Portworx is time. We can get to market faster with Portworx than we could if we implemented everything yourself.  For instance, I love automated snapshots. I don’t have to code anything on my side in order to implement a snapshot or backup schedule. I think that you saved me four or five months with that feature. With Portworx, we bought ourselves time!

We did look at a couple of other alternatives before settling on Portworx but those were not as mature as Portworx by comparison and we had problems with installation, maintenance, and performance. Ceph was also an option but implementing that would have been a lot of work because it just provides the basic features. Extending Ceph for our use case would have taken an additional four to five months of development.
The real business value of Portworx is time. We can get to market faster with Portworx than we could if we implemented everything ourselves.

What advice would you give someone else thinking about running stateful services in production?

Don’t build it from scratch yourself! If you don’t have a large team of very good engineers, it is going to be very hard to build and bring support to these services yourself. Just like you wouldn’t want to build the Kubernetes API yourself, you probably shouldn’t try to build a volume management API yourself.