Monopoly

We always wanted to be free and not to be dependent on where our solution is deployed. It is a very strong mindset we have at InsideBoard.

As a SaaS solution, being dependent on one cloud provider is too risky.

So we cannot bring ourselves to be pies and fists linked to only one cloud provider.

Client first

When it came time for scaling the platform, of course we wanted InsideBoard to be deployed worldwide for the best user experience.

InsideBoard is a very customer-centric company. As such, we know that our customers care a lot about their data, where and how it is stored.

We came to the conclusion that our clients should have the choice of where and with whom to host their data, and that we have to dedicate cloud resources.

With all that said, let’s make InsideBoard Cloud-agnostic!

How ?

The two main options that came to our mind were:

• Adapt the code to use cloud providers’ services and resources

or

• Manage every stack and use only network, storage and virtual machines resources from cloud providers

Adapting the code means that our developers would have to know almost all providers’ APIs and SDKs, from message queues to databases. The code will not scale so this is probably a bad idea.

So, we have to manage every stack and understand every technology we will use! Perhaps harder on the infrastructure team, but easier to scale for the company 😅

But what about storage?

Object storage

Object storage is probably the best option for scaling worldwide.

But still, we will have to choose a cloud provider for our storage or we will have to adapt the code for S3, Azure Blob, GCS, and so on….

Definitely that’s something we want to avoid.

So we have to find another way!

Zenko

We looked for a solution on the market that fit well with our freedom mindset and our infrastructure stack.

Zenko matches all our needs!

• Kubernetes
• Unique API endpoint
• Multiple storage backends
  (Azure Blob, AWS S3, Google Cloud Storage, Scality Ring, Wasabi, …)

And more!

Zenko has a very nice feature called backend replication which enables us to replicate our objects across different cloud providers and regions!

If like us you are already using Kubernetes, you should try Zenko!

It is the only thing you need to start with Zenko.

For development purposes, you should consider hosting Zenko in a real Kubernetes cluster rather than using Minikube.

Zenko is now widely used at InsideBoard, from the infrastructure team to data science to development.

One more thing: Zenko exposes an S3-compatible API, so yes, the only protocol your code has to support is S3, which has ready-made, official SDKs for almost all languages (Go, Node.js, Python, PHP, Ruby, …).

Cloud agnostic

Today we are cloud agnostic and totally free to host our solution where we want 😛

From cloud providers, we use only resources like network, virtual machines and storage as Zenko backend. We manage every stack and our infrastructure team delivers technology as a service (Zenko, Kafka, Argo, Sensu, Jaeger, Prometheus, ….).

Our storage bottleneck is now solved thanks to Zenko !

What’s next ?

Storing everything where you want with only one protocol, S3.

Here is the topology we have in mind, replicated Zenko clusters geographically load balanced with Cloudflare. That way we can continue to serve our customers even if an entire data center or Cloud provider goes down.

Conclusion

From now on moving from one provider to another is just a matter of very small Terrafom scripting. In another post i will talk about how we automate Terraform with Argo and how it help us to dynamically manage our dedicated resources like Zenko or virtual machines.

References

https://github.com/scality/Zenko