echopom

> my product has a combination of Angular, React, Vue and server-rendered pages.

This is intended by Micro Front.

Most Billions Dollars SaaS are based on this Frankenstein type of architecture, the goal is simple :

- Support legacy code with Zero Effort

The result for the end user is absolutely horrendous , it create slow and bloated web pages with Megabytes of JavaScript with UI of various style and behavior similar to Confluence/ Jira etc...

This architecture fits perfectly fit the state of the current market :

- Push lots of stuff out "as fast as possible"

- Turn over in software in +20%, people who build Jira 5 years ago aren't there anymore , they cashed in their stocks and went somewhere else to get a bigger paycheck

- The people who build those apps , most of the time , don't use them...

Leaders of Atlassian use Gmail and GDrive , I'm pretty confident that they don't even use Jira or any of their own software...

Those apps are so slow and bloated it's astonishing...Yet when something is the "norm" in the industry , it's definitely not an issue.

> Isn't that's because of SOX compliance requirements?

Bank always had very strict rules , SOX just force them to formalize those rules/process.

Per say , prior to SOX they would not conceal the review of the logs , now with SOX they will will edit a PDF that say "We have review logs for Apps X and consider no suspicious activity had occur".

Apart from that , things didn't change much.

>Access to pre-production should be limited.

Banks have extremely strict rules when it comes to system "access".

When it comes to "System Design" they have very little.

This are two separates topic.

> In less than 5 years there will be an EU directive on how financial institutions need to have immutable db architectures with full provenance.

I'm a former Entreprise Architect from Banking Sector in Europe.

To be clear , this will never happen.

There has never been any directive that has had a "concrete" impact on IT Architecture of Financial Institutions.

Yet there has been dozens of regulations that urged banks to "simplify" their IT Systems.

90% of IT Staff are Baby Boomers with no background in Systems Design or Architecture , thus when new regulation comes in it follow this scenario 100% of the time :

- Find a vendor that sell a software that promise compliance with new regulation

- Find an integrator that promise integrations within the deadline

- Integrate the vendors software in Banks legacy stack of 3000+ monolithic apps

- Send report to regulator saying they have "redesigned" their architecture and made "investment" in order to take in account and that new regulation

Best examples of this is "PSD2" which has been the biggest fiasco of the industry , has of the last year only 18% of banks complied with the regulation.

France and UK said they would not "fine" anyone, because banks "aren't ready" and made "considerable" investment in it.

Regardless of what HN thinks , you won't solve Financial Institutions Multi Decade Legacy with a single Directive that would suddenly force them to use "ImMuTABLe Db ARChITectuRES"

It Directives have never worked and will never work.

The only way to enforce anything would be to remove their IT systems completely and have them use APIs provided by the regulators , and have the regulator become the sole provider of "Financial System".

They wont let that happen.

This was an extremely interesting read.

I'm quiet disappointed though they did not update their Go Version to 1.13[0][1] which would normally have remove the spike issue and thus he latency before they move to Rust...

Rust seems more performant with proper usage ( tokio + async ) but I'm more worried about the ecosystem that doesn't seem has mature has Go.

We could quote the recent[2] Drama with Actix...

[0]https://golang.org/doc/go1.13#runtime [1]https://golang.org/doc/go1.12#runtime [2]https://github.com/fafhrd91/actix-web-postmortem

>There don’t seem to be many appropriate dating spaces for the LGBTQ+ community in the physical world...

>I wish there were spaces that didn’t necessitate drinking, where you could meet people in this arena.

Not sure to understand clearly.

Honestly you can go a to a bar and order a Dr.Pepper there is nothing that's going to stop you from doing that... I'm not sure to understand entirely there are many gay bars / nightclubs everywhere I'm sure most of them are appropriate spaces to flirt or engage with other people...

> Why Does Developing on Kubernetes Suck ?

IMHO because we are in a phase of transition.

Having worked for years in software industry , I'm convinced we are halfway to a much bigger transformation for Software Engineers / SRE , Developers etc...

I work in a Neobank ( N26 , Revolut, etc...) , we are currently in the process of re-writing our entire Core Banking System with MicroServices on top of Kubernetes with Kafka.

Not a single day pass without having engineers needing to have an exchange about defining basically all of the the terms that exist within the K8/Docker/Kafa world.

- What's a Pod ? How does a pod behave if Kafa goes down ? Do we really need ZooKeeper etc....

Their workflows is insanely complex and requires hours if not a day to deploy a single change... obviously let's not even talk about the amount of work our SRE has in the pipe to "package" the entire stack of 150+ services in K8 through a single YAML file....

I'm sure this complexity is temporary. One tech will automate all of this away and building , deploying and running will be much simpler. In it's current shape , K8 remains me of mainframe ecosystem I used to deal with at brick & mortars banks.

Powerful systems , but they requires a tremendous amount of work and experts to be properly managed and take full advantage of it. Just like mainframes , K8 leaves very little room for "mistakes" or "approximation".

This is really great content by A16Z.

It shows how complex building a Fintech in US actually is , often due to how many different partners you will actually need to depend on.

In this specific case , you would need to have each partners offer an API that you could call to automate the mortgage workflow.

Obviously , due to the nature of the financial sector it's very likely those partners don't have those APIs and don't want to build them because they are sitting on a very profitable business and have no plan to change that anytime soon.

I can draw a comparison to Airbnb , where most of their jobs wasn't so much to build "disruptive tech" but to lobby local administration to let people rent their appartement to individuals , while hotel industry was lobbying the other way around.

It becomes even more complex when you realize you'll have to do this at global scale to build a unicorn.

> The video is very American centric

Honestly I'm very happy this video was "American Centric" mortgage are by definition very complex and specific to each country but America has one the most complex financial and legal system on earth.

Absolutely terrifying.

If you add this to the model that guesses identity based on the sound produced by inputs (keyboard , mouse...) you basically end up with an "ambiant sound fingerprinting" tech , where the sounds emitted nearby a device can be used to accurately determine the individual that's standing close to it...

If you add this to china's facial recognition , it scares me to think how "Gattaguesque" our societies are turning thanks to Machine Learning and Big Data...

It fascinating that in 2019 we aren't able to get one text editor that would work seamlessly across all frameworks , but instead need to basically re-write huge "bindings" to support the reactivity and the rendering logic in each of them.

Web Components have definitely failed.

>Huawei's microchip vulnerability explained

This article does not explain a single thing about why those chips are vulnerable.

It just enumerate some of the components within it.

Those clikbait titles for ad-revenue are becoming a real issue...

> What is the recommended course of action? Stop buying Intel products, and devices which contain them?

There is absolutely nothing to be done on our level about this.

I'm fairly convinced this is systemic issue that can only be solved by redesigning almost entirely modern cpus and computers architecture.

I can draw a parallel to approximately all Intel cpus which are know to have a dedicated "mini cpu" called "Minix" which is an absolute "black box" and have been found to be vulnerable for to a wide variety of attack for nearly decades...

Not only we need to redesign computers and cpu architecture but we desperately need to make that entire process and knowledge open source , available to all and more transparent.

Today this entire knowledge is the hand of few gigantic corps whom are keeping it to ensure their monopolistic position.

I didn't a find a single argument about why the seniors engineers I used to work with in some of the largest European bank would move away from Java to Go.

Those engineers are already hostile to just changing naming conventions or "trying" Kotlin instead or Java and now you want them to use Go ?

Most seniors developers working in Fortune 500 learned one major framework like Spring , GWT or JSF and are generally sticking to it for everything.

They have absolutely no valid reason to move away from those frameworks because they are slowly approaching the late part of their career where they are eligible to become Manager. Managers in those institutions also have very little incentives to promote a new technology like Go because it would introduce major risk in their projects or dealing with developers hostile to change.

I can naturally draw a parallel to Airbnb React Native Fiasco where their mobile engineers wrote platform specific code on each platform because they didn't like JavaScript.

Go is becoming Node.JS not the new Java , JavaScript is now the new Java , and Java is the new Cobol.

It'll take half a decade for Go to truly penetrate all the institutions in the same way Node.JS did ( Enterprise , Schools , Bootcamps etc...) and be considered as a mainstream language like Python.

But even then , I doubt Go would replace Java. Java is here to stay the same way Cobol is staying.

> how I can build a minimal app that works on all those platforms

That's perfectly normal.

There is no such thing as "Cross Platform .NET"

The C# language and the.NET Framework does indeed run on almost all platforms, but that pretty much ends here in terms of "portability".

Anything beyond that is "platform specific"

For instance, building "desktop" applications is either UWP with advanced styling and reactive data binding but only for Windows or GTK# with Mono which is very limited.

For Mobile either Xamarins.Forms for Android + iOS but it's very limited in terms of features, or it's Xamarin.iOS + Xamarin.Android which require platform specific code for UI / Routing and many others OS specific functions.

For Web , the WASM Binary is something like 5MB+ which makes it not reasonable compared to an app written in Plain JavaScript or TypeScript.

There is still a long way to go for C# to be really "cross platform"