Live data from Hacker News

You might not need Kubernetes

blog.jessfraz.com

151–160 of 319 posts

Re: You might not need Kubernetes

#151

Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP. I manage dozens of apps for thousands of users. The apps are all on one server, its load average around…

I personally use Docker combined with a $5 droplet on Digital Ocean. This makes it easy to spin up multiple applications and sites without worrying about conflicting dependencies, and docker-compose gives me most of the benefits of orchestration tools (e.g. Kubernetes) that actually matter for my small scale usage. Also Traefik makes a nice load balancer for this uage

> docker-compose gives me most of the benefits of orchestration

I feel this is a very unappreciated feature of docker-compose. I've gotten pretty far with setting restart: always, baking a machine image, using cloud scaling and load balancers.

Re: You might not need Kubernetes

#152

Maybe someone here can help me figure out what I need, since the world of containers is growing faster than I can understand. I have one code base that I run on multiple servers/containers independently of each other. Think Wordpress style. I used to run it on Heroku but I switched to Dokku because it's substantially cheaper and I don't mind taking care of the infrastructure. I like Dokku but I do worry about being t…

Never really tried it, but when I was looking for Dokku and Flinn alternative, I found this: https://captainduckduck.com/

Re: You might not need Kubernetes

#153
post #65
post #43

Earlier quoted context omitted.

I don't know. I've always found having an actual, functional product to be more impressive than a list of buzzwords on your resume. And most of the buzzword-driven development doesn't usually lead to a functioning system.

If you're buzzword compliant, you can fail forward. Your last product may not have worked out, but you've become an expert in Docker, Kubernetes, AWS, OpenShift, and Terraform which means that companies who are committed to the cloud (i.e., everybody) won't pass you over. Built an app that works before the cloud hype hit? Congratulations. You're a specialist in legacy technologies. We'll call you if we have a COBOL o…

No companies worth working for hire that way. What you are describing is a way to get jobs at startups or non-tech companies that don't have a good grasp on fundamentals.

Re: You might not need Kubernetes

#154
post #65

Earlier quoted context omitted.

If you're buzzword compliant, you can fail forward. Your last product may not have worked out, but you've become an expert in Docker, Kubernetes, AWS, OpenShift, and Terraform which means that companies who are committed to the cloud (i.e., everybody) won't pass you over. Built an app that works before the cloud hype hit? Congratulations. You're a specialist in legacy technologies. We'll call you if we have a COBOL o…

No companies worth working for hire that way. What you are describing is a way to get jobs at startups or non-tech companies that don't have a good grasp on fundamentals.

From my experience a lot of companies (not all) work that way. I am little stuck in some legacy tech and during interviews it looks like they can't even conceive that someone may learn their stack quickly.

Re: You might not need Kubernetes

#155

Earlier quoted context omitted.

I imagine if you have an ops team, they're going to continue to pray every time you have to upgrade k8s or a supporting underlying service and the expectation is that everything will continue to function without dropping an inbound request. I imagine they are going to be less than impressed being on call for something that is essentially still in beta. And if you have no ops and your devs are responsible for it, god…

Man, I wish I could give you more upvotes for this sentiment. Making the decision to put the livelihood of a company on any platform is not to be taken lightly. As an SRE I feel like I have to take a slightly conservative approach to new technologies.

Do me a favor and pay it forward. When technology decisions are made, look at them with a conservative eye. Make absolutely sure the technology selected is being selected for the right reasons (ie not resume driven development, premature optimization, culture signaling, or because it's "new" it must be better). It'll pay dividends for whomever has to operate it, as well as the business.

Re: You might not need Kubernetes

#156

Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP. I manage dozens of apps for thousands of users. The apps are all on one server, its load average around…

> Some day I would like a powwow with all you hackers about whether 99% of apps need more than [...]

Close. But I also need it HA w/ automatic failover, auto-SSL certs (meaning I might need to give my DNS provider creds depending upon LE approach), notifications on outages, easy viewing of logs past and present, easy metric viewing, automatic backups, and updates that are easy for me to sign off on to then run. I'll do the plugging on the app side (that is exporting metrics, logs, etc). And no vendor-specific solutions (even if they are repackaged common components like RDS is for Postgres), I should be able to run on a couple VMs on my laptop if I want and it be the exact same. And I may want to add an MQ/stream (e.g. Kafka), in-mem DB (e.g. Redis), etc later and still want log aggregation, metrics, backups, etc.

Really, that's not asking too much but it's definitely more than LAMP. We need a pithy name for this startup-in-a-box (again, that's NOT a PaaS, but a self-hosted management on an existing set of servers). Nobody wants to fumble w/ Ansible/Puppet/Salt/Chef/whatever all over the place or hire an ops guy, and people don't want to use vendor-specific solutions.

I agree with the "you only need this"...but we need just a bit more to handle outages and auditing.

Re: You might not need Kubernetes

#157

Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP. I manage dozens of apps for thousands of users. The apps are all on one server, its load average around…

Spot on, friend.

So recently I started writing a simple web application for my family. They send emails to each other with gift wish lists in them and we all have to juggle those emails around. I figured some products would exist already to solve this problem, but I wanted to make my own.

When it came time to make it I thought: "This has to be a REST API with a JS front end" and then further down the line, "Man I should use Flutter and only make it a mobile app!" I had other thoughts about making it Serverless and doing $thisCoolThing and using $thatNewTech. In the end nothing got done at all.

Fast forward to today and it's a monolith Go application that renders Bootstrap 4 templates server-side, serves some static CSS directly, sits on a single server (DigitalOcean) and uses a single PostgreSQL instance (on the same server). The Bootstrap 4 CSS and JS come from their CDN.

I made the technology simpler and the job got done. It's an MVP with basic database backups in place, using Docker to deploy the app. It just works.

Lessons for me from this:

* Server-side template rendering is perfectly fine and actually easier, frankly * JS can still be used client-side to improve the experience without replacing the above or making the entire rendering process client-side * Although Go compiles to a single static binary I still need other assets, so it went into a Docker container for the added security benefits not to mention portability * Serverless is nice, but unless it's replaced the above day-to-day, there's always a steep learning curve around something you haven't done with it yet, but need * Picking the latest and greatest tech tends to stagnate progress or halt it entirely, in most cases * An a software MVP needs an MVP infrastructure to go with it

Just my thoughts.

Re: You might not need Kubernetes

#158
post #133

Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP. I manage dozens of apps for thousands of users. The apps are all on one server, its load average around…

As someone who runs a very successful data business on a simple stack (php, cron, redis, mariadb), I definitely agree. We've avoided the latest trends/tools and just keep humming along while outperforming and outdelivering our competitors. We're also revenue-funded so no outside VC pushing us to be flashy, but I will definitely admit it makes hiring difficult. Candidates see our stack as boring and bland, which we ma…

Good on you mate. I love this approach.

I'll be doing the same thing my self with a few products I'm developing with my brother.

"Keep it simple, keep it stable" is what I like to say.

Re: You might not need Kubernetes

#159
What bothers me about k8s is that it promises a lot ("15 years of experience of running production workloads at Google" at your fingertips! yay!) but it's in fact still a young, ever-changing solution.

Even developing an app locally with minikube is a PITA for a lot of reasons. From Helm to Telepresence to Skaffold, every tool out there is just unpolished and overambitious.

Don't want to imagine how those problems might amplify in production.

Re: You might not need Kubernetes

#160
post #87

Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP. I manage dozens of apps for thousands of users. The apps are all on one server, its load average around…

As somebody who has his own colocated server (and has since Bubble 1.0), I definitely agree that the old-fashioned way still works just fine. On the other hand, I've been building a home Kubernetes cluster to check out the new hotness. And although I don't think Kubernetes provides huge benefits to small-scale operators, I would still probably recommend that newbs look at some container orchestration approach instead…

You can put everything in containers and still not need much orchestration, though. My personal projects run in dozens of containers, and the "orchestration" consists of a Makefile include pulled into each project that creates a systemd service file based on some variables, and pushes it into the right place. The service files will pull down and set up a suitable Docker container. The full setup for a couple of dozen containers is 40-50 lines of makefile and a ~20 lines or so of a template service file.

Of course it won't scale to massive projects, and for work, I occasionally use Kubernetes and other more "serious" orchestration alternatives, but frankly it takes fairly big projects before they start paying for themselves in complexity.

Meanwhile, my docker containers has kept chugging along without needing any maintenance aside from auto-updating security updates for several years.

I do agree with you that Kubernetes may encourage patterns that are useful, though. But really the most essential part is that you can find relatively inexperienced devops people who have picked up some Kubernetes skills. That availability make up for a lot of pain vs finding someone experienced enough to wire up a much leaner setup.

Post reply on HN