I find the simplicity of the stack brilliant. It makes me to think now, to which extent, the industry nowadays simply suffers from a mix of lack of knowledge, CV driving design and big players in the game trying to sell you overkilling solutions and approaches for their own economical benefit. Have we perhaps, fell into a big enchant and, at the end of the day, 99% of companies out there could just use a classic LAMPish kinda stack managed by 3 or 4 dudes?
How Instagram scaled to 14 million users with only 3 engineers
81–90 of 202 posts
Re: How Instagram scaled to 14 million users with only 3 engineers
#82Earlier quoted context omitted.
That's why it's important to keep the number of devs low, it makes it less likely that one starts talking about microservices.
We use the microservices architecture as a single team and don’t have any issues with this for many years. The key is to have a monorepo and stay consistent by following strict coding guidelines. In my opinion it makes the backend way more resilient than a monolith. Don’t kill me for this opinion please ;)
How does it make the backend more resilient than a monolith? Do you not realize you have multiple instances of a monolith or something?
Re: How Instagram scaled to 14 million users with only 3 engineers
#83I'm more interested in how they got 14 million users with only 4-5 people. what marketing tactics did they use? I assume those should be milked to death by now.
Luck.
Re: How Instagram scaled to 14 million users with only 3 engineers
#84"When you choose the right people you'll need only a few. When you don't, you'll need them all"
I think this idea hurts the industry. Don't get me wrong. I think it is important to hire the right people, but if you don't hire enough people this 3 man job is 80-100 hours a week per for months to years. Look how X has diminished in quality as Elon started slashing team sizes. Then when you design more features, security and other various systems to serve the customers it will creep in complexity. You can not esca…
> Look how X has diminished in quality as Elon started slashing team sizes.
Has it? I've had the exact same experience.
Re: How Instagram scaled to 14 million users with only 3 engineers
#8514 million doing not so complex things is an easy achievement. When you get into a lot of microservices providing tons of features your teams will balloon.
Honest question: what justifies microservices in the popular companies compared to instagram?
Twitter: just sharing a bunch of text.
Netflix: platform with static content, where sharing isn't even possible.
TikToķ: Instagram for video, so basically just bigger files.
WhatsApp: they also pulled it off with a small team.
If you talk about Roblox, now there's a challenge! And they pulled it off with way less engineers than Twitter.
Re: How Instagram scaled to 14 million users with only 3 engineers
#8614 million doing not so complex things is an easy achievement. When you get into a lot of microservices providing tons of features your teams will balloon.
That's why it's important to keep the number of devs low, it makes it less likely that one starts talking about microservices.
In two decades of development I've never once seen a monolithic architecture that with some form of shared database not be terrible for the business it powered. I certainly understand why it's very common, it's what's still being taught to most CS students in my country after all, and, it's frankly a lot easier to implement. The result, however, is always the same. It ends up being a mess where nobody can do anything because the data structures are so intertwined (and undocumented) that nobody knows how it's actually used. What happens is that monoliths become magnets for business logic, and then you bottleneck every change into requireing a select few members of your organisation. As time goes by, you end up with a giant turd that stagnates and directly hurts your business. Not by intention, but because that's exactly what happens when you make things complicated.
It's important to keep in mind that this isn't a technical problem. It's an organisational problem. In fact, there is no technical reason why monoliths would be an anti-pattern, which is likely why they are still being taught as though they weren't at many universities where professors still naively think that the MBA's aren't going to cost-cut IT at every opportunity even though their entire organisation is made up of employees who spend 100% of their working time on IT devices of some form. Similarily, Microservices, aren't really the "technical" response to this. It's how IT and digitalisation had to evolve to keep up with business demands and better generate value. The simpler and more decoupled you keep things, the better you'll be able to respond to business needs. Sure, there are a gazillion different ways to do Microservices wrong, and if you do it wrong, then you'll likely be in the same mess that you would be with a monolith, only so much worse, because now you have 9 million tiny monoliths and shared databases.
Luckily we still live in a world where everyone is somehow still OK with IT not working. We went to an appointment that isn't relevant the other day, and they had a tablet where you could register your license plate to avoid getting a parking ticket. It didn't work, so we talked with the receptionist who was like "yeah, it does that all the time, don't worry, if the systems are down then they can't give out tickets"... Fine for us, but think about that... It turned out the system was down in my entire city, which means that all those hundreds of employees who are out handing out tickets had nothing to do while their IT system was being fixed, hell, the entire company wasn't generating income for my city while their IT was down, and this was a regular occurrence? What my point with this is, is that you can do things really wrong, and still be a "successful" company, it's just that the companies who manage to generate value better (which is frankly always microservices of some form) tend to simply do better. But like I said. You can do "microservices" in a million different ways. Running two different django backends to handle different parts of Instagram could be considered having two microservices after all. The importance is how you deal with the needs of your organisaiton in a rapid fashion.
Re: How Instagram scaled to 14 million users with only 3 engineers
#87> we can assume that Instagram was written using Objective-C and a combination of other things like UIKit. How can they know the internal infrastructure but have to assume the app language? Edit: So the entire piece is taken almost verbatim as-is from a couple old articles on instagram engineering blog. It might as well just redirect to: https://instagram-engineering.com/what-powers-instagram-hund... This is against…
It IS an original source. It's not just a repost or a report on another older article. It's a reworking of those articles.
Re: How Instagram scaled to 14 million users with only 3 engineers
#88Earlier quoted context omitted.
They had a different person/team working on the front end and/or they don't remember?
[flagged]
Enough with the "rules" just because you don't find it novel enough.
The author is on HN and says "Just my own brain reading through old talks and articles from Instagram engineering and Excalidraw for the diagrams. I did my best to put together all the info I learned from them into a comprehensive and simple manner".
You can take it with them.
Re: How Instagram scaled to 14 million users with only 3 engineers
#89Earlier quoted context omitted.
[flagged]
Not OP. No anger in his words. Please don't make OP feel inadequate for expressing themselves clearly.
They sure seem bothered a lot by something trivial (god forbid the post which was NOT made for HN anyway quoted some original sources and didn't go into the detail they'd like it to).
Somebody took the effort of compiling an article on several sources, and we're throwing the rulebook on them.
Re: How Instagram scaled to 14 million users with only 3 engineers
#90"When you choose the right people you'll need only a few. When you don't, you'll need them all"
I think this idea hurts the industry. Don't get me wrong. I think it is important to hire the right people, but if you don't hire enough people this 3 man job is 80-100 hours a week per for months to years. Look how X has diminished in quality as Elon started slashing team sizes. Then when you design more features, security and other various systems to serve the customers it will creep in complexity. You can not esca…
>Look how X has diminished in quality
Ideologically or from a service perspective? I don't see any noticable drop in the latter. Some disruption is expected as huge parts of the team is fired/leaves, but I see it going on in business as usual otherwise.