Ten years of deploying to production
brandonvin.github.io
brandonvin.github.io
I like to think there is no curve only fashion. I've seen company's that were so behind that they managed to avoid adopting disasters like microservices etc. I've seen companies ahead of the curve go from monolith to microservices back to monolith.
Also funny that the ops team is now back just rebranded as the platform team.
Plus ça change.
A true platform team is responsible for implementing and maintaining an internal platform for automated deployment and operation of a company's software. The platform is essentially a product, where the customers are developers and anyone else who has a stake in the deployment, maintenance, and operation of the company's software - including the ops team! I.e. strictly speaking, an ops team is a customer of the platform built by the platform team.
Done properly, this automates away a lot of what ops teams and "devops teams" do, because it allows fully automated self-service by developers. Developers should be able to create new environments and deploy new and existing services without opening tickets to some other team. Those environments and services are fully compliant out of the box with company policies and architectural decisions.
People sometimes think that this means that if you let devs submit PRs for terraform files and, say, k8s configs, that that's a "platform". But no, that's just shifting that kind of work to developers, it's not automating it. Under the hood, a platform might use those tools, but if deployment of environments and services requires interacting directly with generic tools that can be configured however a developer wants, that's not an internal platform.
Exactly! For instance, we had pull-based monitoring 20 years ago (Zabbix et al), but we abandoned it because it scaled poorly, favoring push-based agents (for InfluxDB, KairosDB etc). Now Prometheus is all the rage, yet we’re hitting the exact same scaling walls these systems had before. In a few years, we’ll rediscover push agents and call them the best thing since sliced bread.
Spacetimedb, convex, etc are basically the revenge of stored procedure.
It might be seen boring. Brakes in my bike are boring. I like them that way
The director made sure things compiled, then we would drive down to the hospitals and copy the dlls into each PC one by one. And because hospitals can’t shut down their computers willy nilly, we could only deploy on weekends or public holidays. Not weekday nights because the directors have to be home for the kids.
That was in 2014. They’ve worked that way since the late 90s and ‘no point changing what works’.
The smart companies completely skip the cost and time spent moving to AWS. They instead use Linux-boxes-in-the-cloud solutions with zero integration of AWS specific services, making it easy to deploy on multiple host platforms world wide, and saving $millions.
That being said CI/CD is a luxury for coders at lean startups, but there’s still a lot of jobs where you have to work with some DevOps Team to deploy your code to prod. Organizations past a certain size have more hoops to jump through, for reasons.
Of course as a dev it’s ideal to have full access!
Putting up bash script that pulls repo and deploys it is already CI/CD.
Setting up basic Jenkins installation for a technical person should not be taking longer than 2 hours. For person who already is familiar with Jenkins that would be 30mins.
Once you have paying customers I would say there should be max and minimum 2 devs that can fiddle with prod. Others should pass changes via senior people.
If not, then that's a good signal they should invest more into their CI/CD setup, and like you said it's not necessarily a huge investment, but it can be a barrier depending on skills.
If you can't set up CI/CD you're not qualified to program anything
...so? You sit your ass down and learn. It might take a bit longer if you never touched shell but it's far easier than anything actual programming deals with, especially currently with set of ready or near ready recipes for every environment.
Really? even before github actions, circleCI did that sort of thing.
Gitlab's runners are nice an easy to configure. Plus all CI/CD is fancy bash with some git triggers.
FT.com used to deploy either directly through heroku to prod, or later via circleCI, and that was in 2015.
It takes next to no time to setup some basic one and not all that much time to setup decent one, and returns on investments are huge. There is no startup small enough where that isn't a good return.