Earlier quoted context omitted.
I don't think anybody is suggesting containers are bad for ephemeral exploration, development, the things you mention. The argument is what you use it for when it comes to production. For example if you're modeling machines with docker you're already using it wrong. Even docker considers that an anti-pattern.
I've invested some time to learn about best practices and have been using docker in production for many months with completely satisfactory results. I am not seeing a rational discussion here.
Ex VMware, Microsoft and Citrix workers set up application container company
31–40 of 59 posts
Re: Ex VMware, Microsoft and Citrix workers set up application container company
#32> Container hype is running high. Developers have flocked to the technology for more easily packaging applications and running them across various disparate environments. It's a hype that should die in a fire bigger than the one reserved for Adobe Flash. Many people will think they can just deploy a shitload of containers and be done... well, each and every single one of them has to be maintained, updated for securit…
It's no longer building some servers that run and putting somebody else's code on it. Instead, it's working closely with the team producing code and helping build a mature deployment and management capability. It's about being a responsible expert on the bits outside of the application process.
Containers help immensely here because they recognise that a product is composed of more than just an application and they have lowered the barrier of entry to making the system of parts as a whole cooperate.
As part of this change there will of course be quality issues. Classically trained developers will produce poor quality container images, just as classically trained sysadmins produce poor quality apps.
This initial hump will pass as new tools are introduced to assist with this and as people learn the skills they need to produce higher quality images.
If you have the skills, invest your time in helping this process along rather that raging at the fact you work in an industry where change is disruptive and constant.
Re: Ex VMware, Microsoft and Citrix workers set up application container company
#33Earlier quoted context omitted.
I don't think anybody is suggesting containers are bad for ephemeral exploration, development, the things you mention. The argument is what you use it for when it comes to production. For example if you're modeling machines with docker you're already using it wrong. Even docker considers that an anti-pattern.
I've invested some time to learn about best practices and have been using docker in production for many months with completely satisfactory results. I am not seeing a rational discussion here.
Re: Ex VMware, Microsoft and Citrix workers set up application container company
#34Docker is a tool which was built for platform-as-a-service/DevOps people who had to manage complex systems made up of many different technologies which those DevOps people didn't want to think about. It provides a relatively clean encapsulation of complex logic.
With microservices, the idea is to break up your complex system into independent services which each perform a specific task. I think an implied goal of microservices is that each individual service should be made up of relatively few technologies - If each microservice is made up of few technologies, it's really easy and fast to just git pull the relevant changes (or update from your package manager) and relaunch your service.
I would like it if someone could explain it to me why I need to pull something from DockerHub instead of GitHub (assuming that you have a simple microservice made up of a single, cohesive technology stack which you actually understand and builds relatively quickly)?
Re: Ex VMware, Microsoft and Citrix workers set up application container company
#35> Container hype is running high. Developers have flocked to the technology for more easily packaging applications and running them across various disparate environments. It's a hype that should die in a fire bigger than the one reserved for Adobe Flash. Many people will think they can just deploy a shitload of containers and be done... well, each and every single one of them has to be maintained, updated for securit…
These are great point, but as someone who is beginning to think what I can do with containers for my current infrastructure setup, so far my impression is container is not to change the infrastructure, but rather how compute is used. The meaning and the life cycle of container are no different from having a big virtual machine image, but container technology such as docker has been made blazing quick to start and kil…
Re: Ex VMware, Microsoft and Citrix workers set up application container company
#36Re: Ex VMware, Microsoft and Citrix workers set up application container company
#37> Container hype is running high. Developers have flocked to the technology for more easily packaging applications and running them across various disparate environments. It's a hype that should die in a fire bigger than the one reserved for Adobe Flash. Many people will think they can just deploy a shitload of containers and be done... well, each and every single one of them has to be maintained, updated for securit…
Then you patch it by redeploying it.
> Not to mention the likely possibility of breaking API changes in the container version. vagrant/puppet I'm looking at you, nothing is worse than having to figure out which ancient version of vagrant and puppet was used at creation in order to get the system running again
Is this a real issue that people run into? I've never had any issues with this.
> Or, well, look five years in the future, and hope today's hyped container solution will still be present then.
Good thing the real work essentially boils down to some scripts which can be easily translated into any new technology
> Fuck containers, get a properly managed ordinary Debian server and save yourself a lot of headaches.
Spotted the Debian sys admin!
Re: Ex VMware, Microsoft and Citrix workers set up application container company
#38Earlier quoted context omitted.
It's hard to take your criticism seriously when Google, Netflix, Heroku, Shopify, Paypal, Uber, Ebay, Yelp, Spotify don't qualify as "sane" orgs according to your criteria.
All the companies you name have significant engineering manpower to dedicate whole teams to maintain all the tooling so that the devteams don't need to worry about maintaining their containers, VMs and whatnot. I dare say that all that microservice stuff only works with 300+ employees if you keep everything containerized.
Re: Ex VMware, Microsoft and Citrix workers set up application container company
#39> Container hype is running high. Developers have flocked to the technology for more easily packaging applications and running them across various disparate environments. It's a hype that should die in a fire bigger than the one reserved for Adobe Flash. Many people will think they can just deploy a shitload of containers and be done... well, each and every single one of them has to be maintained, updated for securit…
> Many people will think they can just deploy a shitload of containers and be done... well, each and every single one of them has to be maintained, updated for security fixes... Do you apply the same kind of reasoning to virtual machines, and reach the conclusion that a single massive mainframe is the optimal configuration?
Re: Ex VMware, Microsoft and Citrix workers set up application container company
#40Earlier quoted context omitted.
Something I think a lot of people struggle with, both on the Dev side and the Ops side, is to think of VMs and containers as completely disposable. Does it add value, or help you, for you to have an emotional attachment to this server? Instead of doing OS updates, application updates, code updates, and configuration updates to 50 identical webservers that live behind load balancers, it might be faster to upgrade one.…
Puppet/Chef and general admin automation scripts handle the updates/config changes/etc... very easily without the added complexity of container management/orchestration.
Containerization is now letting individual teams manage app-specific configuration they actually understand and can test and iterate. A central org maintains the base image and can redeploy our containers with OS-level fixes as necessary. Our "self-service" deployment infrastructure was a behemoth that no one understood, documented by tribal knowledge. At less I can Google how to use the Docker API.