If you are a start-up that needs to build server-side applications: you do not need microservices, you do not need kubernetes, and you certainly do not need service mesh and it’s assorted bullshit.

There’s a common fallacy amongst engineers (even some more seasoned ones), that whatever Netflix, Google, Meta or Amazon are doing is “best practice”, and that may be the case – if you are one of the aforementioned companies.

As a start-up, you may have ambitions to become that size one day, but for now – you’re not, you’re trying to make a buck and stay alive.

Readers of this blog might be like “but Martin you run an Open Source API Management company, how can you shit on microservices?” Because I see customers come through the door that make their lives infinitely more difficult by doing things “the best way” instead of just getting shit done.

No cap – the amount of times I’ve seen someone cause a fuss because they do not understand how to use their own infrastructure or stack is mind-boggling – and then you or your team need to become experts in micro-service-k8s-mesh-fuckery to help them fix it. This is said with love: If you don’t understand it, don’t adopt it into production you absolute cabbage.

Ok, ok ok… getting close to “getting fired” territory here, so any opinions stated in this blog are mine and mine alone and do not reflect the opinions or views of my employer (happy now Jess?).

What I am trying to say to all the fledgling Tech Entrepreneurs, CTO’s, and Head of Engineering folks reading this, take to heart what you hopefully learned in school: KEEP IT SIMPLE STUPID.

A Tale of Two Clouds

Lemme tell you a story about how I fucked up: A few years ago I wrote the controller for our new Tyk Cloud SaaS as a proof of concept, I used all the cool tech: K8s, Ingress, Helm, Elasticsearch, Influx DB and of course: I abstracted the absolute fuck out of the code – it was so full of interfaces, the interfaces had interfaces to interface with their interfaces. I was the Xzibit of Golang.

I thought I was so fucking clever and my engineers at Tyk would be super happy to get this code because it was so LOOSELY COUPLED.

Well, come the time the PoC starts moving into real development with real engineers, that actually know what they are doing, I find out the horrifying truth:

I truly suck at software development…

My poor, stressed team of extremely talented cloud engineers looked at the code, smiled, looked me in the eye and said “leave it with us”.

What they were really thinking was: “HOLY FUCK WHAT HAS HE DONE TO US NOW, I CAN’T TELL HIM THIS IS SHIT. MAYBE I SHOULD FIND A NEW JOB?”

The result – almost a year of them scraping my tech-debt shit off their boots, and yes – they told me… numerous times… that the code was a big bag of overly-complex doggy doo-doo. We’re an honest and trusting team here.

Sometimes, going too far, too fast, with too many tools gets you so far up your own arse you can’t actually ship, and it was my fault for trying to do hang with the cool kids.

Side note: My team are awesome.

So – the moral of this story: it’s very easy to get hypnotised by the glitz and glamour of big cloud software architecture, frameworks and development patterns, but there’s a time and place for them – just like everything else.

When you are trying to iterate fast, get to production, find product-market-fit, the last thing you want is something that is over-complicated.

I can give you a counter-example, one I should really have bloody learned from – because I think I did something right here: our Legacy Tyk Cloud.

This thing is still running, but it’s being sunset in favour of our new (much better engineered and flexible) cloud.

The OG SaaS didn’t have any custom code except for an NGINX management layer to handle hostname rewriting (when we launched the legacy cloud in 2016, we didn’t have hostname routing capability in the gateway yet). The whole thing ran in pre-baked docker containers, where the latest binary was simply mounted into the environment, and launched on ECS (ECS was Amazon’s attempt to own the cloud container market before K8s came along fore anyone not familiar – it was pretty good too). Each “component” ran in it’s own ECS deployment group , all deployed by that most ancient of tools: Elastic Beanstalk.

The software components? It was literally a massive multi-tenant Tyk instance – the same thing our on-prem enterprise users were running, just with hundreds of thousands of APIs and tens of thousands of tenants all on horizontally-scaling hardware. Talk about dog-fooding huh?

Deployment was literally uploading a zip file to the Amazon UI (we did automate this later).

This basic-ass architecture continued to work – without significant change, for over 6 years. 90% of the time, problems were solved by a reboot or throwing more hardware at the problem (And Everyone knows that this is the best way to solve problems ;-))

The thing is: this whole SaaS could be maintained by a single person, the moving parts were relatively simple, there weren’t many of them, and the whole thing had a UI to fall back on if automations failed: Absolutely stellar for a startup with limited resources.

Of course this wasn’t a panacea, it caused us problems further down the line when we started getting more customers and we needed to iterate faster, or we needed better specific SaaS-outcomes for customers or we got customers with some truly epic scale.

However, it did get us to market on a shoestring budget, with limited staff to maintain it. It was the right thing to do at the stage we were at…

Should we have ditched it earlier? Yes. Should I have let saner minds develop the next version? Yes.

Don’t be like me folks – learn from my mistakes…

The trick with choosing your software stack and planning for scale is this: If you start seeing scale as a problem, that’s a good problem to have because it means you have demand.

If you spend all day overcomplicating your stack trying to plan for scale you don’t have yet, then all that complexity means nothing, because by the time you’ve reached a point where you capitalise on that scale, you’ll need to eat the tech debt elsewhere anyway.

(P.S. you may be able to tell I’m in the “fail fast, fail forward” camp of product management, fight me.)