How to Deploy All Day yet Deploy Nothing
1–10 of 45 posts
Re: How to Deploy All Day yet Deploy Nothing
#2The sad part is that it's even worse when using windows. The only thing I've got working without too much yak-shaving was node, but anything devops-y is a pain including vagrant, otto and even the package manager (chocolately)
Re: How to Deploy All Day yet Deploy Nothing
#3"I’ve wasted the whole day exploring new things and concepts" is a weird thing to say after you set out with the goal of learning some new tools. Definitely seems like he learned something.
Re: How to Deploy All Day yet Deploy Nothing
#4Two important points the author (re-)discovered here, that are really not as commonly known as they should be:
1. Docker is a first-class citizen on Linux, and a second-class citizen everywhere else. "Setting up Docker" on Linux means installing the Docker daemon. "Setting up Docker" on OSX or Windows means installing a Linux VM containing Docker and getting it to port-forward the docker daemon from that VM to your host. After it's set up, there's no day-to-day usage difference—but that stumbling block is a big one.
2. Nothing AWS offers—no matter how much it might look that way—is an end-user platform. It's all infrastructure, the kind of thing sysadmins set up/deal with. Infrastructure-as-a-Service effectively means "our market is bigcorp CIOs making buy-vs-build decisions": decisions of whether to provision more local data-center infrastructure, or provision that same infrastructure "in the cloud."
In other words: Elastic Beanstalk isn't for prototyping an instance of your app! Instead, it's for CIOs considering replacing "our data center containing a bunch of machines with docker daemons on them" with "our AWS VPC containing a bunch of opaque instances with docker daemons on them." The same goes for every other AWS service: the documentation and "semantic models" of AWS services are not targeted at app developers, but rather at the sysadmins who were implementing the CIO's whims by keeping local infrastructure going at-scale, and are now implementing the CIO's whims by porting said infrastructure to the Amazon cloud.
AWS might be intuitive to you as a developer if you have 5+ years of devops experience, deploying your own code and and managing the infrastructure it sits on. Otherwise, the choices AWS offers will be pretty opaque to you.
(Side-note: there's a business model [that AWS allows and encourages] in taking an AWS IaaS-level component, and shellacking a coat of UX onto it to make it into a PaaS component, and making your money by arbitraging on the "PaaS premium." Heroku is PaaS-shellacked EC2 instances; Tarsnap (or Dropbox, even) is PaaS-shellacked S3 buckets; etc. I'm surprised more of these businesses don't exist.)
Re: How to Deploy All Day yet Deploy Nothing
#5The sad part is that it's even worse when using windows. The only thing I've got working without too much yak-shaving was node, but anything devops-y is a pain including vagrant, otto and even the package manager (chocolately)
That's funny because I was about to say the complete opposite.
Re: How to Deploy All Day yet Deploy Nothing
#6Note, I'm definitely not a web developer. I've put static web pages together and fooled around with Rails & Heroku a little. So, as an outsider, I'm curious: How did you all (the web development community) make DEPLOYMENT so complicated? All these packages and environments and VMs and containers and environment variables. Shouldn't deploying something on the web be a few minutes of FTP and then go do something more productive the rest of the day? What am I missing?
Re: How to Deploy All Day yet Deploy Nothing
#7Two important points the author (re-)discovered here, that are really not as commonly known as they should be: 1. Docker is a first-class citizen on Linux, and a second-class citizen everywhere else. "Setting up Docker" on Linux means installing the Docker daemon. "Setting up Docker" on OSX or Windows means installing a Linux VM containing Docker and getting it to port-forward the docker daemon from that VM to your h…
> Once it's set up, there's no day-to-day usage difference
On a laptop you now have an extra OS running, with all the associated costs: talking to disk every now and then, doing os-y things.
If nothing else, it feels like my battery runs out faster with docker-machine on and no containers running. But maybe somebody has actual numbers on this?
Re: How to Deploy All Day yet Deploy Nothing
#8I guess my question is: why not Heroku?
Or, since I work for Pivotal: why not Pivotal Web Services?
The Ruby buildpack (which is > 90% identical code between the two) is pretty well-tested for deploying Rails at this point.
Re: How to Deploy All Day yet Deploy Nothing
#9Note, I'm definitely not a web developer. I've put static web pages together and fooled around with Rails & Heroku a little. So, as an outsider, I'm curious: How did you all (the web development community) make DEPLOYMENT so complicated? All these packages and environments and VMs and containers and environment variables. Shouldn't deploying something on the web be a few minutes of FTP and then go do something more p…
When your dev teams are strewn all over the world and the lowest common manager with the people managing the OS is the CTO 6 layers up, you will find making things "just work" get exponentially more difficult and all sorts of workarounds and safeguards have to be put in to ensure small changes introduced by other teams do not screw up your portion of the app and vice versa, eg not letting the OS team control the JVM for fear security and performance decisions by the OS team will cause unexpected deployment problems... which will lead to performance and security problems that need to be worked on without OS team involvement...
Of course this is a slippery slope and often devs not familiar with RPM eg end up reinventing the wheel as each deployment failure breeds distrust between teams and more workarounds and safeguards get introduced.
Re: How to Deploy All Day yet Deploy Nothing
#10Two important points the author (re-)discovered here, that are really not as commonly known as they should be: 1. Docker is a first-class citizen on Linux, and a second-class citizen everywhere else. "Setting up Docker" on Linux means installing the Docker daemon. "Setting up Docker" on OSX or Windows means installing a Linux VM containing Docker and getting it to port-forward the docker daemon from that VM to your h…
> I'm surprised more of these businesses don't exist
Oh, they do; but because they target niches, they might be small and not be on your radar. Also, the whole field is still pretty green, in the grand scheme of things; as you say, it takes years to be able to properly leverage the AWS ecosystem.