Have had a bit more meetings than my ideal number recently but other than that everything is humming along. Client work getting finished up, new client work being nailed down.

As per usual there should be a stream on the YouTube channel today. This one at 14.00 CEST. Either I'm going to tackle some more of the Photo project or I'm going to try to make a more satisfying outcome from the Operational Transformation video where I didn't nearly achieve my goals. I might be close though.

A BEAM Radio episode without me in it was launched so I actually listened to it because our guest, Quinn Wilton, is great. And it is a great episode. Don't miss it.

What were our options back then?

I get into a bunch of conversations with people curious about Elixir and sometimes I get the question about "how do you put it into production?" which always puzzled me a bit. Not as in feigned surprise "wow? you don't know how to put things into production?" but rather that it typically comes from people who already do production things in other languages. And the question isn't one I would have asked.

Trying to open my mind a bit to the source of the question I'm thinking there has been a lot of movement on the operations and platforms side of software development. Some of the question I think comes from people who've worked in larger orgs where they have an operations team where the Dockerfile and CI is the end of the developer's journey with the code.

But also people are working with modern Node.js platforms, which I know next to nothing about. There's also plenty of people doing Heroku and similar minimal-ops platform deployments. In which case putting something into production can get a bit obscured.

The reason the question initially confounds me is that I feel like I've put things in to production very similarly through the years. PHP is a bit special in that you either deal with some Apache PHP module or more recently PHP-FPM and those are slightly special in that they provide that "visit mydomain.com/index.php" functionality. But overall, you have some kind of application server, or a compiled binary or a server script of some sort. That listens to a port on that server and then you  make sure everything else is in order around it.

Elixir releases have never felt like a mystery to me, rather a slightly finicky but very clear path into shipping something onto a server. You essentially compile the thing and put it on a server.

Thing is, when I came up, that's what I did with everything. I'm sure there were some more abstracted ways, I did at some different times use cheapo PHP hosts which I guess also didn't quite give you the full picture or the full experience of a server. And if you've only used those you might ask the same type of question. "So what's a good Elixir host?" And I'd be similarly stumped. And then I'd mutter something about Heroku or Gigalixir probably being good options but that I've never touched them. I had a slow computer repurposed as a web server before I had money for hosting. So that's reverse to me.

It isn't wrong to not care about servers and it is fine to only have worked in either limited scopes or managed platforms. Great. The abstractions or organizational constructs worked and you got to focus on your code.

And you can have the same setup in an Elixir org, absolutely. Either with a PaaS (Heroku/Gigalixir) or with and ops team running some Kubernetes or whatever and letting you ignore it.

I think it is an immense benefit to any developer to have a pet server facing the public internet to run things on. For all kinds of purposes. But primarily to remove the mystery of production and to make absolutely clear that there is nothing stopping you from cloning a repo onto your server and just compiling it right there to run. That's fine. That's great if it gets you rolling. Automation and reproducable builds are next steps, not the starting point. When you start wanting to learn about servers, you probably shouldn't start with building a full CI/CD chain, k8s, Docker or any of that. Because you still need to get comfortable screwing up servers.

So keep it simple. Get to know a single server. Ubuntu is fine, quite friendly. Well supported. There is a lot to learn at that point. Linux is not a small thing to grok. But it doesn't just demystify a single type of production deployment, it starts to demystify all of them.

Now personally, I need to find a decently standardized way of handling my server-deploys because I'm oscillating between options like mad and not quite at peace with any of them. I'd rather not use containers in prod, beyond that suggestions are quite welcome.

Do you have a pet server? Does this make zero sense to you? Have you yet to learn dealing with servers? You can poke me at lars@underjord.io or Twitter where I'm @lawik.

Thank you for your attention, I appreciate you reading this.

- Lars Wikman