Show HN: I wrote a book on web application deployment
deploymentfromscratch.com
deploymentfromscratch.com
The book however does not go into detail on these tools (ansible, terraform), its goal is to teach the basics of deploying an app on a linux vps.
> So, what is a CPU anyway? A central processing unit (CPU) is your processor (or processor core).
> Nevertheless, making a thread-safe code unsafe is more than easy and so if your application works with threads in some ways, make sure things work as expected.
Cut the filler and just say what you're trying to say.
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 bla" here.]
Also, for taking apps to production, there should definitely be a part on high availability.
As for high availability I discuss whether it's worth it or not in the Scaling chapter. I also show how to use NGINX as a load balancer. I currently don't have HA content written for PG and Redis, but there are planned (as a free update).
It is a review of the most fundamental tools and strategies in Red Hat flavored Linux distros. Things like troubleshooting the entire stack would be far too advanced and specific.
Ad 12-factor. Some makers are better off not to follow everything. For example, it's fine to use server disk space for a single server. So I don't want to include it as dogma.
Ad CI/CD. You either build it yourself (and the book gives you the technical knowledge to do it) or use a vendor (GitHub/GitLab/Circle CI). I actually want to do a bit more on CI/CD, but thinking how to approach it.
There is a reason it's called "from Scratch", because I cover starting out. Some things bootstrapping startups don't need (there are only nice-to-haves). I will update and improve the text based on feedback, though (including the comment above).
@strzibny, it would be great if you can put some curated links or references at the end of the book so the reader know where to go if they want to go deeper in that particular topic. It would really improve the value that some of us get from the book.
I am Josef, a full-stack developer, a formal Ruby Linux packager at Red Hat, and an author of Deployment from Scratch (which is this post about!).
After working at Red Hat and technically leading a start-up (of which I was the primary production engineer), I decided to write down a resource I felt was missing on the market:
A book that gives you the confidence to deploy your first application focused on fundamental, transferable, and long-lasting skills rather than tools of the day:
* You'll learn about networking, Linux, systemd, deployment strategies, web servers, application servers, databases, and containers.
* You'll be able to deploy Rails or Django applications (or anything really) together with production PostgreSQL and Redis databases. All automated with just a few lines of Bash.
What's unique about this book:
* It's a comprehensive book where things are designed to work together. I take readers from general networking knowledge to databases and containers. It's for beginners, but I am not skipping anything, not even SELinux.
* There are no abstractions, just Bash. I believe in learning the actual thing rather than an abstraction. Abstractions are great once you know what they are abstracting.
* Everything is done on Enterprise Linux with full SELinux support. While I have happy readers using Ubuntu, I thought the market doesn't have a good CentOS/Rocky/RHEL book.
There are three scripted demonstrations, cheatsheets, and a security checklist, apart from the book content. The demonstrations include:
* A git-push deployment of a database-backed Ruby on Rails application with Encrypted Credentials and Action Cable
* A self-sufficient PostgreSQL cluster with automatic system upgrades, log rotation, and TLS
With these demonstrations, you can be up and running quickly and also save a lot of money on Heroku :)
Stats so far:
* Took me more than 3 years to write (1+ year of fulltime billable time)
* Built a mailing list of more than 600 interested people
* Sold 366 copies
* 22 readers gave the book 5-star rating
The table of contents and the first small chapter: https://deploymentfromscratch.com/previews/intro.pdf
A special SHOW HN preview of the Web Servers chapter: https://deploymentfromscratch.com/previews/show_hn_preview.p...
Buy on Gumroad: https://gum.co/deploymentfromscratch
I am around to answer any questions.
Josef
p.s. You can use "showhn" discount code at checkout for 20% off as a thank you to this community that put my posts several times on the HN frontpage ;)
Your website comes off as hustle to get money without content:
* The first section where you describe your product, you avoid all that the product is, making me think you don't actually have content which you want to show off(the book image is digital with no mention of it being an ebook, the description is about me and tehnologies, no preview, no list of concrete things I learn)
* In the next section you continue marketing a dream instead of the actual content, then you sell reviews, a story and others' opinion. Again, I conclude that you don't want me to form my own opinion of potentially bad content.
* "What I'll get" is meta content, things I should see after being sold the content. At that point I clicked off the website thinking it's a scam.
Before commenting this I went one more time to make sure I didn't miss anything and discovered that you actually do have chapters content and preview, just past the point where I clicked off.
It was clear to me the content I was supposed to get.
The only reason I didn't purchase is because the value proposition "save time managing your own side-project/startup deployment" is not smart, to me at least.
I decided to pay and outsource most of these things away in order to focus on differentiating software, marketing/sales and peace of mind.
Edit: I also think the "start a career in SRE" is quite a long stretch.
> the value proposition "save time managing your own side-project/startup deployment" is not smart
I would say it's not right for all. But it's 100% true (from my readers) that people learn self-hosting to cut costs. That part of the page targets these people.
> I decided to pay and outsource most of these things away in order to focus on differentiating software, marketing/sales and peace of mind
I want to say that the saving angle is only one of the reasons pointed out. If you want to know how things work and don't care about saving, it's still worth to learn it.
I think you are not the target audience, though, since you want to focus on other aspects of the business which you probably enjoy more. :)
> I also think the "start a career in SRE" is quite a long stretch
The book shows you lot of Linux content you can find in RHCSA and RHCE exams. If you would really learn what's in it, you can be hired on spot for a junior role.
I've done this kind of work in the past and would certainly enjoy learning more. Your book was inviting. I just won't have the time at this moment. Need to focus elsewhere, as I said.
When thinking about business, the initial scale is quite small and managed services are cheap (and a variable cost) compared to the time I'd spend on self-managed (high upfront, fixed cost).
I agree I should clarify it's an ebook sooner in text. And I want to redo the chapters. But I get a lot of conflicting feedback so hard to know what's right.
The page has a good conversion, though. So something is working.
I just don't think small startups or side-projects should spend so much time getting all the configuration and moving parts right compared to just Docker+Terraform+(IaaS of choice). Then if one is on a tight budget, then just run Docker Compose on a single host, or run on a computer at home being proxied by Cloudflare free account. If able to spend more, then use the IaaS managed services like for containers and databases.
I guess I feel that setting people up to deploy with bespoke Bash scripts is borderline irresponsible since they won't be easily, or automatically, updated in case there are any other issues, unlike something like Terraform. I can't tell that easily however because there is no architectural diagram to help understand what the book leads up to as how one should deploy things.
However it seems more like it would be a better guide as "Linux Servers from Scratch"? That would be something which would be good reading for someone new to tech. Before moving onto higher abstractions. Or being used as the from scratch guide on how to customize container images by more experienced programmers, but those missing the Linux admin fundamentals.
Hype aside, I'd add serverless. One can build a lot of stuff with very little hassle on top of AWS Lambda, API Gateway, DynamoDB and S3.
> I just don't think small startups or side-projects should spend so much time getting all the configuration and moving parts right compared to just Docker+Terraform+(IaaS of choice).
It's the opposite actually! I show you how to avoid a lot of indirection and have a deploy script in 200 lines of Bash that you understand in an afternoon.
If you choose to use Docker, I have a full chapter of building containers, doing Docker networking, running containers with the Docker engine or with Podman like any other systemd service.
You can then write a small Bash script to install Docker and deploy your container or write an abstraction in a tool like Ansible. That's your choice and I think I present good arguments for both.
> deploy with bespoke Bash scripts is borderline irresponsible
Only like 5% of the book spends time talking about how to glue everything with Bash. Most is networking, permissions, configuration. The idea is to see how things are done with the most basic building block which is a shell.
The thing is shell code is how you interact with your operating system unless you are using C API. It's what most deployment tools use under the hood, not to mention that many tools are basically Bash (ruby-install, chruby) or based around executing it (Dockerfile).
> However it seems more like it would be a better guide as "Linux Servers from Scratch"?
I already renamed the book twice :). Not anymore, please ;). Most people actually told me they don't care for the name at all. Yes, there is a lot of Linux, but I named it after the intent. The intent is to deploy at the end. The fact that most of the deployment is configuration is implementation detail.
The demonstrations are made alongside the indie hackers/early-stage startup mindset. Run a single server, or possibly single server with a dedicated database.
I wrote my own book about Ruby for beginners https://leanpub.com/rubyisforfun, and converted it to a course, which is quite fun https://www.educative.io/courses/handbook-ruby-developers
Released 1-2 weeks ago, but it looks to me like a promising future - the new format of books that are more interactive. Website allows to run snippets, do interactive assessments, and so on.
The reading and learning is much more convenient.
It shows - very polished. Have you described your process for writing the book anywhere? Given the quality of the landing page and samples, I'd also be interested in that.
I didn't split it into tears (book, book+code, book+code+...), because I think it works better together. I do realize I am losing some customers this way.
I already lost more then one year of earnings working on the book and I couldn't afford a professional editor. So editors are only volunteers, and therefore I don't have a single editor for the whole book.
(I know that as a potential customer you don't care about my excuses, I am just explaining my situation. Earning money on technical content is hard.)
I also use some Ruby for preprocessing (when building other formats), previews, etc. Someone submitted my post on that to HN a while ago so there is some discussion here: https://news.ycombinator.com/item?id=28594863
This is especially true for security. How do you know things are secure once your deployment works?
Needless to say, I'm looking forward to this book.
If you'll have any feedback for me or questions down the line, just send me a DM.
It goes in depth on many subjects like provisioning, configuration and deployment. For a beginner like me it's perfect.
Highly recommend for web developers who wants to understand better how a server works under the hood and how to deploy it.
I want to know how to push only pre-configured dependencies without Docker. So no build tools in production, just pre-built binaries. (Specifically not building gems on the production server.)
Basically you need to build your .so files beforehand and then copy them over. If you use the same system as your target you can just copy gems' files around.
A good approach (which we did at Red Hat) is to repackage gems as RPMs and then install them as other system packages. But it's a lot of work. Fedora has a whole default Rails stack packaged, though.
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 repeatable closed environment that runs everywhere. Monkeying with server configuration is a quick path to becoming a systems administrator, introducing unnecessary bugs, and increasing complexity. Try to avoid using software that is platform-specific (see next point).
Services with systemd. You should probably not use systemd to manage services. The primary reason is that you might not fully control the system you run services on if it's a multi-user system, and you need to have system control to modify systemd. It's also generally not portable outside of a Linux system. In the cloud you would ideally be using a deployment or orchestration system which has its own configuration format and method to run services, obsoleting systemd. The most portable service manager you could learn to use would be runit (even Busybox has an implementation of it), and after that, whatever one you choose that you can run as an unprivileged user. You can then run your preferred service manager as a systemd service, or in a container, etc.
Databases. Try not to get into monkeying around with backups and restores. Find some kind of managed provider that can do simple snapshots before deployments and easily restore them. Doing it manually is painful, and automation could be done better by a managed provider than trying to roll it yourself. However, you should be familiar with Flyway-style database deployments.
SELinux. You should not have to learn how it works to deploy. But if you do, get a dedicated book on it.
Storage concerns. Don't use networked filesystems for production. You can, in the sense that you can toast bread in the bathtub, but I wouldn't recommend it.
Backups and restores. Use versioned immutable artifacts in an artifact repository. Use a managed backup service/tool/etc for whatever doesn't work that way.
I don't see mention of caching proxies, reverse proxies, or CDNs. These can get tricky, from being careful about headers to preserving source IPs to invalidating stale caches to load balancing and resource limits.
I don't see any mention about continuous deployment, continuous integration, the 12 Factor App, or Immutable Infrastructure. All these are core components of modern deployments.
And as much as I hate it, Kubernetes is slowly of eating the entire world of modern systems, so learning how deployments work on it is essential to working in modern professional settings.
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.
My intention wasn't writing a book on fancy-cloudy deploys for enterprises, but teaching people more about systems they use. I deploy my side projects the way I describe in the book, and I can tell you I have a good time, because everything is straightforward and easy-to-fix.
* Ad Server configuration: I explain deployment with and without containers. People can choose the right path for them. If you would read the book, you might have realized there is not all that much system configuration after all and it's easy to keep up.
* Ad Services with systemd: Hard disagree. systemd-based distributions (Fedora, CentOS, RHEL, Ubuntu, Debian) are eating the Linux world. systemd is an init system, so even if you don't write a systemd service on your own, you should understand how they work (your databases, firewalls, system services, and even Docker would be managed as a systemd service).
* Databases: This book is not an argument for running the database yourself, but about how you can do it with just 20 lines of Bash. People should decide themselves what's best for the project at hand.
* SELinux: You should absolutely learn it as it's a security layer of your Linux systems. Most resources skip it and then people don't feel confident running with SELinux, and thus deploy less secure systems.
...
I see your whole argument looks like let's run Kubernetes. I don't think it's the right choice for indie hackers and early startups (the target audience of my book).
If you want to go the path of Kubernetes, than my book gives you a great introduction to networking and Docker which are prerequisites for understanding and working with K8s. And SSH, Puma configs, encrypted backups, and other topics are same whether you have K8s or not.
I only use Kubernetes at work, and I prefer doing things without it.
4 CPU cores, 16 GB of RAM, and automated backups for barely €15 a month.
Where can you get a VPS for so cheap, I do not think even Hetzner goes that low?
This is the service I use: https://www.netcup.eu, and by the way I recommended it too.
I also have BuyVM.net instances as well. They are also excellent and have been around a long time.
(don't judge me!)
(It's a joke, but as a Red Hat guy I yet have to see it in real life to believe it.)
My last Windows was XP, but I actually use Azure at work right now. If you want to mostly do cloudy things (use clouds for more than simple VMs), you might want to look into certifications[0].
[0] https://docs.microsoft.com/en-us/learn/certifications/browse...
I'm excited to dive in!
And thanks!
Web Protection by Bitdefender Dangerous page blocked for your protection https://deploymentfromscratch.com/ Dangerous pages attempt to install software that can harm the device, gather personal information or operate without your consent.
TAKE ME BACK TO SAFETY I understand the risks, take me there anyway If you know this page is not dangerous, you can add it to your Exceptions list. Be aware that you will not be warned about any threats existing on this pag
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
I find it very hard to believe the ratio of happy purchasers already seeing value vs. questioners about what this really is being 5:1 or more. Sad to see.
I swear nothing was solicited. I just posted it myself and waited. No Twitter, no mailing lists, nada.
There's a whole successful social network (Goodreads) built on people's desire to talk about books, frequently in the form of effusive praise. I think being able to trace the product to a single individual (e.g. a book's author) helps make it particularly appealing to leave that sort of feedback: we know it feels great to hear that someone values a thing you've created, and we like the idea of giving that pleasure to the creators of things we like.
If you’re just looking at the top reviews for a book it’s more questionable; they tend toward the extremes: enraptured encomiums about how beautiful and important and bold the book is, or insult-laden rants where the book is a whipping post for the reviewer to show off what a biting sense of humor they have.
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'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.
Pretty much everything about this guy rubs me the wrong way. The usual cheesy testimonials / vague promises of content which never really gets previewed, the obvious astroturfing, which he continues to respond to as if they're organic genuine comments, etc. Just leaves a really bad taste in my mouth.
Testimonials, podcasts appearances, and comments here were not solicited. People just did that on their own.
Jeremy from Software Engineering Radio actually really bought the alpha version, and his invitation to the podcast was out of the blue. Jason didn't buy my book (I think) but wanted to talk about it. Juan sent me his testimonial himself. And I wasn't their friend beforehand either.
> never really gets previewed
I linked two previews, one is a full chapter. I also have like 8 readable screens of good quality on the book page.
As you mentioned, I was flat-out wrong about the previews. Not sure if I scrolled straight past that section or what.
Wishing you the best with your book. And FWIW I like the bash-based approach; I agree with the philosophy of peeling away the abstraction layers.
Thank you!
The comments could have been seen as odd, but your openness suggests it was just a coincidence.
Also, congrats on writing a full book!
> Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.
I believe that means that asking people to leave positive comments on a post is something the guidelines ask you not to do.
But I would agree that, for instance, just posting on your social media "I posted this on HN, check out the comments" by itself should probably be fine, and might result in the same behavior, it's kind of a fuzzy line.
Please don't actually ask people to leave positive comments though. Or post something that you hope people read-between-the-lines the same way.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
I never talked to the author, I only follow him on Twitter.
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 I could see such commentary having a chilling effect on discourse.
https://news.ycombinator.com/item?id=29542871
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
That guideline makes sense to me. I was previously unaware of it [the guideline] but the justification is sound, doubly so because it turned out the comments were genuine* :) My apologies.
* Albeit at least one user presumably found the post via Twitter from following the author which is a little bit of a grey area
"Deploy Ruby, Python, PostgreSQL, and Redis."
But to provide more value I chose certain language runtimes and databases, because writing only in general is not as useful and tangible. What it means is that a chapter on application servers goes through some options you want to look for, and after that discusses configuration of Puma and Gunicorn as examples.
So if you are running Node.js, I don't have (currently) specific configuration directives listed, but you would know what to look for.
I might add more to the current list, but obviously I can never cover everything.