4 ms·

I seem to spend far more time on the deployment of code than I ever used to, more time writing CloudFormation and ansible than the Java backend, python lambdas

I seem to spend far more time on the deployment of code than I ever used to, more time writing CloudFormation and ansible than the Java backend, python lambdas and static UI that it deploys. That seems nuts to me. I'm not sure how you fix it without being Amazon/Google. People moan about Terraform too before that gets mentioned.

shadycuz 7y ago
I was actually just talking to a friend the other day about starting a company to solve this for fortune 500's. Nothing radical. Just a managed service provider that would build and maintain the CI/CD pipeline for them.
- deleted 7y ago
  [deleted]
ishi 7y ago
I recently heard about a startup trying to do something about this. Probably not totally mature, but might be worth a look: https://www.kaholo.io/ https://www.kaholo.io/ (I am not related to company in any way)
tbrock 7y ago
There is always heroku until your app is actually popular. Fake it till you make it.
markbnj 7y ago
> I seem to spend far more time on the deployment of code than I ever used to, more time writing CloudFormation and ansible than the Java backend, python lambdas and static UI that it deploys. I'd really like to understand more about what the pain points are here. In contrast to your experience I spend almost no time deploying code. We commit, tests run, we click a button and the deployment is updated in our kubernetes cluster. We did have to put a fair bit of work into our gitlab pipelines and the tooling that patches config into our kubernetes manifests and depoys them to the right place (let's say 2 person months all-in), but the payoff in the end was pretty significant. We're a fairly small company so if we could afford to put the time in to build the foundation for painless deployment I wonder what prevents larger orgs from doing this work? Is it access to the right skills? Difficulty prioritizing non-revenue tasks?
- cs02rm0 7y ago
  Part of it is perhaps that I mostly do consultancy work. So rather than a product a company lives and breathes through the success of, they're usually costs that just need to be done sufficiently, quickly and then left to run themselves. 2 months is an awful lot if the project only runs for up to 6 months. The last project I worked on was deployed to two different environments (double the headache in itself). One side required AWS CloudFormation (requirement imposed on us for that side to be serverless) which we were new to, so we brought in three different specialists one after another. None of whom could really help other than to tell us it was messy and confirm that we were on the right track. There was a time when I'd just drop a jar and an init script on a linux box for an MVP, now I'm looking up what the yaml should be for sticking a lambda in a VPC, or adding security groups to EC2 instances or whitelisting CloudFront access IP addresses. And redeploys involving CloudFront are slooow. I think that project must have used a dozen AWS services and a few thousand lines of CloudFormation - for deploying perhaps half that many lines of code.
- j4yav 7y ago
  As an aside, GitLab PM for CI/CD here. It would be awesome to hear about what you built and how we could have made that learning and setup process easier. Feel free to DM me on Twitter? @j4yav
  - markbnj 7y ago
    > As an aside, GitLab PM for CI/CD here. It would be awesome to hear about what you built and how we could have made that learning and setup process easier. Feel free to DM me on Twitter? @j4yav Honestly most of the effort was not in the gitlab pipelines. We found those facilities easy enough to understand and implement. Most of the work went into the tooling layer between gitlab and our runtime environment. My email is in my profile if you'd like to reach out with more specific questions.
timdorr 7y ago
We're working on this at Spaceship: https://spaceship.run https://spaceship.run We've still got a lot to build, but the goal is zero config deployment for any app/service.
zelly 7y ago
We're in a weird transition period where developers are being forced to do ops. People will wake up to the fact that this so-called automation was just changing one type of work into another. Eventually there will be jobs called "build system engineers" and there will be a whole department that does this bookkeeping for you.

shadycuz 7y ago

I was actually just talking to a friend the other day about starting a company to solve this for fortune 500's. Nothing radical. Just a managed service provider that would build and maintain the CI/CD pipeline for them.

deleted 7y ago
[deleted]

ishi 7y ago

I recently heard about a startup trying to do something about this. Probably not totally mature, but might be worth a look: https://www.kaholo.io/ https://www.kaholo.io/ (I am not related to company in any way)

tbrock 7y ago

There is always heroku until your app is actually popular. Fake it till you make it.

markbnj 7y ago

> I seem to spend far more time on the deployment of code than I ever used to, more time writing CloudFormation and ansible than the Java backend, python lambdas and static UI that it deploys. I'd really like to understand more about what the pain points are here. In contrast to your experience I spend almost no time deploying code. We commit, tests run, we click a button and the deployment is updated in our kubernetes cluster. We did have to put a fair bit of work into our gitlab pipelines and the tooling that patches config into our kubernetes manifests and depoys them to the right place (let's say 2 person months all-in), but the payoff in the end was pretty significant. We're a fairly small company so if we could afford to put the time in to build the foundation for painless deployment I wonder what prevents larger orgs from doing this work? Is it access to the right skills? Difficulty prioritizing non-revenue tasks?

cs02rm0 7y ago
Part of it is perhaps that I mostly do consultancy work. So rather than a product a company lives and breathes through the success of, they're usually costs that just need to be done sufficiently, quickly and then left to run themselves. 2 months is an awful lot if the project only runs for up to 6 months. The last project I worked on was deployed to two different environments (double the headache in itself). One side required AWS CloudFormation (requirement imposed on us for that side to be serverless) which we were new to, so we brought in three different specialists one after another. None of whom could really help other than to tell us it was messy and confirm that we were on the right track. There was a time when I'd just drop a jar and an init script on a linux box for an MVP, now I'm looking up what the yaml should be for sticking a lambda in a VPC, or adding security groups to EC2 instances or whitelisting CloudFront access IP addresses. And redeploys involving CloudFront are slooow. I think that project must have used a dozen AWS services and a few thousand lines of CloudFormation - for deploying perhaps half that many lines of code.
j4yav 7y ago
As an aside, GitLab PM for CI/CD here. It would be awesome to hear about what you built and how we could have made that learning and setup process easier. Feel free to DM me on Twitter? @j4yav
- markbnj 7y ago
  > As an aside, GitLab PM for CI/CD here. It would be awesome to hear about what you built and how we could have made that learning and setup process easier. Feel free to DM me on Twitter? @j4yav Honestly most of the effort was not in the gitlab pipelines. We found those facilities easy enough to understand and implement. Most of the work went into the tooling layer between gitlab and our runtime environment. My email is in my profile if you'd like to reach out with more specific questions.

timdorr 7y ago

We're working on this at Spaceship: https://spaceship.run https://spaceship.run We've still got a lot to build, but the goal is zero config deployment for any app/service.

zelly 7y ago

We're in a weird transition period where developers are being forced to do ops. People will wake up to the fact that this so-called automation was just changing one type of work into another. Eventually there will be jobs called "build system engineers" and there will be a whole department that does this bookkeeping for you.