New post on serverless

1 files changed, 19 insertions, 0 deletions

diff --git a/content/posts/2022-09-09-serverless.md b/content/posts/2022-09-09-serverless.md
new file mode 100644
index 0000000..fbd572c
--- /dev/null
+++ b/content/posts/2022-09-09-serverless.md
@@ -0,0 +1,19 @@
+---
+title: "Serverless"
+date: 2022-09-09T21:48:19+01:00
+draft: false
+---
+
+At work, our main product is a web application. Its primary function is receiving health data from hospital systems (and GP systems, and anyone else that has health data) and making it available to patients. I've been heavily involved in the infrastructure side of things; including migration to public cloud infrastructure.
+
+Our infrastructure is complicated. We use SQL databases, Redis, Cloud storage buckets, and messaging systems as stateful components. We use kubernetes to run our application(s). Even though all of these are managed to some extent by the hosting provider, a lot of the detail is still left up to us; for example provisioning groups and users, scheduling upgrades, handling deprecation of APIs. Also our customers frequently ask things like 'where is your data hosted' and 'which standards for data security do you conform to'. These are reasonable questions.
+
+It gets even more complicated when you have to also consider CI pipelines, and security at every step of the supply chain from developer machine, to production data, to support staff, and even _more_ complicated when you start trying to build out business intelligence.
+
+I've often found myself asking if things could be simpler. One way things could be simpler is [just use one big server](https://specbranch.com/posts/one-big-server/). This is really alluring, right up to the point where either your one big server explodes, or can't get any bigger. It can also mask scaling problems in your code, for example the classic N+1 query problem isn't really a problem if your application and database are on the same server, but it is almost certainly a problem the moment that any latency is introduced by e.g. a network hop. One big server is probably still fine in a lot of cases though.
+
+Another way things could be simpler is to let platforms handle more of the infrastructure and scaling concern for you. I've been experimenting with [Darklang](https://darklang.com/) which aims to provide _everything_ you need to write web applications (like ours), all hosted and managed right from the code editor to 'production', so you can spend nearly zero time thinking about, and working on, infrastructure. There are some pretty big tradeoffs at the moment, for example: the platform revolves around an entirely new language, so there are very few libraries. There is no separation of 'staging' and 'production', code in a canvas is live immediately, which would require a pretty significant change in approach for code review and testing. Code is not portable, there is only one darklang environment right now, so if that goes away for any reason, you have to rewrite.
+
+Infrastructure for a company that doesn't sell infrastructure is purely a 'cost centre' i.e. something that's necessary for the company to function, but isn't a direct money-maker. We're not selling infrastructure, we're selling a product built on that infrastructure. I hope that something like darklang becomes mature and useful in future; and software developers can cut out a big chunk of time spent worrying about infrastructure.
+
+Maybe I could even spend that time skating instead.