Bonjour la liste, Nous sommes à la recherche d'un DevOps pour nous aider à créer le premier établissement bancaire construit de zéro en France : https://trustbk.com/jobs/#releases-engineer L’entreprise a été créée par des anciens de Captain Train (désormais Trainline) où nous appliquons les mêmes principes fondateurs : nous mettons la technologie au service de l’humain, nous portons beaucoup d’attention au produit et au client, et nous aimons les projets européens. Notre ambition est de créer une banque de nouvelle génération, tournée vers les entreprises et créatrice de valeur : https://trustbk.com/ N'ayant pas de dette technique, nous avons eu la liberté de choisir des technologies adaptées à nos objectifs de sécurité et de mise à l’échelle : Architecture CQRS, Event Sourcing, Elixir (cœur transactionnel), Kotlin (back-end), React (front-end). Coté infrastructure, nous allons opter pour AWS et souhaitons respecter l’état de l’art du DevOps : intégration continue, outils de configuration serveur, Infrastructure as Code, gestion de versions… Nous avons d’ailleurs commencé à documenter nos différents choix sur notre blog : https://blog.trustbk.com/choosing-an-architecture-85750e1e5a03 Nous cherchons des personnes curieuses, humbles, positives et qui aiment apprendre et explorer de nouveaux territoires. Nous avons une vision très long terme et quelques principes que nous partageons sont expliquées ici https://trustbk.com/en/playbook/ Bonne journée, Michel --Michel GALIBERT +33661098518 Email -Linkedin
On 01/23/2018 09:00 AM, Michel Galibert wrote:
Bonjour la liste,
Nous sommes à la recherche d'un DevOps pour nous aider à créer le premier établissement bancaire construit de zéro en France : https://trustbk.com/jobs/#releases-engineer
L’entreprise a été créée par des anciens de Captain Train (désormais Trainline) où nous appliquons les mêmes principes fondateurs : nous mettons la technologie au service de l’humain, nous portons beaucoup d’attention au produit et au client, et nous aimons les projets européens. Notre ambition est de créer une banque de nouvelle génération, tournée vers les entreprises et créatrice de valeur : https://trustbk.com/
N'ayant pas de dette technique, nous avons eu la liberté de choisir des technologies adaptées à nos objectifs de sécurité et de mise à l’échelle : Architecture CQRS, Event Sourcing, Elixir (cœur transactionnel), Kotlin (back-end), React (front-end). Coté infrastructure, nous allons opter pour AWS et souhaitons respecter l’état de l’art du DevOps : intégration continue, outils de configuration serveur, Infrastructure as Code, gestion de versions… Nous avons d’ailleurs commencé à documenter nos différents choix sur notre blog : https://blog.trustbk.com/choosing-an-architecture-85750e1e5a03
Nous cherchons des personnes curieuses, humbles, positives et qui aiment apprendre et explorer de nouveaux territoires. Nous avons une vision très long terme et quelques principes que nous partageons sont expliquées ici https://trustbk.com/en/playbook/
Bonne journée,
Michel
-- *Michel GALIBERT* +33661098518 Email <mailto:michel.galibert@trustbk.com> - Linkedin <http://www.linkedin.com/in/michelgalibert>
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Par curiosité, pourquoi avoir choisi Kotlin pour le backend ? Jo
Pour répondre aux questions sur Kotlin, on avait formalisé ça sur notre documentation interne (en anglais). Je copie-colle ça ici : * Elixir relevant for the core thanks to high availability foundations, but has limited productivity for development at large: * Lack of maturity of IDEs, frameworks, libraries; Dynamic typing reduces code safety. * Kotlin vs Elixir * Access to the whole Java ecosystem: libraries, frameworks;Static typing and null value handling reduces runtime errors; Superior IDE support (IntelliJ): refactoring, static checking, debugging; Quick ramp up for Java developers * Matches our in-house competencies; * Facilitates hiring; Perennity: backed by Google and by JetBrains; can be reverted to Java in case of a catastrophe. Based on standard Java deployment vs. own VM Performances should not be an issue in the short/medium term for our B2B business. * Kotlin vs Java * Fixes many Java flaws: less verbose and more secure through type inference, data classes, null pointer security, additional syntactic constructs, etc Better functional programming support * Kotlin vs other modern statically typed languages with a rich ecosystem * Few contenders: Scala, maybe C#, which is for the MS world Scala integration with the Java ecosystem is less seamless than Kotlin; also, it is perceived as complex and less pragmatic by team members who have some exposure to both languages. Pour AWS, vu que le sujet est (très) clivant, je préfère ne pas lancer de troll. En revanche, vu qu'on a également documenté notre choix en interne, pas de souci pour partager ça avec des personnes potentiellement intéressées par le poste. Bonne journée, Michel On Tue, Jan 23, 2018 3:23 PM, Wallace wallace@morkitu.org wrote: Le 23/01/2018 à 09:00, Michel Galibert a écrit : Coté infrastructure, nous allons opter pour AWS Bon ben je pourrais jamais être client chez vous, dommage ça promettait d'être bien. --Michel GALIBERT +33661098518 Email -Linkedin
+1 De : FRsAG <frsag-bounces@frsag.org> au nom de Wallace <wallace@morkitu.org> Date : mardi 23 janvier 2018 à 15:24 À : <frsag@frsag.org> Objet : Re: [FRsAG] [JOBS] DevOps | Paris | TrustBK Le 23/01/2018 à 09:00, Michel Galibert a écrit : Coté infrastructure, nous allons opter pour AWS Bon ben je pourrais jamais être client chez vous, dommage ça promettait d'être bien. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
+1 Dommage. Je lorgnais sur TrustBK depuis son annonce. Le 23/01/2018 à 15:23, Wallace a écrit :
Le 23/01/2018 à 09:00, Michel Galibert a écrit :
Coté infrastructure, nous allons opter pour AWS
Bon ben je pourrais jamais être client chez vous, dommage ça promettait d'être bien.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (6)
-
Alain Bieuzent -
Arnaud Launay -
Bernard BELLE -
Jonathan Tremesaygues -
Michel Galibert -
Wallace