At my current company we employ a microservice style cloud architecture. One of the side benefits of this approach has been our ability to localize our tech debt into size-able chunks. When you’re a startup you need to be able to build things fast and fail fast if you need to pivot. Sometimes being perfect is the enemy of building a company, and sometimes it is not. This is where microservices can help mitigate long term issues and allow you to apply perfection where it could block you from growth and allow tech debt to pool in places where you can address it in a reasonable manner in the future,  essentially allowing tech debt to truly be like financial debt. It’s much easier mentally to tackle $10,000 of debt across 4 credit cards at $2500 each than 1 card at the full $10,000. It allows you to apply a sharper, more targeted focus that gives a more immediate gratification. Let’s level set on the phrase tech debt for the purposes of this article. “You want to make a “quick change” to your software of a kind you mean to be able to, and it isn’t quick.  Whatever made that happen, that’s tech debt.” – Dave Diehl.

When trying to build a microservice architecture at a startup you need to identify what are the core services you need designed and well structured to allow for future growth that if you get wrong will hurt your chances of being able to move at a fast, safe pace.  At first glance this might seem easy. We’re going to be a huge consumer play and will have a billion users so you go off and build a complex database sharding layer from scratch, because hey, you’re gonna grow too big for a single master DB.

This however will be highly dangerous. Startups are fluid organisms. Assumptions made on day 1 can quickly become invalidated in practice. In a previous startup where the previous founding team was from an extremely large scale web property and scalability was baked into their DNA, when it came to decide on how we’d store user information for our new product it quickly delved into a data center order of half a dozen DB class master boxes with replicas while the dev team started on a user sharding layer that took weeks of effort. In the end the product didn’t take off, that code was ripped out in multi night hackathons and the DB boxes were re-purposed for other projects leaving a teeny little box to handle the load. That was missed opportunity cost to work on features the users wanted by speculative investing. Perhaps instead just stubb’ing out the interfaces and APIs in such a way that all of the sharding/routing logic was localized to set of client methods and in the future those methods could be fully implemented or backed by a remote service.

Proper technical debt assessment is making known tradeoffs. If you don’t even know the tradeoffs you’re making that’s not so much technical debt as poor engineering and planning. As long as you focus on getting your APIs and interfaces modeled out you should be able to refactor the details behind those if the service turns out to be something that becomes core to your platform. Creating smaller, standalone microservices allows you to iteratively build scalable, well tested, easily digested services. At CrowdStrike we wrote some of our initial services in Python for quick prototyping, but focused on the API interactions with those services and less on the scalability of those particular services. For one particular service as we ramped up and had 10 of those Python boxes running with questionable stability we refactored them to GO (golang) and reduced down to 2 boxes. We actually only needed 1 box but used 2 for redundancy. The API did not change whatsoever and clients happily connected and were serviced as before.

We took on tech debt to test our hypothesis that those services would be critical down the road. It turned out they were and we were able to swap in highly performant, stable, tested code in place and paid off our technical tebt. $2500 less debt! Now to time to get that AMEX bill 🙂

If those sound like fun problems to work on, join the mission at CrowdStrike: