5 ms·

If I'm a one man show, doing my own DevOps, what my best option? I'm technically proficient, but I want easy.

by ClayM 10y ago

samwillis 10y ago
Heroku
ewindisch 10y ago
If your app can fit the model, then PaaS, including "serverless" is a fine fit that eliminates many of the classic DevOps challenges. With "serverless" there are still many operational problems, however, so I'd only suggest this for those comfortable being early-adopters. For microservices architectures, having just gone through this, my choice was Google Cloud with Google Container Engine (Kubernetes). You build Docker images, deploy them, specify how those resources are connected, how many copies of each container should be deployed, etc. I didn't have to mess with Terraform, Chef/Puppet/Salt/Ansible, deploying Kubernetes, Swarm, or any other container management system. Because it's just Kubernetes, it's easy enough to bring on-premise or deploy on AWS. The main draw toward Amazon are all of the other services that they offer, of course. I see a lot of users of Kinesis, Redshift, etc. If you need them, then you need AWS, but deploying and managing your own apps brings many more barriers, IMHO.
johansch 10y ago
Google App Engine + their other no-ops services. Google is way ahead in this area.
jacques_chester 10y ago
I work at Pivotal, so I'm partial to Cloud Foundry. My workflow for deploying a new app for my own projects is to cd into the source directory and type cf push After a while I get tired of that, so I set up a Concourse pipeline and let it type `cf push` on my behalf, after going through the testing pipeline. Interestingly, I used to be much more bullish on moving from the buildpacks model to a container model a la everyone else in the PaaS space. To the point that I presented a case internally that buildpacks should essentially be pushed aside in favour of that model. But once I started actually writing Dockerfiles I changed my mind. It's a bloody inconvenience. Composition is not really A Thing in Docker, you can only stack. For all the talk about elegance (and it's elegant as an implementation), you're left with what is essentially a single inheritance hierarchy with no clean way to compose containers. The ability to get your app running immediately is something Heroku pioneered and Cloud Foundry continued (although, OK, if you insist on hurting yourself that way, you can push docker images too). Once you hand off the frankly boring business of automatically building a container to the platform, containers as the unit-of-deployment lose all of their magic. But again. I'm biased. I've only seen both alternatives up close in my day job and in my personal projects.
- deleted 10y ago
  [deleted]

If I'm a one man show, doing my own DevOps, what my best option? I'm technically proficient, but I want easy.

by ClayM 10y ago

If I'm a one man show, doing my own DevOps, what my best option? I'm technically proficient, but I want easy.

samwillis 10y ago

Heroku

ewindisch 10y ago

If your app can fit the model, then PaaS, including "serverless" is a fine fit that eliminates many of the classic DevOps challenges. With "serverless" there are still many operational problems, however, so I'd only suggest this for those comfortable being early-adopters. For microservices architectures, having just gone through this, my choice was Google Cloud with Google Container Engine (Kubernetes). You build Docker images, deploy them, specify how those resources are connected, how many copies of each container should be deployed, etc. I didn't have to mess with Terraform, Chef/Puppet/Salt/Ansible, deploying Kubernetes, Swarm, or any other container management system. Because it's just Kubernetes, it's easy enough to bring on-premise or deploy on AWS. The main draw toward Amazon are all of the other services that they offer, of course. I see a lot of users of Kinesis, Redshift, etc. If you need them, then you need AWS, but deploying and managing your own apps brings many more barriers, IMHO.

johansch 10y ago

Google App Engine + their other no-ops services. Google is way ahead in this area.

jacques_chester 10y ago

I work at Pivotal, so I'm partial to Cloud Foundry. My workflow for deploying a new app for my own projects is to cd into the source directory and type cf push After a while I get tired of that, so I set up a Concourse pipeline and let it type `cf push` on my behalf, after going through the testing pipeline. Interestingly, I used to be much more bullish on moving from the buildpacks model to a container model a la everyone else in the PaaS space. To the point that I presented a case internally that buildpacks should essentially be pushed aside in favour of that model. But once I started actually writing Dockerfiles I changed my mind. It's a bloody inconvenience. Composition is not really A Thing in Docker, you can only stack. For all the talk about elegance (and it's elegant as an implementation), you're left with what is essentially a single inheritance hierarchy with no clean way to compose containers. The ability to get your app running immediately is something Heroku pioneered and Cloud Foundry continued (although, OK, if you insist on hurting yourself that way, you can push docker images too). Once you hand off the frankly boring business of automatically building a container to the platform, containers as the unit-of-deployment lose all of their magic. But again. I'm biased. I've only seen both alternatives up close in my day job and in my personal projects.

deleted 10y ago
[deleted]