Julien took part in the 2017 Zenko x 42Paris hackathon, and was a member of the winning team! One of our open source contributors, he agreed to have his portrait featured here!
What’s your role in Zenko? How did you get involved in it? How long have you been involved with it?
Scality has organized a hackathon in my school, 42 Paris. My team carried on with the hackathon’s project for 3 month to allow Zenko to support the Backblaze B2 API for object storage. Our work is currently a pull request, and we got school credit for it.
What other open source projects have you worked on? Which ones are you currently involved with?
For now I have only worked on open source projects once but, soon, I would like learn Golang to work on Terraform, a project by Hashicorp
Which of your skills helped you the most with Zenko?
Before working on Zenko’s CloudServer, I had never used Node.js so, at the beginning, it was tricky! It’s very difficult to understand callback into a huge codebase like Zenko’s CloudServer, therefore, I would say my main skills were bravery and obstinacy.
What do you think makes Zenko special?
Zenko gives you the possibility to work with multiple cloud providers. That is essential to keep independence from companies like Microsoft, Google or Amazon. It also lets you add support for other cloud provider like Backblaze, with much cheaper rates than the big ones.
Would you rather start every sentence with “This was going to be a joke” or end every sentence with “and then I wish I knew better”
“This was going to be a joke”
Would you rather everything you say never happens or everything you think always happen?
Everything I say never happens
Would you rather start a new Github account after you reached fame and prosperity with the current one, or have to rename that famous account i-make-great-bugs?
Have it rename i-make-great-bugs
Would you rather never go outside again, or never go inside again?
It’s always fun to deal with “chaos monkeys”, a barrel full of fun indeed. A lucky bunch of team members at Scality had their dose of monkey fun at the Paris Kubernetes Meetup. While presenting MetalK8s to the group, Julien Girardin, R&D Engineer and Laure Vergeron, Zenko Technology Evangelist, mused over Zenko’s architecture and its resilient design. The meetup was a joint event with the serverless, Docker, and chaos engineering communities, and the keynote speaker was from the Chaos Engineering community.
You get chaos in your systems when there is an urgent problem, with assumed causes and consequences, but the link between them is unclear and so is the path to resolution. The ability of a system to cope with chaos is called resilience. Resilience can be defined as a system’s ability to absorb perturbation and keep functioning, even if in a less efficient fashion.
Chaos Engineering is the practice of injecting perturbations in a production system and studying its resilience. It’s a scientific approach and it’s not testing! Testing should be done at unit, functional, and integration levels before anything is put in production. On the other end, Chaos Engineering lets you evaluate you system’s resilience in a real production setting, with all its functional partners available, at all levels of your architecture and deployment; it also lets you evaluate the resilience of the people in your teams, which is equally important to a service survival as the system itself.
At Scality, we’re familiar to deployments in environments where failure is not an option: some of our customers are Tier 1 providers, global banks, government agencies, global booking systems… they cannot afford to have their service down at all. Our architects designed the RING and Zenko to be resilient to chaotic situations. While the RING leverages the chord algorithm, private cloud replication, and shared nfs/object interfaces over a single storage, Zenko uses different mechanisms.
Zenko is designed with auto-scaling, self-healing, infrastructure checks and data availability in mind:
Auto-scaling: to handle sudden surges of traffic which are common at Tier 1 network providers, we chose Kubernetes for its native auto-scaling feature;
Self-healing: thanks to Kubernetes again, any pod that disappears will immediately be respawned elsewhere; together with microservices replica sets and auto-balancing of services on nodes, Zenko’s deployments are very resilient, even with several nodes gone;
Infrastructure checks: thanks to MetalK8s, our optimize K8s distribution, Zenko will not be deployed on a shaky network or an insufficient number of nodes, providing automatic protection from Network Chaos Monkey;
Data availability: the main purpose of Zenko is to give you multi-cloud control, so when one of its providers is down, an application can seamlessly failover to another using the S3 API; a single namespace over all clouds, with aggregated metadata search and replication workflows across all of them can, when used wisely, provide unlimited service availability.
All of that allows Zenko to pass the Chaos Engineering test: its components probe the hardware, scale up or down automatically, self-heal, offer stats on the system’s health via Orbit management UI. We love the quote attributed to Nora Jones (Senior Software Engineer @Netflix) about Chaos Engineering: Introducing Chaos is not the best way to meet your new colleagues, though it is the fastest: are your systems Chaos-proof? Come tell us in Zenko’s community… (fast)!
Giacomo is one of Zenko’s core team developers and he works from the SF office. Below, a profile and interview:
Giacomo Guiulfo, Scality
What’s your role in Zenko? What made you decide to get involved in it? What are you most excited about?
My role in Zenko is simple: to implement new features and ensure their proper functioning to deliver an outstanding product. As a Software Developer, the tasks that fulfill this role include: writing well-documented code, designing and implementing different kinds of tests, and applying DevOps practices to improve infrastructure and continuously deliver Zenko.
The first time I heard about Zenko was during a hackathon that Scality organized at my school, 42 Silicon Valley. At that time, my exposure to the tech industry and especially the cloud landscape was still fairly new, and even though Zenko looked very promising, I didn’t quite understand its full potential. Nevertheless, half a year later I joined Scality and couldn’t be more excited to work on Zenko, this time with more knowledge and a better picture of what it means to the tech world. I’m excited to grow with a community that has great potential to cause an impact on how we think about the cloud. On the technical side, I’m excited to work with Kubernetes (especially metal-k8s, our own flavour of Kubespray), a very promising open-source container orchestration system that is used to deploy Zenko.
Why does multi-cloud storage matter?
These days we live in an application-centric world where the enterprise needs to solve problems using the best and most appropriate tools out there. Different clouds, whether public or private, have their own benefits and provide services that can be particularly useful for an application. That’s why multi-cloud is becoming the norm for designing cloud infrastructures. However, in terms of storage, many companies still want to manage their data locally in their own data centers, which prevents them from leveraging the true potential that clouds offer. Multi-cloud storage solves this problem by allowing data mobility between public or private clouds and letting enterprises choose where their data sets need to be. It also offers enhanced data availability and durability with data spread in the different clouds, cost optimization with the ability to use the most appropriate cloud for each application and all this without any concern of vendor lock-in.
What do you think makes Zenko special?
Multi-cloud storage and therefore, data mobility and true freedom, can only exist if there is a way to interact with the different cloud platforms using the right communication protocols, perhaps in a standardized way. This is where Zenko, a multi-cloud data controller, comes in. With Zenko, you can use the AWS S3 API as one interface for multi-cloud data storage. Better yet, all data written through Zenko is kept in its native format and it can be easily used by services on the underlying clouds. It also has some amazing features like metadata search, multi-cloud replication, and more on the way. Zenko is simply a one of a kind product.
Zenko’s multi-cloud capabilities keep expanding with the addition of Digital Ocean Spaces as a new endpoint within the Orbit management panel. Digital Ocean is a cloud hosting company that has experienced explosive growth since 2013 with a very simple to use product. Spaces is the latest addition to the popular Digital Ocean cloud offering: a simple object storage compatible with Amazon S3 API.
The video below demonstrates how to set up data replication between an Amazon S3 bucket and a Digital Ocean Space. One might want to setup such replication to keep multiple copies of a backup file for example, or to increase resilience of an application in those rare cases when a cloud is not available. Another typical use case is to optimize costs, using the best features of many clouds while keeping costs under control.
The newly released version of Zenko Orbit lets you seamlessly replicate objects between Amazon S3, Digital Ocean, Google Cloud, Azure, Wasabi, Scality RING and local storage. You can test the replication capabilities easily by creating an account on Orbit and then connecting it to your accounts on Amazon AWS and Digital Ocean Space. Watch the video for more details. If you have questions don’t hesitate to ask on Zenko forums.
One of the first recommended ways to test Zenko is to deploy it in a Docker Swarm cluster. Docker Swarm allows to make a group of servers part of a cluster that will give you fault tolerance. Deploying, and that provides Zenko with a high-availability architecture.
Since Zenko deployment documentation mentions a functioning Docker Swarm cluster as one of the prerequisites, we recorded a short video to illustrate how to create a cluster with 2 worker nodes and 3 manager nodes. We do this every day, we tend to forget that we had to learn it too, at some point in (recent) time. Enjoy the video and reach out on our forum if you’re having any difficulty deploying Zenko: we’re here to help!
