Q&A

Civo Offers Simplicity To Take on the Big Three Cloud Services Providers

Civo CEO and cofounder Mark Boost recently shared his views on the current state of cloud services, including vendor lock-in and the complexity that inevitably brings problems.

• By Kurt Mackie
• 09/14/2022

Civo is a relatively new managed Kubernetes services provider, having launched at the "general availability" stage almost a year ago.

Civo's approach breaks away from the traditional cloud services mold by simplifying billing for its customers, removing things like data transfer fees. Its customers are protected by multiple network safeguards plus traditional service-level agreements. The UK-headquartered company currently serves developers and software-as-a-service providers in three geographical regions, with datacenters located in the U.S. East, London and Frankfurt, with more regions planned in the coming months.

Civo came into being after CEO Mark Boost sold hosting services provider LCN.com, a company he founded back in 1999. LCN had grown to become the fifth largest U.K. hosting company, with 450,000 domains under management, before it was sold in 2019.

Redmond: Why was Civo created?
Mark Boost: LCN was my first company and it was grown organically with no investment. Over the years, competitors like GoDaddy were making it hard to grow that business, so we made the difficult decision to sell it and invest that money to create Civo. At the time, we saw an opportunity with emerging cloud native technologies that would eventually become Civo's specialty. My background is very much focused on datacenters, networks and the transition from physical services to virtualized services and to containers -- that whole journey. With Civo, we would double down on cloud native technologies.

Civo doesn't really offer many of the legacy services. We don't advertise even standard IaaS VMs. Everything we do is focused around cloud native technologies, and Kubernetes has been the main part of that.

We've seen day-long service outages, even from large cloud services providers such as Microsoft. Is it just an industry expectation?
I've personally had over 20 years of experience in running datacenters, and I've seen all the pitfalls. And so I'm not surprised by the outages with Azure, AWS or Google because there are so many moving parts and things go wrong. A lot of it still comes down to human error, though, when someone for instance accidentally pushes out an erroneous network change.

But relying on the three big cloud providers creates a big risk for everyone in having so many eggs in one basket. We've seen the impact of a Microsoft 365 outage, given how many people rely on Microsoft for their businesses and access to files and the like. Everyone should be aware of the risks of going with the big service providers. They should diversify as much as possible to make sure they're not overexposed. And yes, I'm going to wear my Civo hat and say we'd love people to come to us.

How does Civo address complexity and service uptime?
We have values going right back to the LCN days of building everything as simple as possible. The hyperscalers have very complicated ecosystems that are going to have weak points because of the sheer scale involved. At Civo, we've tried to build in a way that scales out on a smaller modular basis. We work on a rack-by-rack hyperconverged design and treat a rack almost like a region in itself. So even if we have multiple racks in a single datacenter, there are lots and lots of discrete miniregions, in a way, so you can reduce your blast radius.

So if we had any kind of issue, it will be isolated to a single rack as a minimum. But we've even recently gone a step further and we've created something similar to "availability zones." It's like miniracks within racks that create their discrete zones. And then when people use Kubernetes to deploy applications, they're spread across these minizones, even within a single rack.

When Amazon and Microsoft talk about availability zones, they mean availability centers and datacenters. We're taking it down to a rack level so that blast radius only becomes like ten servers, rather than a whole rack of servers. The point is to get away from a single point of failure. We're very careful to be more granular and not have any amount of racks exposed. Even when it comes to our core edge routers we only put six racks into them before deploying the next set of core routers with another six racks, and we then bring in discrete ISP links to each six-rack deployment.

Of course, there's always a risk of a datacenter problem, though, such as a catastrophic natural disaster which could happen at any time. For instance, one of Google's London datacenters overheated when the UK recently hit record temperatures. Developers, though, should take advantage of modern ways to build containerized applications across multiple regions to diversify the risk.

Does Civo offer service-level agreements?
Yes, we do. It's very similar to the big three's service-level agreements, but enhanced, and uses the same sort of metrics.

When it comes to monitoring and pushing Kubernetes clusters and things like that, we have a marketplace with a number of different tools. There are many good projects out there to use rather than rely on Amazon and Azure tools, which can be a lock-in component.

There's a strong argument nowadays that if you can keep everything in cluster and deploy all the applications in cluster, then your workload becomes more portable, and you de-risk yourself from vendor lock-in. So if you did have a consistent problem with your cloud provider, you could seamlessly pick up your Kubernetes clusters and move them somewhere else. If you buy all the extra wrap-on services that Amazon or Microsoft might sell you, then you're going to find it hard to ever leave them if they provide a bad service or charge too much. I believe that's very much by design.

My belief is it should instead be a fair fight in terms of who offers the best service, the best performance and the best reliability -- and not trying to lock-in customers.

Is the multicloud concept real or just a pipe dream?
I think we are getting there. I certainly think there's a multicloud opportunity to have different types of workloads with different providers, which is a lot easier than trying to run a single production environment across multiple cloud providers. But trying to run a Kubernetes cluster across multiple cloud providers, well, I'm not sure we're quite there yet. You've got issues around licenses, all sorts of challenges around data, existence and persistence, stateful workloads, and things like that, so, we're not quite there yet. It will get easier though.

If an organization is using Kubernetes on AWS, Azure or Google Cloud Platform, could they just migrate over to Civo?
It's much simpler if you kept everything "in-cluster," by deploying the majority of your applications within the cluster itself.

Many hyperscale cloud providers have a lot of wrap around services they will push heavily for you to buy. To leverage their services fully you often need to use many things that live externally to the cluster such as their custom firewall service, load balancer service or identity and access management. If Civo doesn't have the exact equivalent service that's deployed in the same way, then you can't just seamlessly migrate everything. So that's the challenge.

A migration almost always entails a start-from-fresh approach of building out a new environment and then start migrating the data, but there are tools available to help automate much of this.

Does Kubernetes offer a path to standardization in cloud services?
In a way, Kubernetes promised the dream of standardizing the way we do things and it's certainly helping to standardize things more. Early on, there were a lot of custom drivers that were built for AWS or Microsoft for storage and things like that. An example is we now have a common CSI driver for storage, replacing the custom drivers that previously existed for each provider.

Still, there might be resistance from the big three-type cloud services companies to move away from their own versions of these types of things, as it does reduce vendor lock-in. In my opinion, that's a good thing for the end user, providing more freedom of choice.

Civo aspires to be a pure Kubernetes service provider and be very open about the way we work. We support open source and aim to drive change in the industry that would be good for business and good for consumers -- namely, more choice, less vendor lock-in and more standardization. Cloud services should be about who provides the best and most reliable level of service, not vendor lock-in.

Is Civo mostly marketing its services toward software application developers or software as service providers (SaaS)?
It's a bit of both, but SaaS companies are a big one for us. We're particularly keen on new SaaS startups that potentially haven't already chosen a preferred cloud provider. We currently attract customers looking to save money from the big three cloud providers, as we offer a very fair price with predictable billing. We don't have a lot of usage-based charges, data transfer fees and all these things. It's consistent, so anxiety about billing changes happening every month doesn't happen with Civo.

Also, we've got the fastest launch time for a Kubernetes cluster in the industry. It's about sub-90 seconds and is soon to be reduced to sub-60 seconds. In particular, this benefits the developer environment needing fast spin times. Most of the hyperscalers require 10 to 30 minutes to spin up a cluster by comparison.

What concerns do customers have when selecting a cloud services provider?
We did a survey recently that found that the main two reasons why people don't want to use a small cloud services provider over a hyperscaler were security, followed by concerns about outages. However, there's been a lot of outages from these big cloud service providers, so I don't buy into that. No one's immune to them. Security issues affect them too. I'm not suggesting that the services offered by Microsoft, Amazon and Google are insecure, but due to the sheer complexity of their platforms, it's been well documented that users often accidentally misconfigure things and leave systems vulnerable.

Civo keeps things simple, which helps avoid such misconfigurations and problems.

Do customers need to know Kubernetes?
Kubernetes is what we specialize in and it's very simple to use. We've got lots of guides, plus a Kubernetes Academy with 60 training videos where people can learn, from beginner, intermediate and advanced levels. What sets us apart is that we have a really good support network and community. We have about 13,000 people in our Slack community that can help and support people in their learning journey and moving to Kubernetes. If someone's looking to move from older style, noncontainerized hosting into containers, we're probably the best starting point.