How to Deploy All Day yet Deploy Nothing
11–20 of 45 posts
Re: How to Deploy All Day yet Deploy Nothing
#12Note, 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…
It should be, but well... this is something if you're using PHP.
If you're using anything hipster (ruby, iirc python, Java) you're out of luck with that.
Re: How to Deploy All Day yet Deploy Nothing
#13Note, 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…
> Shouldn't deploying something on the web be a few minutes of FTP It should be, but well... this is something if you're using PHP. If you're using anything hipster (ruby, iirc python, Java) you're out of luck with that.
I worked on Cloud Foundry buildpacks for a while. The PHP buildpack is actually one of the more complicated ones, because at staging time it tries to recreate a shared hosting environment in a standalone container.
The Ruby buildpack is complicated for legacy reasons, but for 99% of modern apps all it really does is run bundler and rackup.
Meanwhile every PHP app wants to keep on living in the 90s.
Arguably the Java buildpack has the simplest job, if you use a sane build tool. "Here, launch this jar".
Re: How to Deploy All Day yet Deploy Nothing
#14Two 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 don't agree here. I'm definitely in the sysadmin camp but I'd like to think I've advanced from where I was when that was my job title 5 years ago or so.
For us, Cloud Formation was the real eye-opener. We leveraged CF to build a rather sophisticated environment. We referred the CF to our customers who then set it up on their own. We did this over several customers, with various degrees of AWS experience from zero to expert, and various backgrounds from security, to network, to IT. All were successful. I'd describe all as end-users.
The reproducibility, atomicity, and ease of this solution gave us huge gains.
Re: How to Deploy All Day yet Deploy Nothing
#15Note, 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…
You might have a database and a web app. But the database gets slow, so you add a caching layer. Then you need to scale up to accomodate more users. You've got to be able to back up all your users' data. And when your app gets complicated, deployments can break things, so you also need to be able to roll back quickly. Once you have a dozen or more servers going, you realize that if one goes down everything breaks, so you have to add redundancy to each part of the system, which adds even more concerns about how backups and recovery is handled. Then you need to add some search features to your growing dataset, which necessitates another kind of database to index your primary database, and more app servers. Oh, and by this point when things break, it becomes really hard to tell why things are broken, so you need monitoring and centralized logging, and whoops, those are two more kinds of databases and the associated web applications to manage them. And when you're at this scale, you have to coordinate multiple pieces of the system for any change you make, so you have additional software to manage that. And by now, you'll realize your original code was terrible, and while you are wise enough to know not to try to rewrite everything, you instead take various pieces of your infrastructure and break them into microservices in new languages, and...
Are you getting the picture?
Re: How to Deploy All Day yet Deploy Nothing
#16The 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
#17Note, 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…
If you have a static website, maybe. If you have a web application with millions of users, several large and complex data stores, and lots of functionality, things get complicated fast. Most critically, it's not a direct relationship. If you double the number of pieces in your infrastructure, your problems become four times as hard if not more. You might have a database and a web app. But the database gets slow, so y…
Re: How to Deploy All Day yet Deploy Nothing
#18Earlier quoted context omitted.
If you have a static website, maybe. If you have a web application with millions of users, several large and complex data stores, and lots of functionality, things get complicated fast. Most critically, it's not a direct relationship. If you double the number of pieces in your infrastructure, your problems become four times as hard if not more. You might have a database and a web app. But the database gets slow, so y…
Got it, but this guy was trying to deploy a 15-minute sample app.
Re: How to Deploy All Day yet Deploy Nothing
#19Earlier quoted context omitted.
If you have a static website, maybe. If you have a web application with millions of users, several large and complex data stores, and lots of functionality, things get complicated fast. Most critically, it's not a direct relationship. If you double the number of pieces in your infrastructure, your problems become four times as hard if not more. You might have a database and a web app. But the database gets slow, so y…
Got it, but this guy was trying to deploy a 15-minute sample app.
Re: How to Deploy All Day yet Deploy Nothing
#20Earlier quoted context omitted.
If you have a static website, maybe. If you have a web application with millions of users, several large and complex data stores, and lots of functionality, things get complicated fast. Most critically, it's not a direct relationship. If you double the number of pieces in your infrastructure, your problems become four times as hard if not more. You might have a database and a web app. But the database gets slow, so y…
Got it, but this guy was trying to deploy a 15-minute sample app.
If you want to experiment with an entirely new stack of technologies intended for deploying distributed, multi-tier, scalable apps, that's cool, but don't feign surprise if it takes you more than 30 minutes.