24 ms·

You might not need Kubernetes

307 points by tannhaeuser 8y ago

effnorwood 8y ago
You don’t.
- beagledude 8y ago
  or Do you?
  - toomuchtodo 8y ago
    You don't. EDIT: 99 times out of 100, you don't.
    - jmkni 8y ago
      But, maybe?
      - toomuchtodo 8y ago
        Maybe you'll become a billionaire. But probably not. Your monolith in a container will take you far, before we go down the treacherous path of microservices (for team demarcation, not technical scaling, but maybe technical scaling!), container lifecycle management, inbound load balancing, internal load balancing, service mesh and discovery, and all the fun that container orchestration at scale encompasses (are you ready to cry for a bit when you're running on no sleep and you can't determine why your orchestrator is unable to retrieve container images from your registry?).
        diminoten 8y ago
        How old are you?
        toomuchtodo 8y ago
        Almost 40, 20+ years of tech experience.
        diminoten 8y ago
        Are you concerned that you're taking a stance here that's more reflective of your years of experience than of the changing trends in tech? Experience can be a crutch too, especially in a field that gets upended by new concepts every 3-5 years. I hope you're cognizant of that. What worked 5 years ago is a joke today, in many cases.
        toomuchtodo 8y ago
        Not concerned at all. I get paid to de-risk, not to ride the hype train. > What worked 5 years ago is a joke today, in many cases. Postgresql was first released in 1997. Lots of the web still runs on PHP, Python 2, and large amounts of Java. What you call a joke, I call a sustainable business and an amortized cost. No one is paying you to use shiny tools, they're paying you to solve business problems.
        diminoten 8y ago
        Refusing to adopt innovation because it doesn't match with what you knew when you were a technical contributor is risky, too. Sticking to Python2 is risky. Using a version of Postgres released 5 years ago (9.3) is risky, using legacy PHP is risky, relying on the JVM and Java developers to solve problems that other tech stacks solve faster/better is risky. What you call a sustainable business with amortized costs I call an un-turnable ship that wastes money dealing with problems that were solved years ago.
        toomuchtodo 8y ago
        I think you misunderstand. I am not refusing to adopt innovation. I'm refusing to be underpaid to "innovate". If you want to spend sleepless nights troubleshooting beta software in production, it is not my place to stop you. It is my place to not recommend said software to businesses, and this is extremely easy to demonstrate to decision makers. If you do recommend software to a business that isn't proven (and Kubernetes is still very much unproven, it's first release was only 3 years ago), and it fails, you should be accountable for your poor judgement.
    - beagledude 8y ago
      but what if? Imagine.
      - toomuchtodo 8y ago
        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 help you unless you're leaning heavily on a Kubernetes managed service (which is of course, as we recently saw with Google's outage [1], no guarantee everything will work flawlessly). My hesitation and cautiousness doesn't come from being a greybeard curmudgeon, it comes from a healthy dose of skepticism that this is The One True Path that will Solve All The Problems. I am cautiously optimistic it might be a stable, proven ecosystem, eventually. But it isn't today. When making technology decisions, imagine that you're the one with the pager at 3am and work backwards accordingly. [1] https://news.ycombinator.com/item?id=18428497 https://news.ycombinator.com/item?id=18428497
        jeletonskelly 8y ago
        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.
        toomuchtodo 8y ago
        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.
        gaius 8y ago
freehunter 8y ago
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 tied to just one server and not being able to horizontally scale or easily load balance between multiple servers/regions. Ideally what I'd like is Dokku with horizontal scaling built in. I've seen Deis and Flynn but they seem less active/mature even than Dokku, which is saying something. Is Kubernetes the right answer here or should I stick with Dokku and forget about horizontal scaling?
- coreyja 8y ago
  I am in the exact same boat as you are, and would love some feedback as well! I have been considering Kubernetes so that I can allow horizontal scaling, but haven't done it yet. For my use case I am VERY well aware that Kubernetes is overkill, but I don't see a great middle ground between Dokku where I am now, and Kubernetes.
  - amq 8y ago
    I have found Docker Swarm Mode to be a good middle ground. Essentially, it's docker-compose which you can run on multiple servers.
    - hinkley 8y ago
      I've started experimenting with Swarm myself but I know one guy who has a histamine reaction every time I mention it. I haven't gotten (or really tried to get) a straight answer out of him about why it's a bad thing. If you have a countable number of instances of a couple dozen services and one or two "lots of instances" services it seems like it should suffice just fine. And really, my brief sojourn into Kubernetes left me feeling like I bumped into road blocks for anything more complicated than that. Especially with sidecars, or if your tool chain uses multiprocessing instead of threading (Rails, Node, Python?, etc) to deal with concurrency.
maxxxxx 8y ago
"Anyways, the point I am trying to make is you should use whatever is the easiest thing for your use case and not just what is popular on the internet. " This is good advice in theory but in the real employment world you are killing your own career that way. At some point you get marked as "dinosaur" that hasn't "kept up". Much better to jump on the latest tech trend.
- sequoia 8y ago
  I'm so annoyed that this is true. I hate this, and I'm in the JavaScript world, which is worse than anyone else in this regard as far as I know. Incidentally, this "don't follow trends" advice ironically seems to carry the most weight when it comes from tech celebrities, frequently those who built a name by being experts in trendy technologies. When someone who's not trendy says "don't follow trends," either no one listens or it's taken as proof that they're a dinosaur. (No shade on Jess intended here, she didn't create this phenomenon.)
- mcguire 8y ago
  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.
  - bitwize 8y ago
    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 or Perl app that needs maintenance. snicker
    - maxxxxx 8y ago
      "If you're buzzword compliant, you can fail forward. " Exactly. You don't even need to have delivered something useful but you are still a hot commodity on the job market. Same with a lot of "data scientists". Having used the tools with or without success is sufficient to being hired.
frostyj 8y ago
Depends on the scale. If I only have 10 containers to manage I'd throw them on a m4 and let it be. Benefit of using k8s kicks in when your use case gets complicated.
- hasperdi 8y ago
  What's m4?
  - leetrout 8y ago
    AWS instance type. "M4 instances provide a balance of compute, memory, and network resources, and it is a good choice for many applications." https://aws.amazon.com/ec2/instance-types/ https://aws.amazon.com/ec2/instance-types/
  - lostapathy 8y ago
    AWS ec2 instance type
  - palunon 8y ago
    I guess they're taking about the AWS EC2 instance type https://aws.amazon.com/ec2/instance-types/ https://aws.amazon.com/ec2/instance-types/
  - enigmango 8y ago
    Probably the AWS m4 instance type, meant for general purpose workloads (and replaced with the m5 instance type about a year ago). https://aws.amazon.com/ec2/instance-types/m5/ https://aws.amazon.com/ec2/instance-types/m5/
  - Znafon 8y ago
    GP probably references an AWS EC2 machine type: https://aws.amazon.com/fr/ec2/instance-types/ https://aws.amazon.com/fr/ec2/instance-types/
  - deleted 8y ago
    [deleted]
  - 8y ago
atleta 8y ago
Yeah, you probably don't. And not only that, but it probably makes your life harder. I've interviewed for a tech lead position at a company working with freelancers and I'm pretty sure the reason they ended up rejecting me was that I mentioned the technical interviewer that I think containers, container infrastructures (like Kubernetes) and even cloud infrastructure is being overused/used without giving too much thought about it as if it came free (in the sense of setup and operating complexity). Too bad the interviewer started rambling about how he was into Kubernetes those days :). (Actually, this was the most technical part of the interview.) I'm mostly working with startups and small companies creating MVPs and that was their client base too. Now most of the time these are just building CRUD apps, most of the time these apps don't see heavy usage for years (maybe never). Developers love technology, love to play with new(ish) things so quite a few of us will prefer using whatever is new and hip for the next project. Now it's containers and microservices. And it feels safe, because done right, these will give you scalability. And once you convince the client/boss that you need it it's unlikely that anyone will come back in a year and say: hey, it seems that we'll never need this thing that made the development $X more expensive. (Partly because they won't know the amount.) So actually politically it is the safe choice. But professionally and cost wise it's usually worse. It's a lot better to have to transition after seeing the need (preferably from the projected growth numbers). At least you minimize the expected value of the costs (bacause YAGNI).
- djsumdog 8y ago
  I once got an interview from a company in the container space because one of their exec read an article I published talking about the trouble with container systems[1]. (Really good talk/interview, but I ended up not moving forward because I didn't want to move back to the west coast). I've been in smaller shops that wasted a lot of time on K8s stuff and fell behind on their timeline. If you want to run k8s, DC/OS, etc. you need a lot of ramp up time and at least 4 ~ 8 dedicate staff members. I've talked to other startups that preferred running Nomad instead due to setup complexity. I doubt k8s will go the way of Open Stack since it does actually work, but I do think we'll see it limited to big-end enterprise systems and smaller startups will push forward with other, easier to build up clustering technologies. [1]: https://penguindreams.org/blog/my-love-hate-relationship-with-docker-and-container-orchestration-systems/ https://penguindreams.org/blog/my-love-hate-relationship-wit...
combatentropy 8y ago
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 0.1. I know, it isn't web-scale. Okay, how about Hacker News? It runs on one server. Moore's Law rendered most of our impressive workloads to a golf ball in a football field, years ago. I understand these companies needing many, many servers: Google, Facebook, Uber, and medium companies like Basecamp. But to the rest I want to ask, what's the load average on the Kubernetes cluster for your Web 2.0 app? If it's high, is it because you are getting 100,000 requests per second, or is it the frameworks you cargo-culted in? What would the load average be if you just wrote a LAMP app? EDIT: Okay, a floating IP and two servers.
- deleted 8y ago
  [deleted]
- tshannon 8y ago
  Does hacker news really run on one server? What if server goes down? I've always though high availability was the more important reason for multiple servers, rather than performance. Even if you have only two paying customers, they are probably paying for the right to hit your website / service 24/7.
  - lostapathy 8y ago
    What if hacker news goes down, more work gets done for the day? It’s really common to over estimate the cost of being down, while underestimating the costs of resiliency. And in the end if you can’t fully afford the resiliency, you end up with a system that’s more complicated and thus less stable than it could have been had you just accepted a tiny bit of risk.
    - _drFaust 8y ago
      extremely valid point. The initial setup isn't the challenge, it's the endless tweaks to make it fault tolerant. For anyone looking into k8s, take time to research best practices for monitoring and readiness probes.
bg4 8y ago
You don't need K8S, you don't need microservices.
bg4 8y ago
You probably don't need microservices either - it's insane how much money and time is being thrown away to these industrial strength hammers by companies that simply don't need it.
- garysahota93 8y ago
  So true! I think the Rick & Morty reference alone speaks volumes for everything. haha
deleted 8y ago
[deleted]
chess44 8y ago
I am interested in people's opinion on the "break even point" between using Kubernetes and not using Kubernetes. Let's pretend that the only options are Kubernetes and something substantially less powerful. What is the simplest/easiest personal project where using Kubernetes might be justified? I am a junior software engineer trying to figure out how to contextualize all of these container/container management systems.
- l_t 8y ago
  IMO, Kubernetes is one of those things where if you have to ask, you don't need it. It's only really "justified" if you're actually using features like: - High availability services (more than one copy running at once). - Service discovery (services talking to each other in a resilient way). - Ability to automate operational tasks. - Rolling deployments of services. Very few personal projects will tick those boxes -- by the time they do, they've usually evolved into a full-on "real project". Doesn't mean you can't mess around with Kubernetes for fun and learning, of course. But from a purely practical perspective, it's overkill unless you have all of those requirements above. (If you just have one or two of those needs, there is usually a simpler tool to fulfill it with less overhead).
  - fulafel 8y ago
    If you need high availability, you get into the second order effects: consider the risk from the complexity of the HA setup, your lack of experience with its failure modes, and lack of low level access to the managed kubernetes service? If you are not a seasoned SRE, there are a lot of "unknown unknowns" for you waiting around the corner.
    - l_t 8y ago
      Yeah, great point. Kubernetes done right can help with these things, but done wrong, it can cause more problems than it solves. Of course, for a personal project, hitting those "unknown unknowns" is all part of the growing process, but in a business context I would be even more hesitant to adopt K8s unless you already have an ops team that's ready to support it.
zwischenzug 8y ago
A lot of people don't have a choice.
- Walkman 8y ago
  The choice of not using Kubernetes?
  - ThePadawan 8y ago
    I believe the parent is referring to Businessperson: "What do you mean <software> isn't in the cloud/on kubernetes/<some other catchy phrase> yet?" Engineer: "Well we believe there are pros and cons which don't yet justify the additional cost or complexity for this use case..." Businessperson: "All our competitors use Kubernetes! We can't sell <software> if it isn't on Kubernetes! Get on it ASAP!"
    - bdcravens 8y ago
      As I commented to grandparent, the article's audience probably isn't the powerless worker bee, but the architect who gets to make those choices.
- bdcravens 8y ago
  Also, most people don't get to choose their language, or server operating system, etc. (Aside from the jobs they choose to take or continue working at) I don't think that's the audience of this discussion.
segmondy 8y ago
If you don't have microservices/soa architecture then you don't need k8s. Most people don't need skyscrapers. But yet there's a lot of them in the world. Just because you don't need one and don't have one doesn't mean that other's don't
rek32 8y ago
Buy this danger hypnotism https://play.google.com/store/apps/details?id=com.rishibhakat.pallavi.sammohancontrol https://play.google.com/store/apps/details?id=com.rishibhaka...
konschubert 8y ago
I just create a container image for my service and run it via the heroku container registry. Zero setup. I think it has auto scaling as well but I never needed that.
rek32 8y ago
Buy this danger hypnotism
elsonrodriguez 8y ago
Most organizations don't need to manage servers or Ansible playbooks either. The reason Kubernetes became so popular is because the API was largely application-centric, as opposed to server-centric. Instead of conflating the patching and configuration of ssh and kernels with the configuration of an application, you had clearly separate objects meant to solve different application needs. The problem with Kubernetes is that to gain that API you need deploy and manage etcd. To bring your API objects to life you need the rest of the control plane, and to let your objects grow into your application you need worker nodes and a good grasp of networking. This is a huge burden in order to gain access to K8's simple semantics. GKE helps greatly, but the cluster semantics still come to the forefront whenever there's a problem, or upgrade, or deprecation, or credential rotation. Of course there's always a time for worrying about those semantics. Specialized workloads might have some crazy requirements that nothing off the shelf will run. However I think the mass market is ready for a K8s implementation that just takes Deployments and Services, and hides the rest from you. In lieu of that, people will just continue adoption of App Engine and other highly-managed platforms, because while you might not need Kubernetes, you almost certainly don't need to go back to Ansible.
- marmaduke 8y ago
  Ansible isn’t just ssh though. In principle you could have a k8s_deployment role for example. Most playbooks are host oriented but one write k8s playbooks that are cluster oriented
bashmonkey 8y ago
I do my level best to stay away from containers. I don't think most people even need them. It's a fad of sorts. I tend to stick with the tried and true and not follow trends, cloud or otherwise. Nothing worse than having your data on someone else's HW and losing connectivity through no fault of your own. Years ago, I worked for UUNET in Reston/Ashburn, VA, and built web servers and the attendant HW/SW that ran them (usually Sun Solaris/Apache/Oracle). We always had a "back net" into every device. Now? One NIC, one way in. I always like having more than one way to get to a device, be it local or remote. With the cloud, you tend to give this up. I recommend VMs over the cloud using someone else's data and data centre. Nothing worse than going to a tech conference with your boss, and him being the "deer in the headlights" as it were with regard to buying into what's being sold by the vendors. Last time we went, it took me the entire 3-hour car ride home to convince him we didn't need half of what was on offer. I tend to be old school and prefer to make do with Linux/FreeBSD VMs, and whatever software is needed to make something work. I like being in control of my own architecture.
- eropple 8y ago
  Containers and container orchestration are wildly different, though. A container is a pretty handy way to distribute an app to a production environment. Container orchestration is a bad application of the bin packing problem. Pretty different things.
- kayoone 8y ago
  problem with that mindset is that it will be harder to get hired. At least where i work, knowledge about containers and cloud services is pretty crucial to get a senior position in a bigger company.
- devhead 8y ago
  i like being able to sleep at night knowing my infrastructure will self heal in almost all cases.
  - bashmonkey 8y ago
    HA is self-healing. And for things that don't do HA very well, there are hot spares that can be activated in 30 seconds. Depends on the SLA, though, as with most things. Most things in my firm can be stood up within two minutes' time should there be an issue with something.
jasonlotito 8y ago
This is another way of saying "You might need Kubernetes."
metalrain 8y ago
You most likely need few cheap servers, a loadbalancer and great team. So yeah no Kubernetes, no microservices nor chaos monkey. What you need is to know, really deeply know your technology stack. This is where boring software helps.
martinlaz 8y ago
Yeah, but... Nobody ever got fired for using K8s.
- mharroun 8y ago
  I'm sure many startups and other companies have close by failing to hit their product goals and buisness kpi's. Then again I guess that's not being fired... just picking technologies your company doesnt need that may ultimately kill everyone's jobs.
xmly 8y ago
K8S is too complex. I just want a small and easy to use cluster toooool
- devhead 8y ago
  aws / gce
Sahbak 8y ago
I honestly don't understand the amount of negativity towards dockers and kubernetes sometimes. All major cloud providers have a managed k8 service, so you don't have/need to learn much about the underlying system. You can spend a few days, at most, to learn about dockers, k8 configuration files and helm and you're pretty much set for simple workloads (and even helm might be overkill). Afterwards, deploying, testing, reproducing things is, in my opinion, much better than managing your applications on random servers. Might I be wasting some money on a k8 cluster? Maybe. Do I believe the benefits outweigh the money? Absolutely.
- Enginerd3 8y ago
  I honestly think this website's negativity towards stuff stems from not understanding use cases and being a general curmudgeon. "All major cloud providers have a managed k8 service, so you don't have/need to learn much about the underlying system. You can spend a few days, at most, to learn about dockers, k8 configuration files and helm and you're pretty much set for simple workloads (and even helm might be overkill)." This is the reason why I use k8s. It is ridiculously easy to deploy applications and I don't have to worry about hardening the VM.
vander_elst 8y ago
As much as I agree with the fact that for 95% of the cases k8s is not needed, the problem most likely lies in the overengineerin around it. Take a managed k8s solution setup a deployment that serves through an ingress controller. Done.
mfer 8y ago
If you're going to use Kubernetes it's good to look at your business case or other need. Don't use a hammer if you need to unscrew something. Kubernetes has it's place... I recently wrote a post on that... https://codeengineered.com/blog/2018/kubernetes-biz-case/ https://codeengineered.com/blog/2018/kubernetes-biz-case/ But, there are many times you just don't need it. Like, for my personal sites... just isn't a need there.
marghidanu 8y ago
What bothers me the most is the assumption that adopting Kubernetes will solve all design problems.
barbecue_sauce 8y ago
Sometimes choice of technology acts as a signifier. If you're building a startup, and you want to communicate to investors that "hey, we may not have the users yet, but we're built to scale!", Kubernetes and microservice architectures and sophisticated ETL pipelines convey that image better than saying "we've built for the minimal load that we're currently experiencing with a LAMP-based monolith.". The reality may be that your product's consumption patterns will never necessitate having anything more than that, even at a large scale. Your product may be great, you might easily be able to scale manually, but someone who holds the purse strings who knows just enough to be dangerous, might decide that if you're not using the "hot" technologies, you must not know what you're doing.
sebringj 8y ago
It was interesting to note about workers and using web assembly together within V8 as this scenario could bypass the need for complexity and memory overhead, while combining different programming languages on the server-side. Not that it could replace Kubernetes as that is an amazing technology but if you are in a scenario where your tech could fit within workers, could be interesting. https://blog.cloudflare.com/introducing-cloudflare-workers/ https://blog.cloudflare.com/introducing-cloudflare-workers/. I was amazed to think web assembly would be used for that purpose but i guess it does make sense in reading about how it is put together.
vemv 8y ago
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.
- shaklee3 8y ago
  Skaffold is only 5 months old. That's a little unfair to call it unpolished an over-ambitious.
  - vemv 8y ago
    It's made by Google which boasts about its 15y experience on containers?
    - shaklee3 8y ago
      I've been using skaffold for about 3 months. It works well, and there continually improving it. I'm not sure what else is expected from a new project.
rcarmo 8y ago
If you’re looking for a simple way to manage web apps on Linux, check out https://github.com/rcarmo/piku https://github.com/rcarmo/piku I wrote it as a sort of micro-Heroku/Dokku replacement to run on small ARM boards, and ended up deploying a few apps with it on Intel boxes (I also use Docker Compose, but for simple stuff it’s overkill). It uses uWSGI and is heavily Python-oriented, but I’ve run other stuff on it (it’s basically a supervisor with automatic reverse proxy setup and a Procfile approach to specifying what to run - git push to it and you’re in business).
geo_mer 8y ago
Kubernetes may be overkill for small projects and it's actually hard to setup for a single-machine cluster, but the idea of container orchestrators (k8s, docker swarm, nomad, etc...) is extremely useful, I understand that some abuse the word "scale", but for me container orchestration is far bigger than just scaling, these features include: 1. rolling updates 2. decoupling configs and secrets from code and mounting/changing config files easily 3. robust and predictable testing/production environments 4. centralized logging Also microservices's goal isn't really about just "scaling" in my opinion, there are other important advantages even if you have no intention to scale, aspects like modularity, separation of concerns, robustness and lowering the technical debt are still as important whether your app serves 1 or a 10000 users at the same time. Of course you can pull your python app from your repo or even rsync it (just like you can just develop any software without using git or any revision control) and just execute it might work very well, but sooner or later you are going to regret it if you're a business
beiller 8y ago
My experience is that Kubernetes is too complex for the average functioning product. At our company, everyone is obsessed with it because it promises no cloud vendor lock ins! But at what cost? The complexity. Also the direction cloud vendors are going in my opinion, is more hardware-centric (eg. TPUs). How will you avoid the cloud lock in when only Azure offers the image tagging machine learning as a service? How will Kubernetes solve that? I believe a balance between a small bit of lock-in, but retain environment freedom (free programming languages like python, javascript...) is the sweet spot for cloud, eg. PaaS like appengine or azure app service or beanstalk.
- weberc2 8y ago
  I'm not a k8s expert, but I'm pretty sure it has an extensible architecture (plugin or similar), so it probably would allow for the definition of an image tagging service interface that could be satisfied by Azure or whomever. Would love to hear from someone more knowledgable than I.
amai 8y ago
Unfortunately standalone Docker container don‘t allow to inject secrets (keys, passwords, etc) in a secure way for your app in the container. For doing this it seems to be necessary to use a orchestration solution like swarm or kubernetes.
amai 8y ago
Isn‘t Kubernetes of today the same thing Tomcat used to be fo Java web applications yesterday?
wstrange 8y ago
If you are writing "business" apps (for some definition of business), you should probably use a PaaS. If you want to create a PaaS, Kubernetes is an excellent foundation (see Knative).
jammygit 8y ago
Its a bit funny to ask this question in this thread, but here we go: What are the important topics & technologies to learn about with these types of topics? My uni experience didn't really include things like distributed systems or containerization. Ideally fundamentals that won't be invalidated in 5 years when 'the new thing' becomes something else. (Love good book recommendations on any subject a new grad should learn, not just this topic)
AzzieElbab 8y ago
What is wrong with running your app on a managed kubernetes? Of course the cost of maintaining your own cluster is overwhelming for a company with less than 1k servers, but if Google is taking care of this for you, why not?
sjapkee 8y ago
If you think you need kubernetes, docker, etc., you are wrong. This is the only thing you need to know about these technologies.

307 points by tannhaeuser 8y ago

effnorwood 8y ago

You don’t.

beagledude 8y ago
or Do you?
- toomuchtodo 8y ago
  You don't. EDIT: 99 times out of 100, you don't.
  - jmkni 8y ago
    But, maybe?
    - toomuchtodo 8y ago
      Maybe you'll become a billionaire. But probably not. Your monolith in a container will take you far, before we go down the treacherous path of microservices (for team demarcation, not technical scaling, but maybe technical scaling!), container lifecycle management, inbound load balancing, internal load balancing, service mesh and discovery, and all the fun that container orchestration at scale encompasses (are you ready to cry for a bit when you're running on no sleep and you can't determine why your orchestrator is unable to retrieve container images from your registry?).
      - diminoten 8y ago
        How old are you?
        toomuchtodo 8y ago
        Almost 40, 20+ years of tech experience.
        diminoten 8y ago
        Are you concerned that you're taking a stance here that's more reflective of your years of experience than of the changing trends in tech? Experience can be a crutch too, especially in a field that gets upended by new concepts every 3-5 years. I hope you're cognizant of that. What worked 5 years ago is a joke today, in many cases.
        toomuchtodo 8y ago
        Not concerned at all. I get paid to de-risk, not to ride the hype train. > What worked 5 years ago is a joke today, in many cases. Postgresql was first released in 1997. Lots of the web still runs on PHP, Python 2, and large amounts of Java. What you call a joke, I call a sustainable business and an amortized cost. No one is paying you to use shiny tools, they're paying you to solve business problems.
        diminoten 8y ago
        Refusing to adopt innovation because it doesn't match with what you knew when you were a technical contributor is risky, too. Sticking to Python2 is risky. Using a version of Postgres released 5 years ago (9.3) is risky, using legacy PHP is risky, relying on the JVM and Java developers to solve problems that other tech stacks solve faster/better is risky. What you call a sustainable business with amortized costs I call an un-turnable ship that wastes money dealing with problems that were solved years ago.
        toomuchtodo 8y ago
        I think you misunderstand. I am not refusing to adopt innovation. I'm refusing to be underpaid to "innovate". If you want to spend sleepless nights troubleshooting beta software in production, it is not my place to stop you. It is my place to not recommend said software to businesses, and this is extremely easy to demonstrate to decision makers. If you do recommend software to a business that isn't proven (and Kubernetes is still very much unproven, it's first release was only 3 years ago), and it fails, you should be accountable for your poor judgement.
  - beagledude 8y ago
    but what if? Imagine.
    - toomuchtodo 8y ago
      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 help you unless you're leaning heavily on a Kubernetes managed service (which is of course, as we recently saw with Google's outage [1], no guarantee everything will work flawlessly). My hesitation and cautiousness doesn't come from being a greybeard curmudgeon, it comes from a healthy dose of skepticism that this is The One True Path that will Solve All The Problems. I am cautiously optimistic it might be a stable, proven ecosystem, eventually. But it isn't today. When making technology decisions, imagine that you're the one with the pager at 3am and work backwards accordingly. [1] https://news.ycombinator.com/item?id=18428497 https://news.ycombinator.com/item?id=18428497
      - jeletonskelly 8y ago
        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.
        toomuchtodo 8y ago
        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.
      - gaius 8y ago

freehunter 8y ago

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 tied to just one server and not being able to horizontally scale or easily load balance between multiple servers/regions. Ideally what I'd like is Dokku with horizontal scaling built in. I've seen Deis and Flynn but they seem less active/mature even than Dokku, which is saying something. Is Kubernetes the right answer here or should I stick with Dokku and forget about horizontal scaling?

coreyja 8y ago
I am in the exact same boat as you are, and would love some feedback as well! I have been considering Kubernetes so that I can allow horizontal scaling, but haven't done it yet. For my use case I am VERY well aware that Kubernetes is overkill, but I don't see a great middle ground between Dokku where I am now, and Kubernetes.
- amq 8y ago
  I have found Docker Swarm Mode to be a good middle ground. Essentially, it's docker-compose which you can run on multiple servers.
  - hinkley 8y ago
    I've started experimenting with Swarm myself but I know one guy who has a histamine reaction every time I mention it. I haven't gotten (or really tried to get) a straight answer out of him about why it's a bad thing. If you have a countable number of instances of a couple dozen services and one or two "lots of instances" services it seems like it should suffice just fine. And really, my brief sojourn into Kubernetes left me feeling like I bumped into road blocks for anything more complicated than that. Especially with sidecars, or if your tool chain uses multiprocessing instead of threading (Rails, Node, Python?, etc) to deal with concurrency.

maxxxxx 8y ago

"Anyways, the point I am trying to make is you should use whatever is the easiest thing for your use case and not just what is popular on the internet. " This is good advice in theory but in the real employment world you are killing your own career that way. At some point you get marked as "dinosaur" that hasn't "kept up". Much better to jump on the latest tech trend.

sequoia 8y ago
I'm so annoyed that this is true. I hate this, and I'm in the JavaScript world, which is worse than anyone else in this regard as far as I know. Incidentally, this "don't follow trends" advice ironically seems to carry the most weight when it comes from tech celebrities, frequently those who built a name by being experts in trendy technologies. When someone who's not trendy says "don't follow trends," either no one listens or it's taken as proof that they're a dinosaur. (No shade on Jess intended here, she didn't create this phenomenon.)
mcguire 8y ago
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.
- bitwize 8y ago
  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 or Perl app that needs maintenance. snicker
  - maxxxxx 8y ago
    "If you're buzzword compliant, you can fail forward. " Exactly. You don't even need to have delivered something useful but you are still a hot commodity on the job market. Same with a lot of "data scientists". Having used the tools with or without success is sufficient to being hired.

frostyj 8y ago

Depends on the scale. If I only have 10 containers to manage I'd throw them on a m4 and let it be. Benefit of using k8s kicks in when your use case gets complicated.

hasperdi 8y ago
What's m4?
- leetrout 8y ago
  AWS instance type. "M4 instances provide a balance of compute, memory, and network resources, and it is a good choice for many applications." https://aws.amazon.com/ec2/instance-types/ https://aws.amazon.com/ec2/instance-types/
- lostapathy 8y ago
  AWS ec2 instance type
- palunon 8y ago
  I guess they're taking about the AWS EC2 instance type https://aws.amazon.com/ec2/instance-types/ https://aws.amazon.com/ec2/instance-types/
- enigmango 8y ago
  Probably the AWS m4 instance type, meant for general purpose workloads (and replaced with the m5 instance type about a year ago). https://aws.amazon.com/ec2/instance-types/m5/ https://aws.amazon.com/ec2/instance-types/m5/
- Znafon 8y ago
  GP probably references an AWS EC2 machine type: https://aws.amazon.com/fr/ec2/instance-types/ https://aws.amazon.com/fr/ec2/instance-types/
- deleted 8y ago
  [deleted]
- 8y ago

atleta 8y ago

Yeah, you probably don't. And not only that, but it probably makes your life harder. I've interviewed for a tech lead position at a company working with freelancers and I'm pretty sure the reason they ended up rejecting me was that I mentioned the technical interviewer that I think containers, container infrastructures (like Kubernetes) and even cloud infrastructure is being overused/used without giving too much thought about it as if it came free (in the sense of setup and operating complexity). Too bad the interviewer started rambling about how he was into Kubernetes those days :). (Actually, this was the most technical part of the interview.) I'm mostly working with startups and small companies creating MVPs and that was their client base too. Now most of the time these are just building CRUD apps, most of the time these apps don't see heavy usage for years (maybe never). Developers love technology, love to play with new(ish) things so quite a few of us will prefer using whatever is new and hip for the next project. Now it's containers and microservices. And it feels safe, because done right, these will give you scalability. And once you convince the client/boss that you need it it's unlikely that anyone will come back in a year and say: hey, it seems that we'll never need this thing that made the development $X more expensive. (Partly because they won't know the amount.) So actually politically it is the safe choice. But professionally and cost wise it's usually worse. It's a lot better to have to transition after seeing the need (preferably from the projected growth numbers). At least you minimize the expected value of the costs (bacause YAGNI).

djsumdog 8y ago
I once got an interview from a company in the container space because one of their exec read an article I published talking about the trouble with container systems[1]. (Really good talk/interview, but I ended up not moving forward because I didn't want to move back to the west coast). I've been in smaller shops that wasted a lot of time on K8s stuff and fell behind on their timeline. If you want to run k8s, DC/OS, etc. you need a lot of ramp up time and at least 4 ~ 8 dedicate staff members. I've talked to other startups that preferred running Nomad instead due to setup complexity. I doubt k8s will go the way of Open Stack since it does actually work, but I do think we'll see it limited to big-end enterprise systems and smaller startups will push forward with other, easier to build up clustering technologies. [1]: https://penguindreams.org/blog/my-love-hate-relationship-with-docker-and-container-orchestration-systems/ https://penguindreams.org/blog/my-love-hate-relationship-wit...

combatentropy 8y ago

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 0.1. I know, it isn't web-scale. Okay, how about Hacker News? It runs on one server. Moore's Law rendered most of our impressive workloads to a golf ball in a football field, years ago. I understand these companies needing many, many servers: Google, Facebook, Uber, and medium companies like Basecamp. But to the rest I want to ask, what's the load average on the Kubernetes cluster for your Web 2.0 app? If it's high, is it because you are getting 100,000 requests per second, or is it the frameworks you cargo-culted in? What would the load average be if you just wrote a LAMP app? EDIT: Okay, a floating IP and two servers.

deleted 8y ago
[deleted]
tshannon 8y ago
Does hacker news really run on one server? What if server goes down? I've always though high availability was the more important reason for multiple servers, rather than performance. Even if you have only two paying customers, they are probably paying for the right to hit your website / service 24/7.
- lostapathy 8y ago
  What if hacker news goes down, more work gets done for the day? It’s really common to over estimate the cost of being down, while underestimating the costs of resiliency. And in the end if you can’t fully afford the resiliency, you end up with a system that’s more complicated and thus less stable than it could have been had you just accepted a tiny bit of risk.
  - _drFaust 8y ago
    extremely valid point. The initial setup isn't the challenge, it's the endless tweaks to make it fault tolerant. For anyone looking into k8s, take time to research best practices for monitoring and readiness probes.

bg4 8y ago

You don't need K8S, you don't need microservices.

bg4 8y ago

You probably don't need microservices either - it's insane how much money and time is being thrown away to these industrial strength hammers by companies that simply don't need it.

garysahota93 8y ago
So true! I think the Rick & Morty reference alone speaks volumes for everything. haha

deleted 8y ago

[deleted]

chess44 8y ago

I am interested in people's opinion on the "break even point" between using Kubernetes and not using Kubernetes. Let's pretend that the only options are Kubernetes and something substantially less powerful. What is the simplest/easiest personal project where using Kubernetes might be justified? I am a junior software engineer trying to figure out how to contextualize all of these container/container management systems.

l_t 8y ago
IMO, Kubernetes is one of those things where if you have to ask, you don't need it. It's only really "justified" if you're actually using features like: - High availability services (more than one copy running at once). - Service discovery (services talking to each other in a resilient way). - Ability to automate operational tasks. - Rolling deployments of services. Very few personal projects will tick those boxes -- by the time they do, they've usually evolved into a full-on "real project". Doesn't mean you can't mess around with Kubernetes for fun and learning, of course. But from a purely practical perspective, it's overkill unless you have all of those requirements above. (If you just have one or two of those needs, there is usually a simpler tool to fulfill it with less overhead).
- fulafel 8y ago
  If you need high availability, you get into the second order effects: consider the risk from the complexity of the HA setup, your lack of experience with its failure modes, and lack of low level access to the managed kubernetes service? If you are not a seasoned SRE, there are a lot of "unknown unknowns" for you waiting around the corner.
  - l_t 8y ago
    Yeah, great point. Kubernetes done right can help with these things, but done wrong, it can cause more problems than it solves. Of course, for a personal project, hitting those "unknown unknowns" is all part of the growing process, but in a business context I would be even more hesitant to adopt K8s unless you already have an ops team that's ready to support it.

zwischenzug 8y ago

A lot of people don't have a choice.

Walkman 8y ago
The choice of not using Kubernetes?
- ThePadawan 8y ago
  I believe the parent is referring to Businessperson: "What do you mean <software> isn't in the cloud/on kubernetes/<some other catchy phrase> yet?" Engineer: "Well we believe there are pros and cons which don't yet justify the additional cost or complexity for this use case..." Businessperson: "All our competitors use Kubernetes! We can't sell <software> if it isn't on Kubernetes! Get on it ASAP!"
  - bdcravens 8y ago
    As I commented to grandparent, the article's audience probably isn't the powerless worker bee, but the architect who gets to make those choices.
bdcravens 8y ago
Also, most people don't get to choose their language, or server operating system, etc. (Aside from the jobs they choose to take or continue working at) I don't think that's the audience of this discussion.

segmondy 8y ago

If you don't have microservices/soa architecture then you don't need k8s. Most people don't need skyscrapers. But yet there's a lot of them in the world. Just because you don't need one and don't have one doesn't mean that other's don't

rek32 8y ago

Buy this danger hypnotism https://play.google.com/store/apps/details?id=com.rishibhakat.pallavi.sammohancontrol https://play.google.com/store/apps/details?id=com.rishibhaka...

konschubert 8y ago

I just create a container image for my service and run it via the heroku container registry. Zero setup. I think it has auto scaling as well but I never needed that.

rek32 8y ago

Buy this danger hypnotism

elsonrodriguez 8y ago

Most organizations don't need to manage servers or Ansible playbooks either. The reason Kubernetes became so popular is because the API was largely application-centric, as opposed to server-centric. Instead of conflating the patching and configuration of ssh and kernels with the configuration of an application, you had clearly separate objects meant to solve different application needs. The problem with Kubernetes is that to gain that API you need deploy and manage etcd. To bring your API objects to life you need the rest of the control plane, and to let your objects grow into your application you need worker nodes and a good grasp of networking. This is a huge burden in order to gain access to K8's simple semantics. GKE helps greatly, but the cluster semantics still come to the forefront whenever there's a problem, or upgrade, or deprecation, or credential rotation. Of course there's always a time for worrying about those semantics. Specialized workloads might have some crazy requirements that nothing off the shelf will run. However I think the mass market is ready for a K8s implementation that just takes Deployments and Services, and hides the rest from you. In lieu of that, people will just continue adoption of App Engine and other highly-managed platforms, because while you might not need Kubernetes, you almost certainly don't need to go back to Ansible.

marmaduke 8y ago
Ansible isn’t just ssh though. In principle you could have a k8s_deployment role for example. Most playbooks are host oriented but one write k8s playbooks that are cluster oriented

bashmonkey 8y ago

I do my level best to stay away from containers. I don't think most people even need them. It's a fad of sorts. I tend to stick with the tried and true and not follow trends, cloud or otherwise. Nothing worse than having your data on someone else's HW and losing connectivity through no fault of your own. Years ago, I worked for UUNET in Reston/Ashburn, VA, and built web servers and the attendant HW/SW that ran them (usually Sun Solaris/Apache/Oracle). We always had a "back net" into every device. Now? One NIC, one way in. I always like having more than one way to get to a device, be it local or remote. With the cloud, you tend to give this up. I recommend VMs over the cloud using someone else's data and data centre. Nothing worse than going to a tech conference with your boss, and him being the "deer in the headlights" as it were with regard to buying into what's being sold by the vendors. Last time we went, it took me the entire 3-hour car ride home to convince him we didn't need half of what was on offer. I tend to be old school and prefer to make do with Linux/FreeBSD VMs, and whatever software is needed to make something work. I like being in control of my own architecture.

eropple 8y ago
Containers and container orchestration are wildly different, though. A container is a pretty handy way to distribute an app to a production environment. Container orchestration is a bad application of the bin packing problem. Pretty different things.
kayoone 8y ago
problem with that mindset is that it will be harder to get hired. At least where i work, knowledge about containers and cloud services is pretty crucial to get a senior position in a bigger company.
devhead 8y ago
i like being able to sleep at night knowing my infrastructure will self heal in almost all cases.
- bashmonkey 8y ago
  HA is self-healing. And for things that don't do HA very well, there are hot spares that can be activated in 30 seconds. Depends on the SLA, though, as with most things. Most things in my firm can be stood up within two minutes' time should there be an issue with something.

jasonlotito 8y ago

This is another way of saying "You might need Kubernetes."

metalrain 8y ago

You most likely need few cheap servers, a loadbalancer and great team. So yeah no Kubernetes, no microservices nor chaos monkey. What you need is to know, really deeply know your technology stack. This is where boring software helps.

martinlaz 8y ago

Yeah, but... Nobody ever got fired for using K8s.

mharroun 8y ago
I'm sure many startups and other companies have close by failing to hit their product goals and buisness kpi's. Then again I guess that's not being fired... just picking technologies your company doesnt need that may ultimately kill everyone's jobs.

xmly 8y ago

K8S is too complex. I just want a small and easy to use cluster toooool

devhead 8y ago
aws / gce

Sahbak 8y ago

I honestly don't understand the amount of negativity towards dockers and kubernetes sometimes. All major cloud providers have a managed k8 service, so you don't have/need to learn much about the underlying system. You can spend a few days, at most, to learn about dockers, k8 configuration files and helm and you're pretty much set for simple workloads (and even helm might be overkill). Afterwards, deploying, testing, reproducing things is, in my opinion, much better than managing your applications on random servers. Might I be wasting some money on a k8 cluster? Maybe. Do I believe the benefits outweigh the money? Absolutely.

Enginerd3 8y ago
I honestly think this website's negativity towards stuff stems from not understanding use cases and being a general curmudgeon. "All major cloud providers have a managed k8 service, so you don't have/need to learn much about the underlying system. You can spend a few days, at most, to learn about dockers, k8 configuration files and helm and you're pretty much set for simple workloads (and even helm might be overkill)." This is the reason why I use k8s. It is ridiculously easy to deploy applications and I don't have to worry about hardening the VM.

vander_elst 8y ago

As much as I agree with the fact that for 95% of the cases k8s is not needed, the problem most likely lies in the overengineerin around it. Take a managed k8s solution setup a deployment that serves through an ingress controller. Done.

mfer 8y ago

If you're going to use Kubernetes it's good to look at your business case or other need. Don't use a hammer if you need to unscrew something. Kubernetes has it's place... I recently wrote a post on that... https://codeengineered.com/blog/2018/kubernetes-biz-case/ https://codeengineered.com/blog/2018/kubernetes-biz-case/ But, there are many times you just don't need it. Like, for my personal sites... just isn't a need there.

marghidanu 8y ago

What bothers me the most is the assumption that adopting Kubernetes will solve all design problems.

barbecue_sauce 8y ago

Sometimes choice of technology acts as a signifier. If you're building a startup, and you want to communicate to investors that "hey, we may not have the users yet, but we're built to scale!", Kubernetes and microservice architectures and sophisticated ETL pipelines convey that image better than saying "we've built for the minimal load that we're currently experiencing with a LAMP-based monolith.". The reality may be that your product's consumption patterns will never necessitate having anything more than that, even at a large scale. Your product may be great, you might easily be able to scale manually, but someone who holds the purse strings who knows just enough to be dangerous, might decide that if you're not using the "hot" technologies, you must not know what you're doing.

sebringj 8y ago

It was interesting to note about workers and using web assembly together within V8 as this scenario could bypass the need for complexity and memory overhead, while combining different programming languages on the server-side. Not that it could replace Kubernetes as that is an amazing technology but if you are in a scenario where your tech could fit within workers, could be interesting. https://blog.cloudflare.com/introducing-cloudflare-workers/ https://blog.cloudflare.com/introducing-cloudflare-workers/. I was amazed to think web assembly would be used for that purpose but i guess it does make sense in reading about how it is put together.

vemv 8y ago

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.

shaklee3 8y ago
Skaffold is only 5 months old. That's a little unfair to call it unpolished an over-ambitious.
- vemv 8y ago
  It's made by Google which boasts about its 15y experience on containers?
  - shaklee3 8y ago
    I've been using skaffold for about 3 months. It works well, and there continually improving it. I'm not sure what else is expected from a new project.

rcarmo 8y ago

If you’re looking for a simple way to manage web apps on Linux, check out https://github.com/rcarmo/piku https://github.com/rcarmo/piku I wrote it as a sort of micro-Heroku/Dokku replacement to run on small ARM boards, and ended up deploying a few apps with it on Intel boxes (I also use Docker Compose, but for simple stuff it’s overkill). It uses uWSGI and is heavily Python-oriented, but I’ve run other stuff on it (it’s basically a supervisor with automatic reverse proxy setup and a Procfile approach to specifying what to run - git push to it and you’re in business).

geo_mer 8y ago

Kubernetes may be overkill for small projects and it's actually hard to setup for a single-machine cluster, but the idea of container orchestrators (k8s, docker swarm, nomad, etc...) is extremely useful, I understand that some abuse the word "scale", but for me container orchestration is far bigger than just scaling, these features include: 1. rolling updates 2. decoupling configs and secrets from code and mounting/changing config files easily 3. robust and predictable testing/production environments 4. centralized logging Also microservices's goal isn't really about just "scaling" in my opinion, there are other important advantages even if you have no intention to scale, aspects like modularity, separation of concerns, robustness and lowering the technical debt are still as important whether your app serves 1 or a 10000 users at the same time. Of course you can pull your python app from your repo or even rsync it (just like you can just develop any software without using git or any revision control) and just execute it might work very well, but sooner or later you are going to regret it if you're a business

beiller 8y ago

My experience is that Kubernetes is too complex for the average functioning product. At our company, everyone is obsessed with it because it promises no cloud vendor lock ins! But at what cost? The complexity. Also the direction cloud vendors are going in my opinion, is more hardware-centric (eg. TPUs). How will you avoid the cloud lock in when only Azure offers the image tagging machine learning as a service? How will Kubernetes solve that? I believe a balance between a small bit of lock-in, but retain environment freedom (free programming languages like python, javascript...) is the sweet spot for cloud, eg. PaaS like appengine or azure app service or beanstalk.

weberc2 8y ago
I'm not a k8s expert, but I'm pretty sure it has an extensible architecture (plugin or similar), so it probably would allow for the definition of an image tagging service interface that could be satisfied by Azure or whomever. Would love to hear from someone more knowledgable than I.

amai 8y ago

Unfortunately standalone Docker container don‘t allow to inject secrets (keys, passwords, etc) in a secure way for your app in the container. For doing this it seems to be necessary to use a orchestration solution like swarm or kubernetes.

amai 8y ago

Isn‘t Kubernetes of today the same thing Tomcat used to be fo Java web applications yesterday?

wstrange 8y ago

If you are writing "business" apps (for some definition of business), you should probably use a PaaS. If you want to create a PaaS, Kubernetes is an excellent foundation (see Knative).

jammygit 8y ago

Its a bit funny to ask this question in this thread, but here we go: What are the important topics & technologies to learn about with these types of topics? My uni experience didn't really include things like distributed systems or containerization. Ideally fundamentals that won't be invalidated in 5 years when 'the new thing' becomes something else. (Love good book recommendations on any subject a new grad should learn, not just this topic)

AzzieElbab 8y ago

What is wrong with running your app on a managed kubernetes? Of course the cost of maintaining your own cluster is overwhelming for a company with less than 1k servers, but if Google is taking care of this for you, why not?

sjapkee 8y ago

If you think you need kubernetes, docker, etc., you are wrong. This is the only thing you need to know about these technologies.