It’s common for online applications to refer to themselves as a “platform” as soon as they have a public-facing API. Facebook is probably the biggest example of this, but it’s a fairly standard marketing tactic (I used to work for a company that did the same thing). Basically you make some public-facing endpoints, and voila, you’re now a “platform” – and developers please build stuff for us, so we can increase customer lock-in. That’s not how this actually, or ever, works – because that’s not how platforms work.
The term “exit” always irritated me when people write about startups. Especially because it only happens when a company is either bought or IPOs. I’m not saying that startups don’t use acquisition (or IPOs if you’re Twitter – never X) as an exit strategy to avoid actually making money, but a lot of times companies do this after they’ve become a profitable, self-sustaining business. Despite that, we still don’t have a clear definition of when non-retail companies stop being startups and start being plain old businesses (even if they’re small), and it needs to be fixed.
The world is full of applications that are big enough that companies need multiple development teams to work on them. No matter how these teams are organized (but I’m going to go out on a limb and guess they’re not completely cross-functional, even ignoring the hard parts). The benefits to organizing multiple software teams is they can operate independently, but the downside is that any best practices learned are hard to propagate across teams. After all, the whole point is they only need to interact with each other to inform each other of service-level changes. So how can all these development teams actually learn (and adopt) best practices?
Like just about everybody else who runs software post dot-com bust, I read about Amazon Prime Video re-architecting their monitoring service, and saw all the microservices vs monolith hot takes. For the best monolith vs microservice analysis on the post, I recommend CodeOpinion’s video. What I found more interesting about the post wasn’t the monolith vs. microservice debate (I agree with CodeOpinion – that’s not really the relevant point to the original article), but rather the limits to using Functions as a Service (FaaS)…as a service.
Reading a lot about platform engineering kept reminding me about the concept of the paved road (I’ve also seen the term “golden path”) in software engineering. It’s easy to understand why – if you do platform engineering correctly, then you end up with a paved road. Spotify probably has the best definition of a golden path (emphasis mine): “The Golden Path — as we define it today — is the ‘opinionated and supported’ path to ‘build something’ (for example, build a backend service, put up a website, create a data pipeline).” For all practical intents and purposes, a paved road is essentially the output of platform engineering. But why should we be trying to pave these roads? Shouldn’t we just build a stack and incorporate toolsets specific to each project, app, or service? Surely that way we can optimize for the specific problems each was built to solve, right? Wrong.
So after taking a brief break to write about Twitter, because that’s everyone’s new favorite hobby, I wanted to revisit part of my central thesis in my posts on platform engineering – that it’s hard to find places with actual cross-functional teams capable of doing everything needed to build and run an application or service from concept to being used in production. I’m not totally sure why this is something that organizations don’t want to do, but I still don’t platform engineering is the solution (or as I’m sure some companies will try to spin it, “compromise”). Continue reading »
So apparently there’s this hot new app that just released called Mastodon, and everyone’s leaving Twitter to join that. It’s OK if you haven’t heard of it, it’s that new. Snark aside, people are stumbling onto Mastodon because they’ve been told it’s the biggest Twitter alternative (it probably is), which isn’t really saying much – there aren’t a lot of Twitter alternatives that anyone would really think twice about. It does a good job of replicating the basic Twitter experience, type some things into a box and click the post button to publish. But there are important, non-obvious (to general users) differences between Mastodon and Twitter, and people seem to be struggling with them.
When people talk about the “death of DevOps,” platform engineering is brought up as its successor. That’s probably overstating things. The practices associated with platform engineering certainly look like they have a lot to offer, but getting platform engineering right is difficult. And getting platform engineering right is important, because that’s the only way platform engineering is going to work. Otherwise, what you’re going to end up with is a mashed-up team of random engineers desperately trying to keep infrastructure afloat while developers wreak havoc on everything.
I came across an article titled “Devs don’t want to do ops” that started with the premise that developers managing their own production infrastructure is stressful (it is), questioned whether development and operations should be separated again, and settled on declaring “DevOps is dead,” and that platform engineering is the future. It was quite a ride. It also raised some good questions about DevOps, and the ideal approach to building and running code. Is DevOps really dead? Is platform engineering really the future? What does it mean to “own your own code in production?”
If you see any sort of headlines about CEOs and remote work, then you likely heard that Malcolm Gladwell does not like remote work. I had some thoughts on why I think his position (and others like it) is stupid. My position is hardly uncommon – most of the arguments for returning to the office revolve around saying either a) people can’t collaborate unless they’re in the same room (the fact that team-based jobs kept up just fine since Covid happened thoroughly disproved that), b) we need it for the “culture” (“culture” has nothing to do with physical proximity, and isn’t as valued as some people think it is – although looking at that meme makes me miss the days when we at least got cubicles), or c) people aren’t productive working from home (they weren’t productive in the office either, you just thought they were because you saw them sitting at a desk). In my tweet thread, I brought up a personal hypothesis that you can group most people into 1 of 2 groups, “true believers” and “mercenaries,” that I thought warranted more details than you can get on Twitter.