i wish my company was using Go for it's SOA instead of node.js. so much less overhead to run that neatly compiled binary than the dependency hell which is node.js. probably because node.js is hardly a language and almost every basic function needs to be imported from some third party, which also feels not so safe, as a sys admin. go is also easy to use.
> almost every basic function needs to be imported from some third party, which also feels not so safe, as a sys admin
Go (and most languages) also supports importing a lot of packages from third-parties. Just pin your dependencies to specific known versions and do hash verifications.
we use `govendor` to inline dependencies in tree; removes npm as a critical path when deploying, also means we can review dependency code changes like normal code changes.
I suspect the technological baggage in finance to be one of the main deterrents for young developers, the people who want to engineer modern, elegant systems and not go into the business of maintaining legacy spaghetti. I imagine you guys are attracting some really high end talent.
My questions are a little more about Monzo as a workplace in general as I will be applying for an internship with you guys.
Is there any Scala in your infrastructure? If not, was it a language that was given much consideration earlier on?
I see Kafka as part of your stack. Are stream processing frameworks like Samza, Spark and Flink found in your infrastructure?
How many developers? What would you estimate the backend/frontend split to be at?
Most of the other banks are too ashamed to publish their tech stack. After all, it's kind of hard to attract 25-30 year olds with technologies that had their last major updates before the candidates were born :p
Hi there, I scrolled through the video and also read the blog post describing your stack and couldn't find anything about your data modeling and persistence layer. To me that is the most interesting part since you are a bank but at the same time you are using a micro service based architecture. Is there any information available about what database you use and how you manage your data?
We store the vast majority of our data in Cassandra, which gives us tuneable consistency and high availability given its master-less architecture. Those properties suit the rest of our architecture perfectly, though there are of course trade offs involved. Each service then has its own keyspace and is unable to access the data of other services.
I'd be much more interested in understanding how you managed to handle banking level transaction on a non rdbms system like cassandra, than how you coded some logic in go.
Thanks for the talk Matt. Lots of really good detail there. Working with both Go/Java and Microservices.
One question I have is how critical is linkerd to having a dependable microservice mesh? Another question is what did you use for async services?
You're welcome! In our case linkerd is critical to this, as we've offloaded load balancing, circuit breaking, and retry policies etc to linkerd. If we hadn't then we would need to implement this functionality in multiple languages (though we mainly use go) and keep these in sync as we developed our platform, which from my experience is quite difficult. Using linkerd largely removes this from us, meaning we have a well tested method of inter-service RPCs, and we get free feature development ;) For async processing we're using Kafka, which powers the majority of our event sourced architecture.
For some reason https://monzo.com/ crashes in both Chrome and Firefox before the pages loads on my linux desktop machine. Never seen anything like that before...
I play AV Geek sometimes; I think I first saw Defcon do this, only within the video. I've been trying this out, partially for laziness; it's much quicker to edit the video if you don't have to transition from the speaker to the slides.
I always dream of something that would make easier for foreigners to open an US bank account, I now people that went to the US as tourist and could open an account there, but there's no way to do that via internet without actually visiting a branch in person. Don't seems to be so difficult is it? Seems very much its just a internal political thing.
Not that I'm against learning new languages, but your question piqued my interest.
Are you thinking about transitioning from C# to Go? If so, is it because you think the language is cool or is it because in your region there are more/better paying Go jobs?
I ask this because I can't really imagine someone transitioning from C# to Go, especially these days that dotnet core is available. Hell, I'd first try to transition to F# :)
(Yes, I know that these are loaded questions and that I'm biased against Go..., but I think the questions are valid even in these conditions)
I'm still a "recent" grad, so my answer might be a bit strange.
I've been doing full time C# for almost 2 years now, and while I enjoy it one of my biggest fears is getting stuck into only knowing one technology/stack.
I don't have a professional need for using Go currently, but I've always had an interest in learning new languages.
Aside from those aspects - the people who implemented and worked on Go (Rob Pike and Ken Thompson in particular) I find very interesting.
If I'd want to diversify I'd probably look away from another Algol-inspired language. That's why I mentioned F#.
Go is an extremely practical language, maybe too practical, almost like C#. I'd rather look at something which takes a different approach, something which includes programming language research from the 90s, at least :)
As an aside, i love Go, and use it fulltime at work. With that said, i agree with the view that Go is boring, and not likely to expand you in the way you seek.
It's usually less rails oriented than C#, so you will figure out a lot of stuff for yourself, but in general it's quite boring (i like that). If you're interested in something interesting, i am in love with Rust, and definitely recommend it.
I don't personally use it these days, as i am not sure i want to invest in the tradeoff of safety vs prototyping speed. However i definitely recommend it as a cool language.
I'd say tour.golang.org is quite good. But the most important thing I feel for C# devs is to know that there is no Visual Studio like fancy IDE for Go.
People may be debate merits/demerits of this situation with valid arguments. However if you are in everything IDE camp Go might just not suit you.
Visual Studio Code is a free text-only "IDE" with very good support for Go (as well as other things like C#, TypeScript etc etc etc). Autocomplete/Intellisense, peek-/goto-definition, error-highlighting, git-integration, visual debugger, tabs, mini-map, extensions etc etc. Not sure what else you need really? Sure there is no GUI-builder, but then GUI in golang is in a very early stage.
I use it a lot for my work (Linux & Mac OSX) and personally at home too (Win10). I am not in any way connected to VS Code or MS, but I think it is a really good editor both for Go, but also for all of the other stuff it supports.
As a Java guy who has dabbled in Golang and I have had good luck with VSCode IDE + command line for compilation/build options. If you're in Windows, get Git Bash or similar for a unixy command line.
tour.golang.org is a good start to get familiar with the language's features. After that it is just worth picking a mini-project and getting cracking. The website https://gobyexample.com/ is a great place to see some simple, real-world examples once you start to actually try and do something.
There will be a lot that is familiar to a C#/Java dev, but also a lot of the stuff you might have got familiar with in C# is missing (famously generics are not there, but also other things like Linq etc has no native equivalent in go, although there are libraries that offer similar functionality).
Picking a mini-project (without completely re-inventing the wheel) was the harder part for me - I did start out with tour.golang.org, and just reading their docs too.
Golang is really, really easy to learn. And as always the key is practicing. Just pick up some medium size project and start building it. Stack overflow will help with the learning curve. This is how I learned to love Golang having 10+ years c# background​.
What sort of mini-projects have you done thus far?
That's the biggest hurdle I've been trying to overcome currently with learning Go (or any new language). Other than re-writing small problems, but that isn't terribly exciting.
He didn't talk much about this, but I find it very hard to believe that they were able to make their own deposit application and get it certified for use (unless the UK has vastly different banking regulations than the US). 32-bit/64-bit systems have small rounding errors that are show-stoppers for banking from what I've heard. There is a reason why COBOL and Big Iron rain supreme in Finance.
I don't really understand why you pick on 32-bit/64-bit. I assume you wouldn't touch floating point with banking. What is it you think Cobol and big iron can do that Go and AWS can't?
I'm the Head of Engineering at Monzo. We don't use floating point at all in our core banking systems, which are all written in Go by our own engineering team :)
That is typically how you handle it (in my limited understanding). If you're going to make an error, let it be in the presentation layer and not the actual math.
Warning: I don't program applications for finance. However... I'm not sure that representing things in cents works. Mostly because of exchange rates. These can have quite a bit of decimals and go beyond cent-precision.
I now wonder if that is what c# does under the hood for currency type which is a rather safe way of dealing with a limited number of decimal places for money. Hm.
Any chance you could go into detail on this regarding data types? How do you handle exchange rates & such that can be to more precision than 100ths of a $ or other currency for instance?
I don't know how it works under the hood but when I use Monzo for Euro payments the conversion is shown in cents - they probably round it and pocket the difference. But the actual rate is very good, interbank rates