The 1990's called and they want your relational database and server back
The 1990s were a very important time for me. I remember being in high school in the early 1990s before there was an internet, back then we had a BBS, Compuserve and AOL all via a modem that took an hour to download a single image. In addition, nobody even considered the idea of multiple processors or the cloud, but standalone relational databases were a big thing. In fact, databases in the 1990s were a huge deal. They were literally the only tool you had.
Fast forward to ten years later, and we got a lot of web frameworks, Rails, Django, etc, that were formed on trying to make 1990s style databases easier to use while you did server development on single core machines. Today, closer to 2020, then 1990, there are still many companies stuck in 1990s thinking. Using tools and frameworks around relational databases to make developing single core server development faster.
Entire companies have spun up to make hosting Wordpress or hosting Rails easier. The problem is for many companies this is the wrong problem to solve. Relational Databases and web frameworks and CMS solutions like Wordpress are sometimes the right solution, but they have evolved from the 1990s and help solve 1990s thinking. If your doing Content Management today, you should ask yourself why you are using a server or a database at all. It is mostly useless abstraction, around old problems.
A few great examples of the future are:
- Hugo: generates thousands of pages sub second
- AWS Lambda: executes code without servers
- AWS, Google Cloud, AWS (the entire cloud): The new operating system (sqs is queues, lambda is threads) (not a single core server from the 1990s). Concurrency is a breath of new air for scripting languages like python, ruby, javascript (but they don't need the web framework, horrible concurrency models and Relational Database baggage).
The future is right in front of us. You may not need Erlang, or Go, although I like them both, (the Cloud does the same thing they do...massive concurrency, but they have monopoly companies providing services support vs your own developer or some other services company you call that may are may not be a value added services provider). You may not need a Relational Database (there are an incredible amount of alternatives: S3, Dynamo, Google NoSQL, Open Source, etc). These are not bad solutions and have their place, but think twice before you go back to the 1990s.