10 ms·

Why Kubernetes Is the New Application Server

281 points by rterzi 8y ago

zokier 8y ago
Is this a response for the Jib announcement and the inevitable comments that followed? Sounds a lot like it is...
testvox 8y ago
Sorry but this article implies that containers can solve issues like the difference between path separators on Windows and Linux. They can't even solve issues arising from differences in kernal versions, not to mention operating systems.
- SriniK 8y ago
  Did you consider http://kubevirt.io/ http://kubevirt.io/ ? It supposed to solve some of these hard limitations.
  - pdimitar 8y ago
    This can work, but stacking framework on top of the framework is what made the classic application servers undesirable and a horrible mess to begin with. Observing similar patterns creeping in the Kubernetes culture and ecosystem does not inspire optimism in a side observer like myself.
- lkrubner 8y ago
  Nor does Docker protect against such obvious things as differences in versions of base images. Check out the Slack dialogue at the end of this: http://www.smashcompany.com/technology/docker-protects-a-programming-paradigm-that-we-should-get-rid-of http://www.smashcompany.com/technology/docker-protects-a-pro...
  - foolzcrow 8y ago
    Why are you such a pussy? You flagged my Hillary Clinton is shit comment. You lost because your ideology is broken trash and I've been a lifelong Democrat so go let more Russians fuck your mom..#snowflake again I'm a lifelong Democrat and I'm going to vote against you
- craftyguy 8y ago
  Always use / Windows can, surprisingly, handle it just fine.
  - JetSpiegel 8y ago
    On interactive uses, sure. But it's not clear cut, some code paths are lower level and bypass that.
    - craftyguy 8y ago
      Yea I guess most of my uses have been in things like python (e.g. open() and as.*). Got any examples of code paths that bypass that check and fail if you use /?
      - testvox 8y ago
        I think they are wrong and actually it's the opposite problem. Some applications and libraries that do their own path mangling on Windows will choke if you give them a /. The win32 file I/O API handles them correctly.
  - lardo 8y ago
    I spent two hours scratching my head today because I had put "/path/to/thing/**" in a nuspec file instead of "\path\to\thing\**" The backslash was escaping the wildcard characters :(
  - mkesper 8y ago
    Never use windows, why should you for development and deployment?
taeric 8y ago
It is hard not to build this impression of containers. Worse, it seems that the docker image format is massive compared to what most war files were like. This is annoying not just in terms of raw bytes to move around, but in taking stock of what is getting moved around. My team originally pitched how docker solved much of the dependency upgrade management by having layers for each major set of dependencies. That ignored the fact that upgrading a layer is not really something you do. So, then you can go around the path of coordinating many containers communicating with each other. That works, but in that world, things really don't seem any easier than the earlier alternatives. Harder, in many ways. Don't get me wrong, the momentum and raw money being put into containers certainly paints it as the future. It just feels like lying to say that they have even come close to parity with what we were capable of not that long ago.
- xj9 8y ago
  the linux world is slowly (and badly) recreating technology that has existed in FreeBSD and Solaris/Illumos for decades.
  - taeric 8y ago
    Be fair here. The software world is slowly recreating technology. Being even more fair, they do often add to it. Usually UX capabilities, but sometimes full on features. Yes, often the features require more resources than were available before. Such that previous versions couldn't have offered some of these things. That said, it is not limited to any one set of our industry. It is likely not even limited to our industry.
    - redbeard0x0a 8y ago
      Software getting recreated, sometimes without the security promises (linux containers as they started vs. solaris zones) the previous solution had. To be fair, Google didn't really need the security in linux containers, they didn't run multi-tenant workloads, so it wasn't their top concern when submitting code to the linux kernel... We like building new things, from different angles, but in the end it seems like everything cycles through the same ideas.
tzakrajs 8y ago
Instead of the new Application Server, Kubernetes is the new OpenStack. A conglomeration of projects that support a platform for deploying and operating software in containers or virtual machines. Just like OpenStack, some of the components deal with storage, others with networking, and others still with service discovery or proxying. Without getting too far into semantics, I think the author is using a well overloaded terminology. When I hear Application Server, I immediately think tomcat or some other jvm.
sewercake 8y ago
We're in the process of migrating our (primarily) java services from straight AWS to kubernetes. At the beginning the author poses the following questions: * Do you use Mac, Windows, or Linux? Have you ever faced an issue related to \ versus / as the file path separator? What version of JDK do you use? Do you use Java 10 in development, but production uses JRE 8? Have you faced any bugs introduced by JVM differences? * What version of the application server do you use? Is the production environment using the same configuration, security patches, and library versions? * During production deployment, have you encountered a JDBC driver issue that you didn’t face in your development environment due to different versions of the driver or database server? * Have you ever asked the application server admin to create a datasource or a JMS queue and it had a typo? I've experienced problems whose root cause are some form of all of those. Much of it could be chalked up to growing pains etcetera, but, for example, there are concrete differences between docker versions running on mac and linux that have shown up for me. This doesn't reduce the author's argument, but they do seem liked strange examples. Our choice to move to Docker and kubernetes came from developers, and specifically spoke to the need for consistent, reproducible test environments. We had dockerized most applications many months before the notion of using them in production was put on the table. What remains to be seen is if the switches in production reduce complexity and maintenance on the devops end of things, as well. I'm also curious how many other organizations had containers introduced 'from the bottom up' like us.
- taeric 8y ago
  Honestly, most of the introduction I've seen has been bottom up or from new hires. I think there is a major point in having happy development environments. Happiness with tools is a very important point that is hard to quantify. https://www.johndcook.com/blog/2011/07/31/enjoyment-of-ones-tools/ https://www.johndcook.com/blog/2011/07/31/enjoyment-of-ones-... has a fun exploration of two great quotes on this vein. That said, if you can, I'd be ridiculously interested in a retrospective when you have a chance on your transition. Good luck with it!
- knesek 8y ago
  Hm. My team is running and developing a somewhat complex system based on jvm for years, and never encountered any of the issues in the bullet points. Having consistent test, staging and production environments produced by ansible have been working out for us (and is not hard). Are we just being lucky?
yobrobroprogr4m 8y ago
At least 50% of the neckbeard kvetching about containers is because they don't want to let go of their lovingly hand-crafted servers and mountains of bash scripts and config management crap that they've built over the past 20 years. edit: btw, I'm one of those (former) neckbeards...
- mirceal 8y ago
  that's funny. the same "neckbeards" that are "resisting" k8s have seen this scenario play out over an over and over again. It's very rare that someone actually comes up with something completely new. Usually what' new and exciting are refinements of trying the same ideas that were tried in the past (or changes in the "ecosystem" that enable technologies that were previously not feasible). my prediction is that k8s is NOT going to solve world hunger and it will slowly find its way into being a tool in the toolbelt. I am open to being proven wrong.
  - yobrobroprogr4m 8y ago
    It wasn't so much "this will solve world hunger" as much as it was "this thing that we built internally at Google ended up working out pretty well, here's a free and improved reimplementation of it that you can use".
- nafey 8y ago
  Although I disagree your post did make me laugh
- cphoover 8y ago
  could not agree more with you.
- rb808 8y ago
  Agreed. When people say k8s/docker is complicated, yes it is, but its simpler and more reliable than the shedload of custom build, config & deployment scripts I've seen in past systems.
- markbnj 8y ago
eecc 8y ago
Well, until someone develops and releases (and strangle all naysayers) a language independent thing remotely like JEE JNDI... it’s just not. Sorry, JEE was horrible but also so beautifully ahead of its time
- hyperman1 8y ago
  Unfortunately, JEE was horribly behind the times. A lot of the ideas came from the COBOL middleware world. Others were a remix of CORBA.
dkhenry 8y ago
I would say Kubernetes is becoming the new Application Server, but not for anything listed in the article. Kubernetes is more and more being sold to "enterprise" as a solution for running services much like Application servers were, and much like application servers the standard Kubernetes deployment is becoming a tangled mess of buzzwords and dreams, which work great in a demo, but won't work at all without an army of consultants.
- colechristensen 8y ago
  Very similar abstractions are being created over and over, if you are too close it is hard to see that the abstractions are largely the same, and the grand benefits being toted are actually quite small when comparing one to the other and the differences are just attitudes and a tiny bit of tooling that could be recreated for any of the abstractions.
  - taeric 8y ago
    It does get frustrating to lose tooling you previously had. Even more frustrating when some of the instrumentation that you take for granted in the old world is "TBD" in the new one.
    - threeseed 8y ago
      Instrumentation on Kubernetes is pretty incredible albeit complex. You have host, container, application and ingress level metrics. But via the mesh networking eg LinkerD detailed metrics of how containers are talking to each other. All of which roll into a single metrics server (Prometheus) and dashboard (Grafana).
      - taeric 8y ago
        Most of the instrumentation I have found myself losing have been at the application levels. And to be clear, most of them are still somewhere, but not nearly as well polished as in services we have not on containers. (I'm also primarily talking about a bunch of internal practices at my current job.)
fauigerzigerk 8y ago
Here's my prediction: DevOps is dead. In 5 to 10 years developers will no longer be mentioned in articles like this. There will be specialisation once again, because it makes absolutely no sense to make people whose main job it is to think about use cases, business logic and user interfaces to also deal with stuff like this.
- anothergoogler 8y ago
  What does "DevOps is dead" mean?
  - mandelbrotwurst 8y ago
    Seems he's essentially just predicting an increase in the division of labor between product development and infrastructure work going forward.
    - deleted 8y ago
      [deleted]
    - mancerayder 8y ago
      That's interesting, sounds like the world 5 years ago and before -- outside of the Netflix/Google/Facebook monoliths. Sounds like the landscape made systems so complicated via ease of automation that they don't know what's happening under the hood anymore. That's good news for consultants like myself. Sincerely, DevOps guy formerly known as SysEngineer formerly known as SysAdmin for 15+ years.
      - dsmithatx 8y ago
        If you know Ansible/Puppet/Chef K8s platform doesn't require a complicated mess of scripts to manage. Sincerly, Platform Engineer former DevOps guy, former SysEngineer, former SysAdmin for the past 24 years.
  - fauigerzigerk 8y ago
    That devs will no longer do ops.
humbleMouse 8y ago
I think what a lot of people forget is that this is being driven by costs. Companies don't want to pay for disaster recovery, and it's cheaper to set up a k8's platform. The platform itself performs disaster recovery, so now that's one less cost for the company. It's all about saving money on DR. When these companies realize that developers can't handle doing ops AND complex business logic, maybe they'll rethink it. Until then I expect this trend to spread rapidly as companies look for ways to abstract away DR costs.
- hodgesrm 8y ago
  Can you define what you mean by disaster recovery? To me it means the ability to recover business applications from a site failure. Assuming you have a similar definition how does Kubernetes solve that problem?
  - humbleMouse 8y ago
    What I mean by DR is that if a data center gets nuked, you still have a replica of your k8's platform running in your other data center(s). So k8's basically runs a replica of your whole system behind the scenes so if a physical location goes down you still have your system running.
    - hodgesrm 8y ago
      What about all the data in DBMS, file systems, object stores? Also what about BGP routes, firewall settings, SNAT/DNAT rules and the like? There's a lot more to replicate than just the bits in the apps.
      - SteveNuts 8y ago
        Those are the types of things developers simply don't have experience using. And if Kubernetes tries to replace all of those it will become the new OpenStack.
      - humbleMouse 8y ago
amdelamar 8y ago
As mentioned in the article, The EFK stack (Elasticsearch, Fluentd, Kibana) is great for unified logging. And its not just for OpenShift, its working wonders for our current project with Kubernetes on AWS.
- nikon 8y ago
  I find it a little heavy for log aggregation. LogDNA has been great for my K8s clusters, and is relatively cheap.
- gog 8y ago
  Could you give more details about why Fluentd and not Beats + Logstash on the other end? I don't like the idea of running Ruby on every machine just to ship logs somewhere. Beats are pretty lightweight and for what I used them they work.
  - mehblahwhatevs 8y ago
    Many people use the ELK stack which is Logstash. I imagine you can swap out Fluentd for Logstash.
rdsubhas 8y ago
I feel a bit alone here. The most obvious benefit of kubernetes is that It's an API. There is definitely a tooling angle, but the core disruption that kubernetes brings to the picture is, it allows to model infrastructure as an API. Take the standard cloud application stack: Every app needs an artifact (disk image), a running service, an instance template, a group of VMs running using those templates, networking and a load balancer. Before kubernetes, you had to automate by writing terraform scripts which mutate physical infrastructure as you apply. With kubernetes, you POST a bunch of well-defined resources (container spec for the service, pod spec for the instance, pod as a VM, deployment as the group of VMs, services and ingress for traffic). Every physical cloud resource has a clear API mapping. Basically you save in kubernetes what you need as a first-class API resource. And then, kubernetes responds to what you saved by changing infrastructure to match. You can do the same for practically any kind of infrastructure resources. Want an S3 bucket? Duh, POST a S3 bucket resource and you can write a controller to react and fulfil that bucket. Kubernetes comes with a built-in set of functionality that fulfils a certain core set of infrastructure using containers. But you are not restricted to that. In theory, you could POST a VM as a resource, or an Instance Group as a resource, and you can write a kubernetes controller to fulfil those resources. Why? Because APIs are more powerful than tools. APIs allow a different axis of infrastructure evolution, even if you distribute the control to everyone. By modeling these as APIs, you can bake in a huge amount of infrastructure intelligence into the API. Want to enforce different, code-driven resource-based policies, linting, sane defaults, organizational context? Yeah, make the controller do just that. If you just provide a tool to every engineering team, you basically lose any form of cross-cutting orchestration, and you lose the ability to evolve infrastructure in a separate axis independent of the tool that each team uses. Basically, kubernetes is "Infrastructure as an API". Thinking about it as a "new application server" kinda hides the whole point of it.
- sciurus 8y ago
  Before: Write HCL then run `terraform apply` After: Write YAML then run `kubectl apply` ;-)
  - moondev 8y ago
sheeshkebab 8y ago
The software world keeps on going in circles :). Next up - lightweight k8s server - stripped down of all the crap that can easily run and deploy a single container.
- marcus_holmes 8y ago
  yes, this. I'm just skipping the whole Docker thing this time around, and waiting until the circle turns and the herd decides that containers create too much complexity ;)
RickJWagner 8y ago
Hacker News paydirt!
ironjunkie 8y ago
I hope that the Kubernetes Steering committee will continue its good work to keep the Core tidy and simple. What really makes me afraid are the thousands of complex addons that are being pushed by the community (For example, Istio, Networking addons, etc etc). Those should be kept outside and it MUST be made clear they are definitely not needed for a normal installation of Kubernetes. Istio for example, is such a political brainwash power-move by some bigger companies that benefit from it. I believe less than 5% of the use-cases really require Istio, still it is being pushed as something you should always install in your cluster. This is bad for everyone.
true_tuna 8y ago
Meh
iKSv2 8y ago
Guys who have worked with Kubernetes and virtualization, I have a genuine personal question for you - I have been working as SysAdmin and then into virtualization (VMware / HyperV sort of things) and while natural progression in it says go for advanced VMware courses (related to Virtual machine and its concepts), do you think its better to switch lanes now to container-tech rather than some years down the line? I am totally 0 on Docker / Kubernetes / OpenStack (if thats related with containers).
- voltagex_ 8y ago
  FWIW coming from a Windows dev side of things, I'd have a look at Docker for Hyper-V (https://docs.docker.com/machine/drivers/hyper-v/ https://docs.docker.com/machine/drivers/hyper-v/) and just have a play with things. If you're still getting enough work as a sysadmin and enjoying it, I think "VMs" as a concept will still be around for a long time.
- clhodapp 8y ago
  At this point it is clear that this is a thing that will happen for a whole lot of orgs. You would be well advised to dabble at this point and see if it connects with you. At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation. That said, VMs and scripted/config-managed deployment will continue to be with us for the foreseeable future.
  - iKSv2 8y ago
    "At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation" Seriously, this is so embarrassing at the current point ( with me having absolutely 0 understanding of the concept)

281 points by rterzi 8y ago

Is this a response for the Jib announcement and the inevitable comments that followed? Sounds a lot like it is...

Sorry but this article implies that containers can solve issues like the difference between path separators on Windows and Linux. They can't even solve issues arising from differences in kernal versions, not to mention operating systems.

SriniK 8y ago
Did you consider http://kubevirt.io/ http://kubevirt.io/ ? It supposed to solve some of these hard limitations.
- pdimitar 8y ago
  This can work, but stacking framework on top of the framework is what made the classic application servers undesirable and a horrible mess to begin with. Observing similar patterns creeping in the Kubernetes culture and ecosystem does not inspire optimism in a side observer like myself.
lkrubner 8y ago
Nor does Docker protect against such obvious things as differences in versions of base images. Check out the Slack dialogue at the end of this: http://www.smashcompany.com/technology/docker-protects-a-programming-paradigm-that-we-should-get-rid-of http://www.smashcompany.com/technology/docker-protects-a-pro...
- foolzcrow 8y ago
  Why are you such a pussy? You flagged my Hillary Clinton is shit comment. You lost because your ideology is broken trash and I've been a lifelong Democrat so go let more Russians fuck your mom..#snowflake again I'm a lifelong Democrat and I'm going to vote against you
craftyguy 8y ago
Always use / Windows can, surprisingly, handle it just fine.
- JetSpiegel 8y ago
  On interactive uses, sure. But it's not clear cut, some code paths are lower level and bypass that.
  - craftyguy 8y ago
    Yea I guess most of my uses have been in things like python (e.g. open() and as.*). Got any examples of code paths that bypass that check and fail if you use /?
    - testvox 8y ago
      I think they are wrong and actually it's the opposite problem. Some applications and libraries that do their own path mangling on Windows will choke if you give them a /. The win32 file I/O API handles them correctly.
- lardo 8y ago
  I spent two hours scratching my head today because I had put "/path/to/thing/**" in a nuspec file instead of "\path\to\thing\**" The backslash was escaping the wildcard characters :(
- mkesper 8y ago
  Never use windows, why should you for development and deployment?

taeric 8y ago

It is hard not to build this impression of containers. Worse, it seems that the docker image format is massive compared to what most war files were like. This is annoying not just in terms of raw bytes to move around, but in taking stock of what is getting moved around. My team originally pitched how docker solved much of the dependency upgrade management by having layers for each major set of dependencies. That ignored the fact that upgrading a layer is not really something you do. So, then you can go around the path of coordinating many containers communicating with each other. That works, but in that world, things really don't seem any easier than the earlier alternatives. Harder, in many ways. Don't get me wrong, the momentum and raw money being put into containers certainly paints it as the future. It just feels like lying to say that they have even come close to parity with what we were capable of not that long ago.

xj9 8y ago
the linux world is slowly (and badly) recreating technology that has existed in FreeBSD and Solaris/Illumos for decades.
- taeric 8y ago
  Be fair here. The software world is slowly recreating technology. Being even more fair, they do often add to it. Usually UX capabilities, but sometimes full on features. Yes, often the features require more resources than were available before. Such that previous versions couldn't have offered some of these things. That said, it is not limited to any one set of our industry. It is likely not even limited to our industry.
  - redbeard0x0a 8y ago
    Software getting recreated, sometimes without the security promises (linux containers as they started vs. solaris zones) the previous solution had. To be fair, Google didn't really need the security in linux containers, they didn't run multi-tenant workloads, so it wasn't their top concern when submitting code to the linux kernel... We like building new things, from different angles, but in the end it seems like everything cycles through the same ideas.

tzakrajs 8y ago

Instead of the new Application Server, Kubernetes is the new OpenStack. A conglomeration of projects that support a platform for deploying and operating software in containers or virtual machines. Just like OpenStack, some of the components deal with storage, others with networking, and others still with service discovery or proxying. Without getting too far into semantics, I think the author is using a well overloaded terminology. When I hear Application Server, I immediately think tomcat or some other jvm.

sewercake 8y ago

We're in the process of migrating our (primarily) java services from straight AWS to kubernetes. At the beginning the author poses the following questions: * Do you use Mac, Windows, or Linux? Have you ever faced an issue related to \ versus / as the file path separator? What version of JDK do you use? Do you use Java 10 in development, but production uses JRE 8? Have you faced any bugs introduced by JVM differences? * What version of the application server do you use? Is the production environment using the same configuration, security patches, and library versions? * During production deployment, have you encountered a JDBC driver issue that you didn’t face in your development environment due to different versions of the driver or database server? * Have you ever asked the application server admin to create a datasource or a JMS queue and it had a typo? I've experienced problems whose root cause are some form of all of those. Much of it could be chalked up to growing pains etcetera, but, for example, there are concrete differences between docker versions running on mac and linux that have shown up for me. This doesn't reduce the author's argument, but they do seem liked strange examples. Our choice to move to Docker and kubernetes came from developers, and specifically spoke to the need for consistent, reproducible test environments. We had dockerized most applications many months before the notion of using them in production was put on the table. What remains to be seen is if the switches in production reduce complexity and maintenance on the devops end of things, as well. I'm also curious how many other organizations had containers introduced 'from the bottom up' like us.

taeric 8y ago
Honestly, most of the introduction I've seen has been bottom up or from new hires. I think there is a major point in having happy development environments. Happiness with tools is a very important point that is hard to quantify. https://www.johndcook.com/blog/2011/07/31/enjoyment-of-ones-tools/ https://www.johndcook.com/blog/2011/07/31/enjoyment-of-ones-... has a fun exploration of two great quotes on this vein. That said, if you can, I'd be ridiculously interested in a retrospective when you have a chance on your transition. Good luck with it!
knesek 8y ago
Hm. My team is running and developing a somewhat complex system based on jvm for years, and never encountered any of the issues in the bullet points. Having consistent test, staging and production environments produced by ansible have been working out for us (and is not hard). Are we just being lucky?

yobrobroprogr4m 8y ago

At least 50% of the neckbeard kvetching about containers is because they don't want to let go of their lovingly hand-crafted servers and mountains of bash scripts and config management crap that they've built over the past 20 years. edit: btw, I'm one of those (former) neckbeards...

mirceal 8y ago
that's funny. the same "neckbeards" that are "resisting" k8s have seen this scenario play out over an over and over again. It's very rare that someone actually comes up with something completely new. Usually what' new and exciting are refinements of trying the same ideas that were tried in the past (or changes in the "ecosystem" that enable technologies that were previously not feasible). my prediction is that k8s is NOT going to solve world hunger and it will slowly find its way into being a tool in the toolbelt. I am open to being proven wrong.
- yobrobroprogr4m 8y ago
  It wasn't so much "this will solve world hunger" as much as it was "this thing that we built internally at Google ended up working out pretty well, here's a free and improved reimplementation of it that you can use".
nafey 8y ago
Although I disagree your post did make me laugh
cphoover 8y ago
could not agree more with you.
rb808 8y ago
Agreed. When people say k8s/docker is complicated, yes it is, but its simpler and more reliable than the shedload of custom build, config & deployment scripts I've seen in past systems.
markbnj 8y ago

eecc 8y ago

Well, until someone develops and releases (and strangle all naysayers) a language independent thing remotely like JEE JNDI... it’s just not. Sorry, JEE was horrible but also so beautifully ahead of its time

hyperman1 8y ago
Unfortunately, JEE was horribly behind the times. A lot of the ideas came from the COBOL middleware world. Others were a remix of CORBA.

dkhenry 8y ago

I would say Kubernetes is becoming the new Application Server, but not for anything listed in the article. Kubernetes is more and more being sold to "enterprise" as a solution for running services much like Application servers were, and much like application servers the standard Kubernetes deployment is becoming a tangled mess of buzzwords and dreams, which work great in a demo, but won't work at all without an army of consultants.

colechristensen 8y ago
Very similar abstractions are being created over and over, if you are too close it is hard to see that the abstractions are largely the same, and the grand benefits being toted are actually quite small when comparing one to the other and the differences are just attitudes and a tiny bit of tooling that could be recreated for any of the abstractions.
- taeric 8y ago
  It does get frustrating to lose tooling you previously had. Even more frustrating when some of the instrumentation that you take for granted in the old world is "TBD" in the new one.
  - threeseed 8y ago
    Instrumentation on Kubernetes is pretty incredible albeit complex. You have host, container, application and ingress level metrics. But via the mesh networking eg LinkerD detailed metrics of how containers are talking to each other. All of which roll into a single metrics server (Prometheus) and dashboard (Grafana).
    - taeric 8y ago
      Most of the instrumentation I have found myself losing have been at the application levels. And to be clear, most of them are still somewhere, but not nearly as well polished as in services we have not on containers. (I'm also primarily talking about a bunch of internal practices at my current job.)

fauigerzigerk 8y ago

Here's my prediction: DevOps is dead. In 5 to 10 years developers will no longer be mentioned in articles like this. There will be specialisation once again, because it makes absolutely no sense to make people whose main job it is to think about use cases, business logic and user interfaces to also deal with stuff like this.

anothergoogler 8y ago
What does "DevOps is dead" mean?
- mandelbrotwurst 8y ago
  Seems he's essentially just predicting an increase in the division of labor between product development and infrastructure work going forward.
  - deleted 8y ago
    [deleted]
  - mancerayder 8y ago
    That's interesting, sounds like the world 5 years ago and before -- outside of the Netflix/Google/Facebook monoliths. Sounds like the landscape made systems so complicated via ease of automation that they don't know what's happening under the hood anymore. That's good news for consultants like myself. Sincerely, DevOps guy formerly known as SysEngineer formerly known as SysAdmin for 15+ years.
    - dsmithatx 8y ago
      If you know Ansible/Puppet/Chef K8s platform doesn't require a complicated mess of scripts to manage. Sincerly, Platform Engineer former DevOps guy, former SysEngineer, former SysAdmin for the past 24 years.
- fauigerzigerk 8y ago
  That devs will no longer do ops.

humbleMouse 8y ago

I think what a lot of people forget is that this is being driven by costs. Companies don't want to pay for disaster recovery, and it's cheaper to set up a k8's platform. The platform itself performs disaster recovery, so now that's one less cost for the company. It's all about saving money on DR. When these companies realize that developers can't handle doing ops AND complex business logic, maybe they'll rethink it. Until then I expect this trend to spread rapidly as companies look for ways to abstract away DR costs.

hodgesrm 8y ago
Can you define what you mean by disaster recovery? To me it means the ability to recover business applications from a site failure. Assuming you have a similar definition how does Kubernetes solve that problem?
- humbleMouse 8y ago
  What I mean by DR is that if a data center gets nuked, you still have a replica of your k8's platform running in your other data center(s). So k8's basically runs a replica of your whole system behind the scenes so if a physical location goes down you still have your system running.
  - hodgesrm 8y ago
    What about all the data in DBMS, file systems, object stores? Also what about BGP routes, firewall settings, SNAT/DNAT rules and the like? There's a lot more to replicate than just the bits in the apps.
    - SteveNuts 8y ago
      Those are the types of things developers simply don't have experience using. And if Kubernetes tries to replace all of those it will become the new OpenStack.
    - humbleMouse 8y ago

amdelamar 8y ago

As mentioned in the article, The EFK stack (Elasticsearch, Fluentd, Kibana) is great for unified logging. And its not just for OpenShift, its working wonders for our current project with Kubernetes on AWS.

nikon 8y ago
I find it a little heavy for log aggregation. LogDNA has been great for my K8s clusters, and is relatively cheap.
gog 8y ago
Could you give more details about why Fluentd and not Beats + Logstash on the other end? I don't like the idea of running Ruby on every machine just to ship logs somewhere. Beats are pretty lightweight and for what I used them they work.
- mehblahwhatevs 8y ago
  Many people use the ELK stack which is Logstash. I imagine you can swap out Fluentd for Logstash.

rdsubhas 8y ago

I feel a bit alone here. The most obvious benefit of kubernetes is that It's an API. There is definitely a tooling angle, but the core disruption that kubernetes brings to the picture is, it allows to model infrastructure as an API. Take the standard cloud application stack: Every app needs an artifact (disk image), a running service, an instance template, a group of VMs running using those templates, networking and a load balancer. Before kubernetes, you had to automate by writing terraform scripts which mutate physical infrastructure as you apply. With kubernetes, you POST a bunch of well-defined resources (container spec for the service, pod spec for the instance, pod as a VM, deployment as the group of VMs, services and ingress for traffic). Every physical cloud resource has a clear API mapping. Basically you save in kubernetes what you need as a first-class API resource. And then, kubernetes responds to what you saved by changing infrastructure to match. You can do the same for practically any kind of infrastructure resources. Want an S3 bucket? Duh, POST a S3 bucket resource and you can write a controller to react and fulfil that bucket. Kubernetes comes with a built-in set of functionality that fulfils a certain core set of infrastructure using containers. But you are not restricted to that. In theory, you could POST a VM as a resource, or an Instance Group as a resource, and you can write a kubernetes controller to fulfil those resources. Why? Because APIs are more powerful than tools. APIs allow a different axis of infrastructure evolution, even if you distribute the control to everyone. By modeling these as APIs, you can bake in a huge amount of infrastructure intelligence into the API. Want to enforce different, code-driven resource-based policies, linting, sane defaults, organizational context? Yeah, make the controller do just that. If you just provide a tool to every engineering team, you basically lose any form of cross-cutting orchestration, and you lose the ability to evolve infrastructure in a separate axis independent of the tool that each team uses. Basically, kubernetes is "Infrastructure as an API". Thinking about it as a "new application server" kinda hides the whole point of it.

sciurus 8y ago
Before: Write HCL then run `terraform apply` After: Write YAML then run `kubectl apply` ;-)
- moondev 8y ago

sheeshkebab 8y ago

The software world keeps on going in circles :). Next up - lightweight k8s server - stripped down of all the crap that can easily run and deploy a single container.

marcus_holmes 8y ago
yes, this. I'm just skipping the whole Docker thing this time around, and waiting until the circle turns and the herd decides that containers create too much complexity ;)

RickJWagner 8y ago

Hacker News paydirt!

ironjunkie 8y ago

I hope that the Kubernetes Steering committee will continue its good work to keep the Core tidy and simple. What really makes me afraid are the thousands of complex addons that are being pushed by the community (For example, Istio, Networking addons, etc etc). Those should be kept outside and it MUST be made clear they are definitely not needed for a normal installation of Kubernetes. Istio for example, is such a political brainwash power-move by some bigger companies that benefit from it. I believe less than 5% of the use-cases really require Istio, still it is being pushed as something you should always install in your cluster. This is bad for everyone.

true_tuna 8y ago

Meh

iKSv2 8y ago

Guys who have worked with Kubernetes and virtualization, I have a genuine personal question for you - I have been working as SysAdmin and then into virtualization (VMware / HyperV sort of things) and while natural progression in it says go for advanced VMware courses (related to Virtual machine and its concepts), do you think its better to switch lanes now to container-tech rather than some years down the line? I am totally 0 on Docker / Kubernetes / OpenStack (if thats related with containers).

voltagex_ 8y ago
FWIW coming from a Windows dev side of things, I'd have a look at Docker for Hyper-V (https://docs.docker.com/machine/drivers/hyper-v/ https://docs.docker.com/machine/drivers/hyper-v/) and just have a play with things. If you're still getting enough work as a sysadmin and enjoying it, I think "VMs" as a concept will still be around for a long time.
clhodapp 8y ago
At this point it is clear that this is a thing that will happen for a whole lot of orgs. You would be well advised to dabble at this point and see if it connects with you. At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation. That said, VMs and scripted/config-managed deployment will continue to be with us for the foreseeable future.
- iKSv2 8y ago
  "At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation" Seriously, this is so embarrassing at the current point ( with me having absolutely 0 understanding of the concept)