Welcome back to our Ask an Onner blog series, where we put the spotlight on the smart, driven, and passionate people who make Onna what it is. (In case you missed them, catch up on our previous conversations with Pavel Pratyush, Allison Keane, and Shannon Smith.)

Tell us a bit about you and your role.

Paul: My name is Paul Charbonneau, I’m a senior backend developer in what we call our Connectors Team. I’ve been working as a backend engineer for almost seven years and with Onna since June 2020, based in our Barcelona HQ.

What drew you to Onna originally?

Paul: What brought me here is what most engineers are looking for: a complex problem to solve. In Onna’s case, having a massive infrastructure that needs to ingest data from many sources, extract as much information as possible from that data, and then index it so it can be searched.

I was also looking for a company that was applying modern practices with modern technologies. When I joined Onna, everything was already on Kubernetes and containerized, and we had good pipelines, good testing, etc. But there was still the challenge of building an architecture that could scale indefinitely, which was interesting to me — so here I am. 

How’s your time with Onna been so far and what type of work have you been doing?

Paul: I’ve always been on the Connectors Team, meaning I work on the part of Onna’s Knowledge Integration Platform that is responsible for collecting massive amounts of data from some of the world’s best-known cloud tools. My projects have varied, however. During my onboarding, I learned about our execution model and worked on some simpler tasks. Then I worked on our Marketplace for about four months, helping to develop the necessary tools for external developers to build connectors for Onna. After we released our Marketplace beta release, I went back to working more on architectural challenges. 

In a nutshell, I’ve been doing different things: from developing, to architecting, to even becoming a Squad Lead in January 2021. My current role is a mixture between team lead and tech lead, and it’s quite flexible. Some people prefer to be closer to the product, others, like me, prefer to be more on the technical side, and others might spend more time on people management. In that sense, I feel that Onna is quite a flat company, hierarchically speaking, in which you can move around different areas depending on your interests and the impact you would like to make. For me, becoming a Squad Lead was a great opportunity to actually see what my interests are and what I would like to do next with my career. 

Describe the tech ecosystem a software engineer faces at Onna on a normal day.

Paul: The main language we use on the backend is Python. Almost all of our code is asynchronous, so we use a lot of Asyncio. The main problem we work on is data, and data being a very I/O-bound problem, you can always benefit from this kind of execution. And from there, as I noted before, everything is containerized. The technologies we use really depend on what the needs are. For instance, if you need a service, we usually use FastAPI. And if you don’t, you can run Python directly as a Kubernetes job, for example. Kafka is another important piece, we use it as our main technology to do any stream-based or event-based communication. We developed an in-house Python framework called Kafkaesk that allows us to easily create Kafka producers and consumers. We have some RabbitMQ queues as well, in components where Kafka is not well suited. For storage, we mainly use PostgreSQL, but we are moving newer components to ScyllaDB. For Key/Value storage we use Redis, but I think Memcached is also used in some other parts of the infrastructure. And obviously what sustains everything is containers and Kubernetes. 

A normal sprint for an engineer here at Onna involves touching a bit of everything. Our engineers are expected to understand and to be able to work on any part of the platform they own: from development, to testing (we use Jenkins to execute our pipelines), to deployment, to observability (we use Prometheus and Grafana). There are common things that are managed by the Ops team, of course, but you’re basically expected to understand the whole development cycle, the components and technologies required and why, the metrics and alerts you need to put in place, etc. 

Are there any interesting challenges that either you or your broader team hope to tackle in 2021-2022?

Paul: For the second half of 2021, the Connectors Team will be focused on improving our collection speeds. To do that, we’ll need to work on the architecture. At a high level, this means moving some processing that still occurs at data-collection time to separate components that react to collection events. That will also allow us to use the collected data better. We’ll also probably add more integrations to our platform.

Looking ahead to 2022, as we continue to build out our Knowledge Integration Platform, we’ll keep making architecture changes to allow the platform to scale better.

Anything else you want to add?

Paul: The freedom you have as an engineer at Onna is huge. Even if you’re a junior engineer, you can speak up in leadership meetings and propose things. Your voice will be heard, and you’ll be able to put things into practice. That’s something I value a lot about this company. There’s a lot of room for growth, and people actually listen and care about your opinions. It’s a very pleasant environment to work in. 

We hope you enjoyed getting to know one of the many faces behind Onna. Be sure to follow us on LinkedIn and Twitter for more!