Technical Treadmill

I've gone back and forth on this one several times in my career and I cannot confidently say where I stand on it. Where it succeeds is that it is an incredible abstraction over complex, distributed infrastructure that might be cloud-based, on your own hardware, or both. It's as simple as you need it to be but it takes experience to understand what 'simple' is (as always, simple isn't easy). It's also easy to make an mess of it but that's a criticism to be levelled at engineering culture, not the tech, because any team of engineers can make a mess if there isn't any discipline.

My overall experience is that you get the best out of K8S with a team of SREs who can help maintain it. It's not something you give to a team of senior software engineers with the idea of saving some money by making them all devops experts.

I started off excited about this though, and spent a lot of time learning how to use it and maintain it. These days my excitement is tempered but I appreciate knowing about it so I can work with it and help out in a pinch.

If anything, I expect K8S to be an inevitability in any startup and a migration to it is just a matter of time. K8S is choosing build over buy and you can get a hell of a lot out of Heroku, Render, Fly, Vercel, etc. before you make such an enormous commitment… if you can convince the org about that.

Similarly, I think letting teams host their own on Linode or Digital Ocean is unlikely to pass muster in any startup seeking any kind of compliance, if only because K8S has solved the job of provisioning workloads dynamically, making deployment a self-service problem.

Many good cases can be made for abstracting parts of your business logic over the network but in my experience microservice design has either been impulsive or a manifestation of Conway's Law.

Basically, you get microservices because the company re-organised your teams into smaller autonomous units, and therefore your architecture has to consist of smaller autonomous services. How do they talk to each other? Probably as well as how the teams talk to each other.

I will admit to falling for the fantasy of building a brand new feature or business domain from scratch in a new service - that always has an appeal especially if you feel bogged down by legacy - but there are many alternatives to choose that don't involve distributed architecture.

If you want it, you should probably acquire intimate knowledge of the business's domains and design around those instead of taking the org chart as a given.

Unfortunately this also seems to be an inevitability in many startups that want to 'replatform' the codebase and turn a monolithic architecture into a distributed one. I have never not known that to be an expensive mistake but I remain to be convinced.

Ultimately, it was exciting to be told each team could build stuff using the language of their choice with full autonomy, but it never played out that way. Just ends up with a meta-layer of management to keep it all in sync.

One of the biggest regrets, as well as biggest achievements, in my recent career was taking the lead on introducing Kafka into the tech stack. In my mind I was addressing latent demand in the engineering team and stepping up and to that extent it was a success. We designed a git-hosted schema registry using protobuf and all other sorts of things to fit it in to the architecture.

I was big on this, I loved the idea of it. In a way I still am and I still do because it comes in handy where SQS/SNS/et al can't do the job and, in the case of microservices, can help tame the architecture a bit.

I would not even consider suggesting this now, though, unless there was a clear game plan for it. The problem isn't just the tech, or the event sourcing pattern, it's getting all of the engineers on board and understanding how to work with it, and to even agree if it was even needed in the first place.

To that extent it's like microservices but you're not distributing the org-chart over a network, you're distributing business data with the idea that it will be consumed many times. But what happens when most of the time you have have data that nobody understands, because it hasn't been designed for sharing?

Yet still, I'd be happy to meet this challenge again and I'd find some enjoyment in it.

It doesn't matter how many 'Rails is dead', 'Rails is dying', 'Rails is boring' posts there are…nothing feels better to a Ruby dev than a blank slate in a Gem or a Rails app.

It's my bread and butter, simple as, and I've never regretted spinning up a prototype in Rails. One of my favourite career moments was selling it to the team as a legit way to prototype.

For me this is the circle you can't square; I was a scrum master and agile coach for a while over the years.

If you ask the internet I think you'll find more critics of agile than supporters. For every job I've worked, no matter what I've done to do my best, I keep getting pulled back into what I learned and did a decade ago in an agile/scrum/XP team.

Agile for me has been good, and tremendously hard, but never outright bad.

As far as the treadmill goes, this one keeps coming up and smacking my ankles to remind me it's still there.

-—

I'll leave it there but I've got plenty more. My opinions on these will surely change but it's where I am now, on this particular cycle.