Plurrrr

We all know that parsing is an important part of designing and implementing programming languages, but it’s the equivalent of Brussels sprouts: good for the diet, but a taste that only a select few enjoy. Unfortunately, I’ve come to realise that our general distaste for parsing is problematic. While many of us think that we’ve absorbed the advances of the 1960s into our collective understanding, I fear that we have regressed, and that we are often making inappropriate decisions about parsing. If that sounds accusatory, I don’t mean it to be: I spent over 20 years assuming that parsing is easy and that I didn’t need to understand it properly in order to use it well. Alas, reality has been a cruel teacher, and in this post I want to share some of the lessons I’ve been forced to slowly learn and acknowledge.

Have you ever wondered why a green lock icon appears on your browser URL bar? And why is it important? We did too, and this comic is for you!

Each release has a lot of these "hidden gems" -- features that may not jump off the page, but can have a big impact when you actually need them. Postgres 13 is no exception: some of these features make it easier to write queries, add additional layers of security, or help you to avoid downtime.

So what are the hidden gems of PostgreSQL 13?

In this installment we are going to look at “container orchestration” for Docker. In the previous installment, we just looked at how to run an individual container. However, most applications are a combination of services which are orchestrated together to make an application.

While in theory all the pieces of an application could be built into a single container, it is better to split an application into its relevant services and run a separate container for each service. There are several reasons for this, but the biggest one is scalability.