>The company leveraged Instagram's existing monolithic architecture and quickly iterated to create a new text-first microblogging service in record time.<p>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.<p>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.
I 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.<p>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.<p>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.<p>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?).<p>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.<p>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.<p>Funny they ran into timezone issues and a lot of technical debt. Now <i>that</i> I can relate to.
> 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.<p>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.
> Theads's technology stack is almost identical to Instagram's, consisting of a <i>few monolithic application components</i> and dedicated data stores.<p>"Monolithic Architecture" // shows diagram with like 5 boxes on it...
Another article on don't go micro services and don't reinvent the wheel.<p>I wonder if most solutions could be implemented on top of Laravel/Django/Adonisjs without too much effort.
Here'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.
I 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.
Really wish people would stop seeing this as an either or philosophical choice to be made<p>Also - it can change<p>You’re picking a tool for the job at hand not declaring lifelong allegiance
I wonder how much of the "were working to support ActivityPub" story is real (mentioned at the end of the article).<p>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.<p>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.
No sane person would kick off a brand new application that expects huge traffic on Django + PHP, right?<p>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.
Is 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.
Microservices are risk mitigation. If you know what are you doing - Monolith is optimal way.<p>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.<p>Facebook was creating clone of Twitter, well known product, well known path. There is no need for microservices.
I mean its just another social networking site.<p>These have been pretty much figured out for about ten year now.<p>There aren't many interesting problems besides how to monetize it/make it profitable.<p>The only question is having the money to deploy at scale.
I 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.
Controversial take: Most indiemaker projects and startups would probably be build faster if they just used the<p><pre><code> <?php include 'header.php'>
Hello <?=$name>, how are you today?
<?php include 'footer.php'>
</code></pre>
approach.<p>Afaik, <a href="https://twitter.com/levelsio" rel="nofollow">https://twitter.com/levelsio</a> still works this way.