Last night after the Atlanta JavaScript meetup, Toby Ho and I had a discussion about how deployment techniques have changed. He lamented on how many newbies and inexperienced users refer to Git in the same way they would have referred to FTP a few years ago. I’ve never really thought about it before, but he had a really good point.
Thinking about it, a few years ago we would regularly run into development shops where you had a lot of beginners (or experienced developers with really bad habits) who didn’t use any form of source control on their projects. Back in those days, if you wanted to use source control, most of the time you needed to stand up your own source control server in addition to setting up servers for a web based application, etc. While there are still some places that don’t use it, with things like Github, it is a lot easier for a development shop to set up their source control — and most seem to be using Git.
As a result, many of the platform-as-a-service (PAAS) offerings like Heroku only allow you to deploy via Git. Although this might be annoying if you really have your heart set on using another tool, in general it’s a good thing. We have no direct evidence of this, but anecdotally it’s probably the main reason why some shops are using version control today.
With this conversation fresh in my mind, today I had a discussion with a client who is in the process of breaking up their monolithic architecture into a service-oriented one. They are big Amazon users and have been levering the OpsWorks platform for most new projects. One of their components has data that needs to be shared between two of the services.
Whenever you need to do that, you usually want to have one system of record and then sync data between the two systems. An anti-pattern that many groups will do in this scenario is to have two of the systems use the same database. You can follow this anti-pattern in OpsWorks if you really want to, but you have to do a lot more manual configuration to set it up. If you want to set up a RDS instance that can only be used in one environment, which is the recommended way, it is a lot easier.
Ultimately, bad engineer or a really dumb user will always find a way to do the wrong thing, but lowering the barrier to entry for doing the right thing will make more of them favor it. Next time we complain about someone doing the wrong thing in our software, perhaps we should think about how to make it easier for them to do the right thing.
Leave a Reply