I'm very versatile, so if you're looking for somebody to work with, we can talk. I have my hands in a number of things in the very early stages right now, but me good at multi-tasking.
I don't think I'm convinced. But maybe I'm missing something ?
You can't go on assuming user base won't grow. Also massive is not a quantifiable amount. There are certain thresholds that require the application to scale, and those depend on the functionality expected. If I hash passwords, but I can only hash 100 at once. If I offer integration API's that get hit more often than my actual site. Will I need to scale my monolith app for those specific cases?
To say that a large application let's you focus on just dev work is a bald statement in my opinion. A large application is harder to test, harder to deploy, changes have a higher risk, risk of data leaking by mistake, very coupled, and not simple -> harder to design for -> harder to move stack. Just on boarding an engineer into a monolith app from my experience is hard..
I'm not sure how with micro services you're worried about the processes? I lost you there..
I have a quick script that spits out a microservice with basic health endpoint. I made a communication module that uses sockets and parent as a bus to communicate through.
A bank offers some sort of signin application, statement generating (sent to email), some api's for payroll, and maybe an integration with a credit card where it notifies customers about any purchases made. When sign in is down, it doesn't mean you shouldn't get alerts about CC purchases, or that reports shouldn't be generated. Even when you're signed it's possible certain feature might not be active. With a mono if a bug took down the application every service you offer is down. --- This scenario is very much around the kind of service we want to provide.
The number of developers today who assume their user base will grow, and optimise for that, when it's not required, far exceeds the number who assume their user base won't grow, and have growing pains because of it.
> If I hash passwords, but I can only hash 100 at once
What do you mean if? Why would you ever not hash passwords?
Also, this is exactly what horizontal scaling is for, which you need to deal with regardless of whether you're using micro services or not.
> A bank offers some
first off - you're still comparing yourself to a massively different field. If you are working for a bank, you shouldn't be asking for this type of advice, unless you've lied to them about your skills.
secondly - those things you described are all different applications within a bank. There may be some integration but more likely the common point for them all is a massive mainframe system that they all interact with. That is not micro services.
> The number of developers today who assume their user base will grow, and optimise for that, when it's not required, far exceeds the number who assume their user base won't grow, and have growing pains because of it.
I think discussing this point is useless. For the same of the argument assume we are.
> Also, this is exactly what horizontal scaling is for, which you need to deal with regardless of whether you're using micro services or not.
I give you that. You can. I don't think it's a correct approach, but you can def just scale once you hit your smallest bottlenecks and you'll be fine (I think).
>first off - you're still comparing yourself to a massively different field. If you are working for a bank, you shouldn't be asking for this type of advice, unless you've lied to them about your skills.
>secondly - those things you described are all different applications within a bank. There may be some integration but more likely the common point for them all is a massive mainframe system that they all interact with. That is not micro services.
I'm confused. How do you know which field I'm working in? I am comparing us to a bank because like I said, the services we offer are very similar. I shouldn't be asking for advice? That's plain ignorant. I am asking for the advice because I am a strong believer in micro services but I figured I'd rather ask people for their opinion to see what I get without the title giving away my thoughts. I doubt you would have clicked this thread if what you read was an opinionated title saying "Micro services are the only way" at least I wouldn't. I'd assume that persons mind won't change. Instead I wanted to get as much feedback as possible (including yours :) ).
While the banking world moves slow, and tends to make up new terms for anything they do to make them sound cooler. The newer core banking systems (check out cloud banking, micro service banking) are usually composed of smaller services that communicate through some buss and managed through one uniform API. I'm pretty sure that's along the lines of micro services or at the very least more micro than mono! -- When I say new I mean within the last 10-15 years. I worked at Citigroup and they had that structure implemented on so many of their products.
You're asking for technical advice for a financial platform, on HN, watering hole for flavour of the week, cargo culting, me-too cool kids who change software stacks, libraries and development methodologies more often than they change their underwear.
That is why I said you shouldn't be asking for advice here, if you're working on a banking like platform.
It's like a brain surgeon going to ~~~webmd.com~~~ reddit.
As for the bit about horizontal scaling: if you have a limit like # of hashes per second you can generate, microservices isn't going to solve that - whatever is running your password checking code has that bottleneck, and the answer is either (to a point) faster cpu's, or more frequently and eventually inevitable at scale, distributing the workload. That means multiple servers running the same code to handle more clients - aka horizontal scaling. That's unrelated to whether it's monolithic or microservices based.
My initial response to the team when I heard the proposal was that programming is an art form. There is a beauty how software is organized and orchestrated.
Given that the microservices do very different things, combining them together will do nothing but clutter a the code base. JS gives an excellent module system which allows for maximum code reuse. That should be emphasized. But combining 6 code bases together into a project that is planning to expand extensively over the next year makes little to no sense at least to me.
Depends on how advanced you want your routing to be I can see going with the from scratch rout, but that means you'll need to spend time writing unit tests..
You might as well fork and delete/modify a bunch of code.
I just moved back here from NYC. I was working in automated trading. You want to apply to 2sigma and bridgewater. They value smarts over experience. You can also work for Chase, Citi Group, Citi Bank, CapitalOne.
If you wanna become a quant, or do anything related to actual decision making of when a purchase order is processed or when it's dropped. You'll need at least a masters in Mathematics or Engineering, and be fluent in C/C++ for finance.
I will tell you right away. As a developer even if you knew your stuff you'll always be a developer. When shit hits the fan you'll be the first out the door.
Lastly, you need to learn the language. You'll need to know all these terms that many will refuse to explain to you because that's what earns them value. Our director of engineering used to always say the only reason he still has the job is because he understand the language.
-- I worked at Citi Group.
Overall I hated nyc. I lived my whole life in California. Didn't have to wear dress cloths to work, didn't have to be at work at 7:30-8 am sharp, but the money was great.
All good points from swtf: especially on C++ and masters level maths. I'd add Python too; hopefully you've already had some contact with that as a web dev. Back in 2007 I was building automated rates market making systems in Python. Another big factor is market timing. Businesses that earn their revenue from trading financial instruments tend to have volatile earnings. Compare the year by year earnings of the investment bank at JP Morgan Chase vs the retail bank, credit card biz etc. So trading businesses have volatile earnings, but they also have high costs, and the main cost component is staff compensation. Which accounts for the hire and fire nature of the business. Times are tough currently, with HFT firms consolidating in the face of falling returns, and many large banks struggling too in the face of low interest rates and returns. There's a reason so much cash has crowded into VC; because there are few returns elsewhere. The last real hiring upswing was 2010, when the QE cash hit. In the big banks regulation and compliance are the only growth areas. Very boring work! So I suggest building your C++, Python, maths skillsbase, and waiting for the next hiring upswing. Trump & Brexit are bringing market volatility back, interest rates look likely to go up, maybe that will help trading businesses and we'll get a new growth cycle in financial markets.
I would add that the only other real market related finance jobs (that I know of) are in Chicago. There is a large commodity and futures market there as well as the Chicago Board of Trade. I worked at a clearing company there and it was really interesting and enjoyable. There are a bunch of prop trading firms here as well as execution services (which are interesting in their own right) and clearing firms.
Edit: I would note that there is a lot of C# work in the financial markets in Chicago. There is the C++ high performance stuff but there is also high performance C# as well as just plain ol' "normal" C# work.
This is something that also interests me, as a web developer with a mostly LAMP background. I live in Chicago and getting tired of just doing web dev for small business clients. I have hobby experience with C# (3+ years, built several native apps).
I'd like to know how to break into the trading industry in Chicago with this background. So far I've been rejected to every C# job I've applied to and I cannot try C# at my job as I'm currently unemployed.
I'm not looking to do high frequency trading algorithms (seems well beyond my scope), but I'd be open to writing finance-related tools that aren't performance intensive, if that makes any sense.
