Hi! My name is Cédric Vidal and I’ve been passionate about software since I got my first Macintosh SE in 1987, I was 7 and never stopped since. I’ve been designing numerous server architecture styles since my first monolith TCP server in 2001, searching for the right balance of agility and simplicity.
I started working with Quicksign first as a consultant then as its CTO in January 2014– that’s when I took on the challenge to migrate the current legacy application to a microservices platform. I had experimented various CQRS ideas on a few previous projects before coming up with our CQRS ES and BPMN microservices architecture. However, building at such a large scale within Quicksign was quite a ride!
Hi, my name is Nicolas Romanetti and I am a Software Engineer with more than 20 years of experience and I currently work as the Delivery Manager on QuickSign’s new platform which Cédric just described.
I remember pretty well the first time I created a “microservice”, it was in 1999 in Mountain View, the application I was working on at that time (Corba based ahaha) needed some kind of flexible external extension, I came up with a simple server/http/servlet “microservice” that the application could easily invoke. Ok it was rudimentary, but it was a blast!
We’ll talk about how building a microservices platform at scale is a great challenge. Before going for it, you should be aware of potential pitfalls, how to avoid them and whether it matches your business case.
We’ll share why the microservices approach was relevant for us, how we leveraged Kafka as the backbone of our architecture and BPMN as the heart to orchestrate our microservices and Kafka Streams to implement the CQRS-ES architectural pattern.
We believe these choices will lay the strongest foundation for QuickSign’s growth in the coming years, we’ll explain why & why it could be relevant for you.
Indeed, BPMN can be quite intimidating at first, but for QuickSign it made sense since we have the proper use cases and incentives :
BPMN has been traditionally integrated as a monolith and advocated as incompatible with microservices architectures but we believe the contrary: the BPMN engine can simply be used as a Saga pattern implementation. It contains long running state and orchestrates microservices.
We wanted BPMN to be fun and easy to work with on a daily basis, not just some irrealist architectural idealism. The tooling has changed a lot and modern products such as Camunda make BPMN pleasant to use. The ease of use of the modeler, the extensibility of the core engine, as well as the clarity of the source code (except for the core process virtual machine which is complex) and the excellent Spring integration made us feel right at home and confident that we would be able to commit to BPMN on the long run.
Yes, we’re looking forward to meeting passionate people! Feel free to come and discuss with us, we love questions & feedbacks. We also have interesting open positions at QuickSign in case what we do tickles your brain.
#quicksign #kafka #camunda
Twitter: https://twitter.com/cedricvidal
Linkedin: https://www.linkedin.com/in/cedricvidal
GitHub: https://github.com/cedricvidal
Twitter: https://twitter.com/nromanetti
LinkedIn: https://www.linkedin.com/in/nromanetti
GitHub: https://github.com/nromanetti
LinkedIn: https://www.linkedin.com/company/quicksign
Twitter: https://twitter.com/quicksign_sas