381–390 of 558 posts
Earlier quoted context omitted.
Good grief. First and foremost I was simplifying to make a point. >> You can’t just hire 1 DevOps superstar Secondly, that assertion is not necessarily true. Obviously, you should just hire 1 DevOps superstar... in some cases. Don't nitpick and don't argue foolishly.
I’ve run DevOps and know from experience the pitfalls. I’m sorry that you’ve interpreted my general agreement and elaboration of your comment as nitpicking foolishness.
I'm getting tired of the "You don't actually need Kubernetes while starting out!" crowd, despite being part of it. Of course you don't. Of course if you don't know Kubernetes, learning it as you try to get a company going on a minimum headcount is not the most efficient approach. But for pete's sakes man, if you have used K8s before, know what you're doing and you're running on cloud, just shove a couple off-the-shel…
I've seen projects fail or take 10x as long due to choosing to go with k8s day 1 instead of starting with even a basic VM.
It may be easy enough to get k8s itself setup. However, without an in-house expert sat within the dev team, all the access/permissions to resources to/from the cluster were hell. NFS disk Read/Write, S3 Read/Write/List, RDS DB access, Kafka access, corp network access to web server within k8s.. and then all the daemons you need to actually be able to monitor your logs/health of apps/etc.
Each of these things in isolation would be no big deal, except that they'd take a different subset of 10 different infra/devops team members 1-2 weeks to sort the first time, in some fragile manner that frequently fell over.
All of these for an application that was replacing something basically owned by 1 dude as 10% of his job, running on a 10 year old server under cron, with a big disk attached.
Earlier quoted context omitted.
You seem to be saying there's nothing inbetween K8s and "use a BaaS or PaaS"? What about something that does the subset of what K8s does that is the simple bit and covers most use-cases outside of complex clusters? I get the strong sense people are just misusing it for the wrong types of task. I've seen this happen countless times in tech. Development by CV.
Docker Swarm, Nomad, ECS?
…and if you don’t understand how to use and deploy kubernetes just what in the fresh hell are you doing? Stick with technology you know and then move to kubernetes later if or when you need it.
We’re a relatively small shop, and we’re using k8s. All of our senior stuff know and understand it. The pipeline is fully automated. If we prematurely optimizing anything it’s developer output over saving money.
I'm getting tired of the "You don't actually need Kubernetes while starting out!" crowd, despite being part of it. Of course you don't. Of course if you don't know Kubernetes, learning it as you try to get a company going on a minimum headcount is not the most efficient approach. But for pete's sakes man, if you have used K8s before, know what you're doing and you're running on cloud, just shove a couple off-the-shel…
> Stop pretending Kubernetes is this humongous infrastructure investment that mandates a full time job to keep up at low scale. It is a full time job. The cost of using something is not just the setup cost. The same way that software development is not just the cost of writing the software.
"It's easy to setup" speaks nothing to how much effort it takes to maintain.
Earlier quoted context omitted.
Yeah but k8s isn’t hard at all if you know it, it’s actually substantially easier than a couple web servers and dbserver and provides a whole lot more
So, your argument is that you should use a tool if you know how to use it, regardless of if it's actually needed? Personally I would take managing "a couple of webservers and a db" any day over k8s.
Earlier quoted context omitted.
> Setting up a new application on IIS or a new web server to scale is a mare. I disagree. With octopus deploy I can add a step, set a package and hostname, and press a button, and have a new deployment of a new api or website in IIS pushed out to how ever many servers currently exist in a few minutes. There are many ways to manage deploying services, and scaling, without K8S or containers in general. While I could se…
We’ll see if octopus deploy is around in 10 years
I would say they will be.
I really don't understand all these complaints about how Kubernetes is so complex, how it's an investment etc. I am a single developer that uses Kubernetes for two separate projects, and in both cases it has been a breeze. Each service gets a YAML file (with the Deployment and Service together), then add an Ingress and a ConfigMap. That's all. It's good practice so still have a managed DB, so the choice of Kubernetes…
It’s really complicated when something goes wrong. That is my only criticism. Particularly in the various CNI layers out there. You really have to know exactly how everything works to get through those days and that is beyond the average person who can create a docker container and push it into the cluster which is the usual success metric.
Earlier quoted context omitted.
The thing is, unless using those technologies was somehow core to what the single engineer was trying to, it might be technically impressive but might not have actually provided value for users. Users don't really care if you have a really impressive stack with cool technologies if it doesn't offer anything more than a couple of web servers and a DB server.
Yeah but k8s isn’t hard at all if you know it, it’s actually substantially easier than a couple web servers and dbserver and provides a whole lot more
You can find plenty of auto mechanics though. Cars are cheaper and ubiquitous. Maybe they can't drive to the moon, but they can get most things done.
Unless your business is flying to the moon, stick to cars and trucks over spaceships.
As a startup founder that's not VC funded, I would totally recommend you look into building with kubernetes from the get go. The biggest learning curve is for the person setting up the initial deployments, services, ingress etc Most other team members may just need to maybe change the image name and kubectl apply to roll things out. Knowing that rollouts won't bring down prod and that they can be tested in different…
One guy (okay it was two guys) set up all the infrastructure and as soon as it was working bounced to new jobs with their newfound experience. The result is that dozens of engineers have no idea what the heck is going on and are lost navigating the numerous repos that hold various information related to deploying your feature.
In my opinion (and I’m sure my opinion has flaws!), unless you have global customers and your actual users are pushing 1k requests per second load on your application servers/services, there is no reason to have these levels of abstractions. However once this becomes reality I think everyone working on that responsibility needs to learn k8s and whatever else. Otherwise you are screwed once the dude who set this up left for another job.
And honestly.. I’ve built software using node for the application services and managed Postgres/cache instances with basic replication to handle heavy traffic (10-20k rps) within 100ms. It requires heavy use of YAGNI and a bit of creativity tho which engineers seem to hate because they may not get to use the latest and shiniest tech. Totally understand but if you want money printer to go brrr you need to use the right tool for the job at the right time.