[jhuckestein]

I work at Monzo.

I agree that using microservices and kubernetes is not what allows us to provide a good user experience. We could provide the same user experience if we had built everything on rails and postgres. In fact, that would have been much easier.

The reason we are investing so heavily in a rock solid platform is that we want to still be able to offer the best possible user experience in 10 years time. This is what we mean when we say we want the platform to be "extensible".

Many large banks IT systems are not extensible, in the sense that it is very expensive to make changes. Take, for example, the ability to freeze a card in the app at the tap of a button. A friend at RBS told me that they considered this feature many times, but it took a long time to work out which 20 IT systems would need changing and some of them had been under change freeze for a few years. So eventually the idea was discarded as too expensive.

The freeze card feature would be easy to implement for a startup, regardless of their stack. The key is to still be able to implement such a feature easily in 10 years time :)

[raesene6]

Interesting, although I'd suggest that the problems for RBS in implementing such a system are more a reflection of the complexity and age of their systems than than technology used.

I'm interested that you say you were looking for "rock solid" when you're using what is a pretty new stack. CoreOS and Kubernetes are very new products, innovative, exciting yes, seems early days to describe them as "rock solid".

Out of curiousity did you consider using a more conservative stack (e.g. ASP.NET ?)

[mstade]

> Interesting, although I'd suggest that the problems for RBS in implementing such a system are more a reflection of the complexity and age of their systems than than technology used.

And I'd suggest you're wrong. Neither complexity or age of a system is usually the issue. In fact, I'd say technology is almost never the real issue, but rather organizational red tape. Those owning the various systems often operate as more or less autonomous entities, largely with their own change policies and process, and I'd be willing to bet this will be a bigger hurdle than anything technical. Also, there will be a fair bit of politics involved.

Perhaps a small outfit as monzo can move fast and be nimble now, but if you reach the point where you have multiple system owners you will inevitably run into these problems, and they have almost nothing to do with technology. FUD, often fueled by compliance requirements (whether actual legal compliance or perceived such) also plays a large part.

For me personally, I sometimes wish the red tape would just go away, and at other times I'm glad it's there to save us from some of the madness I've seen people try to get deployed.

Source: I have worked with and in top tier financial institutions for about half a decade at this point, including RBS.

[raesene6]

Interesting perspective, I too have worked with large financial institutions (for 15 years if that matters) including RBS :)

Organisational red-tape is obviously part of the problem but that's part of what I meant by complexity. Change in large FS companies comes slowly because of their size and complexity both organisationally and technologically.

Once you get a complex network setup and a load of systems that aren't designed to work together (which tends to happen over time as technologies shift) implementing new layers across the top of them takes time.

One of the problems with changing existing systems is that impact to production is something which has to be avoided, so changes to those systems have to be planned carefully. Now it's arguable that some organisations take that too far, but it's not fair (I think) to suggest that all of the change controls in place in those companies are "FUD".

[mstade]

I don't think I suggested that all change controls amount to FUD, certainly I didn't mean to anyway. What I did say was that it plays a large part, which is evident in how little many of the decision makers actually know about what a change is, what it means, and what repercussions it might have, so it's easier to err on the side of caution. The answer, of course, is to do more research, but that's more expensive and harder than to just say "no."

My experience is that whatever technical issues may arise really aren't that big of a deal, provided you do the proper research to realize what a change to the system actually means. Significant effort, perhaps, but not particularly difficult from a purely technical standpoint. But it usually means coordinating with different parts of the organization, which can be excruciating, and more often than not has little to do with technological aspects and more with territorial politics and process. That's not necessarily a bad thing, like I said I've seen it stop some really horrid stuff make it into production, but it can also introduce so much friction that you give up before even having started.

I don't rightly know where the balance lies. For a small outfit like monzo it makes sense to be nimble, but for a huge organizations like RBS, UBS, JPM, HSBC etc., there are so many things at play that being conservative isn't necessarily a bad thing. Plenty more degrees in this hell than people generally believe there is, that's for sure.

[fixxer]

I'm sure you mean well. You need to pare back the jargon and focus these blog posts on user experience, IMO. As an engineer dealing with all the usual bullshit from higher ups that learned a new buzzword and have to have it right now (even though it doesn't do what they think it does...), an article like this is always going to get a response like mine. And on this forum, I'm not alone.

[sirgiganticus]

I'm sorry you have issues communicating with your higher ups. However this particular post is written by the Head of Engineering at Monzo, who is the higher up, and seems to be aware of the implications and design decisions, as well as downsides and pitfalls.

I'd also wonder if a post marked "Technology" with a title that includes "Backend" really needs to pare down the jargon and focus on the user experience as opposed to say, this one https://monzo.com/blog/2016/08/08/updated-design/ , which has minimal jargon. Also when talking about architectural decisions across an entire platform, you're going to have to mention a lot of different technologies.

Finally, to quote you: "an article like this is always going to get a response like mine" == "it's not actually my fault, the post made me do it" - it's not an acceptable excuse.

[fixxer]

Lol. Loading up a blog article with tech buzz is a huge red flag to me that the CTO doesn't know as much as you might think. And no, I don't have a problem communicating with my higher ups: I just have had enough time in industry from startups to Fortune 500s to understand how decisions are made.

EDIT: I'm guessing you work there. You disagree with me; that is fine (many do). But... How quick did this fall off the front page?! From that alone, I'd claim my negativity is more representative of the readers that post was trying to target. I'm sure your company is trying to do something awesome, but you're not going to win hearts and minds with tech fodder like that.