As a veteran of several hurried rewrite projects, I can say with confidence that if parler is “rebuilding from scratch,” the SOONEST they’ll be back online is July.
Parler’s CEO is now claiming they’ll have less than 12 hours of downtime for the switch away from AWS.
I’m curious about their backend codebase. I vaguely remember hearing that it was php, but now I can’t find anything about it. Anyone know?
I worked on an open source social network, and if it were a fork of that codebase, they’d be in violation of the terms of the license.
I doubt it is, but I’m curious.
In my experience, when someone says their web app architecture is “cloud neutral”, what they really mean is “I’ve wrapped functions around all my AWS API calls”.
As long as the new cloud uses the same metaphors & breaks operations down the same way, it’s totally portable!!!
Guess how many clouds use exactly the same metaphors
It’s really hard to do software development these days without depending on external services.
Even a bog standard CRUD (create, read, update, delete) web app like parler needs services for source code hosting, work tracking, email sending, text messaging, etc - and that’s not including anything they need to scale.
I have worked with software teams who didn’t want to use these services, often because they saw the service providers as competitors. For example - retailers often don’t want to be on Amazon web services because they directly compete with Amazon’s retail arm.
That’s just one example. I’ve also worked with teams who avoided a particular project management service, or a particular source code hosting service, because of perceived competition.
So I have some experience building software without access to the common services.
It’s hard. Working without software development services and APIs throws a huge amount of sand in the gears. It drastically reduces how quickly you can improve the actual product.
There’s a reason you’ve heard so much about APIs and services the last few years, even from the non-technical business press.
It’s all about improving your product faster by relying on the expertise of other companies.
All that to say - most teams should embrace web services & APIs. Amazon isn’t your competitor until you have a successful product, and getting to a successful product is surprisingly hard. Putting sand in the gears early generally just means you never get there.
But the one time you shouldn’t embrace services & APIs is when you’re going to host illegal content. Such as, say...detailed planning for the violent overthrow of the US government.
Because then, each service becomes a takedown vector.
If you’re just hosting run of the mill conservative content, you will have no issues. Amazon web services continues to host the National Enquirer, for example, even though they’ve directly targeted Jeff Bezos in the past.
Perhaps we’re all tired of dunking on parler, but just in case you’re not, I did some investigation this evening.
tl;dr: technical clown shoes.
🧵
Their CTO is a person named Alexander Blair, whose career (according to his LinkedIn) has been mostly sys admin and DevOps jobs. His job history goes back to 2008. linkedin.com/in/alexander-b…
On the surface, Blair is not an unreasonable CTO choice for a small startup thinking they’re going to have backend scaling issues.
My mode of software development is to just start trying things. But I love working with people who need to read all the docs first.
I used to think that was a waste of time & I wanted a whole team like me, but it turns out - my mode isn’t always the right way to go.
I also like to use boring, reliable technology. But I love working with people who are into the new hotness.
Because it turns out, boring & reliable isn’t always the right answer, and I need people pushing me to consider the new hotness - because sometimes they’re right.
My goal is to write more great software, and while you might SOMETIMES get great software from a team of people who all think like me, you will CONSISTENTLY get great software from a team of people who have a variety of approaches.
PSA: There is currently no way for web components to be accessible if you use the isolation feature (called “shadow dom”).
Isolate the label from the input field, for example, & you break all the assistive technology - which requires they be tied together with ids.
There will eventually be a plan for dealing with accessibility across web component isolation boundaries, but the discussion is in the early stages, and we’re not likely to see consensus for several years.
Until then, isolation via shadow dom is a nonstarter.
So when you see all this stuff about how using web components can isolate your changes and take the cascading out of the CSS - mentally add “in 2-3 years” to all the claims.
Part of the problem is that he’s a rich tech executive who is actively contributing to the income inequality that leads to these property crimes, yet instead of addressing that, all he does is demand MORE resources.
There’s a slide deck somewhere on some VC’s computer that is the “exploit gig workers handbook” - and it includes this move, because for awhile after you do it you still get higher-level work done for pennies because your workers trusted you & engaged with your platform.
They can’t all move off right away. So they protest, & maybe organize. You string them along with platitudes (“our shoppers are the reason we exist!”) to slow attrition. Meanwhile you onboard new, lower-quality, more desperate workers at the new rate as fast as you can.
When I was younger & often the only woman on a team, I found that the white men in my team could jump straight to “X is terrible” & have it cheerfully explained to them.
I & my PoC male coworkers, on the other hand, often got defensiveness & tone policing when we did that.
So even though it took me awhile, I still think I picked up this skill (because I had to!) before many of my white male colleagues did.