Earlier quoted context omitted.
I hope the HN community will stop doing easy smackdown comments like this. Someone spent a ton of time on this product. It's exciting and terrifying at the same time to post it on HN. That "terrifying" is completely unnecessary, and 100% caused by reactions like yours. At the very least, please write a "shit sandwich" next time. [Mandatory "Yada yada yada, I don't know the author, not affiliated to the product, bla b…
Sorry, my comment was intended to be direct feedback. I'll try to practice more emotional intelligence in the future.
Show HN: I wrote a book on web application deployment
121–129 of 129 posts
Re: Show HN: I wrote a book on web application deployment
#122Earlier quoted context omitted.
> frequently in the form of effusive praise I somehow doubt it's in the form of 5:1 ratio of effusive praise to questioning/criticism outside of the true top books there, and then to see this on a random ad where the OP swears he's not contacted anyone about the Show HN and yet all his "happy" "lurking" "customers" pop up with really sweet words within an hour is comical I understand people are nice sometimes, but it…
> it's clearly not organic here. And yet it's 100% organic here. I was few times on the HN frontpage with my blog (that links my book) so I was hoping some of my readers actually hang out here. I postponed Show HN a few months to get a few hundreds customers first. But that's it. You don't have to believe me, but it's the truth.
Re: Show HN: I wrote a book on web application deployment
#123I would not suggest this book to people who want to practice professional software deployments in 2021. This book is setting you up with a limited set of skills that are over-complicated and not best practice. For instance: Server configuration. You should not be monkeying around with OS configs. If you do, it should only be in something like a Docker container, which is an easily tested/updated versioned immutable r…
what would you recommend in its stead? for a similar audience
Everyone should read Continuous Delivery to start (https://www.amazon.com/gp/product/0321601912/ref=as_li_tl?ie...). It's 10 years old but it's still the canonical reference for how most people should be deploying in the modern age.
A book on containers would be the next thing I'd learn very thoroughly. Whether you run them in Docker on a single host, or run them in a cloud orchestration system, doesn't matter really. Just having an app in a container provides the abstractions you want to enable rapid, reliable deployment on multiple platforms. Most deployments should be dead simple: pulling and starting a new container, pointing traffic at the new container, stopping the old one. Rollback is the same in reverse order of container. There should be a billion different services to manage this for you, but you can also do it yourself on a single Linux box easily.
Then a book on database migrations, which isn't really complicated once you get the jist of it. This teaches the idea that if you're using a database, you have to think hard about how you're using it in context of your code deployments, and gives you a model for how to handle both reliably.
Next, the tools Terraform and Packer are very useful for handling the "infrastructure" side of deployment. If you manage an actual VM that runs your apps, build the image with Packer and deploy it with Terraform. It's much better to use some managed provider that just runs your containers so you don't need to deal with this. But if you do need to manage a host OS, this will make it seamless and reliable to do the inevitable maintenance in a way that you can test first, and recover easily from failure.
Ensuring your app works along the methods of the 12 Factor App (it's just a website, no book) will make sure it fits into all the tools and methods. If you just look for the deployment piece of every part of 12FA, you'll build a very robust deployment system.
Finally, learn Bash and how to set up a web server like Nginx (and how to use it as a reverse proxy) and you will have basically all the skills you need to do modern best practice deployments.
Re: Show HN: I wrote a book on web application deployment
#124Earlier quoted context omitted.
Nginx, in 2021, really? Envoy stomps it. https://www.loggly.com/blog/benchmarking-5-popular-load-bala... Also, what about caching, a-la at the top varnish, redis/memcache in the middle, and database tuning in the BE?
Yes, because: 1. It's popular and well understood. 2. It's included in the distribution and enjoys security fixes. 3. It's included in the distribution and shipped with good SELinux profile. 4. Since I use it to explain reverse proxy, I don't have to go into explaining new syntax (and people don't have to learn two different tools just for the sake of it). Most people will prefer the reasons above to a better perform…
It will be a bottleneck for anything real.
Plus, it's old and doesn't do what Envoy does. Nginx isn't a full-featured, live-reconfigurable L7 ingress RP. It's a toy.
Re: Show HN: I wrote a book on web application deployment
#125Earlier quoted context omitted.
Interesting about the total requests, but the article does not test.. balancing load? In a perfect world, 1 lb in front of 4 app servers should be able to serve 4x the requests as 1 lb in front of 1 app server. So I'd imagine 4x nginx back-end servers, and a baseline hitting 1 nginx directly? That, and the fact that the nginx config is shorter, and the performance not terrible (though terrible next to envoy in this t…
Its not, its still widely used also in kubernetes world. Tho a lot of traction is going for apps written in GO. Which supposedly makes them faster.
Re: Show HN: I wrote a book on web application deployment
#126Earlier quoted context omitted.
Nginx, in 2021, really? Envoy stomps it. https://www.loggly.com/blog/benchmarking-5-popular-load-bala... Also, what about caching, a-la at the top varnish, redis/memcache in the middle, and database tuning in the BE?
Interesting about the total requests, but the article does not test.. balancing load? In a perfect world, 1 lb in front of 4 app servers should be able to serve 4x the requests as 1 lb in front of 1 app server. So I'd imagine 4x nginx back-end servers, and a baseline hitting 1 nginx directly? That, and the fact that the nginx config is shorter, and the performance not terrible (though terrible next to envoy in this t…
And you don't necessarily need Nginx between an app and the LB if the app speaks http/s. DSR is an option too.
Re: Show HN: I wrote a book on web application deployment
#127This might just be paranoia but a couple of the early comments on this thread feel very astro-turfy. For example: https://news.ycombinator.com/threads?id=vich (hasn't commented since aug 2020) https://news.ycombinator.com/threads?id=matthieuchabert (hasn't commented for 10 months) https://news.ycombinator.com/threads?id=vivty is slightly sketchy as well but not super cut and dry
Aside: Is HN so fragile that it requires end-users to police anomalous activity? Given the age and influence of the platform I'd assume dang and co. who moderate and maintain the board are old hands at staying on top of manipulation of the platform. Could any mods comment on this? _Should_ we be keeping an eye out and calling out odd activity? It'd be nice to avoid posts like __blockcipher__'s; while well intentioned…
Re: Show HN: I wrote a book on web application deployment
#128Earlier quoted context omitted.
> it's clearly not organic here. And yet it's 100% organic here. I was few times on the HN frontpage with my blog (that links my book) so I was hoping some of my readers actually hang out here. I postponed Show HN a few months to get a few hundreds customers first. But that's it. You don't have to believe me, but it's the truth.
I’d be far likelier to believe you if it wasn’t so obvious and you didn’t protest so much.
Re: Show HN: I wrote a book on web application deployment
#129Earlier quoted context omitted.
Interesting about the total requests, but the article does not test.. balancing load? In a perfect world, 1 lb in front of 4 app servers should be able to serve 4x the requests as 1 lb in front of 1 app server. So I'd imagine 4x nginx back-end servers, and a baseline hitting 1 nginx directly? That, and the fact that the nginx config is shorter, and the performance not terrible (though terrible next to envoy in this t…
1 LB would be a SPoF. And you don't necessarily need Nginx between an app and the LB if the app speaks http/s. DSR is an option too.
In this setup both the "app" and the lb are SPOFs...