I already described in this post the inception of SixSq in 2007 from my drive to introduce cloud computing at CERN.

For a while, starting from my time in Germany (1997-2004), creating a company was something I wanted to try. That and doing a PhD. So while working on my cloud vs grid position paper at CERN, after being convinced that cloud computing was the future, it was clear to me that I had the foundation for what could be a potentially successful company. But this is a scary (and crazy) endeavour. And surround yourself with amazing people was a really good piece of advice I got early on.

The people I had around me I would go into battle with were very clear: Louise Merifield and Cal Loomis. Louise is my wife! Since we climbed our first multi-pitch rock face together (400m in the French Alps), our first 4000m peak, jumped from an airplane together (she went first!) and went as far as having kids together… there was no one else I would trust as my wing-lady. I had known Cal at CERN, working together on an architecture working group trying to herd architects and developers from across Europe to bring together a sensible grid infrastructure. Cal is super bright and has immense patience (something I hope rubbed off on me over the years). So once they took time to think about my proposal and decided to give it a try, we were off.

It’s hard to summarise in a few words 12 years of hard and often fun work. Here for me are the highlights. We initially decided to bootstrap the company ourselves, as opposed to raising capital with business angels or investors. So we had a slow start, giving us time to explore and figure things out. Leaving CERN, I had a few months of sabbatical during which I focused on creating SixSq, with Cal joining part time after negotiating with his employer at the time: CNRS.

In 2010, Gartner interviewed us and suggested that what we were doing was about 3 years ahead of the market and competition, and that we would probably be better off continuing on our own for the market to mature and our software as well. The first real trigger for SixSq was the award of the European Commission Seventh Framework Programme project: StratusLab. This 2.3M € project allowed us to hire software developers, and accelerate our software development.

In 2012, my old boss, Bob Jones asked us to join the Helix Nebula initiative. This was a great way to reconnect with CERN and join the European effort to build a public/private cloud strategy to accelerate cloud adoption in European research and academia. Cloud brokerage and multi-cloud management was for a long time the target SixSq aimed at. But as we built both the software and our go-to-market strategy, it became clear that this path was tricky. It was relatively easy to link small contracts to get by, but it was challenging to identify truly scalable business. Nevertheless, I found the whole journey, from the initial lukewarm reception of my suggestion in 2007 that the cloud would overtake the grid (read the details here), to being asked to join as a cloud subject matter expert, very satisfying. CERN eventually ended up becoming a customer of SixSq.

Along the path, we built nice systems, most of the time leveraging our own open source software. A really productive collaboration was with ATOS, for whom we built three different private high performance clouds, targeting European research communities. Working with very large system integrators, like ATOS, gave us a wealth of information and knowledge about how to do business with such entities, as well as the challenges in repeating this type of business with similar companies.

In 2014, we started to realise that running a software development company on our own was becoming both difficult and stressful. Having our personal wealth entirely linked to the company was a challenge. And having myself and Louise, my wife, in the same boat, added to the pressure. My excellent friend, Cédric Seynat presented me to a truly amazing man: Denis Gagnon. Telco engineer from McGill University and confirmed private pilot (I also fly single engine aircrafts), Mr Gagnon was then looking at rebuilding technology for his companies. Cloud computing being on his target list, we started talking. In 2014, he eventually bought 55% of SixSq, in a partnership that promised to bring in existing mature markets and customers to SixSq and extend his companies’ reach with new cloud based technology offerings. However, soon after Mr Gagnon was forced to leave his duties and step aside. We therefore never had the opportunity to work together as we had dreamt it, during our meetings, in Geneva, Ottawa and the ski slopes of Zermatt.

On the technology side, both Cal and I wanted to ensure we used the best software languages, frameworks and tooling available. In 2014, dissatisfied with the Java environment we had, we started exploring alternatives. We eventually chose Clojure, a LISP-like functional language, targeting the Java Virtual Machine (JVM). The elegance and expressiveness of the language allowed us to reduce our codebase significantly, improve testing and massively increase scalability. The Clojure community soon after released ClojureScript. This meant that with the same language, we could build meaningful front-end and back-end, not only using the same language, but often sharing the same code. Cal became a true wizard of the language, its ecosystem and frameworks. One regret I have is for Clojure not to have become more popular over the years. This means that recruiting experienced Clojure/ClojureScript developers is challenging. But since the language is reasonably easy to learn (after a mind shift into functional programming), we have recently had more success in training talented developers.

Cal eventually left in September 2019, moving back to Chicago, the place he calls home. It was a real honour to share this journey with him.

One important aspect, and a personal pride, in SixSq, is our smart and pretty much systematic usage of agile methodologies. My discovery of agile methodologies deserves its own entry, so I’ll skip it for now. Throughout, we have applied (and regularly improved) our agile methodology. I was fortunate to learn from Jeff Sutherland (founder of Scrum, the most popular agile methodology) himself. Learning by doing at SixSq, I trained a number of customers, including the European Space Operations Centre of the European Space Agency. Not only did this give us revenue, it also opened up access to key stakeholders in the agency to build business. We now use a customised version of Kanban and DevOps.

Last year, SixSq had its best financial year, with a turn over of 2.5M CHF and a healthy margin. But it’s the team that I’m the most proud of. The pivot to edge as a Service is truly exciting and I can’t wait to see this team deliver its wonders to the market.

The other early success of our edge solution (see this post to read about our contribution to the genesis of edge computing) was with the European Space Agency (ESA). With the need to process terabytes of data daily and at numerous locations across the globe, ESA could not afford, nor was it feasible, to move this much raw data to the cloud. Mark Dumville, CEO of NSL, whom I knew from early work with ESA on Galileo related work, had the foresight to imagine combining SixSq’s edge capability and NSL’s GNSS signal processing mastery. The result is an edge-to-cloud solution, capable of precessing petabytes of data daily, using a sophisticated strategy between processing stations (edge) and the cloud.

During the bid process for this contract, we beat straight out several consortium, including mighty European organisations, in space, defence and cyber security. If there was one case of David defeating Goliath, this is it, and I’m immensely grateful for ESA to have put its trust in the hands of SMEs like SixSq and NSL. Our proposal put forward an edge-to-cloud architecture, providing a scalable, yet resilient solution. Further, with a potentially large addressable market, our ability to deliver the resulting solution as a service together was I think a winner. You can hear from Vicente Navarro talking about this project in this video.

The Orchestra Director for this work at SixSq is Konstantin Skaburskas. Konstantin was the first engineer to join SixSq’s core development team, from CERN. Konstantin has this amazing super power of being able to cast and adapt SixSq software technology and knowledge to solve customer problems.

The result of this project is a big data solution, leveraging an edge-to-cloud architecture, where each ground station records TDs of data daily, from the Global Navigation Satellite System (GNSS) (including the American GPS, Russian GLONASS and European Galileo) signal range. Users can then deploy AI or other analysis applications to the edge, to sieve through the data and tag interesting events for replication in the cloud. With limited local storage (288TB), the station has a data retention of a few days, before old data gets discarded and replaced by new data.

Since this is an edge system, which requires tolerance to network jitter and interruptions, data that is tagged for cloud transfer is cached locally if network is lost. The system then attempts to resume data transfer when the connection is re-established. But not only does such a high throughput system require a high level of sophistication, it also needs to also work at scale, as the number of stations multiplies.

While the edge component (aka the stations) of the system provides a near real-time opportunity to react to raw data processing, the main purpose of detecting interesting events and having their corresponding data replicated in the cloud is to build meaningful and rich time series or historical datasets. For example, when a solar flair hits the Earth, it interferes with the GNSS signals, and this will show in the raw data. The same is true for many natural and artificial phenomenona. These are the famous events researchers and users of the system are looking for.

Some scientistes (and I’m sorry I don’t have the source reference) have postulated that before an earthquake occurs, early sign of the impending episode might be detectible in the raw GNSS signal. If this is true, our system should be able to record the data for scientistes to verify or not this claim. When looking for early warning systems, every second could potentially save lives. It’s therefore well worth it to find out.

In 2007, at a conference in Manchester, I heard Tony Hey present two new services that Amazon had just announced: the Elastic Compute Cloud (EC2) and the Simple Storage Service. Using the web to deliver on-demand computing, in a simple and scalable way was, to me, a paradigm shift. In the ’90s, so many giants had tried and failed to deliver a successful on-demand computing service, yet Amazon’s proposal was simple and elegant.

At that time, CERN IT’s strategy was entirely focused on grid computing, building massively distributed job execution clusters, using traditional concepts. The collaboration went as far as even maintaining its own Linux distribution, imposed on all users. Although the collaboration dabbled in new technologies like web services and WSRF (remember that?!), it never really took off.

Cloud computing was transformational on so many levels. From the technology stand-point, virtualisation was solving the problem of isolation and giving users the choice of running their own operating system (no need to impose anything here). On the service delivery side, a commercial offering was available via a spectacularly simple online contract (no more lawyers needed). This challenged the different research organisations contributing IT resources to the grid effort, including CERN, to better understand their total cost of ownership (TCO), so they could compare their own costs with the prices proposed by Amazon.

My enthusiasm was not always welcomed, from gentle dismissals to stronger rebuffs. But my boss back then, Bob Jones, was kind enough to give me space such that I could perform a comparative study between the grid and the cloud, and write a position paper.

You can read the paper if you want the details, but if you’re impatient, the main conclusion was that the cloud was here to stay, and grid applications would be built on top of the cloud. This turns out to be true. I also called for open source implementations of cloud computing services, which was eventually answered by OpenStack, CloudStack and OpenNebula.

I’d like to acknowledge the contributions of my reviewers for this paper. Special thanks go to James Casey for keeping me honest and making me resist attempts to water down my conclusions, and of course Cal Loomis, who was brave enough to launch into the crazy adventure with me that became SixSq (you can read about our adventures in this post).

CERN has of course since become a strong advocate of cloud technologies, now running one of the largest scientific clouds. CERN even became a customer of SixSq, and several SixSq team members are from CERN. Happy days!

Being based in Geneva, I’ve yearned for a long time to contribute to the humanitarian effort that our city is so well known for.

Humanitarian organisations, however, are quite rightly allergic to technology push. We technologists too often fall victim to using technology when an old-fashioned screwdriver will do, and push techie solutions too early. So many times was I stonewalled during discussions with representatives from humanitarian organisations when I tried to push how edge or cloud solutions could be beneficial to humanitarian efforts. The mission of most humanitarian organisations is sensitive and critical, and funding constrained, and it is therefore not surprising that this creates a naturally conservative culture regarding software and IT innovations. Yet it is exactly these organisations which should have the very best tools and technology at their disposal.

This was epitomised recently during a security certification meeting with one NGO (I can’t yet name the organisation), where the technical lead reminded us that in the past the organisation had lost lives due to a poorly cyber protected system. Indeed a malevolent party managed to detect the location of a team following an online discussion, leading to the bombing of their location. Therefore, while working with humanitarian organisations gives a great feeling of reward, it’s also very serious business. I therefore now treat this line of work as if we were in a military setting. In other words, would I entrust our lives to our software? It’s a big mind shift.

This customer is now deploying edge systems in Africa and the Middle East. These systems are used in field clinics, in order to offer a locally highly available IT system for clinical patient tracking and medical inventory management. On top of that, since it’s an edge system, it can be operated remotely, when online. This allows the organisation to centralise its IT operations, and completely avoid having to deploy IT personnel in the field. This means each field mission can focus its key objective of deploying medical and support staff, and save on operations costs, while ensuring an industrial grade local IT infrastructure.

But I want this to work at scale, since, unfortunately, many NGOs will need this type of solution, and need to deploy them quickly (crises don’t wait for the conclusion of a working group and an enquiry). To facilitate this, software and hardware teams must tightening their relationship. For example, when ordering from OnLogic, customers could soon be able to choose our preinstalled edge software (next to Windows and Ubuntu) as their operating system. This will mean NGOs will be able to order systems online and have them shipped directly to the field, without having to transit via Geneva (or another headquarter) to be configured. This will significantly shorten the time between order and a running system, anywhere in the world, without any impact on security. At a time when reactivity saves lives, I strongly believe that IT system providers must up their game to ensure that our customers are able to mobilise, securely and affordably, complex systems within hours. This is a revolution that brings purposeful technology to the benefit of critical humanitarian effort! I’m proud to be part of this effort.

During the Mobile World Congress of 2014, SixSq announced what I believe was the first edge computing solution. Back then, terms like edge, or fog computing didn’t exist. So to explain what we were doing, we called it a cloud in a box. It came from the realisation that the cloud had brought users a transformative way to deploy and manage applications in remote infrastructures (public or private) with ease and at scale. We wanted to bring the same user experience to the edge, but targeting much more constrained devices, outside the data center. Our cloud in a box product eventually became the NuvlaBox (a SixSq brand).

I explain this in a video HPE produced with the European Space Agency (ESA). But like many good ideas, these did not come out of a vacuum. It required the thoughts of a number of people, at SixSq and outside. Lionel Schaub and Khaled Basbous both worked on this product as part of their masters thesis and an InnoSuisse project called PAChA, under the excellent supervision of Professor Nabil Abdennadher in computing engineering at HES/SO (hepia). Lionel and Khaled were too good, so we hired them! Etienne Coulon and Samuel Mellot’s enthusiasm towards this early product and potential field of applications also helped me realise the full potential of edge computing. The name Nuvla was proposed by Robert Branchat during a brainstorming session to find a name for our new software products and services. It means cloud in Romansh.

But being ahead of the market is hard. You have to educate, identify pains that different industries don’t yet feel, and prove that your solution is the right fit. As an SME operating as a start-up, with limited budget and the need to generate revenue right now to feed the troops, the challenge was immense. Using European and Swiss research funds, we managed to bring our edge solution to production readiness in 2018.

In partnership with Schréder Switzerland, under the leadership of Thomas Blum, we created the Volumlight product (a Schréder trademark), the first production grade smart city evolutive edge system, able to automatically control street lights based on traffic volume. This solution is now deployed across Europe and is being adopted by other system integrators and light manufacturers. Cities have recorded 20% to 40% energy savings using this system.

Other successes include the work we are doing with the European Space Agency (ESA), for which I’ve written a separate entry.

As commonly happens in startups, in the autumn of 2018 we decided to pivot. In fact, we did two pivots at the same time. The first one was to focus the company on edge computing as a service, the second was to jettison virtual machine management and adopt a container native strategy. This led to the release of Nuvla v2 in June 2019 and NuvlaBox v2 in August 2019, followed by the launch of Nuvla.io in September 2019 (busy year!) This was made possible by the earlier arrival of Cristóvão Cordeiro from CERN in 2017. Cris brought key knowledge in Docker and container technologies and led the charge towards the container native strategy we pivoted towards.

Edge is now everywhere, and I predict that as we come out of the current pandemic, we’ll realise that way more remote operations are required, to reduce dependencies on humans having to be everywhere to keep our world ticking. I make this argument (in French) in a short interview with Geneva based Radio Lac economics show (segments 1 and 2). I’m not sure what form it will take, but this is going to be fascinating to see, and hopefully it will enable humans to have more fulfilling activities and secured revenues. It might also give a clearer picture regarding what tasks are candidates to artificial intelligence (AI) or machine learning (ML), and what should remain a human task. I’m an optimistic and a bee lover, so I hope our climate and biodiversity will benefit from it as well.

During the 3rd year of my engineering studies at École Polytechnique in Montreal, I was selected for an exchange in France. I was fortunate to be able to do my degree thesis at Aérospatiale (now Airbus Defence and Space) on the Ariane 5 launcher. Comparing wind tunnel measurements, I discovered that the thermal protection system of the launcher was possibly undersized for the hypersonic phase of the flight. This was not only super exciting, it was also a race to verify this intuition. During the summer of 1993, while Aérospatiale staff where enjoying a well-deserved vacation, I had a mighty Cray II supercomputer pretty much to myself to crunch 3D computation fluid dynamics models. This was my first encounter with the full power of software, and I’ve never looked back.

Finding this single anomaly was not good enough. The French engineering culture there did not enjoy uncertainty. I was therefore asked to research a semi-empirical method to characterise my findings, such that future wind tunnel measurements could be extrapolated to improve thermal designs at super sonic and hyper sonic speeds (that’s where it heats up big time).

My findings were summarised in an AIAA publication and presented at the International Space Planes and Hypersonic Systems and Technologies Conferences in Chattanooga, Tennessee, USA. This was the first of a long series of public presentation and speeches I would give in my career. I hope I made my high school French and oral expression teacher, Christine Besson, proud.

This work would not have been possible without the amazing support and patience from my co-directors: Pascal Vincent and Frederic Jacquot, and many more in the aerodynamics and aerothermal teams at Aérospatiale. Thank you so much for managing to tame the energy of a wild and young French Canadian, just discovering the real world in all its wonders. You also gave me the self belief that given enough time and intensity, I could have a go at solving many hard problems.

I’ve since taken this lessen to the next level, where a well-performing team can, when given the right tools and empowerment, give the most challenging problem a real hard time.