9 ms·
Meta used monolithic architecture to ship Threads in only five months
- seydor 2y ago> , that integrates with an older PHP component called WWW.
- spaniard89277 2y agoAnother article on don't go micro services and don't reinvent the wheel. I wonder if most solutions could be implemented on top of Laravel/Django/Adonisjs without too much effort.
- gigatexal 2y agoYup. The logistics startup I joined nearly 7 years ago should have done the same. A single VM of say 4 cores and 8 gigs of memory and about 100G of disk would have been plenty for our proposed PoC and it should have run as a monolith. That’s what I would do had I to do it again. Instead what we did was what I call HN driven development: k8s, microservices, cloud. 7 or so months after I joined and on my way out we had nothing to show for it except for a really strong and capable front end dev who was basically faking functionality to appease investors because we the backend folks were so incompetent. (Man I sure have come a long way from those days. I was dumber then. I’m still dumb now — just not as much.)
- throwaway2990 2y agoHN driven development! It’s so true.
- plugin-baby 2y ago> what I call HN driven development: k8s, microservices, cloud I’ll give you cloud, but my takeaways from HN in the last few years have been things like: * Postgres is a reasonable choice for a job queue * SQLite is a valid choice for server db at quite large scale * k8s makes sense once you have 50+ devs * microservices address issues of team scale, not traffic scale
- plugin-baby 2y ago+ https://boringtechnology.club/ https://boringtechnology.club/
- gigatexal 2y agoBack in 2017 I think k8s was all the rage and all of us were reading it on HN I think. But what I, too, have seen is a greater emphasis on the boring, simple tools here on HN and I love that given all the experience and PTSD from the startup.
- chipdart 2y agoI think these stories tend to be based on a bait-and-switch angle. Minimum viable products only need to implement very basic functionality, just enough to get something out of the door. Limited tech stacks like Laravel/Django/Adonisjs can provide basic functionality, and sometimes a plain static HTML+CSS can serve that purpose as well. Except that micro services are an organizational tool, which just so happens to have important technical traits. When you start to develop your MVP to actually do something relevant to your business, and you start to assign responsibilities and accountability to specific people running specific projects, you create a need to peel out functionalities and data sources and to isolate loosely couple them from the rest of the service. You start to have a need to have teams work independently and autonomously. And that's where micro services come in. There are plenty of system design exercises that ask you how would you implement Twitter, and the first iteration is a monolith with a RDBMS. It quickly grows beyond that. Why?
- aerhardt 2y agoWhat is limited about Laravel or Django, exactly?
- pmontra 2y agoI'm not sure if your comment applies to Threads but if it does, and why not given the short time to launch, that Threads MVP had 100 M app downloads in the first 5 months. It's 4 orders of magnitude more than any customer of mine got in all the lifetime of any of their products. It's one order of magnitude more than what the mobile phone operator I was working for 20 years ago had after years from launch. I guess that it means that an MVP is all we need. OK, they started with the Instagram code base but as you write, the core of the product is a pretty standard exercise. I did it a few times myself for some customers along the years, Rails and PHP.
- chipdart 2y ago> I'm not sure if your comment applies to Threads but if it does, and why not given the short time to launch, that Threads MVP had 100 M app downloads in the first 5 months. Irrelevant. I'm talking about the feature set, which is not determined by the volume of clients being downloaded. > I guess that it means that an MVP is all we need. The clients need content. The business, in order to make money, needs way more than that.
- DarkNova6 2y agoIf you make websites for mid-sized companies and don't need to go beyond simple input-output. Then no. You can make large enterprise backends or similarly large projects but I seriously wouldn't advise any of those three...
- riffraff 2y agoI wonder how much of the "were working to support ActivityPub" story is real (mentioned at the end of the article). I've got a few people I'd like to follow on Threads from my mastodon account, but I have the feeling this will never be generally possible. It feels like something that will always be a low priority until finally a product owner decides that it can just be removed from the backlog.
- redrove 2y agoWord through the grapevine on Masto is they went looking for instances to federate with and pay them and people wouldn't partner up with Meta on principle.
- riffic 2y agorecently shipped and it'll be complete when you can follow fedi accounts from Threads but my feeling is it will be much more restricted in that direction: https://engineering.fb.com/2024/03/21/networking-traffic/threads-has-entered-the-fediverse/ https://engineering.fb.com/2024/03/21/networking-traffic/thr...
- hn1986 2y agoThey already have some preliminary support. You can follow Obama, for example, on Mastodon since his account posts on Threads
- M4v3R 2y agoNo sane person would kick off a brand new application that expects huge traffic on Django + PHP, right? This goes to show that technology stack is not as important as devs (myself included) sometimes made it out to be. And that old, boring, battle-tested framework and technologies can actually deliver.
- ryanjshaw 2y agoNobody uses Threads, that's why they're fine /s. But yeah, I used to get anxious reading HN and hearing about some new web tech stack. I thought my knowledge and expertise was falling behind. 99 times out of 100 the new stuff is nice, but not game changing, and the stuff I know is good enough.
- ben_w 2y agoEven stuff that's been around for a bit; I can't speak for web, but on iOS I'm still seeing a lot of cases of people merely experimenting with SwiftUI and not actually switching to it, because UIKit is still more useful.
- throwaway894345 2y agoI don’t have a dog in the fight, but it seems silly to use “what FAANG companies are able to make their tools do” to inform decisions for smaller companies.
- M4v3R 2y agoI'm actually writing an argument against myself, because I'm usually closer to the "let's use the new shiny thing" camp. But that article is a nice reminder that the new shiny thing is not the only way to go and the "old, boring thing" is as capable if used right.
- aprao 2y agobut Meta's versions are significantly different than the old, boring thing that you and I have access to. At my company, we are slowly rewriting our python services in golang because off the shelf golang incurs significantly less costs than off the shelf python on a per request basis.
- redrove 2y ago>The company leveraged Instagram's existing monolithic architecture and quickly iterated to create a new text-first microblogging service in record time. So they, in fact, had already built out Instagram as a monolithic service based platform and essentially forked it, tweaked it, tested it, and shipped. The title of the article is highly misleading, suggesting they shipped from 0 to full platform in 5 months explicitly due to the fact they were using a monolithic architecture as opposed to a microservice based one.
- makeitdouble 2y agoTBH, it could take more time to clone and tweak a micro-service architecture. Arguably, they'd take another approach altogether in that case (keep some services in common and clone as few services as possible for instance), but it's still notable that they had the option to clone it wholesale in the first place.
- deleted 2y ago[deleted]
- vasco 2y agoYeah this is like working for Google and launching "YouTube Texts" where some engineer removes all the actual videos leaving only the code for comments and calling it a new thing.
- giongteo 2y agoyeah, nothing special about infrastructure indeed... They just reuse IG infra and build features on top of it. Mentioning Microservices is so non-sense here, just for the purpose of clickbait.
- randomdata 2y agoRemember, microservices refers to the architecture of people. It is the emulation of the service architecture found in the macro economy (i.e. businesses buying and selling services with each other without any direct coordination), but localized in the micro economy of a single business. There is a prevailing idea that large organizations do not have the communication capacity for many people to all work together, believing that more people require more meetings to coordinate, which at some point reaches a critical mass where any change requires more meetings than there is time in the day. Teams emulating the macro economy – a world where you can't get Google on the phone no matter how hard you try, where all you get is written documentation – is thought to be the solution to that problem. So there would be something novel about multiple, disparate teams showing they can all work together under direct coordination while actually getting things done and not get bogged down in endless meetings. But, while the article is light on details, it appears that they actually did stick with a microservices model – creating a copy of Instagram so that the Threads team could provide an independent service without needing to communicate with the Instagram team...
- dotdi 2y ago> Despite the apparent advantages of reusing Instagram's platform for Threads (much faster delivery time), Malkani admitted the company introduced a substantial amount of technical debt that must be addressed in the future. This is not the feel-good "ye olde ways are always better" post that the headline suggests. This is a quick-and-dirty ship it by tomorrow™ and we will worry about building it properly later.
- throwaway2990 2y ago[flagged]
- hnlmorg 2y agoYour comment and the GPs aren’t disagreeing.
- _factor 2y agoIf fixing technical debt after the fact costs more than 10months of operating. You have a problem. Not counting the extra hours needed to maintain an archaic codebase. This was more about the uncertainty of threads succeeding. It’s easier to swallow writing off a port than a brand new implementation.
- azangru 2y ago> They could have good greenfield project and shipped in 15 months. Could they have had a good greenfield project and shipped it in 5 months?
- rowanG077 2y agoThey profited of it? Bold statement considering it is a meta product. I would be extremely surprised if they have achieved even a single dollar of profit.
- throwaway2990 2y ago100% They collected millions of people’s data.
- tacone 2y agoTL;DR they copy pasted the Instagram architecture and went on with their lives.
- UberFly 2y agoAnd then Mark Zuckerberg called people who handed over their data "Dumb F**".
- mg 2y agoControversial take: Most indiemaker projects and startups would probably be build faster if they just used the <?php include 'header.php'> Hello <?=$name>, how are you today? <?php include 'footer.php'> approach. Afaik, https://twitter.com/levelsio https://twitter.com/levelsio still works this way.
- ipsum2 2y agoThat's unrelated to the article. If the article was about "how to build SpaceX rockets" the equivalent comment could be "I bought some fertilizer and made my own rocket using PVC pipes".
- davidsergey 2y agoMicroservices are risk mitigation. If you know what are you doing - Monolith is optimal way. We use microservices, because we acknowledge that we don't know how final product would look like, and we mitigate risks associated with adding and removing unknown number of features. Facebook was creating clone of Twitter, well known product, well known path. There is no need for microservices.
- boxed 2y agoHow do you lower risks of adding and removing feature if you need to not only need to add/remove the feature but also decide which service it goes in, set up coordination, and manage networks between the services? That's more work, and more surface area.
- aerhardt 2y agoI mean, can’t you decouple your modules inside a monolith just as well, if what you’re looking is to mitigate the risk of removing features?
- The_Colonel 2y agoI would actually put it exactly the other way round. If you don't have a crystallized architecture yet, prototyping with a monolith is faster. You don't have to make the cuts (this belongs to this service) which are expensive to change later (unlike moving classes between modules). Doing internal Java/.NET/whatever interfaces is easier than introducing external API (and associated infrastructure complexity, authorization, routing...), they are much easier to tweak. You have transactions, don't have to deal with a lot of asynchronicity, network overhead etc. For a prototype, I'd always rather do a monolith.
- DeathArrow 2y agoActually for a big codebase there are always reasons to use microservices: much better scalability, easier to develop using small teams, easier to maintain, the software is more robust.
- smokel 2y ago
- DeathArrow 2y agoSo it took tens of thousands of programmers and five months to modify IG codebase to deliver text instead of images?
- philjohn 2y agoNo.
- forgotpwd16 2y agoYou may've to provide some more info than a plain "No." The question GP made is sound since this is exactly what the article alludes to: >Meta formed a small team to devise an approach to delivering a new service that would directly compete with Twitter in just a few months. Zahan Malkani, a software engineer at Meta, shared how his team was able to reuse the existing Instagram backend components, data stores, and large parts of the existing infrastructure stack but customize them to offer functionality comparable to what now is X. And due to time constrains was even made sloppy: >Malkani admitted the company introduced a substantial amount of technical debt that must be addressed in the future. The team is working on gradually separating the data models from Instagram's as the Threads service gains new functionality so that both platforms can be separated, but the process will take some time.
- 0xFF0123 2y agoSmall team doesn't conjure up an image of tens of thousands of programmes.
- forgotpwd16 2y agoOh shit. Read it as programmer hours. Now curious how many devs this small team had.
- sswezey 2y agoI remember reading somewhere it was about 20 engineers. They took a picture of the whole team when it launched.
- dilyevsky 2y ago> Theads's technology stack is almost identical to Instagram's, consisting of a few monolithic application components and dedicated data stores. "Monolithic Architecture" // shows diagram with like 5 boxes on it...
- Maxion 2y agoI guess it's now called monolithic when you don't split your core features into 10 microservices each?
- theyinwhy 2y agoInteresting enough, Netflix says that what they call microservices others would call monoliths: https://www.infoq.com/presentations/netflix-java/ https://www.infoq.com/presentations/netflix-java/
- darkwater 2y agoIf the same code runs different paths in the the different boxes, it's still 100% a monolith.
- superb_dev 2y agoSo if it never branches?
- darkwater 2y agoSo what? GP was complaining that a monolith cannot possibly have 5 boxes. (It must have exactly one, I guess, in their vision). You can totally have a monolith that runs the same code base in 5 different "roles".
- SJC_Hacker 2y agoI mean its just another social networking site. These have been pretty much figured out for about ten year now. There aren't many interesting problems besides how to monetize it/make it profitable. The only question is having the money to deploy at scale.
- sidcool 2y agoI have loved the Modular Monolith (or Modulith) approach with strict abstraction. It keeps it in same code base/deployment and at the same time keeps it modular enough to be extracted into independently networked services later.
- oznog 2y agoModulith is the way. Simply put, with microservices and all the typical contemporary complexity you can't deliver a shit in 5 months.
- darthrupert 2y agoAgainst All Odds, Company Did Not Fuck Up a Software Project. News at eleven.
- LudwigNagasena 2y agoMeta Used Existing Architecture to Ship Threads in Only Five Months
- EMM_386 2y agoI have worked in small companies and big companies, on monoliths and microservices. Good and bad. Everyone has already gone into the weeds yet again on that topic. I'm just confused on why these types of stories keep coming up recently. I thought the barrage of Sqlite was a lot, but "monolith vs. not monolith" seems to be even more frequent. What exactly is being discussed in these cases? Most large systems don't boil down to pure "microservices" or "monolith". Look at the diagram on that page ... big clouds that talk to little clouds, big clouds that talk to yet another in-house KV store labelled "database" (that has boxes inside of it), big clouds that talk to cylinders, that in turn talk to more cylinders. Then you get to the description ... it's Python running Distillery (custom Django), talking to "WWW" (PHP), with data stored in TAO using UDB. Add sharded MySQL, ZippyDB and Async (just to get some serverless in there?). All of this with a term I've never had to use once in all these decades, "Server-Driven UI (SDUI)". After reading the explanation, this seems to be returning UI as JSON to be put together on the client, as to avoid waiting for a release cycle for UI changes? This sounds a lot like HTML and CSS. What does any of this have to do with monoliths vs. microservices (or not monoliths)? I don't even know what I'd label this system. 8+ different technologies spanning server and client, but referred to as a "monolith"? That term has lost all meaning to me. Funny they ran into timezone issues and a lot of technical debt. Now that I can relate to.
- phyrex 2y ago> All of this with a term I've never had to use once in all these decades, "Server-Driven UI (SDUI)". After reading the explanation, this seems to be returning UI as JSON to be put together on the client, as to avoid waiting for a release cycle for UI changes? This sounds a lot like HTML and CSS. Yes, except for native mobile applications
- btown 2y agohttps://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5 https://medium.com/airbnb-engineering/a-deep-dive-into-airbn... (2021) is Airbnb’s take on this. A fascinating read.
- RachelM71948937 2y ago[dead]
- em1sar 2y ago[dead]
- andrewstuart 2y agoIs anyone advocating for "micro monoliths" - (building lots of little monoliths all deployed side by side)? That's the level of crazy the monolith versus microservices needs to get to.
- pdinny 2y agoMicroliths, if you will. Personally, I'm all for macroservices (no joke).
- throwaway0628f4 2y agoThat just sounds like SOA (Service Oriented Architecture), but nobody dares to utter that word because it makes them seem old.
- gv83 2y agogiven the "rebuild twitter" abundance of questions during the dreaded system design interview, it should have taken 2 weeks!
- glintik 2y agoIn fact, monolithic solution is much faster to ship. And cheaper. And much easier to support.
- lvl102 2y agoI didn’t know Threads is still a thing. It is still very much barebones and frankly laughable for a product pushed out by a trillion dollar company. The fact that it took them five months is even more comical considering that all they did was pare down IG.
- Havoc 2y agoReally wish people would stop seeing this as an either or philosophical choice to be made Also - it can change You’re picking a tool for the job at hand not declaring lifelong allegiance
- oznog 2y agoCan anyone tell any precedent of microservices and all this tipical complexity shipping something in 5 months?
- xpl 2y agoSo now monolith is the new microservices. Makes sense! Wake me up when the next big thing arrives.
- whatever1 2y agoConfiguring microservices is a pita that drains resources. I wish AWS had an llm to just create all these stupid json files.
- nojvek 2y agoDoes anyone know what is the current WAU of Threads?
- nothercastle 2y agoAnyone actually use threads?
- poulsbohemian 2y agoHere's the thing I really don't get about Threads... so now when you are on Facebook, Meta is constantly pushing you to Instagram. And within Instagram, they are constantly trying to push you to Threads. The whole thing is just a mess and as someone who pays for advertising and is trying to push content, there is nothing about it that is easy or understandable. Further - it's clear that the FB demographic is older, and I'm guessing skews female. Instagram is a bit younger and I guess you could make the argument is more video-oriented. Threads is like a wasteland - the only reason anyone has an account there is because of this weird feedback loop with Facebook and Instagram where you likely created one almost by accident. It's not at all clear why anyone would use it over Instagram other than the typical goldrush mentality of trying to claim your name there first. It's all so very messed up.