Choose Boring Technology (2018)

I am six months into a startup. It's a Python monolith with Postgres. It's been a success. There's a product-market fit, paying customers, and a healthy roadmap. The team picked boring tech, and it was the right call. Now, we are scaling to add exponentially more customers and hiring more people. We need to add resilience. We must tackle challenges around back pressure, flaky third parties, etc. Now is the time to introduce additional complexities because they pay for themselves. Such complexities are introducing dedicated read models and caching so we compute on write instead of every query/request, some messaging tech. We want to use Node instead of Django for our client-facing Dashboards and Dynamo for some tables.

In summary, the evolutionary journey of a system starting with a monolith, with a single language, and single db tech with some gnarly SQL isn't very sexy. Still, it takes you a long way before you must reevaluate and acknowledge that optimising for Flow and Pivoting over everything else turns into Flow and Cost to Serve. Your mileage may, of course, vary.

It’s interesting that the wisdoms of “buy, don’t build” and “NiH” etc. seem to be shifting in general.

I think a lot of people have been realizing through the pain of maintenance that dependencies are liabilities and that general, open source solutions with a bit of plumbing are often the lesser evil in that regard.

Given my anecdotal experience it seems to be true in the small, and I can imagine how this problem is even more pronounced in the large.

React and Vue probably qualify as a boring tech, but you could also use traditional server-rendered apps, e.g. with Java, php, etc., with jQuery on the client side.

This is one of those pieces of advice that you don't need to get super specific about and can follow as loosely as fits your circumstances, but in general I think it's nice!

I am doing a freelance thing and opted for mostly "boring" technology and so far it's working out great:

  * OCI containers (Ubuntu based) with Docker and Docker Swarm because it's simple/stable enough and has the features needed
  * Apache httpd as the web server of choice, because it has mod_auth_openidc integration to be an OpenID Connect Relying Party, less abstraction than a Kubernetes Ingress, too
  * .NET with ASP.NET and EF (Core) for the API, because the ecosystem is pretty coherent and it does most of what I need, yet still has an okay type system (much like Java)
  * Vue with various popular packages (Pinia, Vue Router, VueRequest/Axios, VueI18n, PrimeVue, PrimeFlex, PrimeIcons, ...) for the front end, because it's a good fit for the SPA and is simpler to use than React (IMO), yet doesn't have the complexity of Next/Nuxt; I actually considered Angular for the more batteries-included design, but Composition API is just great and most of those libraries are really easy to import and setup
  * MariaDB as the database of choice, because for simpler projects it's also easier to use MySQL/MariaDB than PostgreSQL: the model driven development tooling with MySQL Workbench is nice because of the codegen for migrations with dbmate later, as long as you don't need lots of complex in-database processing or transactional DDL, it just works
  * off the shelf software for day 2 concerns: Portainer for managing the cluster, Keycloak for user management, Matomo for analytics, Uptime Kuma for uptime monitoring, Apache Skywalking for APM and rsync for backups (for now); reasonably stable options for all of the code I don't want to write myself, especially in regards to auth/user management

Will a blog post on what and how I built ever get lots of attention? Probably not. But is it good for shipping software? I'd argue that definitely!

It lets me iterate reasonably quickly and also any learning I do is useful and not overwhelming due to its limited scope: e.g. adding VeeValidate instead of Vuelidate, configuring unplugin-vue-components, discovering VueUse, adding Capacitor into the mix, considering and subsequently discarding AutoMapper for EF/DTO, adding a plugin to my IDE to generate Entity mappings from a live database, working with spatial types in MariaDB (a bit less nice than PostGIS, but serviceable).

All of this also scales far enough for the current resources at my disposal. At the point where the performance of Apache httpd wouldn't be enough, there'd probably be a bigger team that can migrate it to something else.

Admittedly, sometimes this also means using SaaS for certain concerns, like using Mapbox for geocoding/routing, because self-hosting OpenMapTiles/OSRM/whatever would slow me down too much.